The Apache Software License, in its current 2.0 version, is a permissive open source license that lets you use, modify, and distribute the code for any purpose — including commercial — as long as you preserve the license and copyright notices and pass along the required attribution. Its defining feature, and the reason many companies prefer it over MIT, is an explicit patent grant that MIT lacks. If your product bundles Apache-licensed dependencies, understanding a couple of obligations keeps you compliant with almost no friction.
Apache 2.0 is maintained by the Apache Software Foundation and is one of the most common licenses across the open source ecosystem, covering major projects from Kubernetes to Kafka to Android's userspace.
What the Apache Software License permits
Apache 2.0 is deliberately business-friendly. It grants broad rights:
- Commercial use. You can use Apache-licensed code in a product you sell, with no fee and no obligation to open source your own code.
- Modification. You can change the code freely.
- Distribution. You can distribute the original or your modified version, in source or binary form.
- Private use. You can use and modify it internally without any distribution obligations at all.
- Sublicensing. You can incorporate it into a larger work under your own license terms.
Crucially, Apache 2.0 is not a copyleft license. Unlike the GPL, it does not require your derivative work to be released under the same license. You can combine Apache-licensed components into a closed-source, proprietary product.
The patent grant that sets Apache apart
The feature that distinguishes the Apache Software License from simpler permissive licenses is its express patent grant. Section 3 grants every user a royalty-free license to any patents the contributors hold that are necessarily infringed by using the contributed code.
Just as important is the patent retaliation clause: if you initiate patent litigation claiming that the software infringes your patents, the patent license granted to you terminates. This discourages contributors and users from turning around and suing over the very code they received. For companies with patent portfolios, this explicit, defensive patent handling is often the deciding factor in choosing Apache 2.0 over MIT, which stays silent on patents and thus leaves a theoretical gap.
The obligations you must meet
Apache 2.0's requirements are light, but they are real. When you redistribute the code (or a derivative), you must:
- Include a copy of the license with the distribution.
- Preserve copyright, patent, trademark, and attribution notices found in the source.
- State significant changes you made to the files, so downstream users know your version differs from the original.
- Carry the NOTICE file forward. This is the requirement teams most often overlook.
That NOTICE file rule deserves its own explanation.
The NOTICE file: the rule teams miss
If an Apache-licensed project ships a file named NOTICE, you must include its attribution text in your distribution — in the documentation, within the distributed files, or on a screen the software displays. You may add your own attributions, but you may not remove the ones already there.
The subtlety: not every Apache project has a NOTICE file, and the license does not require you to create one. But when a dependency provides one, propagating it is mandatory. A common compliance gap is a build that strips or ignores upstream NOTICE files, which technically breaches the license even though the code itself is freely usable. This is exactly the kind of obligation that automated license scanning is built to catch across a large dependency tree.
Apache 2.0 compared to MIT and GPL
A quick orientation for teams choosing or auditing licenses:
- Versus MIT/BSD: All three are permissive and let you go proprietary. Apache adds the explicit patent grant and the NOTICE/change-statement requirements. MIT is shorter and simpler; Apache is more thorough on patents.
- Versus GPL: The GPL is copyleft — derivatives must be released under the GPL. Apache imposes no such obligation, which is why it is favored for components meant to be embedded in commercial products.
- Compatibility note: Apache 2.0 is compatible with GPLv3 (Apache code can be included in a GPLv3 project) but is not compatible with GPLv2, a wrinkle that occasionally matters when mixing dependencies.
Managing Apache licenses at scale
For a single dependency, the obligations are easy to meet by hand. Across hundreds of transitive dependencies with a mix of licenses, tracking which components require NOTICE propagation and which carry incompatible terms is a job for tooling. Software composition analysis inventories every dependency's license and flags conflicts before they ship; our overview of software composition analysis explains how a bill of materials makes license compliance auditable, and an SCA tool such as Safeguard can generate the attribution report that satisfies the notice requirement automatically.
FAQ
Can I use Apache 2.0 licensed code in a commercial closed-source product?
Yes. Apache 2.0 is permissive and not copyleft, so you can include it in proprietary software without releasing your own source. You must still preserve notices and carry forward any NOTICE file.
What is the difference between the Apache license and MIT?
Both are permissive. The main differences are that Apache 2.0 includes an express patent grant and retaliation clause, and it requires you to state significant changes and propagate the NOTICE file. MIT is shorter and does not address patents.
Do I have to open source my changes under Apache 2.0?
No. You must state that you made significant changes to the files, but you are not required to publish your modifications or license your derivative under Apache.
Is Apache 2.0 compatible with the GPL?
It is compatible with GPLv3 but not with GPLv2. If you mix Apache-licensed and GPLv2 code, check the specific terms, because that combination is generally considered incompatible.