What triggers an obligation
This is the page that explains why the same licence changes nature entirely from one product to the next. Eight mechanisms, of which three decide most of the outcome.
1. Distribution — the principal mechanism
Almost every copyleft obligation is conditioned on transmitting the software to a third party. GPL-3.0 calls this conveying: any act that enables someone else to make or receive copies.
This is distribution:
- shipping a binary, an installer, a package, a firmware image;
- publishing a container image to a registry, even a private one a third party can reach;
- serving JavaScript to a browser — it is code, and it changes hands;
- providing a virtual appliance or a machine image;
- deploying at a customer’s site, on-premises;
- transferring to another legal entity in the group: a subsidiary is a third party.
This is not distribution:
- running the software on your own servers to deliver a service;
- using it internally, including by thousands of employees;
- moving it between your own machines.
The most counter-intuitive consequence in free software law: you can build an entire online service on GPL code without any obligation to publish anything. This is the “service provider loophole”, and it is precisely what the AGPL was written to close.
2. Network interaction
Specific to AGPL-3.0 and OSL-3.0. The obligation arises from remote use, with no binary changing hands.
Three cumulative conditions under AGPL section 13:
- the program has been modified — or combined with your code, which amounts to the same;
- users interact with it remotely over a network;
- your version supports that interaction.
The nuance about unmodified versions is covered in The families. Keep the working rule: in an exposed service, an AGPL component must be treated as a trigger unless the contrary is demonstrated and documented.
3. Derivative and combined works
This is the most contested question in the field, and it must be said plainly: it has no settled European case law for software.
Copyleft propagates only to what constitutes a derivative work under copyright. What counts as one is the question.
Where there is consensus:
- modifying a component’s source creates a derivative work;
- copying a substantial portion of code into your file creates a derivative work;
- placing two independent programs side by side does not (see mere aggregation).
Where there is no consensus: linking. The Free Software Foundation holds, in its GPL FAQ, that linking a program to a library, statically or dynamically, creates a combined work subject to copyleft. That position is the licence author’s interpretation, not positive law; part of the doctrine disputes it, particularly for dynamic linking through a stable public interface.
The criteria usually applied, from most to least contaminating:
| Situation | Prevailing analysis |
|---|---|
| Code copied into your file | Derivative work, no debate |
| Static linking | Combined work on the majority reading |
| Dynamic linking, shared data structures, intimate calls | Combined work per the FSF, contested |
| Dynamic linking through a stable, documented interface | Grey zone |
| Separate processes over a pipe, socket or HTTP | Generally not a derivative work |
| Running a program as a subprocess | Generally not a derivative work |
The engineering consequence. Where a strong-copyleft component is indispensable and you want to protect the rest of the code, the classic remedy is to isolate it in a separate process communicating over a network or command-line interface. This is not a lawyer’s trick: it is an architectural decision, to be taken early and documented as such.
4. Mere aggregation
Placing several independent programs on the same distribution medium does not create a derivative work. The GPL says so expressly.
Examples of aggregation, therefore no contamination:
- a Linux distribution shipping thousands of packages under different licences side by side;
- a container image holding your application and, separately, GPL system utilities;
- an installer dropping several independent executables.
The limit: aggregation ends as soon as there is combination. An image containing a GPL binary your application merely executes is still aggregation. The same image where your application links to a GPL library is not.
Each aggregated component keeps its own obligations: aggregation removes neither the attribution duty nor the source obligation for the GPL components present.
5. Static versus dynamic linking
Decisive for the LGPL, and for it alone.
The LGPL allows a proprietary application to use the library, provided the user can replace it with a modified version and have the application run with it.
| Mode | What you must supply |
|---|---|
| Dynamic linking | Nothing more: the user swaps the shared library. The natural mode. |
| Static linking | Your application’s object files, or any equivalent means allowing the user to relink against their own build of the library. |
The blind spot: many modern ecosystems only know static linking — Go, Rust, JavaScript bundles, mobile apps, most firmware. In those contexts the replacement condition is unreachable in practice, and the LGPL must be treated as strong copyleft.
6. Consumer products and installation information
Specific to GPL-3.0 and LGPL-3.0, section 6 — the “anti-tivoization” clause.
If the software is distributed inside a consumer product, you must supply the Installation Information: the methods, procedures, authorisation keys or other information required to install and execute a modified version on that product.
In other words: if the device refuses to boot software the user has modified, you are not complying with GPL-3.0.
This is the mechanism that makes GPL-3.0 problematic in locked-down embedded systems and on platforms with mandatory code signing — and it explains why so many embedded projects deliberately remain on GPL-2.0. See Embedded / IoT.
7. Technological protection measures
GPL-3.0, section 3: the covered work shall not be deemed part of an effective technological measure, and you waive the power to forbid circumvention.
Direct consequence: a GPL-3.0 component cannot take part in a digital rights management scheme. A recurring friction point with app distribution platforms and set-top boxes.
8. Patent clauses and their termination
Present in Apache-2.0 (section 3), GPL-3.0 (section 11), MPL-2.0 (section 2.1(b)), EPL-2.0.
Two effects, usually invisible to engineering teams:
- a grant: contributors license you their patents covering their contribution;
- a termination: if you bring patent infringement litigation against a contributor over the software, you lose that grant, and sometimes the whole licence.
For a company holding a patent portfolio, that second clause is a subject in itself: it can neutralise a litigation strategy. It belongs to the legal department, not to the team choosing the library.
Summary table
Which mechanism triggers which family:
| Mechanism | Permissive | MPL / EPL | LGPL | GPL | AGPL |
|---|---|---|---|---|---|
| Internal use, no transmission | — | — | — | — | — |
| Network exposure, no transmission | — | — | — | — | ✔ |
| Binary distribution | Attribution | Modified files | Library + replacement | Whole work | Whole work |
| Static linking | — | — | ✔ object files | ✔ | ✔ |
| Locked-down consumer product | — | — | ✔ in v3 | ✔ in v3 | ✔ |
| Patent infringement action | Apache: termination | Termination | v3: termination | v3: termination | Termination |
What to do with this
Before approving a component, three questions handle 90 % of cases:
- Will this component leave the company in executable form?
- Will it be exposed to users over a network?
- Will it be linked to your code, and how?
The answers identify the applicable scenario, and the scenario gives the verdict.