Open Source License Compatibility Checker
Find out whether an open source library can be safely combined with your project. Pick the two licenses below to see compatibility, obligations, and distribution rules in plain English.
The license of the code you want to use.
The license you are applying to your project.
The short answer
Permissive licenses like MIT carry few restrictions, so they can be absorbed into copyleft projects like GPL 3.0.
Key obligations
Retain the original copyright notices and license text for the MIT components.
Potential conflicts
None. The copyleft terms supersede the permissive terms for the combined work.
Distribution notes
The combined work as a whole must be distributed under GPL 3.0.
Deep-dive resources
Stop guessing. Start automating.
Modern applications pull in hundreds of transitive dependencies. A manual check can't keep up.
Disclaimer: This tool offers general guidance based on widely accepted open source community norms and does not constitute legal advice. For commercial use, always consult legal counsel or use a dedicated compliance platform like FOSSA to analyze your specific dependency graph.
Open source license compatibility matrix
Read a row as the library you want to use and the column as your project license. Select any cell for the full breakdown.
| Library ↓ / Project → | MIT | Apache 2.0 | BSD-3 | GPL 2.0 | GPL 3.0 | AGPL 3.0 | MPL 2.0 |
|---|---|---|---|---|---|---|---|
| MIT | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
| Apache 2.0 | ✓ | ✓ | ✕ | ✓ | ✓ | ✓ | |
| BSD-3 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
| GPL 2.0 | ✕ | ✕ | ✕ | ✕ | ✕ | ~ | |
| GPL 3.0 | ✕ | ✕ | ✕ | ✕ | ✓ | ~ | |
| AGPL 3.0 | ✕ | ✕ | ✕ | ~ | ~ | ~ | |
| MPL 2.0 | ~ | ~ | ~ | ~ | ~ | ~ |
Open source license quick reference
The core obligations of each license at a glance.
| License | Type | Commercial use | Patent grant | Source sharing |
|---|---|---|---|---|
| MIT LicenseA short, highly permissive license. Use it almost anywhere as long as you keep the copyright and license notice. | Permissive | Yes | None | Not required |
| Apache License 2.0Permissive, with an express patent grant and a NOTICE-file requirement. Its patent terms make it incompatible with GPL v2.0. | Permissive (+ patent grant) | Yes | Express | Not required |
| BSD 3-ClausePermissive like MIT, plus a clause barring use of the project's name to endorse derived products. | Permissive | Yes | None | Not required |
| GNU GPL v2.0 (Only)Strong copyleft. Distributing a combined work means releasing all of it under GPL v2.0. The "only" variant is incompatible with the GPL v3 family. | Strong copyleft | Yes | None | Entire combined work |
| GNU GPL v3.0Strong copyleft with patent and anti-tivoization protections. Designed to be compatible with Apache 2.0. | Strong copyleft | Yes | Express | Entire combined work |
| GNU AGPL v3.0Network copyleft. Closes the "SaaS loophole" — offering the software over a network triggers the obligation to share source. | Network copyleft | Yes | Express | Combined work + network use |
| Mozilla Public License 2.0Weak, file-level copyleft. You must share changes to MPL-covered files, but the rest of your project can use another license. | Weak copyleft | Yes | Express | Modified files only |
How open source license compatibility works
Two licenses are compatible when code under one can be legally combined and distributed with code under the other. Incompatibility almost always comes from copyleft terms — requirements that the combined work be released under the same license — clashing with another license's rules.
Permissive licenses (MIT, Apache 2.0, BSD)
Add few obligations beyond keeping notices, so they can be combined into almost any project — including proprietary software. Apache 2.0 is the exception that carries an express patent grant, which is why it conflicts with GPL v2.0.
Strong copyleft (GPL)
Requires the entire combined work to ship under the same license. You can pull permissive code into a GPL project, but you cannot re-license GPL code under a permissive license — a one-way street.
Weak copyleft (MPL)
Applies copyleft at the file level. You share changes to the covered files, but the rest of your project can use a different license — so MPL can live inside a permissive project.
Network copyleft (AGPL)
Extends copyleft to software offered over a network, closing the "SaaS loophole." Using AGPL code in a hosted service can obligate you to share your application's source with users.
Compatibility also depends on how you distribute. Purely internal use rarely triggers copyleft obligations; shipping binaries or offering a network service usually does. That is why the checker above asks about your distribution model and whether you modify the component.
Common license compatibility questions
Plain-English answers to the licensing scenarios developers ask about most.
Is MIT compatible with GPL?
Yes. The MIT License is fully compatible with both GPL v2.0 and GPL v3.0. You can take MIT-licensed code, modify it, and ship it inside a larger project distributed under the GPL. MIT is a permissive license that mainly requires keeping the original copyright and license notice intact, so it adds no restriction the GPL disallows. Note this is a one-way street: you cannot take GPL code and re-license it under MIT.
Is Apache 2.0 compatible with GPL?
It depends on the GPL version. Apache 2.0 and GPL v3.0 are compatible — the Free Software Foundation explicitly designed GPL v3.0 to accept Apache 2.0 code. Apache 2.0 and GPL v2.0 are incompatible, because Apache 2.0's patent termination clauses count as an additional restriction that GPL v2.0 cannot accept.
What is the difference between permissive and copyleft licenses?
Permissive licenses (MIT, Apache 2.0, BSD) let you do almost anything with the code — including using it in closed-source software — as long as you keep copyright notices. Copyleft licenses (GPL, AGPL) allow free use but require that derivative or combined works are also distributed under the same copyleft license, keeping the software open.