Why You Can't Always Mix Licenses
Using multiple open-source libraries in a single project is normal. But combining code under different licenses in the same binary can create legal conflicts. License compatibility determines whether two licenses can coexist in the same distributed work.
The core problem: if License A requires "you must do X" and License B requires "you must NOT do X," you cannot satisfy both simultaneously. The combination is legally impossible to distribute.
Key incompatibilities to know:
| Combination | Compatible? | Why |
|---|---|---|
| MIT + Apache 2.0 | ✅ Yes | Both permissive, no conflicting obligations |
| MIT + GPL v3 | ✅ Yes | MIT code can be incorporated into GPL v3 works |
| Apache 2.0 + GPL v2 | ❌ No | Apache 2.0's patent termination clause conflicts with GPL v2's terms |
| Apache 2.0 + GPL v3 | ✅ Yes | GPL v3 was specifically updated to resolve this |
| GPL v2 + GPL v3 | ❌ No | Unless code is licensed "v2 or later" |
| LGPL + Proprietary (dynamic link) | ✅ Usually | LGPL specifically permits this use case |
Practical implication: If your application statically links a GPL v2 library and an Apache 2.0 library, you cannot legally distribute the resulting binary. This is not a theoretical concern — it has blocked real software releases.
A common interview scenario: "We want to use Library X (Apache 2.0) and Library Y (GPL v2) in the same compiled binary. Is this a problem?" The correct answer: "Yes. Apache 2.0 and GPL v2 are incompatible. The Apache 2.0 patent termination clause conflicts with GPL v2's requirement that no additional restrictions be imposed. The fix is to either find an alternative library, use GPL v3 (which resolved this), or keep the components in separate processes communicating over an API rather than linking them together."