The Apache License 2.0 is a permissive open-source license that lets you use, modify, distribute, and sell software (including in closed-source products) as long as you preserve attribution and license notices, state significant changes, and include the project's NOTICE file if it has one. Its defining feature over other permissive licenses is an explicit patent grant, which is why it is the default for many large corporate open-source projects. It is not copyleft: you are never forced to open-source your own code. If you're specifically weighing apache 2.0 license commercial use — or apache license 2.0 commercial use, same question in a different word order — can you sell a product built on it without releasing your source — the short answer is yes, and the rest of this guide unpacks exactly why. It's also unambiguously open source: if you've separately wondered is apache 2.0 license open source as well as commercial-use-friendly, both answers are yes. (You may also see this license called the Apache Software License 2.0; it's the same text, just an older name still used by some package registries.)
That paragraph above is effectively the Apache License 2.0 summary — or the apache 2.0 license tldr, if you're skimming — and the rest of this guide walks through each part with the actual clause language.
If you ship software, the Apache 2 license is one of the handful of licenses you will meet constantly, so it pays to know exactly what it asks of you.
What does the Apache 2.0 license permit?
The grant is broad. Under the Apache 2.0 license you may:
- Use the software for any purpose, including commercial.
- Modify the source however you like.
- Distribute original or modified copies.
- Sublicense and incorporate it into a larger, proprietary work.
- Use it privately without ever distributing anything.
Crucially, you can combine Apache-licensed code with proprietary code and keep your additions closed. The permissive nature is what makes it friendly to commercial adoption, and it is why you will find it on projects like Kubernetes, Kafka, Cassandra, and the Android Open Source Project.
What are the conditions of the Apache License 2.0?
Permissive does not mean obligation-free. When you redistribute Apache-licensed software, in source or binary form, the Apache License 2.0 requires four things:
- Include the license. Ship a copy of the Apache License 2.0 text with any distribution.
- Preserve notices. Keep all copyright, patent, trademark, and attribution notices present in the source. Do not strip them.
- State changes. If you modify files, carry prominent notices stating that you changed them. This is the "change notice" requirement and it trips up teams who assume permissive means "do anything silently."
- Include the NOTICE file. If the project distributes a
NOTICEfile, you must include a readable copy of its attribution notices in your distribution (in the source, the documentation, or a display generated by the work). You may add your own notices, but you cannot remove the upstream ones.
What it does not require: you do not have to release your source code, you do not have to license your product under Apache 2.0, and there is no viral effect. Those are the copyleft obligations of licenses like the GPL, and the Apache 2 license deliberately avoids them. That four-item list is the apache license 2.0 summary of what the license actually asks of you — everything else is permission, not obligation. However you phrase the search — apache license commercial use, apache-2.0 license commercial use, or apache 2 license commercial use — the underlying answer is identical: yes, provided you meet the four conditions above.
Why does the Apache 2.0 patent grant matter?
This is the clause that sets the Apache License 2.0 apart from MIT and BSD, and it's the crux of most apache vs mit license, apache license vs mit, or apache 2.0 license vs mit comparisons you'll find online. Section 3 grants every user an express, royalty-free patent license from each contributor covering their contributions. In plain terms, contributors cannot hand you code and later sue you for infringing patents that read on that code.
It also includes a patent retaliation clause: if you initiate patent litigation claiming the software infringes your patents, your patent license under the agreement terminates. That trade discourages patent aggression among users of the same project.
For a company evaluating dependencies, the explicit patent grant reduces a real legal risk that MIT and BSD leave unaddressed by their silence. It is a large part of why enterprise legal teams are comfortable with Apache-licensed components.
Is the Apache License 2.0 good for commercial use?
Yes, and that is by design — apache 2.0 license commercial use, or apache license 2.0 commercial use if you prefer that word order, is exactly what the permissive grant was written for. You can build a paid, closed-source product on Apache-licensed components without opening your code, provided you meet the attribution, NOTICE, and change-notice conditions above. The permissive terms plus the patent grant are why it is one of the most common licenses in the commercial software supply chain.
Two practical notes for commercial teams:
- GPL compatibility. Apache 2.0 is compatible with GPLv3 (code can flow into a GPLv3 project) but not with GPLv2, because of the patent and termination language. If you mix licenses, this asymmetry matters.
- Attribution at scale. The NOTICE and attribution requirements are easy per project and painful across hundreds of dependencies. Most teams generate a third-party notices file automatically rather than tracking it by hand.
Tracking which of your dependencies are Apache 2.0 versus copyleft is exactly the kind of thing that gets out of date the moment someone adds a package. Software composition analysis reads every dependency's license and flags obligations and conflicts as they enter the tree. Some package registries still list this as the Apache Software License rather than Apache License 2.0 — same text, different label — which is exactly the kind of naming inconsistency SCA tooling needs to normalize when tracking licenses across dependencies. Safeguard's SCA surfaces license type alongside vulnerability data so legal review and security review use the same inventory. For how the major licenses compare, the Safeguard blog has a full breakdown of license families.
FAQ
What is the difference between the Apache 2.0 license and MIT?
If you're comparing apache vs mit license (or apache license vs mit — same question, different phrasing): both are permissive and allow commercial, closed-source use. The key differences: Apache 2.0 includes an explicit patent grant and retaliation clause, requires you to state significant changes, and requires you to preserve any NOTICE file. MIT is shorter, has no patent language, and asks only that you keep the copyright and license text.
Do I have to open-source my code if I use an Apache 2.0 library?
No. The Apache License 2.0 is permissive, not copyleft. You can keep your own source closed. You only need to include the license, preserve notices, state changes to Apache-licensed files, and ship the NOTICE file if one exists.
What is the NOTICE file requirement?
If an Apache-licensed project ships a file named NOTICE, you must include its attribution text in your redistribution. You can add your own notices but cannot remove upstream ones. If the project has no NOTICE file, there is nothing extra to carry beyond the standard notices.
Is the Apache 2 license compatible with the GPL?
It is compatible with GPLv3, so Apache 2.0 code can be included in a GPLv3 project. It is not compatible with GPLv2 because of the patent termination and additional-restriction language. Check the direction of combination before mixing the two.
Is the Apache 2.0 license open source?
Yes. It's approved by the Open Source Initiative (OSI) and meets the Open Source Definition, alongside MIT, BSD, and GPL. Permissive and open source aren't in tension here — it's both.