Here is the short Apache License 2.0 summary: it is a permissive open-source license that lets you use, modify, and distribute the software — including in closed-source commercial products — as long as you preserve attribution notices and an express patent grant travels with the code. It is not copyleft, so it does not force you to open-source your own work. Below is a practical breakdown of what the license permits, requires, and forbids, and how it stacks up against the alternatives you will run into.
What you are allowed to do
The Apache License 2.0, published by the Apache Software Foundation in January 2004, grants broad permissions. Under it you may:
- Use the software for any purpose, commercial or private.
- Modify the source however you like.
- Distribute original or modified copies.
- Include it in proprietary, closed-source products.
- Sublicense it as part of a larger work.
That combination is why so much enterprise software ships with Apache-licensed components inside. You can build a paid product on top of Apache-licensed code without publishing your own source, which the strong copyleft licenses do not allow.
What you are required to do
The permissions come with a small set of conditions. This is the part teams most often get wrong, because "permissive" gets misread as "no obligations."
Keep the license and copyright notices. When you redistribute, you must include a copy of the Apache License 2.0 and retain existing copyright, patent, trademark, and attribution notices from the source.
Preserve the NOTICE file. If the original work includes a NOTICE file, you must carry forward its attribution text in your distribution. This is unique enough that people miss it — MIT has no equivalent. You can add your own notices, but you cannot strip the upstream ones.
State significant changes. If you modify files, you must mark them as changed so downstream users can tell your version from the original.
None of this requires you to release your source. The obligations are about attribution and traceability, not reciprocity.
What the license does not allow
The Apache 2.0 license summary would be incomplete without the limits. You may not:
- Use the names, trademarks, or logos of the project or its contributors to endorse your product. The license explicitly withholds trademark rights.
- Hold contributors liable — the software is provided "as is," with no warranty.
- Assume any patent rights beyond the express grant the license provides.
These are protective rather than restrictive; they shield contributors rather than constrain your usage.
The patent grant is the headline feature
The single most important thing in any Apache 2.0 license summary is the explicit patent clause. Contributors grant you a royalty-free license to any patents they hold that are necessarily infringed by their contribution. In plainer terms: if a contributor's code relies on a patent they own, they cannot later sue you for using the software as licensed.
The license also includes a patent retaliation provision. If you initiate patent litigation claiming the software infringes your patents, your patent license under Apache 2.0 terminates. This discourages contributors and users from weaponizing patents against the project.
MIT and BSD licenses are silent on patents, which leaves a theoretical gap: a contributor could open-source code and separately assert a patent over it. Apache 2.0 closes that gap explicitly, and that legal clarity is precisely why risk-averse enterprises favor it.
How it compares to MIT and GPL
For an apache license summary to be useful, it helps to place it on the spectrum.
Versus MIT: Both are permissive and business-friendly. MIT is shorter and simpler, but it says nothing about patents and has no NOTICE-file requirement. Apache 2.0 is longer, adds the express patent grant, and adds the attribution-preservation obligations. If patent exposure worries your legal team, Apache 2.0 is the safer permissive choice.
Versus GPL: This is the sharp divide. The GPL is copyleft — distribute a derivative work and you must release your source under the GPL too. Apache 2.0 imposes no such reciprocity, so you can combine it into proprietary software freely. Note one directional quirk: Apache 2.0 code can be included in GPLv3 projects, but the reverse does not hold, because GPL's conditions are stricter.
If you want the full landscape of permissive versus copyleft terms, our guide to what a software licence is walks through the categories.
Staying compliant at scale
Reading one license is easy. The real challenge is a repository with hundreds of dependencies, each carrying its own terms, transitively. A single GPL component pulled in three layers deep can create obligations your Apache-licensed direct dependencies never hinted at.
This is where automated license inventory earns its keep. Software composition analysis reads the license metadata of every direct and transitive dependency and flags conflicts against your policy — for instance, warning when a copyleft license shows up in a product you ship as closed source. A tool like Safeguard's SCA builds that inventory from your SBOM so the NOTICE-file and attribution obligations are tracked rather than discovered during due diligence. For teams shipping commercial software, catching an incompatible license before release is far cheaper than untangling it after a customer's legal review flags it.
FAQ
Can I use Apache 2.0 code in a closed-source commercial product?
Yes. Apache 2.0 is permissive and explicitly permits inclusion in proprietary, closed-source software. You must preserve the license text, copyright notices, and any NOTICE file, and mark modified files, but you are not required to release your own source code.
Do I have to publish my changes under Apache 2.0?
No. Unlike copyleft licenses such as the GPL, Apache 2.0 does not require you to license your modifications or derivative works under the same terms. You only need to note that files were changed and preserve the upstream attribution notices.
What is the NOTICE file requirement?
If an Apache-licensed project ships a file named NOTICE, its attribution text must be carried into your distribution. You can append your own notices but cannot remove the original ones. This attribution obligation is specific to Apache 2.0 and has no MIT equivalent.
Is Apache 2.0 compatible with the GPL?
Apache 2.0 code can be incorporated into GPLv3 projects, but not the other way around because of the GPL's stronger conditions. Apache 2.0 is generally considered incompatible with GPLv2 due to specific patent and termination clauses, so check the exact GPL version before combining code.