Open Source Licenses Explained: MIT, GPL, and Apache 2.0

Every open source project ships with a license file, and almost nobody reads it. That is fine right up to the moment you paste a useful function into a commercial product, or a customer's legal team asks why your binary contains GPL code. The three licenses you will run into most often — MIT, GPL, and Apache 2.0 — are not three flavours of the same idea. They grant different rights and attach different obligations, and the differences matter in ways that are rarely obvious from the filenames.

What a license actually decides

By default, copyright law gives the author exclusive control. Nobody may copy, modify, or redistribute the work without permission. A license is that permission, written down. Every open source license answers three questions, usually in a different order and with different emphasis:

• Permissions: what you may do — run it, modify it, redistribute it, sell it, embed it.
• Conditions: what you must do in exchange — keep notices, publish your source, state your changes.
• Limitations: what the author refuses to promise — no warranty, no liability, sometimes no patent rights.

Read a license by hunting for those three things. The rest is lawyerly detail about how the terms survive termination and which jurisdiction applies.

MIT: short, permissive, easy to live with

MIT is roughly 170 words. You can use the code for anything, including in closed-source commercial software, modify it however you like, and redistribute it under your own terms. There is no requirement to share your changes.

The only real condition is attribution. If you distribute the software — in source or binary form — you must include the original copyright notice and the permission notice. In practice that means keeping the LICENSE file next to the code and preserving copyright headers at the top of source files. Strip those headers and you have broken the license, even though you are shipping something perfectly legal otherwise.

MIT says nothing explicit about patents. That silence is usually treated as harmless for small libraries, but it is the reason some companies prefer Apache 2.0 for anything patent-sensitive.

Apache 2.0: permissive, with a paper trail

Apache 2.0 gives you the same broad freedoms as MIT — commercial use, modification, closed-source redistribution — but it adds clauses that corporate legal departments care about. The most important is an explicit patent grant: contributors license any patents they hold that are necessary to use their contribution. If you sue someone over the software claiming patent infringement, that grant terminates for you. It is a peace treaty written into the license.

Apache 2.0 also asks more of you when you distribute:

• Keep the LICENSE and any NOTICE file, and carry the NOTICE contents into your own distribution.
• State clearly which files you changed — a short note in each modified file is enough.
• Do not imply endorsement. You cannot use the project's name or trademarks to promote your product without permission.

None of this is difficult, but it is work. Teams that treat Apache 2.0 like MIT and quietly drop the NOTICE file are technically out of compliance.

GPL: the copyleft bargain

GPL flips the model. Instead of asking only for attribution, it requires that derivative works stay under the same license. If you distribute a program built on GPL code, you must make the complete corresponding source available under the GPL, and you cannot add restrictions that would prevent recipients from doing the same.

Two details trip people up. First, the obligations trigger on distribution, not on use. Modifying GPL software for internal use, with no code leaving your organisation, does not require you to publish anything. Second, linking matters. In the common interpretation, linking a proprietary program against a GPL library creates a combined work that falls under the GPL. Running a separate process and communicating over a network socket generally does not — which is why so much commercial software talks to GPL tools rather than linking to them.

GPLv2 versus GPLv3

GPLv2 is the older text; GPLv3 adds an explicit patent grant, tighter rules against locking down hardware, and compatibility with Apache 2.0. Some projects say "GPLv2 only", some say "GPLv2 or later", and the difference is real: if a project is v2-only, you cannot combine its code with GPLv3 code. If you have ever seen AGPL, it is the GPL with the network loophole closed — offering the software as a service also counts as distribution.

Compatibility: which license can go inside which

Mixing code from different licenses is where people get into trouble. A rough guide to the common cases:

• MIT into GPL or Apache 2.0: fine. Permissive code can be absorbed into a more restrictive project; the result carries the stricter license.
• Apache 2.0 into GPLv3: fine. The patent terms are compatible.
• Apache 2.0 into GPLv2: not fine. The extra patent and notice conditions are treated as additional restrictions the GPLv2 forbids.
• GPL into an MIT project: not fine, unless you relicense the whole thing under the GPL. You cannot strip copyleft from code you did not write.
• GPLv2-only into GPLv3: not fine. Different licenses, no bridging clause.

A short routine before you ship

You do not need a legal department to stay out of trouble. You need a habit.

1. List your dependencies, including transitive ones. A lockfile or an SBOM gives you this in minutes.
2. Read each license and note it. "MIT" and "Apache-2.0" go in one column, "GPL-2.0-only" and "AGPL-3.0" in another.
3. Check the strictest obligation in the stack. One GPL library can change what you owe for the whole product.
4. Keep every LICENSE and NOTICE file in your distribution. Automate it, because manual copying rots.
5. Preserve copyright headers when you vendor code, and mark your own modifications.

Licenses are contracts written for courts, not manuals written for developers, and reasonable people disagree about edge cases such as dynamic linking or mixed-license plugins. If your product depends on a copyleft library and you plan to ship it commercially, spend an hour with a lawyer who knows software. That conversation costs far less than an accidental relicensing.

Photo: Tima Miroshnichenko / Pexels