Open Source and Patents

Open-sourcing your code licenses your patents — read the grant before you publish

If your company holds (or later obtains) patents covering your own code and you release that code under Apache 2.0, MPL 2.0, or GPLv3, you have granted every user a royalty-free license to the patent claims covering your contribution. You cannot later assert those claims against users of the code you released. Decide deliberately: companies that want to open-source while preserving patent leverage sometimes choose licenses carefully, separate patented components, or accept the trade as the cost of adoption.

Your release is prior art — against everyone, including you

Publishing source code is a public disclosure under 35 U.S.C. § 102. Against third parties, your release date defeats later-filed patents on what the code discloses — open source is one of the largest prior art corpora in software. Against yourself: the US gives you a one-year grace period (§ 102(b)(1)) to file after your own disclosure, but most foreign systems have no grace period — releasing before filing destroys European, Chinese, and Japanese patent rights on what was disclosed. File first, release second.

Inbound OSS doesn't clear third-party patents

An Apache 2.0 patent grant covers the contributors' patents — not patents held by strangers to the project. Using open source code can still infringe a non-contributor's patent. The license grant tells you who CAN'T sue you (the contributors), not who can.

Patent retaliation clauses change litigation calculus

If your company runs on Apache-2.0/MPL-2.0 dependencies and you sue alleging one of those works infringes your patent, your patent licenses to that work terminate — potentially exposing your own products built on it. Before asserting patents against anything connected to open source you use, map the retaliation exposure.

CLAs and DCOs allocate patent risk in contributions

Contributor License Agreements (like the Apache CLA) typically include an explicit patent license from the contributor (and their employer, in corporate CLAs) for the contribution. The lighter-weight Developer Certificate of Origin (DCO) does not address patents at all. Projects courting corporate contributors use CLAs in part to lock in patent grants.

Defensive structures exist if you want patents without offense

The Open Invention Network (OIN) is a royalty-free cross-license community covering the 'Linux System' definition — members agree not to assert their patents against it. Companies have also made unilateral non-assertion pledges (Tesla's 2014 pledge, Google's Open Patent Non-Assertion Pledge). These let companies hold patents defensively while credibly committing not to attack the commons.

Does the MIT license include a patent license?

The MIT license contains no patent language — it grants permission 'to deal in the Software without restriction,' phrased in copyright terms, and never mentions patents. Whether it carries an implied patent license is a genuinely unsettled legal question. The arguments: (1) For an implied license: a contributor who owns a patent covering their own contribution, and who releases that code under a license inviting unrestricted use, arguably grants an implied license (or would be estopped from suing) — otherwise the grant of 'use, copy, modify, sell' rights would be illusory. Doctrines of implied license by legal estoppel and equitable estoppel support this. (2) Against / uncertainty: no court has definitively ruled on the scope of an implied MIT patent license; an implied license would presumably cover only the contributor's own contribution as released — not modified versions, not combinations, and not patents acquired later; and it provides no defensive termination clause. Practical consequences: corporate counsel treat MIT/BSD dependencies as carrying meaningful but unquantified patent risk from contributors — and zero protection against non-contributor patents. This is precisely why Apache 2.0 exists in its modern form: its Section 3 makes the patent grant express (perpetual, worldwide, royalty-free, irrevocable, covering claims necessarily infringed by the contribution alone or combined with the work) and adds defensive termination against anyone who sues alleging the work infringes. For projects that expect corporate adoption, the choice between MIT and Apache 2.0 is largely a choice about whether patent terms are explicit.

What happens to my company's patents if we open-source our code?

Two distinct things, and both are permanent: (1) You grant patent licenses (depending on the license you choose). Under Apache 2.0 Section 3, releasing code grants every downstream user a perpetual, irrevocable, royalty-free license to your patent claims that are necessarily infringed by your contribution alone or in combination with the work it was contributed to. GPLv3 Section 11 and MPL 2.0 Section 2.1 have analogous express grants. The license is irrevocable — you cannot open-source a project to build adoption and later assert the covered patents against users of that code. Under MIT/BSD the grant is implied at best, but relying on the ambiguity to later sue your own users would face estoppel arguments and would be commercially toxic. What the grant does NOT cover: claims not embodied in your contribution (your broader portfolio remains assertable against independent implementations that don't use your released code), and future unrelated patents. (2) You create prior art against the world and yourself. Public release is a § 102 disclosure as of the release date. Offensively, this immunizes the disclosed techniques from later third-party patents — defensive publication is a deliberate strategy. Defensively, it starts the US one-year grace period clock (§ 102(b)(1)) for your own filings, and immediately destroys novelty in most foreign jurisdictions (Europe, China, Japan have no general grace period). The correct sequence for a patent-conscious company: identify patentable inventions in the code, file (at least provisionals) BEFORE the public release, then release. Many companies do exactly this — patent first, open-source second — retaining defensive patents while giving the code away.

What is a patent retaliation clause in an open source license?

A patent retaliation (or defensive termination) clause terminates rights granted by the license if the licensee initiates patent litigation involving the licensed work. The design goal: make attacking the project expensive for anyone who also benefits from it. The main variants: (1) Apache 2.0 (Section 3, final sentence): if you institute patent litigation (including a counterclaim) alleging that the Work or a Contribution incorporated in it constitutes direct or contributory patent infringement, the patent licenses granted to you under the license terminate as of the date the litigation is filed. Note it terminates the PATENT licenses, not the copyright license — you can keep using the code copyright-wise, but contributors' patents are back in play against you. (2) MPL 2.0 (Section 5.2): patent litigation against the project terminates rights more broadly. (3) GPLv3: beyond its express grant, Section 10 prohibits imposing further restrictions including patent claims against downstream recipients' exercise of granted rights, and the Section 11 provisions restrict discriminatory patent deals (drafted in response to the 2006 Microsoft–Novell arrangement, where patent peace was offered to one distributor's customers but not the community). (4) GPLv2 Section 7 ('liberty or death'): if a patent judgment or settlement imposes conditions that contradict the license, you may not distribute at all — indirect but forceful. Strategic consequence for patent holders: before asserting any patent against software connected to open source projects your own products depend on, map which licenses govern your dependencies and what terminates. Companies have discovered mid-litigation that their own infrastructure ran on code whose patent licenses their lawsuit just terminated.

Does using open source software protect me from patent infringement claims?

Only partially, and the gap is important. What OSS patent grants cover: licenses with express grants (Apache 2.0, GPLv3, MPL 2.0) give you a royalty-free license to the CONTRIBUTORS' patent claims covering their contributions. A contributor to the project cannot take their contribution's patent and sue you for using the project. What they do NOT cover: (1) Non-contributor patents — the overwhelming majority of patent risk. A patent holder who never touched the project can sue users of open source software exactly as it can sue users of proprietary software; the project's license is irrelevant to them. Open source codecs, wireless implementations, and media formats have faced exactly this (e.g., long-running patent licensing programs around video codecs apply to open source implementations too). (2) Combinations — Apache 2.0's grant covers claims necessarily infringed by the contribution alone or combined with the work it was contributed to; patents reading on YOUR larger product that incorporates the OSS are not licensed by anyone. (3) Modified scope questions — heavily modified versions raise arguments about whether grants still apply. Mitigations in the ecosystem: the Open Invention Network's royalty-free cross-license among thousands of members covering the Linux System definition; patent non-aggression pledges; defensive prior art (the code corpus itself invalidates many asserted claims — prior art searching in OSS repositories is standard defense practice); and indemnification programs from major vendors (some cloud and enterprise vendors contractually indemnify customers for IP claims against the open source they distribute). Bottom line: OSS license grants neutralize contributors as plaintiffs; they do nothing about strangers, and FTO analysis for a product doesn't change because components are open source.

What is the Open Invention Network (OIN)?

The Open Invention Network is a defensive patent community formed in 2005 to protect Linux and adjacent open source software from patent attacks. How it works: (1) Cross-license: every OIN member (called a licensee) receives a royalty-free license to all other members' patents — and grants the same — to the extent those patents read on the 'Linux System,' a defined and periodically expanded list of open source packages (the kernel, Android components, container tooling, and thousands of other packages). (2) Membership is free and open: any company can join by signing the license agreement; the community has grown to thousands of licensees including the largest technology, automotive, and financial companies. (3) OIN also owns a portfolio of patents acquired over the years, held defensively — available to deter or counter-sue entities that attack Linux. (4) Scope limits: the cross-license covers member patents only as they read on the Linux System definition — members retain full offensive use of their portfolios outside that scope, which is what makes joining commercially tolerable for large patent holders. What OIN does NOT do: it cannot stop non-members (including non-practicing entities, which hold no products and fear no counter-suit) from asserting patents against open source users; it does not cover software outside the Linux System definition; and it is not an indemnification program. Complementary structures: License on Transfer (LOT) Network (members agree that patents sold to NPEs carry automatic licenses to other members — defusing the patent-sale-to-troll pipeline); Unified Patents (challenges weak patents asserted in defined technology zones, including via IPR); and unilateral non-assertion pledges by individual companies. For a startup, joining OIN and LOT is free or cheap and is increasingly expected hygiene in open-source-heavy industries.