Open Source License Compatibility Checker
Select Licenses
2 selectedProject Type
Pair Analysis
⚠ Pitfall Warnings
Recommended Outbound Licenses
This tool provides general guidance based on widely accepted license compatibility analysis (FSF, OSI, and community resources). It is not legal advice. For commercial use or ambiguous cases, consult a qualified attorney. License compatibility can depend on jurisdiction, specific use case, and exact license versions used.
What This Tool Does
Select two or more open-source licenses and get a verdict — compatible, incompatible, or conditional — for each pair, the obligations each combination triggers, and a recommended outbound license for the combined work. It covers 20 licenses across permissive, copyleft, and content families, and runs in your browser. The classic trap it catches: Apache 2.0 is incompatible with GPL 2.0, though it is fine with GPL 3.0.
Last updated:
This tool is provided as-is for convenience. Output should be verified before use in any production or critical context.
Agent Invocation
Best Path For Builders
Browser workflow
Runs instantly in the browser with private local processing and copy/export-ready output.
Browser Workflow
This tool is optimized for instant in-browser execution with local data handling. Run it here and copy/export the output directly.
/license-compatibility-checker/
For automation planning, fetch the canonical contract at /api/tool/license-compatibility-checker.json.
How to Use Open Source License Compatibility Checker
- 1
Select your licenses
Click license buttons to toggle them on/off. Licenses are grouped by type: permissive (MIT, Apache, BSD), weak copyleft (MPL, LGPL, EPL), strong copyleft (GPL, AGPL), and content (CC). Select all licenses used in your project or dependencies.
- 2
Set your project type
Choose library, application, or SaaS. SaaS/network services trigger AGPL-3.0 copyleft — if your project runs as a hosted service and uses AGPL-licensed code, you must publish source code for users who interact with it over the network.
- 3
Review pair verdicts
Each license pair shows a Compatible (green), Incompatible (red), or Conditional (amber) verdict. Click any pair to expand detailed notes explaining what requirements apply and what the recommended outbound license is for the combined work.
- 4
Use the matrix for 3+ licenses
When 3 or more licenses are selected, a visual compatibility matrix is shown. Green ✓ = compatible, red ✗ = incompatible, amber ~ = conditional. Hover cells to see notes. This quickly spots problematic combinations across an entire dependency set.
- 5
Check pitfall warnings
The Pitfall Warnings section highlights the most common mistakes — like combining GPL-2.0 with Apache 2.0 (incompatible!), or using CC licenses for code. Address each warning before shipping or open-sourcing your project.
Frequently Asked Questions
What is the License Compatibility Checker?
How do I use License Compatibility Checker?
Why are GPL-2.0 and Apache 2.0 incompatible?
What does 'conditional' compatibility mean?
Does project type (library vs. SaaS) affect compatibility?
How do I check if two open-source licenses are compatible?
License compatibility is about whether you can combine code under both licenses and, if so, which license the combined work must carry. Select the licenses of the components you want to mix and the checker returns a verdict for every pair, the obligations that follow, and a suggested outbound license. It reflects widely accepted FSF and OSI guidance, not legal advice.
Step by step
- Select two or more licenses from the permissive, copyleft, weak-copyleft, source-available, and content groups.
- Set your project type — library, application, or SaaS — to surface the obligations it triggers.
- Read each pair's verdict and expand it for the reasoning and pitfall warnings.
- With three or more licenses selected, read the full compatibility matrix.
- Note the recommended outbound license for the combined work.
License combinations this tool models
| Combination | Verdict | Outbound / note |
|---|---|---|
| MIT + BSD (two permissive) | Compatible | Combine freely; keep every notice, use the more-restrictive input |
| MIT + GPL-3.0 | Conditional | Combined work is GPL-3.0 |
| Apache-2.0 + GPL-2.0 | Incompatible | Apache patent terms conflict; use GPL-3.0 instead |
| GPL-2.0 + GPL-3.0 | Incompatible | Unless the GPL-2.0 component is "or later" |
| MPL-2.0 + MIT | Compatible | File-level copyleft; only modified MPL files stay MPL |
| Permissive + AGPL-3.0 | Conditional | Outbound AGPL-3.0; network-use source disclosure applies |
| CC-BY-SA-4.0 + GPL (for code) | Incompatible | Share-alike content license, not GPL-compatible for software |
Verdicts as this tool models them, based on FSF/OSI guidance — not legal advice. Results can change with version "or-later" clauses, static vs dynamic linking, and MPL/EPL "Secondary License" markers.
How does project type change the result?
The verdict does not change, but the obligations do. Choosing SaaS with an AGPL-3.0 component adds a warning that you must offer complete source to every user who reaches the service over a network. Choosing Library with an LGPL component notes that dynamic linking lets your own code keep its license, while static linking or modifying the LGPL code makes the combined work LGPL.
Why is Apache 2.0 incompatible with GPL 2.0?
The FSF treats Apache 2.0's patent retaliation and termination clauses as an added restriction that GPL 2.0 does not permit, so the two cannot be linked into one binary. GPL 3.0 was written to accept those terms, which is why the checker marks Apache 2.0 as compatible with GPL 3.0 but not GPL 2.0 — one of the most common licensing pitfalls.
Is this legal advice, and does my selection leave the browser?
It is general guidance, not legal advice — for commercial or ambiguous cases consult a qualified attorney, since compatibility can depend on jurisdiction, exact license versions, and how components are linked. The analysis runs entirely in your browser; your license selection is never uploaded.