Apache 2 is a permissive open source software licence. It allows use, modification and redistribution of covered code, including in proprietary software, and grants an explicit patent licence. It also requires preservation of copyright notices, licence text and any NOTICE file in redistributed copies.
What Apache 2 allows and why it is widely used
Apache 2 is a permissive licence, so it is designed to lower friction for adoption, redistribution, and commercial reuse. That makes it attractive for organisations that want to reuse open source code in proprietary products or internal platforms without inheriting copyleft obligations, while still preserving the original authors’ notice requirements and patent grant.
Its practical value is not just legal permissiveness, but clarity. Apache 2 gives downstream users a known permission set for modification and redistribution, and the explicit patent licence helps reduce uncertainty when code is embedded into products, services, or larger software assemblies.
What Apache 2 requires when you redistribute code
The licence is permissive, but it is not permissionless. Redistributors must keep copyright notices, include the licence text, and preserve any NOTICE file that accompanies the software. Those requirements matter because they carry attribution, provenance, and downstream disclosure obligations forward as the code moves through build and release pipelines.
In practice, organisations often need a simple process for tracking which Apache 2 components are in use, where licence files live, and whether modifications or combined distributions change the packaging obligations. If those artefacts are stripped out during release engineering, the software may still function technically while no longer complying with the licence terms.
How Apache 2 compares with other open source licences
Apache 2 is often chosen over stronger copyleft licences because it supports broader commercial flexibility. It allows proprietary redistribution, which can make it easier to adopt in mixed-source products, SDKs, and cloud services. The trade-off is that the licence places more responsibility on the recipient to preserve notices and understand what rights they are receiving.
The patent licence is another important differentiator. It is one reason Apache 2 is often treated as a business-friendly licence for enterprise software, especially where patent risk and redistribution clarity both matter. That does not remove all legal review, but it does make the licence easier to operationalise than many more restrictive alternatives.
Where Apache 2 creates governance and compliance work
Apache 2 is simple to read, but it still needs licence governance. Organisations should know which repositories, packages, containers, and released binaries contain Apache-licensed material, because attribution and notice handling become part of the release process rather than an optional legal afterthought. This is especially important when code is copied into product builds, redistributed to customers, or bundled with third-party dependencies.
Teams should also treat licence review as part of software intake and release hygiene. A permissive licence can still create compliance gaps if the organisation loses track of modified files, omits the licence text, or fails to carry forward a NOTICE file where one is required.
Risk and Threat Considerations
Apache 2 is low-friction, but that same convenience can create governance risk when teams assume “permissive” means “no obligations”. The main exposure is not exploitability in the software itself, but downstream licence non-compliance, provenance loss, and legal ambiguity if required notices are removed during build, packaging, or redistribution.
Failure mechanism: A software supply chain can strip attribution files, merge Apache 2 code into larger bundles, or replace upstream documentation with internal packaging artefacts, which makes the licence terms harder to satisfy and verify.
Impact: The organisation can lose the patent and redistribution clarity it expected, create release compliance defects, and expose itself to legal or contractual remediation work if licence obligations were not preserved.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, OWASP SAMM and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Integrity | Apache 2 compliance depends on preserving provenance and redistribution artefacts across builds. |
| Recommendation — Track license files and NOTICE artefacts through the build pipeline. | ||
| OWASP SAMM | Governance | Licence handling is part of software governance and release discipline for reused components. |
| Recommendation — Add open source license checks to software governance and release reviews. | ||
| CIS Controls v8 | 2 — Software Inventory | Knowing where Apache-licensed components are used supports licence tracking and redistribution compliance. |
| Recommendation — Maintain an inventory of software components that includes license metadata. | ||
Practitioner Guidance
Why practitioners should care: Apache 2 works best when licence tracking is built into procurement, repository review, and release packaging. The licence itself is permissive, but the operational burden shifts to making sure copyright notices, licence text, and NOTICE content survive every copy and redistribution.
Common misunderstanding: Many teams treat Apache 2 as “just public code” and assume there are no downstream responsibilities. In reality, permissive licensing still needs basic governance, especially in product builds that mix internal and open source components.
Practitioner takeaway: Treat Apache 2 components as governed assets, not untracked freebies, and verify notice preservation before every release.
Related resources from NHI Mgmt Group
- How should teams respond when Apache HTTP Server has a remote code execution CVE?
- What breaks when organisations cannot map embedded Apache instances?
- How should organisations back up Apache Iceberg tables without breaking restores?
- Why do Apache HTTP Server vulnerabilities create broader risk than the CVE alone suggests?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org