Almost no modern software is written from scratch: it is assembled from dozens or hundreds of libraries, each with its own license. As long as components stay separate, licenses coexist without trouble. Problems arise when you combine code under different licenses into a single work and distribute it. At that point you have to ask whether there is a way to meet all the obligations at once. If there is, the licenses are compatible; if two licenses demand opposite things, they are not.
The underlying principle
License A is compatible with license B, in a given direction, when code under A can be included in a work distributed under B while respecting both. Compatibility therefore has a direction. MIT code can go into a GPL project, because MIT only asks you to keep the notice, and that does not conflict with the GPL. GPL code cannot go into a project you want to distribute under MIT, because the GPL requires the whole to remain GPL.
A simple way to think about it: more permissive licenses can "flow" towards more restrictive ones, not the other way round.
A practical map
| Included code | into MIT project | into Apache 2.0 project | into GPLv2-only project | into GPLv3 project |
|---|---|---|---|---|
| MIT / BSD | yes | yes | yes | yes |
| Apache 2.0 | yes, with Apache duties | yes | no | yes |
| LGPLv2.1 | as a separate library | as a separate library | yes | yes |
| MPL 2.0 | yes, at file level | yes, at file level | yes, via secondary licenses | yes, via secondary licenses |
| GPLv2 only | no | no | yes | no |
| GPLv3 | no | no | no | yes |
Important notes on the table:
- "Yes" does not mean "no obligations": notices and license texts must always be kept.
- The LGPL entries assume the library remains a distinct, replaceable component.
- For the MPL, combination with the GPLs holds unless the code is marked as incompatible with secondary licenses.
Telling aggregation from combination
Many doubts disappear once you distinguish two situations.
Aggregation: separate programs distributed together, for example on the same disk or in the same system image, communicating through standard mechanisms such as files, pipes, sockets or the command line. The GPL itself states that aggregation does not extend the license to the other programs.
Combination into a single work: code compiled together, linked into the same executable, or modules that share internal data structures closely. Here the licenses must be compatible.
The line is not always sharp. Plugins loaded into the same process, interpreted languages, editor extensions: in these cases you need to assess how the components actually interact.
Concrete examples
A Python web application
A project under the MIT license uses a BSD framework, an AGPL PDF library and an Apache 2.0 database client. If the application is offered as a service and the AGPL library is imported directly into the code, the whole is subject to AGPL obligations. The project can no longer be presented as "MIT" as a whole: your own files can stay under MIT, but the combined work must be treated as AGPL. Alternatively, you pick a different PDF library.
A command-line tool
A proprietary script invokes a GPL program as a separate process, passing it files and reading its output. That is aggregation: the script does not become GPL. If the same script imported the GPL code as a library, the situation would change.
A firmware image
A manufacturer wants to include a "GPLv2 only" component and an Apache 2.0 library in its firmware, linked into the same binary. The two licenses are incompatible: one of the components must be replaced, or they must be kept in separate processes.
How to set up a check
- List the dependencies, including indirect ones, with name, version and license.
- Verify the actual license in the project's files, not just in the package manager's metadata.
- Decide the license of the final work and how it is distributed (binary, service, source).
- Check the direction of each combination against the final license.
- Document exceptions and architectural choices, such as separate processes or dynamic libraries.
In my work this check happens at the start, not when the product is finished: replacing a dependency mid-project costs far more than choosing it well.
Dual licensing
Some projects offer their code under two alternative licenses, for example "MIT or Apache 2.0". Recipients pick the one they prefer, which solves many compatibility problems. With standard identifiers this is written MIT OR Apache-2.0.
In short
- License compatibility has a direction: permissive code can flow into copyleft projects, not the reverse.
- Apache 2.0 and GPLv2 alone are not compatible; Apache 2.0 and GPLv3 are.
- Aggregating separate programs is different from combining them into a single work.
- The check should be done at the start, including indirect dependencies.
- Dual licensing makes integration easier by leaving the choice to the recipient.
