Your Open Source License Is Also a Patent Decision
Picking a license looks like a distribution choice. It is doing three things at once: granting patent rights you may not have meant to grant, publishing an invention onto a legal clock, and arming a tripwire that can cost you the right to keep using your own dependencies. Engineers evaluate the copyright half and almost never the rest.
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: August 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 everyone who receives the code. Some licenses do this expressly. It is irrevocable, and it is not undone by relicensing later.
- 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. Recipients keep it. 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
| License | Express patent grant | Patent retaliation |
|---|---|---|
| MIT | No. Silent on patents. | None |
| BSD 2- and 3-clause | No. Silent on patents. | None |
| Apache 2.0 | Yes, Section 3, scoped to contributions | Yes, Section 3 defensive termination |
| GPLv2 | No express grant. Section 7 constrains distribution under patent burdens. | None as such |
| GPLv3 | Yes, Section 11 | Yes, including limits on discriminatory patent deals |
| MPL 2.0 | Yes, Section 2.1(b) | Yes, Section 5.2 |
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, which is exactly the gap Apache 2.0 closes in the license itself.
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.
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. In Europe and China, which apply absolute novelty, a pre-filing public disclosure can end patent rights in those markets the day it goes live. 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.
The myth worth killing
"We open sourced it, so we can't patent it" is false in the US, at least for a year. What is true is subtler and more often the thing that actually matters: under Apache 2.0 or GPLv3 you have already licensed the people who took the code, and outside the US you may have forfeited the right entirely. The release did not destroy the patent. It reshaped who the patent can ever be used against.
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 or DCO. Silence plus outside contributors is the least defined position.
- Check foreign markets before publishing, not after. Absolute novelty jurisdictions do not offer a repair path.
- Audit the retaliation exposure before you litigate. Know which dependencies carry defensive termination clauses that your own assertion would trip.
Frequently Asked Questions
Can I patent something I released as open source?
In the US, generally yes if you file within one year of your first public disclosure, under the §102(b)(1) grace period. Outside the US it is often no, because Europe, China, and many other jurisdictions apply absolute novelty with no grace period. Separately, if you released under Apache 2.0, GPLv3, or MPL 2.0, you have already granted a patent license to everyone who received the code, so the patent will not reach your own users even if it issues.
Does the MIT license give users a patent license?
Not expressly. MIT and the BSD licenses are silent on patents. That silence does not necessarily mean you retain a free hand to assert: distributing software under a permissive license while intending to assert a patent the software practices raises implied-license and estoppel arguments. The doctrine is unsettled and fact-specific, which is itself the point. Silence leaves the question to background law.
How broad is the Apache 2.0 patent grant?
Narrower than commonly assumed. It covers only patent claims licensable by that contributor that are necessarily infringed by their contribution alone, or by the combination of that contribution with the work it was submitted to. It is not a grant of the contributor's entire patent portfolio, and it does not reach unrelated inventions. It is, however, perpetual and irrevocable for what it does cover.
What is defensive termination and when does it fire?
It is a clause that revokes your patent license if you assert patents against the project. Under Apache 2.0 Section 3, instituting patent litigation, including a cross-claim or counterclaim, alleging that the Work or a contribution within it infringes, terminates the patent licenses granted to you for that Work as of the filing date. It affects the party that filed, not downstream users.
Can I relicense to take the patent grant back?
Not for what has already been distributed. The Apache 2.0 grant is irrevocable, so recipients of the code as published keep the rights they received. You can change the license on future versions, and that is a real strategic option, but it operates going forward. It does not retract rights already granted for already-published code.
Which license should we pick if we might file patents?
That depends on why you would file, and it is a decision to make with counsel rather than from a table. The framing that helps: decide first whether to publish the mechanism at all, since publication is what starts the clocks and can end foreign rights. Then choose the license knowing that an express-grant license licenses your users while a silent one leaves the question to unsettled background law and to whatever contributor arrangements you put in place separately.