license.gen

Guides · 07

License Compatibility Basics

What license compatibility is, why it only works in one direction, and a summary of common pairs: Apache-2.0 and the GPL, MPL-2.0 Secondary Licenses, LGPL linking conditions and combining with the AGPL.

Last checked: 2026-09-23

Compatibility means "can they be distributed together?"

Two licenses are compatible if, when code under each is combined and distributed as a single program, the conditions of both licenses can be met at the same time. If either license forbids a condition of the other, they are incompatible. For example, the GPL requires that no further restrictions be added, so code under a license with additional conditions the GPL does not permit cannot go into a GPL program.

Compatibility has a direction

Permissive code can go into copyleft projects, but not the other way around.

That is why a compatibility table must always be read as "which code → into which project".

Common combinations

Apache-2.0 and the GPL

The FSF considers Apache-2.0 compatible with GPL-3.0 but not with GPL-2.0, because Apache-2.0's patent termination and indemnification clauses are additional conditions not found in GPL-2.0. GPL-3.0 was designed to solve this problem. Therefore a GPL-2.0-or-later project can use Apache-2.0 code by distributing the combined work under GPL-3.0.

MPL-2.0 and GNU licenses

Section 1.12 of MPL-2.0 defines GPL-2.0, LGPL-2.1, AGPL-3.0 and later versions as "Secondary Licenses", and Section 3.3 allows a Larger Work combining MPL code with such code to be distributed under the GNU license. The exception is when the original author attached Exhibit B ("Incompatible With Secondary Licenses").

LGPL libraries and closed-source apps

An LGPL library can be used in closed-source apps. In return, users must be able to replace the library with a modified version (dynamic linking is easiest), and you must provide the source of the library part and the license notice. If you copy LGPL code into your app's source and mix it, things change: the combined work must follow LGPL/GPL terms.

GPL-3.0 and AGPL-3.0

The two licenses expressly permit combination through each other's Section 13. In the combined work, the GPL part keeps following GPL terms, and the AGPL part keeps following AGPL terms, including the condition to provide source over a network.

EPL-2.0 and the GPL

EPL-2.0 is incompatible with the GPL by default, but combination becomes possible if the original author designates the GPL or another license as a Secondary License via Exhibit A.

Imported codeClosed-source appMIT projectGPL-2.0-onlyGPL-3.0
MIT, BSD, ISCYes (notice)YesYesYes
Apache-2.0Yes (notice, NOTICE)YesNoYes
MPL-2.0Conditional (publish files)ConditionalConditional (Secondary)Conditional (Secondary)
LGPL-3.0Conditional (linking)Conditional (linking)NoYes
GPL-3.0NoNoNoYes

How far does "combination" go?

Compatibility problems arise when code is combined into a single program. The FSF regards code linked into the same executable or sharing complex internal data structures as one program, while ordinary communication between separate programs, such as pipes, sockets and command-line arguments, is usually regarded as an "aggregate" of separate programs. However, this line has not been settled by court precedent, and interpretations differ. Simply shipping several programs together in one distribution is not a combination.

Practical steps

  1. Extract your dependency list (with your package manager's license reporting feature or an SBOM tool).
  2. Record each dependency's license as an SPDX identifier.
  3. Do a first check of each pairing with your project's license in the compatibility checker.
  4. For "conditional" pairs, check the conditions (notices, linking method, Secondary License status) in the license texts.
  5. If any pair is not allowed, replace the dependency, separate the programs or adjust your license.
This article is general information, not legal advice. Consult a professional for important decisions.

Sources