Free Online License Compatibility Checker
Check whether two open-source licenses can be combined.
Choose the two licenses
License A is the license of your project. License B is the license of the third-party code you want to include.
Dynamic linking can change the result for LGPL dependencies. It does not rescue GPL or AGPL code from its copyleft obligations.
Why this result
—
Obligations from License B
Warnings and conditions
Reverse direction
—
Informational only, not legal advice. License compatibility depends on how code is linked, which version of a license applies, and whether exceptions or dual licensing exist. Confirm with the license text and a qualified open-source lawyer for distribution decisions.
About the Open-Source License Compatibility Checker
Open-source licenses are not interchangeable. Each one grants different permissions and imposes different conditions, and those conditions can conflict when code from two projects is combined. This checker compares two licenses in a specific direction: you license your project under License A and want to include code released under License B. It reports whether that combination is generally allowed, allowed with conditions, or incompatible, then lists the obligations that come with the dependency and the warnings you should investigate before shipping.
The model covers the most common families. Permissive licenses such as MIT, BSD, and Apache-2.0 allow reuse in almost any project as long as notices are kept, with Apache-2.0 adding a patent grant, a NOTICE file requirement, and a term that can terminate patent rights. Weak copyleft licenses such as MPL-2.0 and the LGPL keep their own files or library under copyleft while allowing a larger program under other terms. Strong copyleft licenses such as GPL-2.0 and GPL-3.0 require the combined work to be distributed under the same license, and AGPL-3.0 extends that requirement to users who interact with the software over a network.
Why direction matters
Compatibility is not symmetric. MIT code can usually be placed inside a GPL-3.0 project, because MIT permits relicensing under stronger terms. GPL-3.0 code cannot usually be placed inside an MIT project, because the GPL forbids adding restrictions and requires the whole distributed work to remain GPL-3.0. The reverse direction panel shows this asymmetry explicitly, which is why the tool asks which license belongs to your project before it gives a result.
Linking style matters too, especially for the LGPL. A separate process or a dynamic link may keep the library independent, while static linking or copying code into the same binary can pull the combined work under the library's terms. The checker uses a simple toggle for this, but real builds can be more subtle: plugins, headers, generated code, and modified library files all deserve a closer look. Dual licensing, license exceptions, and the "or later" option can also change the answer. This tool provides an informational estimate only. It is not legal advice and cannot replace a review of the actual license texts and your distribution model.
Frequently asked questions
Is a "compatible" result a legal clearance?
No. It means the combination is generally accepted under the standard license terms. Your build process, modifications, notices, and the exact license versions still matter. This is informational guidance, not legal advice.
What does "compatible with conditions" mean?
The dependency can usually be used, but only if you meet specific requirements such as dynamic linking, providing relinkable object files, keeping library modifications open, or confirming an "or later" clause.
Can I use GPL code in a closed-source product?
Generally no for a combined work distributed to others. The GPL requires the corresponding source and the same license for the combined program. Separate processes and arm's-length services can be different, but that analysis is fact-specific and needs professional advice.