Patent Exhaustion and Open Source Distributions: When a Patent Owner Loses the Right to Sue

When a patent owner sells or authorizes the sale of a patented product, something important happens automatically: the patent rights in that specific item are exhausted. The buyer — and anyone who receives the item further downstream — generally cannot be sued for infringement based on the ordinary use, resale, or further distribution of what they received. That principle, called patent exhaustion or the first sale doctrine, has real consequences in the open source world, where software and hardware reference designs change hands constantly under licenses that may or may not trigger the doctrine.

What Patent Exhaustion Actually Means

Patent exhaustion is not a contract right. It is a limitation on the patent owner's power built into patent law itself. Once an authorized sale occurs, the patent owner cannot reach back through the chain of distribution and sue a downstream recipient for doing what the item was designed to do.

The key word is authorized. If the original distribution was unauthorized — for example, someone shipped a product in violation of their own license — exhaustion does not attach, and downstream recipients may have no protection. The authorization question is what makes open source distributions complicated.

Authorized Sales vs. Conditional Licenses

Not every transfer of software triggers exhaustion. Courts have drawn a distinction between a sale — which exhausts patent rights — and a conditional license — which may not. When a patent owner grants a license subject to conditions and those conditions are violated, there may be no exhaustion at all.

Open source licenses are, in legal terms, conditional copyright licenses. Whether any given distribution under one of those licenses also constitutes an authorized sale that exhausts patent rights depends on the facts: who holds the relevant patents, whether the license includes an explicit patent grant, and whether the distribution was actually authorized by the patent holder.

How This Plays Out With Common Open Source Licenses

Some open source licenses include explicit patent grants. The Apache License 2.0, for example, grants a royalty-free patent license to use, make, sell, and distribute the covered work. If a company distributes software under Apache 2.0 and holds patents that read on that software, the patent grant in the license is itself an authorization — and a downstream recipient receiving that distribution has both a contractual license and a strong argument that exhaustion applies.

Other licenses, like the MIT License, say nothing about patents. A downstream recipient gets a copyright license and nothing more. If the upstream distributor holds patents that cover the software, those patents are not necessarily exhausted by the distribution. The recipient is in a legally ambiguous position.

The GPLv3 Approach

GPLv3 takes a deliberate stance. It conditions the right to distribute on not imposing additional patent restrictions on recipients downstream. If you distribute GPLv3 software and you hold patents that would be infringed by the recipient doing what the license allows, GPLv3 requires you to either grant a royalty-free patent license or refrain from distributing. This structure is designed to make patent exhaustion arguments stronger, though it does not eliminate all uncertainty.

GPLv2 predates the modern exhaustion framework and is less explicit. Distributions under GPLv2 carry more ambiguity about whether patent rights are exhausted.

What This Means If You Build on Open Source

If your product incorporates open source components, patent exhaustion may protect you — but only if the original distribution was authorized by the relevant patent holder and the circumstances support exhaustion. You cannot assume protection just because you received software under a recognized open source license.

Practical Gaps to Watch

• Third-party patent holders: Exhaustion only runs against the patent owner who made the authorized distribution. A different company that holds patents covering the same code gets no exhaustion argument from a distribution it had nothing to do with.
• Hardware products: Exhaustion applies to the specific item sold, not to every future use. If you receive a reference board under a license, exhaustion covers that board — it may not cover your mass-produced derivative product.
• Forks and modifications: Modifying open source code takes you outside the scope of any exhaustion that attached to the original. Your modified version needs its own analysis.

Practical Takeaways

• Patent exhaustion limits a patent owner's reach only when an authorized sale or distribution actually occurred — check whether the upstream source had authority to grant what they granted.
• An explicit patent grant in a license (like Apache 2.0) gives stronger protection than a copyright-only license (like MIT), which says nothing about patents.
• Exhaustion is item-specific; it does not automatically extend to your derivative products or modifications.
• Third-party patent holders are never bound by exhaustion arguments that arise from someone else's distribution.
• If your product depends heavily on open source components, a freedom-to-operate analysis should account for who holds relevant patents, not just what licenses the code carries.
• When patent coverage matters to your business, review both the license text and the patent position of the entities contributing to the projects you rely on.

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.