How Copyleft Travels Through Derivative Works

Copyleft is a condition attached to the act of distribution. The GPL does not restrict what a program does, who may run it, or where it runs; it restricts what a distributor may do with copies. Reading the license as a restriction on use is the single most common source of mistaken conclusions about it, because the word “license” invites the assumption that permission must be sought for everything rather than for the enumerated acts.

The condition has two moving parts. First, a scope: which works count as works based on the original. Second, an obligation: what must accompany a distribution of such a work. Most of the argument, historically and now, is about the first part, because the license defines it by reference to copyright law and then adds a sentence that tries to limit it.

Where the trigger sits: conveying, not running

The GPL version 2 states that the license applies to “any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License”, and defines a work based on the program as the program itself or any derivative work under copyright law. The same section then adds the sentence that bounds the whole design: mere aggregation of another work not based on the program, placed on the same volume of a storage or distribution medium, does not bring that other work under the license.

That sentence is why a distribution image can contain GPL programs and proprietary programs without the proprietary ones becoming GPL. Placement on shared media is not the test. The test is whether the other work is a derivative work of the GPL program, or is combined with it into a single work.

Version 3 replaces the implied distinction with defined verbs. To propagate a work is to do anything with it that, without permission, would infringe copyright, excluding running it and making private modifications. To convey is propagation that enables other parties to make or receive copies. Private modification and private use are propagation but not conveyance, so they carry no source obligation; handing a modified binary to a customer is conveyance and carries the full set. This is the mechanism that makes the license harmless for internal use and demanding at the moment of shipment.

The link boundary, and the licenses invented to move it

The unresolved question is a combined work. Linking a GPL library into another program, whether at compile time or by loading it into the same address space at run time, produces something that shares data structures and function calls with the library, and the FSF’s published interpretation is that the result is a single work and the whole of it falls under the GPL. Static linking is the clear case. Dynamic linking against a shared library is treated in that interpretation as still creating a combined work, while invoking a separate program as a subprocess or exchanging data through a pipe or a file is treated as aggregation rather than combination. The interpretation is documented and consistent, but it is an interpretation: no clause of the license text converts a linking technique into a legal conclusion, and the underlying question remains what copyright law calls a derivative work.

The GNU Lesser General Public License exists to relax exactly this. Version 3 of the LGPL is not a standalone document: it grants additional permissions on top of the GPL, permitting a larger work to be distributed under terms of the distributor’s choosing provided the library’s own source remains available and the recipient can relink the larger work against a modified library. Satisfying that in practice usually means supplying the library source, the object files or build inputs needed to relink, and, for a program developed against the library, the ability to substitute a different version. Dynamic linking against a shared library that the user can replace is the common way to meet the relinking condition without exposing the surrounding program’s source.

The Mozilla Public License 2.0 attacks the same boundary from a different direction: its copyleft is file-scoped. Modifications to a covered file must remain under the MPL and their source must be available, while the larger work may be distributed under other terms, including proprietary ones. That design makes a library usable inside a closed product without the relinking apparatus, at the cost of leaving the rest of the product outside copyleft altogether.

What conveying a binary obliges a distributor to supply

The obligation is stated as a menu, and the menu has been stable in shape across both versions. Version 2 permits distribution of an executable if the distributor accompanies it with the complete corresponding machine-readable source on the same medium, or accompanies it with a written offer, valid for at least three years, to give any third party a machine-readable copy of the corresponding source for no more than the cost of performing the distribution, or passes along an offer that the distributor itself received. The written-offer route is restricted to noncommercial distribution; a commercial distributor that does not ship source must have received an offer it can pass through, or ship under the first option.

“Corresponding source” is wider than the files the distributor edited. Version 3 defines it as all the source needed to generate, install, and run the object code, including the scripts that control compilation and installation of the object code, plus the source for shared libraries and dynamically linked subprograms the object code is designed to require, with an exception for system libraries and for general-purpose tools that are not part of the work. Build scripts are therefore part of the obligation, which is why the tarball kept for compliance reasons is the build tree rather than the release tarball.

# A compliance archive has to reproduce the shipped artifact, not just contain
# the upstream release. The build tree, the patches, and the build inputs matter.
make distclean && make -f release.mk      # scripts used to control compilation
sha256sum out/app                          # the exact binary that was shipped
git diff --stat v1.4..build-42             # the local modifications

A written offer that names a contact address that no longer accepts mail, or a source archive that no longer builds the binary it claims to accompany, satisfies the letter of the clause only until someone asks.

How the distinction was sharpened between versions

The three published versions of the GPL differ in how much of this boundary they spell out, and the differences are worth separating from the compatibility rules that govern mixing versions. The first version, published in 1989, established the pattern of a license that binds the whole of a distributed work and requires source to accompany binaries, and the second, published in 1991, kept that structure while adding the aggregation sentence that keeps unrelated programs on the same medium outside the condition.

The third version, published in 2007, replaces inference with definitions. Propagate and convey give the license its own vocabulary for the acts that trigger obligations, so that private modification and private use are classified rather than left to be argued about, and conveying is distinguished from propagating precisely because only the former reaches other people. The corresponding source definition grows to include the scripts that control compilation and installation and the source of the shared libraries an executable requires, which closed a gap that distributors had exploited by shipping a tarball that could not reproduce the binary. The same version adds the requirement about installation information for software in consumer devices, aimed at hardware that refuses to run a modified version, and it subsumes the network-interaction clause that had been written for a web service license into a separate Affero variant.

Failure modes at the edges

Three edge cases recur. The first is the front end of the build process: a build step that fetches a copyleft component at compile time and statically links it into an artifact nobody classified as copyleft. The obligation attaches to the artifact that was distributed, and the dependency graph recorded in a manifest is usually narrower than what the build actually consumed, a mismatch taken up in compliance for shipped binaries.

The second is the service boundary. Providing access to a program over a network is not distribution under version 2 and not conveying under version 3, so an operator who modifies a GPL program and lets users interact with it remotely owes no source to those users. The Affero GPL closes this deliberately: its section on remote network interaction requires that users interacting with a modified version over a network be offered the corresponding source. Projects that adopt it do so to remove the server loophole; projects that reject it do so because the same clause reaches deployments that never ship a binary at all.

The third is the version boundary itself, where a work derived from a library that cannot be relicensed meets a project that adopted a later license. Redistribution of a combination requires satisfying every license in it, so a component licensed under version 2 only, with no “or later” grant, blocks a move to version 3 on both sides of the combination. That interaction, and the direction in which licenses can be mixed, is the subject of license compatibility.