The Apache License, Version 2.0 is a permissive open source license that lets you use, modify, and distribute licensed code — including in proprietary, closed-source, commercial products — as long as you preserve copyright and license notices and don't imply the original authors endorse your product. It's one of the most widely used licenses in commercial software specifically because it's permissive on usage while still including an explicit patent grant, which many otherwise-similar permissive licenses (MIT, BSD) don't address at all.
What is Apache License 2.0, in plain terms?
It's a license published by the Apache Software Foundation in 2004 that grants broad rights to use, reproduce, modify, and distribute the licensed software, for any purpose, including commercially, without requiring you to open-source your own code in return. That last point is the key distinction from copyleft licenses like the GPL: Apache 2.0 doesn't propagate — you can incorporate Apache-licensed code into a proprietary product and ship it without releasing your own source. What it does require is narrower but non-negotiable: preserve the license text, preserve copyright notices, and document any changes you made to the licensed files.
What does Apache License 2.0 commercial use actually allow?
Essentially unrestricted commercial use: you can bundle Apache-licensed code into a paid product, a SaaS offering, or an internal tool sold to customers, without paying royalties or seeking permission. This is what makes it one of the go-to license choices for foundational infrastructure projects (Kubernetes, Kafka, and much of the Apache Software Foundation's own catalog use it) — vendors building commercial products on top need confidence that their commercial use is unambiguously covered, and Apache 2.0 gives them that in explicit terms rather than requiring a legal interpretation of a more ambiguous license.
What does the license actually require you to do?
Four concrete obligations, all focused on attribution and notice rather than code-sharing:
- Include a copy of the license with any distribution of the software or derivative works.
- Preserve copyright, patent, trademark, and attribution notices that were present in the source you received — you can't strip them out.
- State significant changes you made to any files you modified, so downstream users can tell your version apart from the original.
- Include the NOTICE file, if the original project shipped one, and add your own attribution notices to it if required — the NOTICE file is a supplementary attribution mechanism separate from the license text itself, and it's the piece teams most often forget to carry forward when repackaging a dependency.
Why does the patent grant matter more than people assume?
Because Apache 2.0 includes an explicit, irrevocable patent license from every contributor to every user of the software, covering any patent claims the contributor holds that would otherwise be infringed by using the licensed code. That's a meaningful protection MIT and BSD licenses simply don't provide — under those licenses, a contributor could theoretically hold a patent covering some part of the code and separately sue a user for patent infringement, since copyright licenses don't automatically cover patent rights. Apache 2.0 closes that gap, and it includes a defensive termination clause: if you sue anyone over patent claims related to the software, your own patent license under Apache 2.0 terminates. That structure is a large part of why risk-averse enterprises and foundations gravitate toward the license for major infrastructure projects.
How should you track Apache-licensed dependencies at scale?
Once a codebase pulls in hundreds of open source packages, manually reading every license file to confirm compliance stops being realistic — you need automated license detection integrated into your dependency scanning, so a NOTICE-file obligation doesn't get silently dropped when a package is upgraded or a new dependency is added. Software composition analysis tooling that flags license type per dependency, and specifically calls out NOTICE-file requirements, turns a compliance risk that's easy to miss into a checklist item your build can enforce automatically.
FAQ
What is Apache 2.0 license, compared to MIT?
Both are permissive licenses allowing commercial and proprietary use with minimal obligations. The practical difference is the explicit patent grant and termination clause in Apache 2.0, plus its more detailed notice and attribution requirements — MIT is a much shorter, less prescriptive text.
Do you need to open-source your own code if you use Apache 2.0 dependencies?
No. Apache 2.0 is non-copyleft — you can combine it with proprietary code and distribute the combined work under your own terms, as long as you meet the attribution and notice requirements for the Apache-licensed portions.
What is the Apache license's NOTICE file for?
It's a supplementary file, separate from the license text, where a project lists required attribution notices. If you redistribute the software, you generally need to include and update that NOTICE file rather than just the license text alone.
Can Apache 2.0 code be relicensed under a different license?
You can combine it with code under other licenses in a larger work and license your own contributions under different terms, but you can't strip the Apache License from the original code itself — that portion remains under Apache 2.0 regardless of what license governs the surrounding project.