Apache License Version 2.0 commercial use is explicitly allowed: you can use, modify, distribute, and sell software licensed under Apache 2.0 in a closed-source commercial product without paying royalties, as long as you meet a few attribution and notice obligations. It is a permissive license, in the same family as MIT and BSD, but with more precise language around patents and contributions. That precision is why so many companies prefer it for dependencies they ship in products.
So when developers ask "can I use Apache License 2.0 in commercial software," the answer is yes. The useful question is what you owe in return, because "permissive" is not the same as "no obligations."
What Apache 2.0 grants you
The license grants two things that matter commercially. First, a broad copyright license: you may reproduce, prepare derivative works of, publicly display, sublicense, and distribute the work and derivative works. Second, and this is the part MIT lacks, an express patent grant. Each contributor grants you a patent license covering their contributions, so you are protected from patent claims by the people who wrote the code.
There is no copyleft. You are not required to open-source your own code just because you depend on an Apache-licensed library. You can link it, bundle it, modify it, and keep your modifications proprietary. That is the core reason it shows up in commercial products constantly, from Kubernetes to countless npm and Maven packages.
The obligations you actually have
Using it commercially comes with four concrete requirements when you redistribute the software or a derivative:
- Include the license. Ship a copy of the Apache License 2.0 text with your distribution.
- Preserve notices. Keep all copyright, patent, trademark, and attribution notices from the source. Do not strip them.
- State changes. If you modified the files, carry a prominent notice saying you changed them.
- Include the NOTICE file. If the original work has a
NOTICEfile, you must include its attribution content in your distribution, though you can add your own.
That fourth one trips people up most often. The NOTICE file is a distinctive Apache 2.0 requirement, and forgetting to propagate it into your build artifact is the most common compliance gap I see in audits. It is not enough to keep it in your source tree; it has to reach whatever you actually ship.
Patents and the termination clause
The patent grant has teeth. If you initiate patent litigation alleging that the Apache-licensed work infringes a patent, your patent license under that work terminates. This is a defensive design: it discourages contributors and users from weaponizing patents against the project. For a commercial user it is rarely a problem, but your legal team should know it exists before you build a patent strategy around a product that ships Apache-licensed code.
Trademarks are explicitly not granted. The license lets you use the code, not the project's name or logo to market your product. Selling "our product, powered by ProjectX" is fine; selling something branded to imply it is the official ProjectX is not.
Tracking obligations at scale
The obligations above are trivial for one dependency and unmanageable by hand for a thousand. A modern application pulls in hundreds of transitive packages, each with its own license, and Apache 2.0 will be mixed with MIT, BSD, ISC, and the occasional copyleft surprise like GPL or AGPL that genuinely does have commercial implications.
The practical control is a license inventory built from your SBOM. Generate a software bill of materials, extract the declared license for every component, and flag anything that is not on your approved list. This is where the risk usually hides: not in the Apache-licensed packages you chose deliberately, but in a transitive dependency five levels down that carries a license your legal policy does not allow. An SCA tool can produce that license report automatically and alert you when a new dependency introduces a license outside policy. If you are comparing options, our pricing page breaks down what license scanning is included at each tier.
A quick compliance workflow
For a team shipping commercial software with Apache-licensed dependencies:
- Automate SBOM generation in CI so the license inventory is never stale.
- Maintain an allowlist of approved licenses; Apache 2.0, MIT, BSD, and ISC are typically on it.
- Fail the build on a copyleft license appearing in a component you distribute, unless legal has cleared it.
- Aggregate every
NOTICEfile and license text into the attribution document you bundle with releases.
Done this way, "can I use Apache License 2.0 in commercial software" stops being a per-dependency judgment call and becomes a policy your pipeline enforces.
FAQ
Do I have to open-source my code if I use an Apache 2.0 library?
No. Apache 2.0 is permissive and has no copyleft. You can keep your own code proprietary while depending on, modifying, and bundling Apache-licensed software.
Do I owe royalties for commercial use of Apache 2.0 software?
No. The license grants use, modification, and distribution royalty-free, including in commercial and closed-source products.
What is the NOTICE file and do I have to include it?
If the original work ships a NOTICE file, its attribution content must be carried into your distribution. It is the most commonly missed Apache 2.0 obligation because it has to reach your build artifact, not just live in your source tree.
Can I use the project's name or logo to market my product?
No. Apache 2.0 grants a copyright and patent license but explicitly does not grant trademark rights. You can say your product uses the software, but you cannot brand it as the official project.