Open Source License Compatibility

What Makes Two Licenses Compatible?

Two licenses are compatible when the conditions of both can be satisfied simultaneously in a combined work. If License A requires attribution and License B requires attribution plus source code disclosure, you can satisfy both by providing attribution and source code. The conditions do not conflict, so the licenses are compatible.

Two licenses are incompatible when the conditions of one contradict or prohibit the conditions of the other. The classic example is the conflict between the GPL v2 and the Apache License 2.0. The Apache License includes patent retaliation and indemnification clauses. The GPL v2 states that you cannot impose any additional restrictions beyond those in the GPL itself. Since the Apache License's patent and indemnification clauses constitute additional restrictions from the GPL v2's perspective, the two licenses cannot be satisfied simultaneously, and code under these two licenses cannot be combined.

Compatibility is directional for copyleft licenses. You can include MIT code in a GPL project (the MIT conditions are a subset of the GPL conditions), but you cannot include GPL code in an MIT project (because the GPL would require the entire combined work to be GPL-licensed, which contradicts the MIT license's intent to allow any downstream licensing). Permissive-to-copyleft is generally possible; copyleft-to-permissive is generally not.

Permissive License Compatibility

Permissive licenses are the easiest to work with from a compatibility standpoint because their conditions are minimal. MIT, BSD (2-Clause and 3-Clause), ISC, and the Unlicense are compatible with virtually every other open source license and with proprietary licenses as well.

The conditions of these licenses, typically just attribution and a warranty disclaimer, are so minimal that they never conflict with the conditions of other licenses. You can include MIT code in a GPL project, an Apache project, an MPL project, or a proprietary product. You simply include the MIT copyright notice alongside whatever other license obligations apply to the combined work.

The Apache License 2.0 is permissive but has a notable compatibility exception. Its patent retaliation clause (which terminates your patent license if you sue anyone over the software) and its requirements around NOTICE files constitute additional conditions that some copyleft licenses do not allow. Specifically, Apache 2.0 is incompatible with GPL v2 but compatible with GPL v3. This matters in practice because the Linux kernel uses GPL v2-only, so Apache 2.0-licensed code cannot be incorporated into the kernel.

Among permissive licenses themselves, compatibility is universal. MIT, BSD, Apache 2.0, and ISC code can all be combined freely. The combined work simply carries all the attribution notices and satisfies all the conditions, which is straightforward since the conditions are minimal and non-conflicting.

GPL Family Compatibility

The GPL family of licenses (GPL v2, GPL v3, LGPL, and AGPL) has the most complex compatibility rules because copyleft's requirement to license the entire combined work under the GPL creates tension with any license that includes conditions the GPL does not permit.

GPL v2 Compatibility

GPL v2 is compatible with MIT, BSD (2-Clause and 3-Clause), ISC, and most simple permissive licenses. Code under these licenses can be included in a GPL v2 project, and the combined work is distributed under GPL v2.

GPL v2 is incompatible with Apache 2.0 (due to Apache's patent retaliation and indemnification provisions), with the original 4-Clause BSD (due to the advertising clause), and with most other copyleft licenses including MPL 1.1 and CDDL. The incompatibility with Apache 2.0 is one of the most practically significant compatibility issues in open source because both licenses are extremely popular.

GPL v2 code that uses the "or any later version" phrasing (which many GPL v2 projects include) can be treated as GPL v3 for compatibility purposes. This is important because GPL v3 resolves several compatibility issues that GPL v2 has. The Linux kernel is a notable exception: it is licensed under GPL v2 only, without the "or later version" clause, which means it cannot be relicensed under GPL v3 and inherits all of GPL v2's compatibility limitations.

GPL v3 Compatibility

GPL v3 was specifically designed to be more compatible than GPL v2. It is compatible with MIT, BSD, ISC, Apache 2.0, and LGPL v3. The resolution of the Apache 2.0 incompatibility was one of the primary motivations for creating GPL v3.

GPL v3 is also compatible with AGPL v3. Section 13 of GPL v3 explicitly allows combining GPL v3 and AGPL v3 code, with the AGPL's network distribution requirement applying to the AGPL portions of the combined work.

GPL v3 remains incompatible with GPL v2-only code (without the "or later" clause), CDDL, and certain other copyleft licenses that impose conditions the GPL v3 does not permit.

AGPL v3 Compatibility

AGPL v3 is essentially GPL v3 with the additional requirement that providing access to the software over a network counts as distribution. AGPL v3 is compatible with GPL v3 (you can combine them, with the AGPL's network trigger applying to the AGPL portions). AGPL v3 is also compatible with the same permissive licenses that GPL v3 is compatible with: MIT, BSD, ISC, and Apache 2.0.

In practice, AGPL v3 causes more organizational policy issues than technical compatibility issues. Many companies prohibit AGPL-licensed dependencies entirely because the network distribution trigger could theoretically apply to any server-side application, and the compliance burden is considered too high relative to the risk.

Weak Copyleft Compatibility

LGPL v3

The LGPL v3 is compatible with GPL v3 and with all licenses that GPL v3 is compatible with. The key difference is that LGPL code can be used by proprietary software through dynamic linking without triggering copyleft for the proprietary code. This makes the LGPL practical as a library license in mixed open-source-and-proprietary environments.

LGPL v2.1 has similar compatibility characteristics to GPL v2, including the incompatibility with Apache 2.0. LGPL v2.1 code with the "or later version" clause can be upgraded to LGPL v3, which resolves the Apache incompatibility.

MPL 2.0

The MPL 2.0 was designed with compatibility in mind. Section 3.3 of the MPL 2.0 includes an explicit "secondary license" provision that allows MPL code to be combined with code under GPL v2 or later, LGPL v2.1 or later, or AGPL v3 or later. This makes the MPL one of the most compatible copyleft licenses available.

MPL 2.0 is compatible with MIT, BSD, ISC, Apache 2.0, GPL v2, GPL v3, LGPL, and AGPL. The file-level copyleft applies only to modifications of MPL-licensed files, while new files can use any license. This combination of narrow copyleft scope and broad compatibility makes the MPL a practical middle-ground choice.

Common Compatibility Scenarios

Here are the most frequently encountered compatibility situations and how to handle them.

Mixing MIT and GPL Dependencies

This is straightforward. MIT code can be included in a GPL project. The combined work is distributed under the GPL. The MIT copyright notice must still be preserved. This is the most common compatibility scenario and causes no issues.

Mixing Apache 2.0 and GPL Dependencies

If the GPL dependency uses GPL v3 (or GPL v2 with "or later"), the combination works. The combined work is distributed under GPL v3, and the Apache 2.0 conditions (including patent provisions) are satisfied because GPL v3 permits them. If the GPL dependency is GPL v2-only, the combination is not possible without relicensing one of the components.

Using AGPL Code in a Proprietary Product

This is generally not possible without complying with the AGPL's requirements, which include making the complete source code of your application available to anyone who interacts with it over a network. Most proprietary products either avoid AGPL dependencies entirely or use them only in isolated components that are not part of the main application (though the boundaries of what constitutes a "combined work" under the AGPL are not always clear).

Combining Two Different Copyleft Licenses

This is usually not possible unless one or both licenses include explicit compatibility provisions. You cannot combine GPL code with CDDL code, for example, because both are copyleft licenses that require the combined work to be distributed under their respective terms, and you cannot satisfy both simultaneously. The MPL 2.0's secondary license provision and the GPL v3/AGPL v3 compatibility clause are the main exceptions to this general rule.

Tools for Checking Compatibility

Manual compatibility analysis works for projects with a handful of dependencies, but modern software projects often have hundreds or thousands of transitive dependencies, each with its own license. Automated tools are essential for managing this complexity.

FOSSA is a commercial license compliance platform that scans dependency trees, identifies license obligations, creates software bills of materials, and flags compatibility issues. It integrates with CI/CD pipelines and supports most major package managers and build systems.

Snyk includes license compliance scanning alongside its security vulnerability features. It can identify problematic licenses in your dependency tree and flag them according to your organization's license policy.

OSS Review Toolkit (ORT) is an open source tool maintained by HERE Technologies that performs license scanning, compatibility analysis, and compliance documentation. It is more complex to set up than commercial alternatives but provides comprehensive analysis without licensing costs.

license-checker (for npm) and pip-licenses (for Python) are lightweight tools that list the licenses of all dependencies in a project. They do not perform compatibility analysis, but they give you the raw data needed to evaluate compatibility manually.

Regardless of which tool you use, the best practice is to check license compatibility early in development, before dependencies become deeply integrated into your codebase. Discovering a compatibility issue after years of development is exponentially more expensive to fix than catching it during initial dependency selection.