The GPL's Patent Grant: What It Means When You Ship Open Source Code

When you distribute software under a copyleft license like the GPL, you are not just granting users permission to copy and modify the code — you are also making a legally significant promise about patents. Most developers and founders never read that part of the license carefully, and that gap can create real exposure.

What a Patent Grant Actually Is

A patent grant is a promise, embedded in the license text, that the licensor will not sue licensees for infringing certain patents by using, modifying, or distributing the covered software. It is a contractual covenant, not a transfer of ownership. The patent owner keeps the patent; they just agree not to enforce it against people who comply with the license terms.

This matters because copyright and patent are separate bodies of law. A copyright license by itself does not stop a patent holder from suing you for patent infringement. License drafters — particularly the Free Software Foundation — specifically added patent grant language to address that gap.

How the GPL's Patent Grant Works

GPL version 2 handles patents indirectly. Its famous "liberty or death" clause (Section 7) says that if a court judgment or patent license would prevent you from distributing the software in compliance with the GPL, you cannot distribute it at all. This was intended to prevent companies from using patent licenses as a way to fragment the open source commons.

GPL version 3 is more explicit. It includes an express patent license from each contributor covering the patents that contributor can license, to the extent those patents are necessarily infringed by their contribution. GPLv3 also contains a retaliation clause: if you initiate patent litigation against anyone for infringing a patent on the covered program, your license terminates automatically.

The Apache License 2.0 — widely used for permissive open source — takes a similar express approach. Each contributor grants a broad patent license, and that license terminates for any party that files a patent suit claiming the covered work infringes.

What "Necessarily Infringed" Means

The express grants in GPLv3 and Apache 2.0 are scoped to patents that are necessarily infringed by the contribution itself, not by every possible use of the software. If a contributor adds a specific compression routine that reads on their own patent, that patent is in scope. A different patent in the same portfolio that happens to be relevant to something a downstream user builds is generally not covered. The boundary matters — it is not a blanket license to the contributor's entire patent portfolio.

What This Means If You Are a Distributor

If your company distributes a product that includes GPLv3 or Apache 2.0 code — even as a small dependency — and a contributor to that code holds patents that are necessarily infringed by the contribution, you have received a license to those patents. That is a benefit.

The flip side is the termination trigger. If your company sues anyone for patent infringement related to the covered software, your license to use that software terminates. For companies that both hold a patent portfolio and ship products built on open source, this creates a genuine strategic tension. A litigation decision that seems straightforward from a patent enforcement perspective could simultaneously put your right to distribute your own product at risk.

Contributions You Make Matter Too

If your engineers contribute code upstream to a GPLv3 or Apache 2.0 project, your company is granting a patent license to the world for any patents necessarily infringed by that contribution. Before allowing employees to contribute to open source projects, companies with active patent portfolios should have a review process — often called a contribution policy — that checks whether a proposed contribution reads on any company-owned patents.

The Interaction With Patent Strategy

Open source patent grants do not affect every patent your company holds, but they create specific carve-outs you need to account for when you assess your portfolio. If you are mapping what you can enforce and against whom, which licenses cover which products in your stack is a threshold question.

Similarly, if you are evaluating a competitor's portfolio, knowing which of their products ship under copyleft licenses can tell you something about which patents they may have effectively licensed away — or which litigation moves would trigger termination of their own software rights.

Practical Takeaways

• The GPL and Apache 2.0 both contain patent grants; they are not just copyright licenses, and the patent language is enforceable.
• GPLv3 and Apache 2.0 terminate your license automatically if you sue for patent infringement on the covered software — understand what that means for products you depend on.
• "Necessarily infringed" limits the grant to patents read on by the specific contribution, not an entire portfolio.
• Before employees contribute code to open source projects, run a patent clearance check if your company holds relevant IP.
• Companies with both a patent portfolio and open source dependencies should have a written contribution policy and a litigation pre-clearance step.
• When building a competitive patent map, open source licensing of a competitor's products is relevant context for understanding what they can realistically enforce.

This guide is general education, not legal advice, and does not create an attorney–client relationship. For your specific situation, talk to a registered patent attorney.