What is the Apache 2.0 license?
The Apache 2.0 license is a permissive open-source license maintained by the Apache Software Foundation. It gives you broad freedom to use, modify, and distribute code, including in commercial and proprietary products, with few legal restrictions.
A permissive license allows commercial use without disclosure, whereas a copyleft license requires you to release modified code under the same terms. Copyleft licenses like the GPL are "viral": Modify the code, and you're legally required to release your changes under the same open-source terms. The Apache 2.0 license removes that requirement.
You can add Apache-licensed components into proprietary codebases without ever triggering an obligation to open-source your own code. Kubernetes, TensorFlow, Android, Kafka, and Spark are distributed under Apache 2.0.
Engineering teams use these components because they provide verified code with explicit patent grants and clear attribution requirements. For enterprise buyers and legal teams, they offer clear patent grants, defined attribution rules, and zero IP contamination risk from restrictive licenses.
When teams require immediate legal clarity, Apache 2.0 serves as a common standard.
Data Governance & Compliance in the Cloud
This Guide to Data Governance and Compliance in the Cloud provides a straightforward, 7-step framework to help you strengthen your cloud governance approach with confidence.
How does Apache 2.0 license commercial use work?
Apache 2.0 is fully commercial-friendly. No royalties, no copyleft obligations, no requirement to open-source your proprietary code. Just meet the attribution requirements, and you're good to ship.
Apache 2.0 license permissions and requirements
Apache 2.0 offers extensive freedom, but its permissive nature includes specific legal obligations. Cloud teams must track these requirements carefully because automated container builds can omit attribution artifacts.
What Apache 2.0 allows:
Commercial use: Integrate and sell software for profit without restrictions.
Modification: Alter source code to fit specific architectural needs.
Distribution: Share modified and unmodified versions freely.
Sublicensing: Incorporate code into proprietary works under different terms.
Patent use: Access a royalty-free, worldwide patent license granted by contributors.
What Apache 2.0 requires:
Attribution: Include the original copyright notice and license text in every distributed copy.
NOTICE files: Preserve upstream NOTICE files during builds and distribution.
State changes: Flag any files you modify to show what changed.
No trademark use: Avoid using the project name for branding or endorsement.
Then there's the patent retaliation clause. If you initiate patent litigation against any entity over Apache-licensed software, your patent license terminates automatically. This provision operates without a grace period. Enterprises often select this license over alternatives like MIT for its explicit patent protections.
Apache 2.0 license vs. MIT vs. AGPL
This table compares the Apache 2.0 license versus MIT and Affero General Public License (AGPL) to highlight key differences in commercial use and patent protection.
| Feature | Apache 2.0 | MIT | AGPL |
|---|---|---|---|
| License category | Permissive | Permissive | Strong copyleft |
| Commercial use | Permitted unconditionally | Permitted unconditionally | Permitted (but triggers open-source requirement) |
| Patent protection | Explicit grant and retaliation clause | None explicitly provided | Explicit grant |
| Copyleft obligation | None | None | Network copyleft; source availability |
| SaaS/Cloud trigger | No | No | Yes (network access constitutes distribution) |
| Compliance burden | Moderate (NOTICE files, attribution, state changes) | Low (preserve copyright notice) | High (Corresponding Source via network use) |
The AGPL includes a network-use trigger that counts API access as distribution. For example, when a platform uses an AGPL-licensed analytics library on the backend to surface results through a REST API, the library triggers the license requirements. This network interaction alone can trigger AGPL's source-availability obligation, which could require open-sourcing your entire proprietary backend. That's why many enterprises choose to block AGPL dependencies and standardize on Apache 2.0 license to manage proprietary codebases effectively.
What are the security risks of Apache 2.0 adoption?
1. Transitive dependency risk
Your app might not directly import a vulnerable library, but something it depends on probably does. During Log4Shell, a significant share of affected Java projects inherited Log4j through transitive dependencies rather than direct imports. That pattern is why software composition analysis (SCA) tools need to inspect the full dependency graph, not just top-level packages. SCA tooling allows teams to identify this exposure in production.
2. Supply chain risks
Permissive, community-driven projects are prime targets for supply chain attacks. Malicious commits, compromised maintainer accounts, and typosquatting packages are all active risks. The XZ Utils backdoor showed how a patient attacker can spend years building community credibility before compromising a foundational component.
Because organizations trust Apache 2.0 libraries, a single compromised component can quickly affect thousands of enterprise environments.
3. Volunteer maintenance and patch lag
Enterprise SLAs don't apply to open-source maintainers. When a zero-day drops, upstream patches can take days or weeks. Security teams cannot wait for upstream fixes. Security teams need independent CVE monitoring, pre-staged compensating controls such as WAF rules, network segmentation, and runtime application self-protection, and a process for deploying mitigations while maintainers prepare patches.
4. Policy and compliance drift
Multi-stage Docker builds strip LICENSE and NOTICE files to minimize image size, which teams identify and resolve during audits or M&A due diligence. In microservices architectures, tracking Apache 2.0 obligations across dozens of services becomes a serious inventory challenge.
Watch 12-min demo
Learn what makes Wiz the platform to enable your cloud security and compliance operations.
Best practices for Apache 2.0 license compliance in cloud environments
1. Automate SBOMs and SCA scanning in CI/CD
Generate SBOMs in CycloneDX or SPDX format automatically at build time, and integrate SCA scanning directly into your pipeline. Identify vulnerabilities and license issues before artifacts reach deployment, not during an audit.
2. Enforce license policy as a CI/CD gate
Treat license compliance like a security control. Gate your pipeline to automatically block builds that introduce incompatible licenses like GPLv2, SSPL, or custom restrictive terms. Effective license gates parse the full transitive dependency tree, including build-time and runtime dependencies, and block promotion when artifacts introduce disallowed licenses.
3. Maintain a real-time open-source inventory
Your package.json or pom.xml shows what you intended to build. It doesn't show what's actually running in production. Runtime SCA scanning catches components that sneak in through base images, Kubernetes sidecars, or just-in-time installs, which may exist outside of standard source control visibility.
4. Monitor and patch vulnerable dependencies
Security teams should monitor CVE feeds independently and prioritize remediation based on runtime exposure. When upstream patches are delayed, teams should deploy compensating controls such as WAF rules, segmentation, or temporary workload restrictions.
Security teams should also use independent monitoring to manage remediation timelines regardless of upstream patch schedules.
Managing open-source risks with Wiz
Apache 2.0 accelerates software adoption, but that same reach makes open-source components spread deeply across cloud environments, often beyond what build-time tools can see. Wiz helps teams manage that sprawl by connecting what developers declare in code to what actually runs in containers, Kubernetes clusters, and cloud workloads.
Wiz uses agentless SCA to go beyond manifest files and scan across source code, container registries, and running workloads. That means every Apache-licensed component and transitive dependency actually deployed in your environment gets accounted for, including components introduced through base images or sidecars.
When vulnerabilities surface, the Wiz Security Graph connects them to runtime context, turning an unprioritized CVE list into a list of exploitable and business-critical risks.
Wiz Code catches vulnerable packages and non-compliant licenses before they hit production. When something does slip through, code-to-cloud traceability traces the finding back to the specific repo and developer that introduced it, so remediation becomes immediate and targeted.
For legal and governance teams, Wiz maintains a centralized inventory of open-source usage across your entire cloud environment, surfacing license issues alongside security findings so engineering, security, and legal are always working from the same data.
Ready to secure your open-source software supply chain? Schedule a demo to see how Wiz provides visibility into your Apache 2.0 dependencies.
100+ Built-In Compliance Frameworks
See how Wiz eliminates the manual effort and complexity of achieving compliance in dynamic and multi-cloud environments.
