Open Source Patent Licenses
An explainer on how patent license provisions in popular open source licenses operate.
Open source software development isn't just a trend; it's a strategic trifecta—fueling business strategy, turbocharging engineering efficiency, and attracting top-tier talent.
Business strategy. Commoditizing associated products or services increases demand for the primary product. For example, Google open sourced Android - commoditizing mobile device operating systems - to increase use of its proprietary services and advertising consumption on its platform. Second, it ensures a stable supply chain. Modern software can use hundreds of open source components. Providing technical leadership to open source projects can influence project roadmaps and guarantee continued reliability of key components.
Engineering efficiency. Incorporating open source code instead of bespoke in-house solutions minimizes the cost of non-differentiating, baseline software components. Development costs are shared with other contributors. Contributing local changes and improvements back to upstream projects is cheaper than hiring full-time employees to apply custom patches every time the upstream versions change. Moreover, code contributed upstream is peer reviewed and the feedback improves code.
Talent. Active involvement in the open source community is a powerhouse for recruiting developers. Be where talent wants to be.
However, from an intellectual property perspective, open source contributions bring a patent risk, particularly for companies with extensive patent portfolios. That isn’t a reason to eschew open source projects; rather it underscores the need to comprehend and mitigate such risks.
The potential risks to a patent portfolio emerge from the restrictions and obligations introduced by patent licenses associated with widely-used open-source licenses. We’ll begin by examining these licenses.
Open source patent licenses
Creating source code gives the author a copyright, providing control over how others, known as downstream users, utilize the code. The author can keep the code proprietary, limiting its use to authorized purchasers. Alternatively, the author may open source the code, permitting free use, modification, and distribution. In both cases, the copyright license, granted by the author, specifies the permissions for downstream users, outlining what actions are allowed or restricted.
The open source universe is divided into permissive and copyleft licenses. Permissive licenses enable downstream users to freely modify and redistribute code, with the condition that they maintain attribution notices. On the other hand, copyleft licenses, exemplified by GPL 3.0, mandate licensing the code under the same GPL 3.0 license when the original code undergoes modification and distribution.
A copyright license might not cover all permissions needed by a downstream user. If the functionality in the source code is also protected by patents, users must have a license for those patents to freely use the permissions granted by the copyright license without facing patent infringement concerns. Open source licenses often incorporate a patent license to address this issue, although these patent licenses can vary across different open source licenses.
MIT
The MIT license is short. It allows downstream users to freely modify and distribute the software without referencing a separate patent license:
Permission is hereby granted, free of charge … to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software …
The license does not expressly specify whether these permissions arise from a copyright license or from both patent and copyright licenses. Thus, a patent license is implicit.1 Theoretically, if an author grants a license allowing downstream users to freely modify and distribute the code, the author shouldn't later expect patent royalties.
While the concise license is clear for engineers and lawyers, the absence of an explicit patent grant can introduce complexity. Downstream users lack assurance against potential patent infringement claims. Conversely, the patent owner lacks the ability to revoke the patent license from non-compliant users.
A comparable permissive license, the 3-Clause BSD license, also lacks an express patent license.
Apache 2.0
The Apache 2.0 license addresses the limitations of the MIT license by explicitly incorporating a patent license:
Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. (emphasis added)
Let’s break this down.
Who grants the patent license? Each contributor to the open-source project, such as Companies A, B, and C, and individual X, provides a free patent license to downstream users. The length of the contributed code does not matter. This patent license ensures that downstream users have the necessary rights to use the open-source project without any cost.
When is the patent license triggered? A contributor grants the patent license when the code is distributed. No patent license is granted if a company distributes existing open-source code without making a contribution.
What is licensed? The downstream user doesn't receive a license for every patent in a contributor's portfolio; instead, the patent license operates on a claim-by-claim basis. It's limited to patent claims that would be infringed by the contributor's specific contribution.
While the contributor's standalone contribution may not infringe claims, the combination of the contribution and the open-source project could. In such cases, the patent claims infringed by this combination are covered by the license.
Looking at it from a contributor's perspective (as illustrated in FIG. 1 below), the patent license includes only those claims related to the contributor's standalone contribution (shown in purple) and the intersection with the open source project (shown in dark purple). The patent license does not include claims unrelated to the contribution (shown in light blue). This is the prevailing interpretation of the license language. A broader interpretation where the combination of the contribution and the open source project is equivalent to the modified software as a whole (the purple and light blue sets), as is the case with GPL 3.0, is possible, but this issue has not been litigated (at least not with a publicly available outcome).
Claims that infringe another developer’s later contributions, whether standalone or combined with the open source project (shown in yellow in FIG. 1), are not part of the license.
FIG. 1. A contributor to an open source project grants a patent license to downstream users, encompassing only the patent claims that are necessarily infringed by the contribution or a combination of the contribution and the open source project.
Consider this scenario: if, at the time of distribution, none of your patent claims apply to either your contribution or the combination of your contribution and the open source project, then none of your patent claims are licensed. Now, if another developer later introduces a contribution that modifies the open source project, resulting in the combination of your contribution and the expanded project infringing your patent claims, those specific patent claims are not automatically licensed.2 When evaluating licensed patent claims, a contributor is only bound by their own contributions and the open source project's functionality as of the contribution date.3 This limits the contributor's potential exposure.
The encumbrance on a contributor’s licensed patent claims is further circumscribed. The contributor retains the freedom to assert these licensed patent claims against any infringing product, whether hardware or software, except for the open source project that benefits from the contributor's patent license.
Nevertheless, a contributor must be ready to reassess which patent claims are licensed in two potential future scenarios: (i) if the contributor acquires additional patents, and (ii) if the contributor's affiliates acquire additional patents. In both cases, the newly acquired claims must be evaluated against the contributor's original contributions to determine their licensing status for downstream users of the open source project.4 This aspect of the patent license acts as a safeguard for downstream users, preventing exposure to the expansion of a contributor's patent portfolio in the future. Notably, a contributor cannot seek royalties for an open-sourced contribution based on patents acquired after the contribution has been made.
The Apache 2.0 license explicitly defines a "contributor" to encompass its affiliates, defined as "all other entities that control, are controlled by, or are under common control" with the contributor. In addition to patent claims originating from a contributor's patent portfolio, the patent license also covers other patent claims infringed, as illustrated in FIG. 1, and licensable by the contributor.
The structure of license agreements among affiliates becomes crucial. If an entity contributes code to an open source project and holds the capability to license some or all of the patents owned by its parent company, the Apache 2.0 patent license extends to include claims from both the subsidiary's patent portfolio and the parent company's patent portfolio, provided that the subsidiary has the authority to license these claims.
From the perspective of a downstream user, the open source project provides a comprehensive bundle of patent licenses (as illustrated in FIG. 2 below). Every contributor to the open source project extends a patent license to cover their pertinent patent claims, as detailed earlier. This arrangement grants the downstream user the freedom to use the open source project without incurring any royalties.
FIG. 2. The downstream user is granted patent licenses by each contributor, enabling her to utilize the open source project without restrictions.
What can downstream users do with the patent license? The patent license granted by each contributor allows downstream users to use, make, or sell the open source project. However, the patent license does not extend to fields of use beyond the open source project. For instance, the downstream user cannot leverage the open source project's patent license to evade royalties for a distinct infringing product that doesn't incorporate code from the open source project.
The defensive termination provision. The patent license granted by each contributor to a downstream user is generally irrevocable, except for a crucial exception. This exception comes into play if the downstream user initiates patent litigation, including a cross-claim or a counterclaim, against anyone asserting that the open source project or a contribution to it infringes her patents. In such a case, the downstream user loses all the patent licenses granted by contributors.
Consider the scenario where Companies P and D incorporate open source code into their commercial products. Whether P and D are contributors to the open source project is immaterial. If P sues D, claiming that D's sale of the open source code in its commercial product infringes P's patents, then P forfeits all patent licenses to the open source project—from every contributor (as illustrated in FIG. 3 below).
FIG. 3. Defensive termination - the downstream user loses patent licenses granted by all contributors.
Consequently, P's sale of its commercial product, containing the open source code, becomes an unlicensed activity. This not only weakens P's position in the lawsuit against D but also exposes P to potential patent infringement claims from contributors to the open source project.
It's important to note that the loss of P's patent license is not retroactive. Any potential liability P incurs does not include royalties owed to contributors before P's lawsuit against D. This defensive termination provision empowers contributors by providing leverage against downstream users who resort to litigation.
Despite the loss of patent licenses, P's license to the open source project based on copyright remains intact. This stands in contrast to defensive termination provisions in other open-source licenses. Key considerations to bear in mind regarding such provisions include:
Scope of Termination:
Does termination apply to the patent license only, or does it extend to the copyright license as well?
Retroactivity of Termination:
Is termination retroactive, impacting activities and obligations before the triggering event?
Triggering Events:
Does termination occur solely in response to cross-complaints, or is it also triggered by other forms of litigation?
Specificity of Patent Litigation:
Is termination tied to patent litigation against a particular licensor, or does it encompass patent litigation related to the open-source project as a whole?
In the scenario where Company P contributes to the open source code, if P initiates a lawsuit against Company D, claiming that D's use of the open source code infringes P's patents related to the contribution, then D possesses a robust defense rooted in the open source license provided by P. This defense is grounded in the patent license provision of the Apache 2.0 license, granting D a license to P's patents and shielding D from patent infringement claims related to the open source project.
GPL 3.0
Section 11 of the GPL 3.0 license includes an express patent license (excerpted):
A “contributor” is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor’s “contributor version”.
A contributor’s “essential patent claims” are all patent claims owned or controlled [“control” includes the right to grant patent sublicenses] by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. …
When is the patent license triggered? A patent license is granted when the software is distributed. No patent license to claims in its patent portfolio is extended if a company merely distributes existing open-source code without actively contributing to it.
What is licensed? The GPL 3.0 patent license operates on a claim-wise basis, licensing essential patent claims that apply to the contributor's modified version of the open-source project. This coverage extends beyond the specific contribution and encompasses the entirety of the "contributor version," which is the modified software as a whole. This is a distinction from the patent claims licensed under Apache 2.0 (see Table 1).
The language of Apache 2.0 license is open to interpretation whether the combination of the contribution and the Work corresponds to the entire Work or a subset of the Work. Although the latter interpretation is prevalent, this issue has not been litigated. In my view, the Apache 2.0 license would be less popular if a company had to license patent claims that read on the entire Work (based on contributions from other developers that contributed before it).
In contrast, the “contributor version” in the GPL 3.0 license clearly refers to the entire software including the contributor's modification. Therefore, even for seemingly trivial contributions, such as bug fixes, the GPL 3.0 patent license extends to all patent claims infringed by any part of the GPL 3.0 open source project. From the contributor's perspective, the GPL 3.0 patent license potentially impacts a more extensive portion of its patent portfolio compared to Apache 2.0, as illustrated in FIG. 4.
FIG. 4. The GPL 3.0 patent license impacts more patent claims than the Apache 2.0 patent license.
The defensive termination provision. The GPL 3.0 license explicitly prohibits a downstream user from initiating any litigation claiming that the open source software infringes its patent claims, covering cross-claims and counterclaims. If such litigation is initiated, the downstream user forfeits not only the patent licenses received from all contributors but also all rights granted by the GPL 3.0 license, including the copyright license. This distinguishes GPL 3.0 from Apache 2.0, showcasing a broader scope of restrictions. Notably, this provision is outlined in Section 10 of the GPL 3.0 license, rather than Section 11, presumably because the loss of rights extends beyond the patent license.5
Each contributor's patent license to downstream users is irrevocable but for the defensive termination provision.
Impact on litigation settlements. Section 11(6) of the patent license imposes a crucial obligation: if a patent license is granted to one downstream user, it must be extended to all other downstream users. The practical implications of this provision become evident in scenarios like the hypothetical involving Company P:
No Contribution by P:
If Company P distributes an open source project without making any contribution, it is not obligated to grant a patent license.
However, if P initiates a lawsuit against Company D for patent infringement based on the open source code, settling with D becomes complex due to Section 11(6).
Settling with D by granting a patent license triggers an obligation to grant the same license to all other downstream users.
Defensive Termination and Distribution:
P's initiation of a lawsuit against D triggers the defensive termination provision, making P’s use of the open source project unlicensed.
To earn royalty on its patents, P's optimal strategy is to stop distributing the open source code.
Impact of Contribution by P:
If P had contributed code to the open source project initially, it would be obligated to license relevant patents to downstream users, including D.
In this case, P would not be able to sue D for patent infringement based on the contributed code, as D is already licensed.
Section 11(6) creates challenges in settling litigation involving patent licenses, especially when a contributor must extend the license universally. It highlights the strategic considerations contributors need to think about to navigate the open source landscape.
In other aspects the GPL 3.0 and Apache 2.0 patent licenses share similarities:
Exclusion of Contributor Versions:
Patent claims infringed by a contributor version from another entity are not covered by the patent license.
Current and Future Patent Claims:
Patent claims currently owned or acquired by a contributor in the future, which cover the contributor version, are subject to the patent license.
Sublicensing Rights:
Patent claims covering the contributor version that a contributor can sublicense, either currently or in the future, are subject to the patent license.
Enforcement Rights for Contributors:
Contributors retain the freedom to enforce licensed patent claims against any infringing product (hardware or software) except for the open source project benefiting from the contributor’s patent license.
Limitation to Fields of Use:
Concerning downstream users, the patent license does not extend to fields of use beyond the open source project.
Irrevocability of Patent License:
Besides the defensive termination provision, the patent license granted by each contributor to a downstream user is generally irrevocable.
The next article in this series will examine the repercussions of open source software contributions on a company's patent portfolio.
Thanks to Duane Valz and Raghavan Dhandapani for their input on this article.
Copyright © 2024 Shrut Kirti. Published here under a Creative Commons Attribution-NonCommercial 4.0 International License
The views expressed herein are the author’s own and do not reflect any positions or perspectives of current or former employers.
There are contrary views. Scott K. Peterson takes the position that the MIT license includes an express patent grant. https://opensource.com/article/18/3/patent-grant-mit-license.
See Apache Licensing and Distribution FAQs, particularly Q1/A1: https://www.apache.org/foundation/license-faq.html#PatentScope
See Apache Licensing and Distribution FAQs, particularly Q3/A3: https://www.apache.org/foundation/license-faq.html#PatentScope
See Apache Licensing and Distribution FAQs, particularly Q2/A2: https://www.apache.org/foundation/license-faq.html#PatentScope
See GPL 3.0 license, Section 10: “You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example . . . you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.”