Open Source License Compatibility Chart

Legacy context

This site is an independent, educational reference archive focused on open source licensing. It is maintained as a personal resource for those studying software distribution and legal compatibility. The content presented here is offered for general information and study purposes only, and does not constitute legal advice or a professional service.

The pages in this archive are intended to help clarify how different open source licenses may interact, based on publicly available license texts and common interpretations. As an educational reference, this site does not represent any organization, vendor, or legal authority, and it does not endorse specific products or projects.

Visitors are encouraged to verify all information against primary sources and consult qualified professionals for specific legal or business decisions. This archive is provided on an "as-is" basis, without warranty of any kind, and reflects the compiler's personal study notes rather than an official or commercial publication.

Open Source License Compatibility: A Practical Checklist Guide

Open source licenses are legal instruments that grant permission to use, modify, and distribute software under specific conditions. When you combine code from multiple projects, the resulting "derivative work" must comply with every license attached to its components. A compatibility chart is a visual tool that maps which licenses can be combined without creating conflicting obligations. This guide provides a decision framework, common pitfalls, and a compact reference—not legal advice, but a structured way to reason about your own situation.

How to Read a Compatibility Chart

A typical chart lists licenses on both axes (rows and columns). The intersection cell shows whether code under License A can be combined with code under License B, and under what conditions. Three common labels appear:

• Compatible: You can combine and distribute under one of the licenses, usually the more restrictive one.
• Conditional: You can combine, but you must satisfy specific requirements (e.g., provide source code, retain notices, or relicense your own additions).
• Incompatible: The obligations directly conflict (e.g., one requires source disclosure, the other forbids it).

Charts are snapshots, not statutes. License versions matter: GPL-2.0 and GPL-3.0 are not automatically compatible. Always verify the exact version and any "or later" clauses.

Core Decision Criteria Before You Combine Code

Use this checklist before consulting any chart. It will save you from misreading a compatibility cell.

1. Identify every license and version in your dependency tree. Use a tool like `license-checker` (npm), `cargo-license` (Rust), or `pip-licenses` (Python). Record the SPDX identifier (e.g., `MIT`, `Apache-2.0`, `GPL-3.0-only`).
2. Determine your distribution model. Are you shipping binaries, hosting a web service, or distributing source only? This changes obligations. For example, the AGPL-3.0 triggers network-use source disclosure; the GPL does not.
3. Check for "or later" clauses. A file licensed as "GPL-2.0-or-later" can be used under GPL-3.0 terms, which changes compatibility with Apache-2.0. A file marked "GPL-2.0-only" cannot.
4. Separate "linking" from "mere aggregation". If two programs run as separate processes and communicate via standard interfaces, they may be considered independent works. If you statically link or copy code into one binary, it is likely a derivative work. Charts assume derivative status unless stated otherwise.
5. Look for explicit exceptions. Some projects add a linking exception (e.g., "GPL-2.0 with Classpath Exception") that permits proprietary linking. The chart cell for plain GPL-2.0 does not apply to that exception.

Common Mistakes That Break Compatibility

Even experienced developers misread charts. Here are the frequent failure modes.

Mistake 1: Treating "permissive" as "always safe." MIT and BSD-2-Clause are permissive, but they still require retaining copyright notices. If you combine MIT code with GPL-3.0 code, the combined work must be GPL-3.0, and you must include the MIT notice. That is fine, but you cannot relicense the MIT portion to GPL-3.0-only—you must keep the MIT notice intact.

Mistake 2: Assuming GPL-2.0 and GPL-3.0 are interchangeable. They are not. GPL-2.0 has a "or later" option, but many projects (e.g., the Linux kernel) are GPL-2.0-only. Combining GPL-2.0-only code with Apache-2.0 code is generally incompatible because Apache-2.0 includes patent retaliation clauses that GPL-2.0 does not recognize. GPL-3.0 is compatible with Apache-2.0, but GPL-2.0-only is not.

Mistake 3: Ignoring the LGPL's "relicensing" trap. LGPL-2.1 allows you to use the library as a shared library in a proprietary program, but if you modify the LGPL library itself, you must release those modifications under LGPL. A chart cell that says "LGPL-2.1 + proprietary = conditional" does not mean you can statically link without providing object files for relinking. You must provide a way for the user to replace the library.

Mistake 4: Confusing "compatible" with "can distribute under either license." If you combine MIT and BSD-3-Clause code, you can distribute under either license, but you must keep both copyright notices. If you combine MIT and GPL-3.0, you must distribute under GPL-3.0 (or a compatible license), not under MIT. The chart cell may say "compatible," but the resulting license is the stricter one.

Mistake 5: Overlooking the "weak copyleft" of MPL-2.0. The Mozilla Public License is file-level copyleft. You can combine MPL-2.0 files with GPL-3.0 files in one binary, but each MPL-2.0 file must remain under MPL-2.0. The combined work can be GPL-3.0, but you must keep the MPL-2.0 source for those specific files available. Charts often mark MPL-2.0 + GPL-3.0 as compatible, but that does not mean you can relicense the MPL files.

Compact Actionable Reference (Common Pairs)

This is a practical starting point, not a substitute for legal review. Always verify with the actual license texts.

License A	License B	Result	Key Condition
MIT	Apache-2.0	Compatible	Distribute under Apache-2.0; keep MIT notice.
MIT	GPL-3.0	Compatible	Combined work under GPL-3.0; keep MIT notice.
MIT	GPL-2.0-only	Compatible	Combined work under GPL-2.0; keep MIT notice.
Apache-2.0	GPL-3.0	Compatible	Combined work under GPL-3.0; Apache patent clause is preserved.
Apache-2.0	GPL-2.0-only	Incompatible	Patent retaliation conflict; do not combine in one derivative.
BSD-3-Clause	GPL-3.0	Compatible	Combined work under GPL-3.0; keep BSD notice.
LGPL-2.1	GPL-2.0-only	Conditional	LGPL code can be relicensed to GPL-2.0, but only if you own or have permission for that change.
LGPL-3.0	GPL-3.0	Compatible	Combined work under GPL-3.0; LGPL library modifications stay LGPL.
MPL-2.0	GPL-3.0	Compatible	Combined work under GPL-3.0; MPL files remain MPL-2.0.
MPL-2.0	Apache-2.0	Conditional	File-level copyleft; Apache files can stay Apache, MPL files stay MPL.
GPL-2.0-only	GPL-3.0	Incompatible	Cannot combine unless one side has "or later."
AGPL-3.0	GPL-3.0	Compatible	Combined work under AGPL-3.0 (stronger network copyleft).
AGPL-3.0	Apache-2.0	Conditional	Combined work under AGPL-3.0; Apache notice retained.

How to Use This Reference in Practice

1. Start with the most restrictive license in your dependency set. That is usually the one that will govern the combined work.
2. Check each dependency against that governing license using the chart. If any pair is "incompatible," you have three options: remove the dependency, replace it with a compatible alternative, or contact the upstream author to relicense (rare and often impossible).
3. Document your reasoning in a `COMPATIBILITY.md` file. Write down the SPDX identifiers, the version numbers, and the chart cell you relied on. This helps future maintainers and shows diligence if questions arise.
4. Re-run the check after every dependency update. A patch release may change a license from MIT to GPL-3.0, silently breaking your build's compliance.