Desktop or command-line application

An executable downloaded and installed by the user, on Windows, macOS or Linux. A command-line tool, a graphical application, an installer.

What actually happens

Question Answer
Does a third party receive the software in executable form? Yes — that is the definition
Does a third party interact with it over a network? No, unless an embedded server component
Is the product a locked-down consumer good? Generally no: the user controls their machine
Is the component linked to your code? Often, and the linking mode is yours to choose

This is the scenario the GPL was written for. The obligations are full, but they are known, bounded and tractable.

The verdict per family

Family Verdict Reason
Permissive Attribution owed, to ship with the product
Weak copyleft, file (MPL, EPL) Publish modified files; your code stays private
Weak copyleft, library (LGPL) Workable with dynamic linking; costly statically
Strong copyleft (GPL) Full duty to supply the source of the distributed work. Possible if accepted
Network copyleft (AGPL) Behaves like the GPL here; section 13 adds to it if the app exposes a service
Source-available Usage restrictions incompatible with broad distribution

Dynamic linking, an architectural decision

This is the main lever in this scenario. With dynamic linking the LGPL is satisfied with nothing further: the user can swap the shared library.

Platform Dynamic linking
Linux Natural — .so, package dependencies
Windows Natural — .dll
macOS Natural — .dylib, but code signing and notarisation complicate replacement
Go or Rust binary, “portable” application Impossible in practice: everything is static

The last case matters: shipping a static Go binary containing an LGPL library means owing the object files needed to relink. Few teams do it, and it is a silent non-compliance.

What “supply the source” means in practice

For a distributed GPL component, the corresponding source comprises:

  • the work’s source code, including your modifications;
  • the build and installation scripts;
  • interface definition files and generation scripts;
  • everything needed to regenerate and install the executable.

Two possible arrangements:

Arrangement Constraint
Ship the source with the binary The simplest: an archive next to the download
Provide a written offer to supply the source GPL-2.0: valid for three years after the last distribution; GPL-3.0: at least as long as spare parts are offered

The written offer looks lighter, but it creates a long archiving duty: you must be able to regenerate, three years later, the exact version shipped. That is precisely the support period problem under the CRA — and therefore the same solution.

Pitfalls in this scenario

The installer bundling third-party libraries. Each component keeps its licence. An installer is not a single work: it is most often mere aggregation, which is good news — but every component keeps its own obligations.

The unfindable attribution file. On a desktop, attribution must be reachable by the user: an About box, a shipped file, a menu entry. A NOTICE file buried in an archive is not a serious provision.

The component invoked as a subprocess. Calling a GPL executable from your application generally does not create a derivative work — but if you distribute it with your product, you are distributing GPL code and the source obligation applies to that component.

Updates. Every new version distributed is a new distribution, with its own obligations. The corresponding source must track versions.

macOS and notarisation. Mandatory signing raises no GPL-3.0 issue on a general-purpose computer — it is not a locked-down “consumer product” under section 6, since the user can disable the checks. The question does arise for dedicated hardware.

What the CRA adds

A distributed application is a fully fledged product with digital elements: technical documentation, SBOM, support period, CE marking, coordinated disclosure.

The happy overlap: the corresponding source to retain for the GPL and the ability to rebuild required by the support period are the same artefact. A well-designed archive serves both — see Evidence retention.