Open source licence compatibility, the practical question
When you pull a library into your project the question is rarely “what licence is it?” but “can these two licences live in the same distributed binary?” Compatibility is one-directional: it asks whether a component under licence A can be combined into a project distributed under licence B. Permissive licences (MIT, BSD, Apache 2.0) flow into almost anything; strong copyleft licences (GPL, AGPL) impose their terms on the whole combined work and so flow into very few targets.
How it works
Each licence pair is looked up in a curated rule table reflecting FSF and OSI guidance. The verdict is one of three:
- Compatible — the component can be combined and redistributed under the project licence with normal notice obligations.
- Compatible with conditions — allowed only if you follow a specific rule, e.g. LGPL requires dynamic linking and the ability to replace the library; MPL 2.0 keeps copyleft at the file level via its secondary-license clause.
- Not compatible — the licences clash. The classic traps are
Apache 2.0 → GPLv2-only(patent clause) and any copyleft code going into a permissive project.
Common compatibility scenarios explained
MIT into a GPL project
MIT code can go into a GPL project without restriction. The GPL’s requirement that the combined work be distributed as GPL doesn’t conflict with MIT, which only asks for the copyright notice to be preserved. The resulting project is GPL, and users who receive it get the MIT code’s notice alongside the GPL terms.
Apache 2.0 into GPL v2-only
This is the most frequently encountered incompatibility. Apache 2.0 contains patent termination clauses (section 3) and an explicit patent grant (section 4) that FSF considers additional restrictions beyond what GPLv2 permits. The result: you cannot distribute Apache-licensed code in a GPLv2-only project. If the library’s licence is “GPL v2 or later,” you can use the v3 interpretation, and the incompatibility disappears because GPLv3 accommodates Apache 2.0.
LGPL into a proprietary application
LGPL exists precisely to allow proprietary software to link against free libraries. The condition is that users must be able to replace the library with a modified version — in practice this usually means dynamic linking. If you statically link an LGPL library, you are generally required to allow users to relink the application with a modified version of the library, which typically requires distributing object files for the non-library parts.
AGPL into anything
AGPLv3 adds a “network use” clause: if you run modified AGPL software as a service (including a SaaS product), you must offer the source to users of that service. Internally this means adding any AGPL library to a proprietary cloud product effectively forces you to publish the whole application’s source. The tool reflects this as a strong constraint, not just a paperwork obligation.
MPL 2.0 — the file-scoped middle ground
Mozilla Public License 2.0 is unusual in that its copyleft applies at the file level. MPL-licensed files must remain MPL, but larger projects that incorporate them can carry a different licence for the rest of the codebase. Its secondary license clause also explicitly permits combining MPL files with GPL v2 or later, making it more flexible than most copyleft licences.
Notes
GPLv2-only is incompatible with the entire v3 family — if a project is “GPLv2 or later” you can treat it as GPLv3 and the picture changes. This reference is informational and not legal advice; for commercial risk or dual-licensing arrangements, consult a lawyer who specialises in intellectual property.