Apache License 2.0 Explained — Plain English Guide (Patent Rights & Commercial Use)

The Apache License 2.0 is a permissive open-source license like MIT, but with an explicit patent grant that protects users from patent lawsuits by contributors — making it the preferred license for corporate-backed projects. It powers Android, Kubernetes, Swift, and TensorFlow, and is the standard choice for projects where patent protection matters.

What You’ll Learn

By the end of this guide, you’ll understand how Apache 2.0’s patent grant works, whether you can use Apache-licensed code in commercial products, what the NOTICE file requirement means, and when to choose Apache over MIT or GPL.

Why It Matters

Patent clauses are invisible to most developers but critical to enterprise adoption. If you’re using open source in a product that could be patented, or if you work for a company with a large patent portfolio, Apache 2.0 provides protections that MIT and BSD don’t. Google, Microsoft, Apple, and Netflix all prefer Apache 2.0 for their open-source projects.

Real-World Use

Your startup builds a machine learning product on top of TensorFlow (Apache 2.0). Your model training pipeline uses Kubernetes (Apache 2.0) running on Android devices (Apache 2.0). You sell the product commercially. Under Apache 2.0, you’re protected: if a TensorFlow contributor tries to sue you over a patent related to their contribution, they automatically lose their license to TensorFlow. That’s the patent retaliation clause in action.

Quick Reference

What the Apache 2.0 License Actually Says

Apache 2.0 is more structured than MIT. Here’s what it grants:

Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work…

And critically, the patent grant:

Each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work…

The Patent Grant — What Makes Apache 2.0 Special

The patent grant is Apache 2.0’s killer feature. Here’s what it means:

1. Contributors grant patent rights: Anyone who contributes code to an Apache 2.0 project grants you a license to any patents they hold that cover their contribution
2. You can use the code without fear: If a contributor’s patent reads on the code, you’re already licensed
3. Retaliation clause: If you sue someone over patents related to the project, your license to the project terminates

Why This Matters

Without a patent grant:

• A contributor could contribute code, then later sue you for patent infringement based on that code
• You’d have no defense — they gave you the code but not patent rights

With Apache 2.0:

• The act of contributing grants you patent rights
• That grant is irrevokable unless you start a patent lawsuit against the project

This is why companies with large patent portfolios (Google, Microsoft, Meta) almost always use Apache 2.0 — it protects their users and creates a patent-safe ecosystem.

Can I Use Apache 2.0 Code in Commercial Products?

Yes, absolutely. Like MIT, Apache 2.0 permits commercial use, modification, distribution, and sublicensing. You can:

• Use Apache-licensed code in proprietary commercial products
• Sell products built on Apache code
• Modify the code and keep your modifications proprietary
• Include it in SaaS products without releasing your source code

The conditions are slightly more involved than MIT:

1. Include the original license notice
2. Include a NOTICE file if the project provides one
3. State any significant changes you made

The NOTICE File

Many Apache 2.0 projects include a NOTICE text file with attribution text. If you distribute the code (including in a binary), you must reproduce this notice. For example, Kubernetes includes a NOTICE file crediting the CNCF and contributors.

Real-World Projects Using Apache 2.0

Apache 2.0 vs MIT vs GPL

Apache 2.0 sits between MIT and GPL: it’s permissive like MIT but with the legal robustness of GPLv3’s patent clauses.

Common Misconceptions

“Apache 2.0 means the project is run by the Apache Software Foundation”

No. “Apache 2.0” refers to the license, not the organization. Anyone can use Apache 2.0 for their project without any affiliation with the Apache Software Foundation.

“Apache 2.0 requires me to contribute back”

No copyleft. You can modify Apache 2.0 code and never share your changes. But you must document that you changed the code.

“The patent grant means I can patent the code”

You can’t patent existing code — only novel inventions. The patent grant means you won’t be sued by contributors for using their contributed code. It doesn’t grant you the right to patent someone else’s work.

“Apache 2.0 is incompatible with GPL”

Apache 2.0 is GPLv3-compatible but not GPLv2-compatible. You can combine Apache 2.0 and GPLv3 code in a single project, but you can’t combine Apache 2.0 code with GPLv2-only code.

“I don’t need a NOTICE file if I only use the code on my server”

True — if you never distribute the code to others. For SaaS or internal use, you don’t need to provide notices. But if you ship a Docker image, a binary, or an appliance, you must include the notices.

Apache 2.0 Compliance Checklist

Before shipping Apache 2.0 code:

• Identified all Apache 2.0 dependencies
• Including any NOTICE files from those projects
• Retained copyright headers in source files
• Documented significant modifications (for distributed code)
• NOTICE file aggregated into your distribution (if multiple Apache projects)
• NOTICE accessible to end users (in binary, installer, or docs)

Example: Aggregated NOTICE File

Apache License 2.0
==================

This product includes software from:
- TensorFlow (Copyright Google LLC)
- Kubernetes (Copyright The Kubernetes Authors)
- Apache HTTP Client (Copyright Apache Software Foundation)

Full license text and notices for each component are available at:
[link to LICENSES directory]

When to Choose Apache 2.0

Choose Apache 2.0 for your own projects when:

• You want permissive licensing (no copyleft) but with patent protection
• You contribute to a project that might be used in corporate environments
• You’re building infrastructure, frameworks, or libraries
• You work at a company with a patent portfolio
• You want the most lawyer-friendly license available

Avoid Apache 2.0 when:

• You want the absolute simplest terms (choose MIT)
• You want copyleft protection (choose GNU GPL)
• You need maximum adoption with zero friction (MIT is marginally simpler)

FAQ

License Compatibility Map

graph TB
    A[Apache 2.0] --> B[GPLv3 Compatible]
    A --> C[GPLv2 NOT Compatible]
    A --> D[MIT Compatible]
    A --> E[AGPLv3 Compatible]
    F[MIT] --> G[Compatible with everything]
    H[GPLv2] --> I[NOT compatible with GPLv3]
    H --> J[NOT compatible with Apache 2.0]

Practice Questions

1. You distribute a commercial product that includes Apache 2.0 code. What files must you include? A LICENSE file with the Apache 2.0 text and any NOTICE files from the included projects.

2. Can you contribute to a competitor’s Apache 2.0 project and later sue them over patents? You can try, but you’d lose your license to their project under the retaliation clause. And if you contributed code, you already granted them a patent license for that code.

3. Your SaaS product runs Apache 2.0 infrastructure code. Do you need to provide the source? No. The distribution trigger hasn’t fired — you’re running the code on your servers, not shipping it.

4. Can you take Apache 2.0 code, modify it heavily, and sell it as a proprietary product? Yes. Apache 2.0 is permissive. You must include the notices, but you don’t need to open-source your changes.

5. When would you choose Apache 2.0 over MIT for a new project? When patent protection matters — for infrastructure, corporate-facing tools, and projects where you want to signal legal safety to enterprise adopters.

Mini Project: License Audit with NOTICE Files

1. Create a project that depends on three Apache 2.0 libraries (e.g., Python packages, npm modules, or Rust crates)
2. Extract the NOTICE files from each dependency
3. Create an aggregated NOTICE file for your project
4. Verify your LICENSE file contains the standard Apache 2.0 template
5. Add a build step that checks for missing license attributions

Challenge: Find an open-source project that recently migrated from MIT to Apache 2.0 (or vice versa). Read their issue tracker and blog posts explaining the decision. Write a summary of the trade-offs they considered.

Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro. This guide is for educational purposes and does not constitute legal advice. Consult an attorney for specific licensing questions.