Apache 2.0 License is a permissive open-source software licence that lets people use, modify, distribute and sublicense covered code. It requires preservation of notices, inclusion of a copy of the licence, and a patent grant with termination terms if a contributor files certain patent claims.
What the Apache 2.0 License allows
Apache 2.0 is a permissive licence, so it is designed to make reuse easy. Organisations can adopt covered code in proprietary or open-source products, modify it, and redistribute it, including in combined or commercial software.
The practical effect is that Apache 2.0 lowers legal friction for software reuse, but it does not remove the need to comply with notice, attribution and patent-related conditions. Those obligations travel with the code, even when the code is embedded inside a larger product or service.
Core obligations and redistribution rules
The licence is often chosen because it is straightforward to operationalise, but it is not “anything goes”. Redistributions must preserve required notices, include a copy of the licence, and keep the terms that apply to derivative or combined works consistent with the licence grant.
That means release engineering, legal review and open-source programme management need to treat Apache-licensed components as governed assets, not as informal snippets. The main compliance work is making sure the distributed artefact still carries the required licence text and notices in the places the licence expects.
In practice, teams should track the licence status of each dependency, component and bundled artifact so that packaging decisions do not accidentally strip the attribution material that Apache 2.0 requires.
Patent grant and termination terms
Apache 2.0 is notable because it includes an explicit patent grant. That gives downstream users more certainty than a simple copyright licence, but it also introduces a termination mechanism if a contributor files certain patent claims against the work.
This matters because the licence is not only about copying code, it also governs the legal relationship around patent rights. For organisations that ship software, the patent clause changes how they assess contribution policies, inbound code acceptance and downstream use of the project.
The result is a licence that is permissive in distribution but still protective against some forms of patent aggression. That balance is one reason Apache 2.0 is widely used in ecosystems where adoption speed and legal clarity both matter.
How Apache 2.0 fits into open-source governance
For security and engineering teams, Apache 2.0 is part of software governance as much as it is a legal document. It helps define what can be reused, what must be preserved and what obligations survive redistribution, which makes it relevant to dependency management and release controls.
It is also one of the licences organisations commonly review when deciding whether a component can move from internal evaluation into a shipped product. The key question is not just “can we use it?”, but “can we meet the notice, distribution and patent conditions at scale?”
Because Apache 2.0 is permissive, it is usually simpler to operationalise than reciprocal licences, but that simplicity can create complacency. Governance fails when teams treat permissive licences as exempt from tracking, attribution or approval workflows.
Risk and Threat Considerations
Apache 2.0 itself is not a security control, but licence non-compliance can create real organisational risk. The most common failure mode is accidental omission of notices, licence text or patent terms during packaging, release automation or downstream redistribution.
Failure mechanism: Build and release processes strip required licence materials, or teams reuse code without preserving the conditions attached to redistribution and patent grant.
Impact: The organisation can inherit legal exposure, forced remediation work, release delays or disputes over whether software was redistributed in accordance with the licence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, OWASP SAMM and SLSA set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-15 — Service Provider Management | Tracks third-party software obligations and licence governance in the supply chain. |
| Recommendation — Inventory open-source components and verify licence obligations before release. | ||
| OWASP SAMM | SAMM Governance — Governance | Covers policy and oversight for software composition and release practices. |
| Recommendation — Define licence review gates in your software governance process. | ||
| SLSA | Supply Chain Integrity | Supports provenance and integrity expectations for distributed software artifacts. |
| Recommendation — Preserve build provenance so licence obligations stay attached to released artifacts. | ||
| ISO/IEC 27001:2022 | A.5.31 — Legal, statutory, regulatory and contractual requirements | Apache 2.0 creates contractual-style obligations that must be tracked and met. |
| Recommendation — Register Apache 2.0 obligations in your compliance process. | ||
Practitioner Guidance
Governance implication: Treat Apache 2.0 components as items that need inventory, review and release-time checks, not as “safe by default” dependencies. The operational issue is usually evidence of compliance, not the permissiveness of the licence itself.
Practitioner takeaway: If Apache 2.0 code is shipped, the safest assumption is that licence text, notices and patent-related terms must be deliberately carried through the build and distribution process.
Related resources from NHI Mgmt Group
- How should organisations measure identity security ROI beyond license savings?
- How should teams use Salesforce license analysis in governance decisions?
- How can organisations tell if automated license optimisation is safe?
- How should teams respond when Apache HTTP Server has a remote code execution CVE?