Open Source License Compatibility Chart

Legacy context

This site is an independent educational reference focused on the historical documentation of open biological licensing definitions. It serves as a neutral archive for those studying the evolution of licensing frameworks in biological research and related fields.

The material presented here is drawn from preserved excerpts and public-domain records, offered without interpretation or endorsement. As an archival resource, it does not provide legal advice, certification, or current licensing guidance. Visitors seeking up-to-date compatibility charts or legal opinions should consult qualified professionals or official licensing bodies.

The content is intended solely for historical and educational purposes, reflecting the state of knowledge at the time of original documentation. No claims are made regarding ongoing operations, affiliations, or the current validity of any referenced definitions. This archive exists to support scholarly inquiry and informed discussion.

Open Source License Compatibility: A Practical Checklist Guide

Open source license compatibility is one of the most misunderstood areas in software development. A license that works perfectly for a standalone utility can become a legal and technical headache when combined with another library. This guide gives you a decision-oriented checklist, common failure modes, and a compact reference chart—without pretending to be legal advice or a certified inventory of every license version.

Why Compatibility Matters (and What It Actually Means)

Compatibility, in the open source context, means that the combined distribution of two or more codebases satisfies the terms of every license involved. If License A requires that derivative works be released under License A, and License B requires the same, you may have a conflict. The practical result is not always a [omitted]—it is often an inability to distribute, a forced rewrite, or a last-minute license swap that delays your release.

The core question is always: Does the combined work create a "derivative work" under copyright law? If yes, the stricter copyleft license may apply to the whole. If no—for example, you are merely linking dynamically and the licenses explicitly allow it—you may keep separate terms. This distinction is fact-specific, so treat any chart as a starting point, not a verdict.

Before using any chart, classify your licenses into three families:

1. Permissive (MIT, BSD, Apache 2.0, ISC). These allow sublicensing, modification, and distribution under different terms, provided you keep the copyright notice and disclaimer. They are almost always compatible with everything, including proprietary code.
2. Weak Copyleft (LGPL, MPL, EPL). These allow linking with proprietary code under certain conditions. LGPL requires that the library itself remain LGPL and that users can relink with a modified version. MPL (Mozilla Public License) is file-level copyleft—only modified files must be MPL. EPL is similar but has specific provisions for patent retaliation.
3. Strong Copyleft (GPL, AGPL). GPL requires that any derivative work be distributed under GPL. AGPL adds a network-use clause: if users interact with the software over a network, you must offer them the source code, even if you never distribute copies.

The Compatibility Chart: A Compact Actionable Reference

This chart is a decision aid, not a legal guarantee. It assumes you are combining two libraries into one distributed product. "Yes" means the combination is generally workable with proper attribution. "Conditional" means you must satisfy specific obligations. "No" means the terms conflict in a way that is difficult or impossible to resolve without changing licenses.

Decision Criteria: How to Use the Chart

Follow this checklist in order. Do not skip steps.

1. Identify every license in your dependency tree. Use a tool like `license-checker` (npm), `cargo-license` (Rust), or `go-licenses` (Go). Manual review is error-prone.
2. Separate "distributed" from "internal only." If you never distribute the software (e.g., internal tool, SaaS backend without AGPL), many copyleft obligations do not trigger. But AGPL triggers on network use, so that exception does not apply.
3. Ask: Is the dependency a separate work or a derivative? Dynamic linking is often considered separate for LGPL, but static linking is usually derivative. For GPL, the FSF argues even dynamic linking creates a derivative work. Courts have not universally agreed. When in doubt, treat it as derivative.
4. Check the "or later" clause. GPL-2.0-or-later can be upgraded to GPL-3.0, which then allows Apache-2.0 compatibility. GPL-2.0-only cannot. Always read the exact license text.
5. Look for explicit compatibility statements. Apache-2.0 has a section stating it is compatible with GPL-3.0. MPL-2.0 has a similar compatibility mechanism. These are written into the license, not inferred.
6. Consider patent clauses. Apache-2.0 and EPL have explicit patent grants. MIT and BSD do not. If you are in a patent-sensitive domain, prefer Apache-2.0 for your own code.