Apache v2 — formally the Apache License 2.0 — is a permissive open-source license that lets you use, modify, distribute, and commercialize the code with almost no restrictions, in exchange for preserving attribution notices and an explicit patent grant. It's one of the most common licenses you'll encounter in a dependency tree, sitting alongside MIT and BSD in the permissive camp, and it powers projects like Kubernetes, Android's open-source parts, and much of the Apache Software Foundation's own portfolio. If you ship software, you need to know what the Apache v2 license asks of you, because "permissive" is not the same as "no obligations." This guide covers what it permits, what it requires, and where teams get compliance wrong.
What the Apache License 2.0 is
The Apache License version 2.0 was released by the Apache Software Foundation in January 2004, replacing the older 1.1 version. It's an OSI-approved, permissive license, meaning it imposes minimal conditions on how you use and redistribute the covered software. Crucially, it is not a copyleft license: unlike the GPL, it does not require you to open-source your own code just because you used Apache-licensed code in it. You can combine Apache v2 components into a closed-source, commercial product and keep your own code proprietary.
That combination — permissive terms plus a formal patent grant — is why it's a favorite for corporate-backed open source. Companies can contribute and adopt without the copyleft obligations that make legal teams nervous.
What Apache v2 lets you do
Under the Apache license v2 you may, royalty-free and perpetually:
- Use the software for any purpose, including commercial.
- Modify the source however you like.
- Distribute original or modified copies, in source or binary form.
- Sublicense and incorporate it into larger works under different terms (your additions can be under your own license).
- Use it privately without distributing anything.
There's no requirement to share your modifications, no "viral" propagation to your own code, and no fee. In practice this is close to the freedom MIT gives you.
What the Apache v2 license requires of you
The obligations are modest but real, and they apply whenever you redistribute the software (in source or binary):
- Include the license. Ship a copy of the Apache License 2.0 text with any distribution of the covered work.
- Preserve copyright, patent, trademark, and attribution notices found in the source. You can't strip them out.
- Retain the NOTICE file. This is the one people miss. If the original project includes a
NOTICEfile, you must include its attribution text in your distribution — in the documentation, an about screen, or a bundled NOTICE. You may add your own notices but must not remove the originals. - State significant changes. If you modified the files, mark that you changed them (a modification notice in changed files satisfies this).
What you do not have to do: publish your source, license your own code under Apache v2, or pay anything. Compared to copyleft, this is light. But "light" still means you owe attribution and NOTICE handling, and shipping without them is a genuine license violation.
The patent grant — the feature that sets it apart
The most important difference between Apache v2 and MIT/BSD is its express patent license. When someone contributes code under Apache v2, they grant every user a royalty-free license to any patents that contribution necessarily practices. In plain terms: you get protection that the contributors won't sue you for patent infringement over their own contributed code.
There's a defensive twist. The grant includes a patent retaliation clause: if you initiate patent litigation claiming the software infringes your patents, your patent license under Apache v2 terminates automatically. This discourages using the software and then turning around to sue over it. MIT and BSD, by contrast, say nothing about patents at all, which leaves a gap Apache v2 deliberately closes.
Compatibility and the compliance angle
Apache v2 is compatible with the GPL version 3, so you can combine Apache-licensed code into a GPLv3 project. It is not compatible with GPL version 2, because GPLv2 predates and conflicts with some Apache v2 terms (notably the patent and indemnification provisions). If you're mixing licenses, that GPLv2 incompatibility is the trap to watch for.
From a supply-chain perspective, the practical problem isn't understanding one license — it's tracking hundreds across a dependency tree. A single application pulls in components under Apache v2, MIT, BSD, ISC, and occasionally something copyleft that shouldn't be there. You need to know, at build time, what licenses you're shipping and whether any conflict with your distribution model. A software bill of materials with per-component license data is how you keep that honest, and an SCA tool such as Safeguard can flag a license that violates your policy before it reaches a release. Our software composition analysis page covers how license and vulnerability data get tracked together.
Practical checklist for shipping Apache v2 code
- Bundle the full Apache License 2.0 text with your distribution.
- Copy through any
NOTICEfile content into your product's notices. - Don't strip copyright or attribution headers from source files you redistribute.
- If you modified files, note the changes.
- Track licenses across your whole dependency tree, not just direct dependencies, and check for the GPLv2 incompatibility if you also ship copyleft code. Our security academy has more on building an open-source license policy.
FAQ
Can I use Apache v2 code in a commercial, closed-source product?
Yes. Apache v2 is permissive and not copyleft, so you can incorporate it into proprietary, commercial software and keep your own code closed. You must still include the license text, preserve attribution notices, and carry through any NOTICE file when you distribute.
What is the NOTICE file requirement in the Apache license v2?
If the original project ships a NOTICE file, you must include its attribution text in your distribution — in documentation, an about screen, or a bundled file. You can add your own notices but must not remove the originals. Forgetting this is the most common Apache v2 compliance mistake.
How is Apache v2 different from the MIT license?
Both are permissive, but Apache v2 adds an explicit patent grant with a retaliation clause and requires preserving the NOTICE file and stating modifications. MIT is shorter and says nothing about patents. Apache v2's patent protection is the main reason larger projects and companies prefer it.
Is Apache v2 compatible with the GPL?
It's compatible with GPL version 3, so Apache-licensed code can be combined into a GPLv3 project. It is not compatible with GPL version 2 due to conflicting patent and indemnification terms. If you mix licenses, that GPLv2 incompatibility is the one to verify.