Apache License 2.0: Patent Grant, Redistribution, and GPL Compatibility

The Apache License 2.0 is a permissive open-source license that lets you use, modify, distribute, and sublicense the covered software — including inside commercial and closed-source products — royalty-free and worldwide, provided you keep the license text, copyright notices, and any NOTICE file intact when you redistribute, and mark files you have changed. Released by the Apache Software Foundation in January 2004, it also grants an explicit patent license from contributors, which is the main feature that sets it apart from shorter permissive licenses like MIT and BSD.¹

What the Copyright Grant Lets You Do

Section 2 gives you a copyright license that is perpetual, worldwide, non-exclusive, royalty-free, and irrevocable so long as you follow the terms.¹ With that grant you can copy the software, modify it, display or perform it publicly, distribute it, and sublicense it to others. Sublicensing matters because you can pass the same permissions along to anyone who receives the code from you.

The rights apply equally to “source” form (the human-readable code and documentation, the preferred format for making changes) and “object” form (compiled binaries and other mechanically transformed versions). Whatever you distribute, and in whatever form, the same permissions and the same conditions travel with it.

Using It in Commercial and Proprietary Products

You can build commercial and closed-source products on top of Apache-licensed code and sell them. Section 4 explicitly allows you to add your own copyright statements to your modifications and to place your derivative work under different license terms, as long as your distribution still meets the Apache License conditions for the original code.² In practice, this is why the license is common in commercial software: your additions can be proprietary, and only the Apache-licensed portions carry the Apache obligations.

Section 9 lets you charge fees for support, warranty coverage, indemnity, or other obligations when you redistribute. You take those on solely on your own behalf. You cannot claim other contributors stand behind them, and you agree to shield the original contributors from any claims that arise out of the extra obligations you offered.³

Running It as a Hosted Service

The license’s redistribution requirements are triggered by distributing copies of the work. Running Apache-licensed software as a hosted or SaaS product, where users interact with it over a network but never receive a copy, does not by itself trigger any obligation to share source code or attach license notices to those users.¹ This is a real difference from network-copyleft licenses like the AGPL, which specifically reach that case.

What You Must Do When You Redistribute

When you do hand out copies of the software or a derivative work, Section 4 sets out a short list of conditions:²

Give every recipient a copy of the license itself.
Keep all existing copyright, patent, trademark, and attribution notices from the source form of the work.
If the work includes a NOTICE file, carry a readable copy of its attribution notices into your distribution.
Add a prominent notice to any file you have changed, stating that you modified it.

The change-marker requirement is easy to overlook and it matters. Downstream users reading the code need to be able to tell your modifications apart from the original, and without markers a debugging session can go badly wrong on the assumption that a file is untouched.

Handling the NOTICE File

The NOTICE rules are more particular than “just ship it along.” You must reproduce the attribution notices from the original NOTICE, but you can leave out notices that do not pertain to any part of your derivative work. You can also add your own attribution notices alongside the original ones, as long as your additions cannot be read as changing the license terms.²

You have flexibility on where the NOTICE content lives. It can sit in a standalone NOTICE file in the distribution, appear within source or documentation, or show up in a display generated by the software wherever third-party notices normally appear. The content just has to remain readable.

The Patent Grant and Retaliation Clause

Section 3 is what most legal reviewers focus on. Every contributor grants you a perpetual, worldwide, royalty-free patent license covering any patent claims they own that would necessarily be infringed by their contribution alone, or by the combination of their contribution with the rest of the work.¹ If a contributor holds a patent that covers what they added, they cannot later sue you for using that functionality as part of the project.

The section also includes a patent retaliation clause. If you file a patent lawsuit alleging that the licensed work, or a contribution embedded in it, infringes your patents, every patent license you received under the Apache License for that work terminates on the date the suit is filed. Cross-claims and counterclaims count too.³

The scope is narrower than it first sounds. Termination is triggered only by claims that the licensed work itself infringes your patents. A patent suit against a contributor over unrelated technology does not affect your Apache patent rights. For companies that hold large patent portfolios and also depend on open-source code, that precision is what makes participation workable.

Trademark Limits

Section 6 draws a firm line around trademarks. The license does not give you permission to use the contributors’ trade names, trademarks, service marks, or product names, except for the minimal use needed to describe the origin of the work and to reproduce the NOTICE file.¹

You can fork an Apache-licensed project and ship your version, but you cannot brand your fork with the original project’s name or logo in a way that suggests endorsement. Building on Apache Kafka is fine; calling your own product “Kafka” without separate permission is not.

No Warranty, No Liability

Section 7 provides the code “as is,” with no warranties of any kind, and puts responsibility for evaluating fitness for your purpose on you.³ Section 8 shields contributors from liability for damages of any kind — lost profits, data loss, work stoppages, direct or indirect — arising out of your use of the software, unless a contributor has signed a separate agreement accepting such liability.¹ These disclaimers are standard across open-source licensing and exist so individuals and volunteers can share code without personal financial exposure.

Compatibility with GPL Licenses

If you plan to combine Apache-licensed code with GPL-licensed code, the version of the GPL matters. The Free Software Foundation treats Apache 2.0 as compatible with GPLv3, so Apache-licensed code can be pulled into a GPLv3 project. The reverse does not work: GPLv3 code cannot be folded into an Apache-licensed project, because that would require the Apache-licensed portions to be redistributed under the GPL, contrary to the Apache Software Foundation’s policy that its projects ship under the Apache License.⁴

Apache 2.0 is not compatible with GPLv2 in either direction. The FSF considers Apache’s patent termination and indemnification provisions to be additional restrictions that GPLv2 does not allow.⁴ Check the specific GPL version before mixing.

How It Compares to MIT and BSD

All three are permissive licenses, and all three let you use the code in commercial and proprietary products. Apache 2.0 is the longest and most detailed of the group. The MIT License runs under 200 words and asks only that you keep the license file when redistributing. BSD 2-Clause has a similar footprint. Apache 2.0 adds three things those shorter licenses lack: an explicit patent grant, a patent retaliation clause, and the NOTICE file mechanism for structured attribution.

The patent grant is usually the deciding factor for companies. MIT and BSD say nothing about patents, which leaves ambiguity about whether using the software could still expose you to patent claims from contributors. Apache 2.0 spells out both the grant and the conditions under which it terminates. The tradeoff is more compliance work: tracking NOTICE files and marking changed files is more effort than MIT’s “keep the license file” rule.

Applying Apache 2.0 to Your Own Project

The license appendix sets out the steps. Copy the full license text into a file named LICENSE at the top level of your project, taken directly from the Apache Software Foundation to avoid errors from modified copies circulating online.⁵

Add the boilerplate header from the appendix to the top of each original source file — code and documentation, but not the LICENSE and NOTICE files themselves. Fill in the copyright year and owner where indicated. The header states that the file is licensed under Apache 2.0 and points to the license URL.⁵³

If your project needs specific attribution credits, or if it pulls in dependencies whose licenses require attribution, add a NOTICE file in the same top-level directory. Keep it focused on attribution. The NOTICE file is not a place to modify the license itself, and additions there cannot be read as changing the Apache terms.

1
Apache Software Foundation. Apache License, Version 2.0
2
Apache Software Foundation. Apache License 2.0
3
Apache Software Foundation. Apache License, Version 2.0
4
The Apache Software Foundation. Apache License v2.0 and GPL Compatibility
5
Apache Software Foundation. Applying the Apache License, Version 2.0