Apache License 2.0

Definition: A permissive open-source license similar in spirit to MIT, but with added explicit protections around patents.

How It Works

Permits free use, modification, and distribution, similar to MIT License
Conditions attach only when you distribute the code (source or binary), not when you merely use it internally
On distribution, you must: include a copy of the license, state any changes you made to the files, and retain existing copyright, patent, and trademark notices
Works the same for source and binary distributions, a compiled app that embeds Apache-2.0 code still has to carry the notices, just usually in a “third-party licenses” screen or file instead of inline comments
If the original project ships a NOTICE file, you must carry its attribution text forward into your distribution
Includes an explicit patent grant: each contributor licenses you to use any of their patents that are necessarily infringed by their contribution
Includes a patent retaliation clause: if you sue anyone (including a contributor) alleging the software infringes a patent, your patent license under Apache 2.0 terminates immediately
Grants no trademark rights, using a project’s name or logo isn’t covered
Lets you sublicense and relicense your own additions under different terms, as long as the original Apache-2.0 portions stay under Apache 2.0
Is one-way compatible with GPLv3: Apache-2.0 code can be combined into a GPLv3 project, but not the reverse, GPLv2 is generally treated as incompatible with Apache 2.0
Applies independently per contributor: each person or company that contributes code grants their own patent license, there’s no single central patent pool
Doesn’t require you to distribute source code at all, unlike GPL, a binary-only release with the license, notices, and NOTICE file attached is fully compliant

Permissions, Conditions, Limitations

Category	Terms
Permissions	Commercial use, modification, distribution, patent use, private use
Conditions	Include license copy, state changes, retain notices, carry forward NOTICE file
Limitations	No trademark use, no warranty, no liability

Recommended File Header

The license’s own appendix recommends adding this boilerplate to the top of each source file so provenance survives even if the file is copied out of its original repo:

Copyright [yyyy] [name of copyright owner]

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

Under the Hood

Given: You take an Apache-2.0 library, modify one of its files, and run it as the backend of a closed-source SaaS product you never distribute to customers. Step: Check what triggers the license’s conditions. Answer: Apache 2.0’s obligations attach on distribution, not use. Since you never hand the code (or a binary built from it) to anyone outside your company, you have no obligation to publish your changes, the NOTICE requirement doesn’t apply, and your SaaS product can stay fully closed-source.

Given: You ship a commercial product built on Apache-2.0 code, then later sue a customer claiming a feature in that product infringes a patent you hold. Step: Check the patent retaliation clause against your own actions. Answer: Filing that suit terminates your own patent license to the Apache-2.0 code you depend on, immediately exposing your product to a patent claim from the original contributors whose grant you just lost.

Given: You want to combine an Apache-2.0 library with a GPLv3-licensed application into one distributed product. Step: Check compatibility direction between the two licenses. Answer: This works: Apache 2.0 is one-way compatible with GPLv3, so the combined work can be distributed under GPLv3. Going the other way, pulling GPLv3 code into an Apache-2.0 project, does not work without also relicensing the whole thing as GPLv3.

Why It Matters

The patent grant plus retaliation clause gives companies a credible reason to trust contributions from competitors, no one can quietly contribute patented tech then sue users later
Large companies with significant patent portfolios (Google, IBM, Amazon) preferred Apache 2.0 for exactly this reason when choosing licenses for major projects like Kubernetes and Kafka
It lets a project stay compatible with proprietary, closed-source downstream products while still giving users real legal cover on patents, something MIT doesn’t address at all
Foundations like the ASF require it for governance reasons: contributors sign agreements, and the patent clause protects every downstream user, not just the foundation itself
Legal teams reviewing a dependency tree often flag Apache 2.0 as lower-risk than a license with no patent language, since the retaliation clause discourages patent trolling within the ecosystem

Common Pitfalls

Treating Apache 2.0 as functionally identical to MIT and skipping the NOTICE file carry-forward requirement
Forgetting to document what was changed in a modified file before redistributing it, a condition MIT doesn’t impose
Assuming the patent grant covers every patent a contributor owns, it only covers patents necessarily infringed by their specific contribution
Believing the license grants rights to a project’s name, logo, or trademarks, it explicitly disclaims that
Losing track of NOTICE file text when combining several Apache-licensed dependencies into one product, each one’s attribution needs to be preserved
Assuming Apache 2.0 and GPLv2 mix freely, they’re generally considered incompatible in the GPLv2-to-Apache direction because of extra conditions Apache 2.0 imposes
Deleting the recommended file-level header boilerplate during a refactor, which strips per-file provenance even though the top-level LICENSE file is still present
Believing the patent grant protects you against patent claims from companies who never contributed code to the project, it only covers the contributors themselves
Overlooking that the patent retaliation clause can be triggered by defensive counter-suits too, not just offensive litigation you initiate first
Assuming a company that just uses Apache-2.0 software, without contributing code back, has made any patent grant of its own, only contributors grant patent rights under this license
This is informational content, not legal advice, consult a lawyer for real license compliance decisions

Comparison

	Apache 2.0	MIT	GPL
Copyleft	No	No	Yes, derivative works must also be GPL
Patent grant	Yes, explicit, with retaliation clause	No	Yes (GPLv3), implicit/weaker in GPLv2
Attribution requirement	Yes, license text, notices, and NOTICE file	Yes, copyright notice and license text	Yes, plus source code availability
Compatible with proprietary/closed-source use	Yes	Yes	No, without also open-sourcing the derivative
Must state changes to modified files	Yes	No	Yes
Trademark rights granted	No	No	No
Compatible with GPLv3	One-way, into GPLv3	Yes, into GPLv3	N/A
Typical use case	Corporate-backed infrastructure projects	Small libraries, quick adoption	Software wanting to stay free/open forever
License length	Long, formal legal text	Very short, a few paragraphs	Long, formal legal text

Example

Apache Kafka, the Android Open Source Project’s core components, and Kubernetes are all licensed under Apache 2.0. It’s the default license for most Apache Software Foundation projects, and Kafka’s own distribution ships a NOTICE file listing bundled third-party attributions as the license requires. Google chose Apache 2.0 for the parts of Android it wants device manufacturers to freely modify and ship in proprietary firmware.

Referenced by

Dig deeper

Spot an error in this note?