Open-source license compatibility
Combining code combines its licenses, and the result inherits the strictest terms. Why permissive-into-copyleft is a one-way street, why Apache 2.0 is incompatible with GPLv2 but fine with GPLv3, and the practical rules for picking dependencies.
In this series
Open source licenses explainedLicense compatibility is the question of whether you can legally combine two pieces of code into one program. It matters because the moment you link, bundle, or merge code under different licenses, the combined work has to satisfy all of those licenses at once — and some licenses make demands that others forbid. When the demands conflict, the combination is simply illegal to distribute, no matter how well the code fits together technically. This is the quiet trap behind "just add the dependency."
Why a combined work inherits the strictest terms
When you distribute a program built from parts, you are distributing every part. Each part's license still applies to it inside the whole. So the combined work must honor the union of all the obligations: keep this one's notice, release source under that one's terms, and so on. If permissive code (keep the notice) is combined with GPL1 code (release the whole derivative under GPL), the result must do both — which means the whole thing ships under the GPL. The strictest license wins, because it's the only way to satisfy everyone.
🔗 Learn more — 1 Copyleft and the GPL family
The one-way street
That dynamic makes permissive-into-copyleft a one-way street:
flowchart TD
PERM["Permissive code (MIT, BSD, Apache)"] --> COMBO["Combined work, distributed under the GPL"]
GPL["GPL code"] --> COMBO
COMBO -. "cannot flow back out as permissive" .-> BLOCKED["A permissive-only product"]
classDef plain stroke:#7b88a1,stroke-width:2.5px
classDef key stroke:#a3be8c,stroke-width:2.5px
class COMBO key
class PERM,GPL,BLOCKED plain
Permissive code flows into a GPL project freely — permissive terms ask for little, so the GPL can absorb them. The reverse is blocked: GPL code cannot be pulled into a permissive-licensed product, because the GPL's share-alike condition would have to be dropped, and it can't be.
- Permissive → copyleft: allowed. You can use MIT or BSD code inside a GPL project. The combined work goes out under the GPL.
- Copyleft → permissive: not allowed. You cannot take GPL code into an MIT-licensed product and keep the product MIT. The GPL's condition can't be waived by anyone but the copyright holder.
This is why permissive licenses are "upstream-compatible" with almost everything, and why copyleft is the term that constrains what you can build.
The Apache 2.0 / GPLv2 sharp edge
The most common real-world incompatibility is also the least obvious: Apache 2.0 is incompatible with GPLv2. Both are open source; you still can't combine them. The reason is Apache's patent-related terms (the patent grant and retaliation clause) impose conditions that GPLv2 — which predates explicit patent language — treats as extra restrictions it doesn't permit. The FSF and the Apache Software Foundation both state this directly.
GPLv3 fixed it. GPLv3 was written to accommodate exactly those patent terms, so Apache 2.0 is compatible with GPLv3. And the incompatibility is one-directional: you can pull Apache-2.0 code into a GPLv3 project, but you cannot pull GPL code into an Apache-licensed one (the one-way street again). So a project pinned to GPL-2.0-only cannot use an Apache-2.0 dependency, while the same project as GPL-2.0-or-later or GPL-3.0 can.
Practical rules for dependencies
You don't need a lawyer for the common cases — four rules cover most of them:
- Permissive deps are safe almost everywhere. MIT, BSD, and Apache-2.0 libraries drop into nearly any project. (Watch the one edge above: Apache-2.0 into a strict GPLv2 project.)
- A GPL dependency makes your distributed program GPL. If you can't or won't ship under the GPL, don't link GPL code into it.
- An AGPL dependency extends that obligation to your hosted service. Running it as SaaS triggers the source-offer requirement.
- Check the SPDX id, including the version suffix.
GPL-2.0-onlyandGPL-2.0-or-laterbehave differently for compatibility — the-or-laterlets you move up to GPLv3 and absorb Apache code;-onlydoes not.
Compatibility only applies to real open-source licenses, where the freedoms are present to begin with. The licenses that publish source but withhold those freedoms — and therefore can't be combined like this at all — are a separate category: source-available.