License guide · Comparison
MIT vs Apache-2.0: which should you choose?
The short answer: both are permissive and both are safe for commercial, closed-source software — anything MIT lets you do, Apache-2.0 lets you do too. The differences are about patents and paperwork. Apache-2.0 gives you an express patent grant MIT lacks, and asks for attribution work MIT does not.
Updated 4 Aug 2026 · by the depproof team
General information, not legal advice. Primary sources: the MIT License and the Apache License, Version 2.0.
The comparison, line by line
| Question | MIT | Apache-2.0 |
|---|---|---|
| Use in closed-source commercial software | Yes | Yes |
| Both are permissive. Neither has any copyleft provision. | ||
| Express patent grant from contributors | No — silent on patents | Yes — Section 3 |
| The single most consequential difference. MIT is a copyright license only. | ||
| Defensive patent termination | No | Yes |
| Sue over patents in the work and your Apache-2.0 patent license ends. | ||
| Must propagate a NOTICE file | No such concept | Yes, if one exists |
| A real, distinct obligation — shipping the license text alone does not satisfy it. | ||
| Must mark files you changed | No | Yes |
| Modified files need prominent notices stating that you changed them. | ||
| Express trademark reservation | Silent | Yes — expressly withheld |
| Apache-2.0 says plainly that no trademark rights are granted. | ||
| Combine into a GPL-2.0-only project | Yes | No |
| The FSF reads Apache-2.0’s patent and indemnity terms as added restrictions GPL-2.0 forbids. | ||
| Combine into a GPL-3.0 project | Yes | Yes |
| GPL-3.0 was drafted with explicit accommodation for Apache-2.0’s terms. | ||
| Length of the license | ~170 words | ~10× longer |
| Brevity is why MIT dominates by count; precision is why Apache-2.0 dominates by corporate policy. | ||
The one difference that actually matters: patents
Strip away the wording and this is the decision. MIT is a copyright license — it grants the right to use, copy, modify and sell, and says nothing whatsoever about patents. Whether an implied patent license follows from the right to “use” and “sell” is an argument from inference, not a term you can point at.
Apache-2.0 removes the inference. Section 3 grants an express, perpetual, worldwide, royalty-free and irrevocable patent license from every contributor, covering the claims they control that their contribution necessarily infringes. Paired with it is defensive termination: initiate patent litigation alleging the work infringes, and your patent license ends. The net effect is a mutual non-aggression arrangement among everyone using the code.
For a team shipping ordinary application software, the practical difference is usually small. For anyone with a patent portfolio, anyone in a patent-active field, or anyone whose legal team reviews dependencies before adoption, it is decisive — and it is why large organisations tend to standardise on Apache-2.0.
The cost of Apache-2.0: attribution work
Apache-2.0 asks for more than “keep the notice.” Distributing it or a
derivative means carrying the license, retaining the existing notices,
stating which files you changed, and — the one teams miss —
propagating the upstream NOTICE file’s content
into your own distribution.
MIT has no equivalent. Its single condition is that the copyright and permission notice travel with the software. Both obligations are per-component, which is why either way the practical answer is a generated third-party notices artifact rather than a hand-maintained list — an application of any size carries hundreds of these.
Choosing a license for your own project
- Choose MIT when adoption and friction matter most — a small library, a utility, anything where you want the lowest possible barrier to someone dropping it in. Its brevity is a feature: people read it and move on. It is why MIT dominates by sheer package count, especially in the JavaScript ecosystem.
- Choose Apache-2.0 when patents are real for you or your users, when corporate adopters need to see an express grant before legal will approve it, or when you want defensive termination discouraging patent litigation among your users. It is the default for foundation and enterprise-backed projects for exactly these reasons.
- Either is fine for the great majority of projects, and the choice is far less consequential than choosing between permissive and copyleft. That is the decision that actually changes what your users can ship.
The GPL-2.0 trap
One asymmetry catches people out: MIT combines with GPL-2.0 and Apache-2.0 does not. GPL-2.0 forbids further restrictions on recipients, and the Free Software Foundation reads Apache-2.0’s patent-termination and indemnification terms as precisely that. GPL-3.0 was written with explicit accommodation, so Apache-2.0 and GPL-3.0 combine without issue.
It matters because the conflict is version-specific and one-directional, so it hides. A tree holding both an Apache-2.0 component and a GPL-2.0-only component has a genuine problem that no amount of notice-file diligence resolves — and nothing announces it unless something is classifying licenses per component, across the full transitive tree.
Which ones are actually in your tree?
In practice you rarely choose between MIT and Apache-2.0 — you consume hundreds of both, plus whatever else arrives transitively. The useful question is not which is better but which obligations you have actually taken on, and whether anything in the tree conflicts.
- Check your npm dependency licenses — every direct and transitive package, straight from the lockfile.
- Check your Maven dependency licenses — the full transitive tree, with no build.
- Apache-2.0 vs GPL-3.0 — the bigger decision: permissive versus copyleft, and what each obliges you to publish.
- The license guide — plain-English pages for every family, permissive through network copyleft.
Frequently asked questions
What is the difference between the MIT and Apache-2.0 licenses?
Both are permissive licenses that allow use in closed-source commercial software with no copyleft. Apache-2.0 adds three things MIT does not have: an express patent grant with defensive termination, a requirement to state which files you modified, and an obligation to propagate the upstream NOTICE file. It also expressly withholds trademark rights. MIT is roughly 170 words and asks only that you preserve the copyright and permission notice.
Which is better, MIT or Apache-2.0?
Neither is better in the abstract — they optimise for different things. Choose MIT when maximum adoption and minimum friction matter, which is why it dominates small libraries and the JavaScript ecosystem. Choose Apache-2.0 when patents are a real consideration, when corporate legal teams need to see an express grant before adopting your project, or when you want the defensive termination clause to deter patent litigation among users.
Is Apache-2.0 more restrictive than MIT?
Slightly, but not in a way that limits what you can build. Every use MIT permits, Apache-2.0 also permits — commercial, proprietary, closed-source, sold. The additional Apache-2.0 requirements are administrative: carry the NOTICE content, mark changed files, and do not use the project’s trademarks. It is more paperwork, not less freedom.
Can I use MIT and Apache-2.0 code in the same project?
Yes, without difficulty. Both are permissive and neither imposes conditions the other forbids, so a project can contain dependencies under both — as the overwhelming majority of real projects do. You simply satisfy each component’s own attribution obligations: the copyright notice for MIT components, and the license plus NOTICE content and change statements for Apache-2.0 ones.
Why is Apache-2.0 incompatible with GPL-2.0 when MIT is not?
GPL-2.0 forbids imposing any further restrictions on downstream recipients. The Free Software Foundation treats Apache-2.0’s patent-termination and indemnification provisions as exactly such restrictions, so the two cannot be combined. MIT contains no comparable terms, so it raises no conflict. Note this is specific to GPL-2.0 — Apache-2.0 and GPL-3.0 combine without issue.
Does MIT really give no patent rights at all?
MIT grants rights to "use" and "sell" the software, and some argue an implied patent license follows from that. But it is an argument from inference rather than an express grant, and it has not been settled definitively. If your risk posture depends on patent protection, an argument is a weaker foundation than Apache-2.0’s explicit Section 3 grant.
General information, not legal advice; confirm specific decisions with counsel. “Apache” and the Apache License refer to the license published by the Apache Software Foundation and are used nominatively.