Your Open Source License Is Also a Patent Decision

The usual way this decision gets made is a quick comparison: MIT if you want maximum adoption, Apache if the company lawyers prefer it, GPL if you care about copyleft. That framing treats a license as a rule about copying. It is also a patent instrument, and the patent half operates independently of the copyright half.

This page covers what each of the common licenses does to patent rights, in both directions, and what to settle before the first public push rather than after.

Last updated: 12 November 2026. Educational information about license terms and the US patent framework, not legal advice, and not an opinion on any specific project or license choice. License interpretation is fact-specific and some questions here are genuinely unsettled. Talk to counsel before relying on any of it.

Three effects, one decision

When you publish code under an open source license, three separate things happen at the same moment:

• You may grant a patent license to the recipients of the code. Some licenses do this expressly. The grant is not undone by relicensing later, though it can be terminated by the license's own terms if you sue.
• You publicly disclose the invention. That starts a one-year US filing clock and, in absolute-novelty jurisdictions, can end patent rights immediately.
• You may accept a condition on your own future litigation. Under several licenses, asserting a patent against the project costs you your license to it.

These are independent. A license can be silent on patents and still produce a disclosure. A permissive license can be the most restrictive of the three on your future enforcement options.

Effect one: the outbound patent grant

The clearest example is Apache License 2.0. Section 3 is a standalone patent grant, separate from the Section 2 copyright grant. Each contributor grants every recipient a patent license described as "perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable" to make, use, sell, and otherwise transfer the Work.

Two qualifications on that grant are load-bearing and routinely misread:

• It is scoped to your contribution, not your portfolio. The grant reaches only those claims "necessarily infringed" by your contribution alone, or by the combination of your contribution with the work it was submitted to. Publishing one module under Apache 2.0 does not license your unrelated patents.
• It is irrevocable, with one exception written into the same section. Apache 2.0 says "irrevocable (except as stated in this section)", and what that section states is the defensive termination clause below. Short of triggering it, recipients keep the grant: changing the license on future versions does not reach back and withdraw what was already granted for what was already published.

The practical consequence: if you publish the implementation of a mechanism under Apache 2.0 and later obtain a patent covering that mechanism, you have already licensed everyone who took the code. The patent may still be useful, for defensive posture, for diligence, for asserting against parties who did not take the code. But the population of people you can assert it against no longer includes your own users.

Where each common license lands

The three express regimes are not interchangeable, and they differ on two axes in opposite directions. Apache 2.0 has the broader trigger and the narrower consequence: a counterclaim sets it off, and what you lose is the patent license alone, so you may still use and redistribute the code. MPL 2.0 has the narrower trigger and the broader consequence: counter-claims and cross-claims are carved out, but asserting a patent against a Contributor Version ends every Section 2.1 right, copyright included, from every contributor at once. GPLv3 reaches the same place by a different route, through a prohibition on suing plus the general termination clause, so there is no single provision to point at. Reading "defensive termination: yes" across a row is therefore not a comparison.

Summary of license text, not an interpretation of how a court would apply it to a particular set of facts. Version matters: these differ materially between versions of the same family.

The "silence is safer" mistake

A common inference is that MIT or BSD preserves your patent position because they say nothing about patents. That inference is weaker than it appears, in both directions.

Silence is not a reservation of rights. Handing someone software under a license that permits use, modification, and redistribution, while intending to later assert a patent that the software necessarily practices, invites implied-license and equitable-estoppel arguments. The theory is unsettled and fact-dependent, so this is not a prediction of outcome. It is a caution that "the license did not mention patents" is an argument, not a shield.

Silence also removes your protection. The Apache grant runs from every contributor, which means an outside contributor who submits a patch has licensed the claims their contribution necessarily infringes. Under MIT there is no such express grant, so a project accepting outside contributions has no license-level assurance that a contributor will not later assert a patent reading on their own patch. Projects that care about this typically layer a Contributor License Agreement or a Developer Certificate of Origin on top, and the two do different work. A CLA can contain an express patent grant, and a DCO does not. The DCO is a provenance certification: the contributor certifies that "The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file", or that it came to them under an appropriate license. Its text says nothing about patents at all. A DCO on an MIT project leaves the project on MIT, so the gap Apache 2.0 closes in the license itself is closed here only by a CLA drafted to close it.

The Open Source Initiative discusses this trade-off directly. Permissive-and-silent is a genuine choice, but it is a choice to leave patent questions to background law rather than to settle them in the license.

When an agent wrote the code, the two halves can come apart

A license's copyright grant rests on there being copyright to grant. For code an AI agent wrote, how much exists is undrawn. The D.C. Circuit held in 2025 that the Copyright Act requires a human author and declined to say how much human involvement is enough; the Copyright Office treats prompts alone as insufficient while protecting a human's selection, arrangement or modification. So a license header on a largely agent-written file may carry less copyright than it suggests, and copyleft conditions, which are usually enforced through copyright, share that open question.

The patent half does not depend on who typed the code. Apache 2.0's Section 3 grant reaches the claims a contribution necessarily infringes, and inventorship turns on who conceived a method, not who wrote its implementation. For agent-written code, the three effects on this page can be the more durable half of the license rather than the less. That is a reading of how the two regimes are built, not a holding any court has given: what you own when AI wrote the code.

Effect two: publication is a disclosure event, whatever the license

This one is independent of which license you pick, including licenses with no patent terms at all. Publishing source code publicly makes it a candidate "printed publication" under 35 U.S.C. §102, where the test is public accessibility rather than whether anyone actually read it.

In the United States that starts a one-year grace period to file. Europe and China have no equivalent inventor grace period, so a pre-filing public disclosure can end patent rights in those markets the day it goes live. They are not quite absolute: Article 55 EPC disregards a disclosure in the "six months preceding the filing of the European patent application" if it was due to "an evident abuse in relation to the applicant or his legal predecessor" or to display "at an official, or officially recognised, international exhibition" under a 1928 convention. Read those two and the practical answer gets sharper rather than softer: the exceptions are for having your invention stolen, or for a trade fair. Publishing your own repository is neither. Choosing MIT rather than Apache changes nothing about this. The publication is the disclosure.

The ordering that follows is unglamorous but decisive: if patent protection matters for a mechanism, the filing decision belongs before the public release, not after. Building in public and patent rights covers the timing in detail, including why the grace period is a fallback rather than a plan.

Effect three: defensive termination as a tripwire

The second sentence of Apache 2.0 Section 3 is the one that surprises companies. If you institute patent litigation, including a counterclaim, alleging that the Work or a contribution within it constitutes direct or contributory patent infringement, then the patent licenses granted to you under that license for that Work terminate as of the date the litigation is filed.

The asymmetry matters. Termination hits the party that filed, not downstream users, and it reaches the licenses granted to that party for that particular work. But consider the position it creates: a company that depends on a widely used Apache 2.0 project, and that asserts a patent claiming that project infringes, can lose its own patent license to the dependency it is built on. The dependency is often something core, and the loss lands at the moment litigation starts.

This is worth checking in a direction most teams never look: not "what licenses are in our dependency tree" for compliance purposes, but "which of our dependencies would we lose the patent license to if we ever asserted this patent." That is a different query against the same data, and it is one to run before filing suit rather than during.

What to decide before the first public push

• Decide whether anything here is worth protecting, before publishing. This is the step teams skip, because it requires knowing what is distinctive in the codebase, and that is rarely written down anywhere. If you cannot name the mechanism, that is a reason to look rather than a reason to conclude there is nothing. The Idea Disclosure template is a plain-language way to capture it.
• Separate the release decision from the license decision. Whether to publish at all is the patent-relevant question. Which license to use shapes who you can assert against afterward. Answer them in that order.
• If you may want to assert, know what the grant covers. Under Apache 2.0 the grant is contribution-scoped. Understanding which claims are "necessarily infringed" by what you published is a practitioner question, and it is far cheaper to ask before release.
• If you accept outside contributions, close the inbound gap deliberately. Either through a license with an express contributor grant, or through a CLA drafted to include one. A DCO certifies provenance and grants nothing on patents, so on its own it does not close this gap. Silence plus outside contributors is the least defined position.
• Check foreign markets before publishing, not after. The narrow exceptions that exist abroad are for abuse and for official exhibitions, and a public release is neither, so there is no repair path.
• Audit the retaliation exposure before you litigate. Know which dependencies carry defensive termination clauses that your own assertion would trip.

One thing none of that buys you. Every effect on this page runs between you and the people who wrote the code. Whether your product infringes a patent held by someone who never contributed is a different question that no license answers: a license is not freedom to operate.

Sources