License Compatibility and the Direction of Relicensing

Compatibility is a question about a distribution, not about a repository. Nobody needs permission to keep two differently licensed directories on their own disk. The question appears when the parts are combined into something that is distributed as a unit, because the distributed unit exercises copyright in all its inputs at once and therefore has to satisfy the conditions of every license that covers any part of it. Conditions accumulate; there is no mechanism by which one license cancels another. The effective terms of a combined artifact are the intersection of its inputs’ terms, and an intersection can be empty.

That framing is what makes the direction of a combination matter. The practical rule survives because licenses differ mainly in how many conditions they attach to redistribution, and a stricter license can absorb the works of a laxer one while the reverse has no answer.

Why the direction is one-way

Consider permissive code moving into a copyleft project. The permissive license requires that redistributed copies carry the copyright notice and the disclaimer, and permits derivative works to be distributed under other terms. A GPL distribution satisfies the notice requirement, because the GPL itself obliges a distributor to keep notices intact, and the GPL’s condition on the whole work is the one the permissive license already allowed someone else to impose. The combination is distributable, with the whole work under the GPL.

Now reverse it. Copyleft code moved into a project that presents itself as permissively licensed. The distributor of the combination must license the copyleft-derived portion under the copyleft terms, so the combined artifact cannot be distributed under permissive terms alone: recipients receive, for that portion, obligations the project’s own label does not mention. Nothing here is forbidden in the sense of being illegal to attempt; the failure is that the project’s stated license is then false, and every recipient who relied on it and redistributed further has redistributed without a grant for the copyleft part. The asymmetry is not a convention adopted by the licenses. It follows from which license has slack to absorb the other.

The permissive licenses that permit sublicensing make this explicit in their grant. The MIT text grants the right to use, copy, modify, merge, publish, distribute and sublicense, with the single condition that the notice and permission text accompany the copies; that formulation imposes no constraint on the license chosen for the derivative, which is precisely the slack the GPL consumes.

The patent clause that stops a combination cold

Permissive licenses without a patent grant are quiet about patents, and quietness composes easily. The Apache License 2.0 is not quiet, and its patent terms are the historically decisive incompatibility. Section 3 grants every recipient a patent license covering the contributor’s patent claims that the work necessarily infringes, and withdraws that grant from anyone who institutes patent litigation alleging that the work infringes. The withdrawal is a condition on the recipient’s ongoing permission, so the combination carries a restriction the GPL version 2 does not contemplate: version 2 grants its permissions and then forbids imposing further restrictions on recipients, with no enumerated list of extra terms it tolerates. The Free Software Foundation’s published position follows from that structure: Apache-licensed code can be combined with GPL version 3, whose patent grant and list of permitted additional terms were written with clauses of this shape in view, but not with GPL version 2.

The same mechanism blocks version pairs inside one family. A component released under version 2 only, with no grant of later versions, cannot be merged into a work distributed under version 3, because the version 2 condition on the whole work and the version 3 condition cannot both hold. A component released under version 2 or any later version can be taken under version 3 by any distributor, which is why the wording of that phrase in a file header, discussed in what a license does to a copyright default, determines whether a project has an upgrade path at all.

Middle-scope licenses as compatibility engineering

Two families exist to make combinations easier without abandoning copyleft, and both work by narrowing the unit to which the copyleft condition attaches. The LGPL applies its condition at the library boundary: a larger work may be distributed under terms of the distributor’s choosing if the library’s source is available and the recipient can relink, and because LGPL version 3 is written as additional permissions layered on the GPL, a recipient may discard those permissions and treat the code under plain GPL version 3 terms. That makes LGPL code usable both in closed products and in GPL projects, the combination discussed in how copyleft travels through derivative works.

The MPL licenses apply the condition per file. Only modified covered files must stay under the MPL and have their source published; the larger work may be distributed under other terms. The MPL 2.0 goes further and defines a secondary-license mechanism, carried in an exhibit in the license text, by which the original author may declare that covered source may also be distributed under a named license from the GPL family. When that declaration is present, the file no longer blocks the combination, and the artifact can be distributed under a single GPL-family license. The EPL 2.0 adopted a comparable secondary-license provision for the same reason: a file-scoped copyleft license that cannot reach the GPL family runs into a wall whenever it meets GPL code.

Component license	Into a GPLv2 distribution	Into a GPLv3 distribution	Into a permissive distribution
MIT / ISC / BSD-2/3	yes	yes	yes
Apache-2.0	blocked by its patent terms	yes	yes
MPL-2.0	per file, only with secondary-license designation	same	yes, covered files keep the MPL
LGPL-3.0	no, version mismatch	yes	yes
GPL-2.0-only	yes	no	no, label would be false
GPL-3.0-only	no	yes	no

The table describes the direction of a merge, not the reverse. Every “yes” is a statement that a distribution can satisfy both sets of conditions; every “no” is a statement that some condition of one license cannot hold while another holds.

Compatibility is a property of a distribution, not of a license

The same pair of licenses can be combinable in one deployment and not in another, because the conditions attach to the acts the distributor performs. A program that links a copyleft library and a permissive library into one executable presents the combined-work question for both; two programs that talk to each other over a socket present it for neither, since the distributor is shipping two works rather than one. Internal build tools under a copyleft license are a separate matter again: a compiler or generator that is used but not distributed imposes nothing on the artifact, because use is not distribution, as the earlier discussion of copyleft scope established.

Artifacts therefore have to be classified before licenses are compared. A statically linked binary, a container image that resolves dependencies at build time, a firmware image with a bundled toolchain, and a language-level package that merely declares a dependency each produce a different set of covered works, and the compatibility table applies to the set that is actually conveyed rather than to the manifest. Tools that compare license strings without looking at link relationships answer a narrower question than the one that matters, and produce both false alarms, where a workspace dependency never reaches a shipped artifact, and missed conflicts, where a vendored component is compiled into the output.

There is one constructive trick the licenses themselves provide. A library offered under two licenses at once, a permissive one and a copyleft one, can be taken under the permissive terms by a distributor who needs to combine it with closed code, and under the copyleft terms by a distributor who wants the reciprocal conditions to apply downstream. Grants that offer a choice are not indecision: they are the mechanism by which one codebase serves both kinds of consumer, and they exist because the alternative was maintaining two forks.

Reading a mixed tree, and the mistakes that survive review

The recurring error in practice is copy-paste across a license boundary in the absorbing direction. A function lifted from a copyleft project into a proprietary one carries its conditions into the whole program, because the copied code is part of a work based on the original. The reverse error is slower and more expensive: a project labelled permissively that vendors a copyleft dependency, or links one statically, discovering the problem only when a scanner reports it or a recipient asks for source. Neither error is visible in the project’s own files; both are visible in the resolved build graph, which is where shipping binaries under copyleft obligations puts the audit trail.

A third class of error is catalogue drift, where the declared license of a package and the licenses of its files disagree. The label is a claim made by whoever wrote the manifest, and it is worth exactly as much as the provenance behind it, which is why license metadata is now carried per file and per package in a machine-readable form rather than as prose. The corresponding mistakes about that representation are covered under license expressions.

There is a final constraint that no license text can relax. If a combination is genuinely impossible, the options are to remove the offending component, to replace it with an alternative written under compatible terms, or to change the license of one side. The last option requires the consent of everyone holding copyright in it, and the mechanics of obtaining that consent are what make license migration expensive rather than administrative, as covered in relicensing a mature project.