Editor’s Note: This post was written by guest contributor Van Lindberg. Mr. Lindberg is a member at Dykema Gossett and General Counsel of the Python Software Foundation. Previously, he served as Vice President of Intellectual Property and Associate General Counsel at Rackspace, a managed cloud hosting provider. A PDF of the following article can be found here and will be published in a forthcoming edition of the Columbia Science and Technology Law Review.
A patent gives its owner the right to exclude others from making, using, and selling the claimed invention. In contrast, open source licenses grant licensees broad permissions to modify, compile, distribute, and use software. When there is software that embodies or implicates patent claims, the patent-related right to exclude and the open-source-granted right to use are at least apparently in tension.
In their article, “The Truth About OSS-FRAND: By All Indications, Compatible Models in Standards Settings” (hereafter, “OSS-FRAND”), David Kappos and Miling Harrington attempt to address this tension in support of their policy position that it is both permissible and desirable to charge FRAND royalties on open-source-licensed code incorporated into a standard. As Kappos and Harrington cast it, they have observed others making three key arguments that they want to address and refute: “(1) FRAND licensing is detrimental for innovation and (2) open source licenses are inherently incompatible with FRAND licensing, … [and (3)] compliance with the Open Source Definition (OSD) has always been understood to preclude patent royalties.” This is the second in a series of articles in which Kappos has advanced similar policy positions. Regardless of the policy outcome that Kappos and Harrington may prefer, however, Kappos and Harrington fail to take into account some cases and facts that collectively undermine the legal and historical argument that they are attempting to make.
I will not engage with the first argument that Kappos and Harrington work to refute, that “FRAND licensing is detrimental for innovation.” Given the number of modern technologies that have evolved through the standards-setting process, I agree that FRAND-based standards setting is unquestionably a successful model for promoting and commercializing innovation. I also agree with the numerous statements in Kappos’ two articles recognizing that open source software (OSS) is also a successful model for promoting innovation. The deeper and more important question is whether these models are essentially “compatible,” as Kappos and Harrington describe, or whether they are “complementary,” as this article argues. To further refine this point, the core question is whether it is permissible to charge ongoing royalties on OSS-licensed materials incorporated into a standard by a patent holder or the patent holder’s licensee. As discussed below, neither the licenses, nor the law, nor good policy, support such a position.
This article proceeds in four parts. First, I present a simple model for evaluating open source licensing. Second, I address the existence and implications of explicit patent licenses included in many open source licenses. Third, I evaluate the points made by Kappos and Harrington relative to the Open Source Definition. Fourth, I discuss the complementary roles of OSS and FRAND licensing in promoting innovation.
Open source is a unique construct in intellectual property law. Rather than using intellectual property law to restrict the use of software, those same laws are used to guarantee the availability of OSS-licensed software to third parties. Some open source licenses accomplish this through broad, automatic licensing to all recipients. In other open source licenses, distributors are required to pass forward to all users the same permissions they received. These pass-forward licenses are sometimes referred to as “copyleft,” a play on the all-rights-reserved orientation of copyright.
While it is true that open source licensing can, in some sense, be considered “just software licensing,” a better mental model is that of a free trade agreement: Open source is a framework that allows people to share and trade intellectual property. This is different from traditional software licensing, where you typically trade intellectual property for money; with open source licenses you trade code—intellectual property—for other code.
A simple model of open source helps illuminate a number of unique factors associated with open source legal analysis. Let’s consider what happens when someone writes some code and releases that code under an open source license:
- Deborah Developer creates some software.
- Deborah chooses an open source license and distributes the software under the license.
- Larry Licensee receives a copy of the software and a copy of the license. The license includes a grant of permissions and one or more conditions with which Larry needs to comply.
- If Larry complies with the conditions, he also receives the right to distribute the software to other people.
Even though this model is simple, it hides tremendous legal complexity.
The first thing to notice about this model is that Deborah chooses an open source license—she doesn’t create an open source license. Most people don’t realize that “open source” is a defined term. Deborah can’t just write a new license and declare that the license is “open source.” There is an organization, the Open Source Initiative (or “OSI”), that certifies whether a license qualifies as an “open source license” or not. The OSI determines whether a license is open source by evaluating whether a proposed license conforms to a set of ten principles called the “Open Source Definition.” At the present time, there are only 81 currently-accepted open source licenses.
Thus, even though Deborah is the open source licensor (the party granting a license to her code), she didn’t draft the license or negotiate the terms of the open source license with Larry. Instead, she chooses one of the 81 official open source licenses and adopts it, “warts and all,” as the license for her software.
The implication of this fact is that some typical canons of license interpretation may not apply in the open source context. There is no finely tuned negotiation. Instead, the licensor chooses an open source license that most closely approximates the terms desired, and offers the software to any potential licensee on a “take it or leave it” basis.
Open source software is designed to spread. Both by presenting favorable terms to licensees and by restricting the set of available licenses (and license terms), open source licenses maximize the ease of distribution and minimize the friction associated with ordinary license negotiations. Open source licenses are self-executing, meaning that a new license grant is automatically given to each person receiving a copy of the covered work upon receipt.
In practice, this means that open source licenses are evaluated using a unilateral contract model. The software is made available under fixed license terms by the licensor, and a licensee indicates acceptance of the license by acting in a manner authorized by the license. In the context of open source licenses, almost any act by a potential licensee is enough to cause the license to attach. No specific performance other than receiving, using, or distributing the software is required.
C. Open Source Licenses are Legal Documents, But Commentary and Context Provide Clues to Interpretation
The scope of an open source license is evaluated just as if it were any other software license: by examining what is present within the “four corners” of the license document. The text of a particular license is the most important factor in understanding the scope of any license grants.
The problem is that many of the original open source licenses were not written by lawyers, but instead by engineers looking to maximize the use of their software. These engineer-written licenses may not reflect common legal usage.
Many open source licenses are also old, with many frequently-used licenses dating back two or three decades. These older licenses sometimes reflect legal understandings that were current when the license was written—not what is understood now.
However, there is a benefit to the history surrounding open source: there are many documents and public analyses that can be used to resolve ambiguous elements in the licenses and to understand the usage of trade that surround open source licenses.
The most important of these public analyses is the Open Source Definition, or “OSD.” The OSD was the result of a concerted effort to consolidate and standardize common usage around the meaning of the term “open source.” The OSD stands out as an interpretive aid because it codifies common principles that apply to all open source licenses. Each time a new possible open source license is proposed, the OSI shepherds a public evaluation of the proposed license, and ultimately votes whether or not to certify the license as “open source.” Thus, the OSD and the actions of the OSI can be given some interpretative weight in evaluating what both parties understood about the scope of an open source license grant.
Returning to the arguments advanced in OSS-FRAND, Kappos and Harrington focus the majority of their analysis on: 1) examining the text of the Open Source Definition, 2) reviewing licensing discussions in the OSI’s archives, and 3) evaluating statements from the technology licensing offices at MIT and U.C. Berkeley, the “stewards” and original “institutional” authors of the MIT and BSD licenses, respectively. Using these tools, Kappos and Harrington argue that there is no historical consensus supporting the argument that a patent owner is precluded from imposing patent royalties on software released under an OSD-compliant open source license.
I agree that the OSD is relevant, and Kappos and Harrington’s work analyzing the OSD is valuable. As noted above, the principles from the OSD can be used to illuminate the “meeting of the minds” between the licensor and the licensee. However, the primary interpretive effort should be centered on the text of the licenses themselves. But under standard canons of license interpretation, parol evidence is primarily useful for guiding interpretation when the text of the license itself is ambiguous—and I submit that there is less ambiguity in open source licenses than would first appear.
To set the terms of the debate, the key question is whether all open source licenses include a royalty-free patent license. This key question can be further subdivided into two related questions:
1) Do all open source licenses include a patent grant?
2) Do all open source licenses specify royalty-free terms?
Separating the key question in this way allows for a substantial simplification of the debate. The first principle of the OSD (henceforth “OSD 1”) specifies that all open source licenses allow for “Free Redistribution” and states that the license “shall not restrict any party from selling or giving away the software…. The license shall not require a royalty or other fee for such sale.” For their part, Kappos and Harrington appear to agree that all open source licenses allow for royalty-free redistribution. Thus, question #2 is answered in the affirmative: all open source licenses require royalty-free terms.
Thus, the focus of this article is on question #1—whether all open source licenses include a patent grant. Kappos and Harrington argue that they do not. I argue that they do.
In the analysis below, I’ll discuss three types of patent grants that apply to open source licenses: “classical” patent grants, “express” patent grants, and implied patent licenses. Because there are only 81 licenses, it is possible to exhaustively review every open source license for evidence of a patent grant. Having done so, I conclude that essentially every open source license includes a patent grant.
The first type is what I’ll call a “classical” patent grant, because this is the type of patent grant that appears in most commercial license agreements. A classical patent grant explicitly uses terms like “patent grant” or “patent license” and echoes the words used in the patent statute to describe a patent holder’s exclusive rights: make, use, sell, offer to sell, and import. For example, from the Academic Free License:
Grant of Patent License. Licensor grants You a worldwide, royalty-free, non-exclusive, sublicensable license, under patent claims owned or controlled by the Licensor that are embodied in the Original Work as furnished by the Licensor, for the duration of the patents, to make, use, sell, offer for sale, have made, and import the Original Work and Derivative Works.
There doesn’t seem to be any disagreement, including from Kappos and Harrington, that these classical patent grants are effective, and that an open source license that contains a classical patent grant is incompatible with FRAND licensing.
The second type of patent grant is what I’ll call an “express” patent grant. An express patent grant does not include a term such as “patent grant” or “patent license,” but the license explicitly grants permission for the licensee to exercise one or more of the rights reserved to a patent owner: to make, use, sell, offer to sell, or import. For example, from the MIT license:
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), 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, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
Similarly, the BSD license:
Redistribution and use, with or without modification, are permitted provided that the following conditions are met . . . .
I admit that most agreements that grant patent licenses use the term “patent.” And the general rule is that the existence of an explicit patent clause in an agreement will foreclose the finding of an implied license with a broader grant—but this is a different situation. Every license with an express patent grant includes an explicit grant of the right to “use” the software. Many licenses, like the MIT license, also grant other patent-denominated rights like the right to “sell.”
Courts have held that agreements that do not contain the word “patent” still may create a patent license if the patentee grants another party the ability to exercise one of the exclusive rights reserved to the patent holder under the statute. For example, in Viam Mfg., Inc. v. Iowa Exp.-Import Trading Co., the Federal Circuit held that a “Marketing Agreement” that stated that “[the patentee] agrees to supply Products to [the licensee] for sale in North America” created a patent license. The 11th Circuit Bankruptcy court cited Viam when analyzing another case, holding that the specific use of the term “sale” was significant, as the right to sell is exclusively reserved to patentees.
A second type of express patent grant is exemplified by the language in a broadly-used open source license called the GNU General Public License, version 2 (or “GPLv2”). The GPLv2 is unusual in that it mentions patents, but does not include a classical patent grant. Instead, there is broad and ambiguous language regarding the grant. The GPLv2 states that “[t]he act of running the Program is not restricted,” and there are statements stating the general belief that patent licenses are required, such as in the Preamble:
We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone’s free use or not licensed at all.
However, this is one of the few occasions in open source law where there is a ruling from a court directly on point. Although Kappos and Harrington indicate that they were “unsuccessful in finding any court case that has considered whether patent licenses are implied by open source licenses in the absence of express language,” this exact issue was discussed and decided in the context of a 12(b)(6) motion in XimpleWare, Inc. v. Versata Software, Inc. In Ximpleware, a patent holder and GPL licensor accused both Versata and Versata’s customers of patent infringement. As stated by the court, “Because an express license is a defense to patent infringement, XimpleWare’s direct infringement claims against Versata’s customers turn on whether the customers’ distribution is licensed under the GPL.” The Ximpleware court went on to find that because Versata’s customers had not distributed the GPL-licensed software in a way that violated the license terms, they had a valid license under the GPLv2—and under Ximpleware’s patents.
Between classical patent grants, express patent grants, and GPLv2-style patent grants, almost every open source license is accounted for. Of the 81 licenses certified as open source, all but three include either a classical patent grant or express patent grant including at least the right to “use” the software. The three exceptions are in a family of licenses (the Licences Libre du Québec) that are not written with reference to US law.
Thus, if effectively every open source license includes some kind of patent grant, the question turns from whether there is a patent grant to the scope of the grant provided. At that point, having established the existence of a patent grant, it is not too hard to find patent rights implicated within the grant, even if such grants are expressed in copyright-denominated terms. For example, the right to “copy” and “make derivative works” both sound in copyright—but to exercise those rights, it is necessary to exercise the patent-denominated right to “make.” The right to “distribute” also implicates the right to sell, offer to sell, and import; to think otherwise would suggest that someone could avoid infringing a patent by giving away an otherwise-infringing item.
As detailed above, every open source license written to be enforceable under U.S. law includes either a classical or an express patent grant. But open source licenses also may give rise to implied patent license.
The theory of implied patent licenses arises from De Forest Radio Telephone Co. v. United States, 273 U.S. 236 (1927). The classic statement establishing the theory of implied patent licensing is as follows:
Any language used by the owner of the patent, or any conduct on his part exhibited to another from which that other may properly infer that the owner consents to his use of the patent in making or using it, or selling it, upon which the other acts, constitutes a license and a defense to an action for a tort.
An implied license can be created by any communicative act by a patentee. It does not require specific words or phrases in an agreement. Rather, per De Forest, the focus of the implied license inquiry is on the language and actions of the patent owner or a licensee, and how the actions of the patent owner create expectations in the licensee.
Kappos and Harrington argue that “courts following precedent would be compelled to find against any implied patent license or any patent exhaustion theory in an OSD-compliant licensing context.” I disagree.
Kappos and Harrington focus their analysis on different theories that can ultimately give rise to an implied license, evaluating whether legal estoppel or equitable estoppel is more appropriate to the open source context (ultimately deciding that neither theory is appropriate). Focusing on the label, however, misses the insight identified by the court in Wang Labs., Inc. v. Mitsubishi Elecs. Am., Inc. (Fed. Cir. 1997):
Since De Forest, this court and others have attempted to identify and isolate various avenues to an implied license. As a result, courts and commentators relate that implied licenses arise by acquiescence, by conduct, by equitable estoppel (estoppel in pais), or by legal estoppel. These labels describe not different kinds of licenses, but rather different categories of conduct which lead to the same conclusion: an implied license. The label denotes the rationale for reaching the legal result. . . .
Neither this court nor the Supreme Court, however, has required a formal finding of equitable estoppel as a prerequisite to a legal conclusion of implied license.
Per the Wang court, it is more important to look at the “conduct” of the licensor, and how it would be seen by a licensee. “The primary difference between the estoppel analysis in implied license cases and the analysis in equitable estoppel cases is that implied license looks for an affirmative grant of consent or permission to make, use, or sell: i.e., a license.” As noted above, even the briefest, most permissive open source licenses include at least an affirmative grant to “use” the software and the capability to “sell.” This is the exact conduct identified by the Wang court as leading to an implied patent license.
Even Oracle v. Terix, which Kappos and Harrington use to support their argument, actually cuts the other way. “‘Courts have found implied licenses only in narrow circumstances where one party created a work at [the other’s] request and handed it over, intending that [the other] copy and distribute it.’” In the case of open source, the work may not have been created “at the other’s request,” but the act of releasing work under an open source license provides documented proof that the licensor “intend[ed] the other to copy and distribute it.” The Oracle court further states that “an implied license can be found where. . . the other [party] may properly infer that the owner consents to [the] use” of the work. Releasing code under an open source license provides exactly that inference.
Based on the review above, essentially every open source license includes either a classic patent grant or an express patent grant, and the context also provides support for a court to find an implied patent license. This analysis is based on the text of the open source licenses themselves—which is what a court would primarily examine if trying to determine whether the licenses granted any patent rights.
However, certain aspects of the OSD are helpful in evaluating what rights were intended to be included in all open source licenses. Given the weight that Kappos and Harrington appear to place on the OSD and other mailing list discussions, I will briefly address their points and make a few of my own.
The first argument advanced in OSS-FRAND is that the OSD does not address patent rights. To the extent that this point is limited to the explicit statement that “nowhere in the OSD does it state that an OSD-compliant license also conveys a patent grant,” this is true. The word “patent” does not appear in the text of the OSD.
However, this observation is less conclusive than it seems. For example, Kappos and Harrington agree that the OSD implicates copyright, but the word “copyright” does not exist in the OSD either. It is inconsistent to assume that the OSD only implicates copyright, but not patents, when the text of the OSD is actually silent as to both terms.
Rather than focus on “patents” or “copyrights,” the OSD instead focuses on the broad permissions required to be considered open source. For example, OSD 1 states that all open source licenses “shall not restrict any party from selling or giving away the software. . . . The license shall not require a royalty or other fee for such sale.” Kappos and Harrington focus narrowly on the text stating that “the license shall not require a royalty” and miss the broader context: The specific right protected is the right of any party to sell the software, royalty-free. The right to sell is one of the core reserved rights under patent law. All open source licenses comply with the OSD, by definition, all open source licenses incorporate this right.
In similar fashion, OSD 6 includes a right to use. As stated in OSD 6: “The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.” Although this element is stated in the negative, the intention is clear: OSS programs may be used by any person for any purpose.
Kappos and Harrington note that they reviewed “all OSI License Discuss and License Review archives” for discussions relevant to patent rights and the OSD. They highlight two mailing list threads in particular as informative: 1) an April 2009 thread on license-review, and 2) a March 2017 thread on license-discuss. Based on these mailing list discussions, they argue that the community showed a lack of “consensus” regarding the interaction of the OSD and patent rights.
More significant than the mailing list discussions, however, are the actions of the OSI in the contexts identified in those discussions. In the April 2009 thread, the MPEG Working Group—a standard development organization, one interested in maintaining FRAND patent licensing—asks for OSI’s approval of the “MXM Public License,” which is an open source license modified particularly to allow licensors in the standard-setting group “to ask for a [patent] license separately from the copyright.” The request to certify the MXM License as open source was denied by the OSI.
Similarly, the March 2017 discussion arose from OSI’s refusal to certify the “Creative Commons Zero” (CC0) license as open source. Again, the problem was an explicit reservation of patent rights.
Finally, Kappos and Harrington’s review appears to have missed a significant response to the April 2009 thread they highlight. The message was posted by Bruce Perens, one of the directors and original members of the OSI. It is significant enough that it deserves being quoted at length:
I am the creator of the Open Source Definition, and thus can shed some light on the parts that might be seen as ambiguous. . . .
The OSD does not distinguish between copyright, moral rights, patents, contract restriction, or any other means of restricting what someone can do with software. It applies equally to all of those. And thus I believe that your proposed license, by making explicit that patent rights are not granted for a large class of binary derivatives of the program, violates most of the OSD rules, not just rule number 7.
You could, however, construct a license that is . . . sufficiently restrictive that many implementors would prefer to license commercially. You can simultaneously place your reference implementation under a commercial license and an Open Source license like AGPL3, so that those who wish to commercially license the patents have a well-defined path for doing so. . . .
So, what you get is the “free” world using the patent without charge, and the proprietary world using it under license and paying royalties.
This is not perfect. . . . But it’s the best I can offer you if you want to be OSD compliant.
Thus, in contrast to Kappos and Harrington’s findings, the author of the Open Source Definition specifically and definitively addressed the issue: a royalty-free patent grant is necessary for compliance with the OSD.
Turning to the “bigger picture,” Kappos and Harrington argue that trying to respect the royalty-free status of OSS results in a kind of “forced license” when open source code is used in the context of a standard. This argument fundamentally misses the point that FRAND-based standard setting and OSS are two different types of innovation development regimes with different standards. They are complementary, not compatible.
As noted above, Kappos, Harrington, and I all agree that the FRAND-based standard-setting process has resulted in remarkable innovation and development. This process has a history and rules that must be respected for the process to work. Among these rules are the IPR policies of various organizations—policies that allow for and expect the imposition of FRAND-based royalties.
We also all agree that the collaborative production of open source communities has also resulted in remarkable innovation and development. Like the traditional standard-setting process, it also has a history and rules—including the licensing of intellectual property on a royalty-free basis for the purposes of collaborative development. In fact, it is the free, messy, noisy collaboration of many different parties with different interests that has resulted in the innovative development that Kappos and Harrington admire. Open source has a much shorter organized history than traditional standards processes, but it has “come out of nowhere” within a relatively short time to dominate all other software development methodologies. A recent estimate stated that 98% of all businesses were using open source code in their products or operations.
The problem, however, is that the policy solution advocated by Kappos and Harrington privileges FRAND-based standard-setting to the detriment of open source. They argue that when standard-setting communities intentionally incorporate OSS-licensed code into a standard, it is the royalty-free status of open source that should give way, not the payment of the FRAND-based royalty.
If adopted, however, their policy would have the effect of turning the royalty-free OSS world, with its attendant innovation, into a mere adjunct of the FRAND-based royalty-bearing world. In doing so, they would break the promise that OSS licensees could take any action allowed by the OSS license without requiring the “execution of an additional license by those parties.” Not to lean too heavily on a cliché, but this would have the effect of killing the goose that laid the golden eggs.
This is why open source and FRAND are complementary, not compatible: they rely on different intellectual property policies to generate innovation. These two development models can learn from each other, and compete with each other, but they are based upon fundamentally different underlying principles.
It is understandable why standard-setting organizations want to incorporate OSS: open source is inexpensive, interoperable, and innovative. Standard-setting organizations have the ability to change to become interoperable with OSS: simply adopt a royalty-free IPR policy, as many organizations have done. But those standard-setting organizations that wish to charge FRAND royalties ultimately have the same option that commercial enterprises have when dealing with open source: respect the licenses and rules that govern the usage of OSS, or take the time to create a commercia version that doesn’t have the same licensing cost.
† This work is made available under the Creative Commons Attribution—Non-Commercial—No Derivative Works 3.0 License.
* Mr. Lindberg is a member at Dykema Gossett and General Counsel of the Python Software Foundation. Previously, he served as Vice President of Intellectual Property and Associate General Counsel at Rackspace, a managed cloud hosting provider.
. 35 U.S.C. § 271(a) (2000) states, “Except as otherwise provided in this title, whoever without authority makes, uses, offers to sell, or sells any patented invention, within the United States, or imports into the United States any patented invention during the term of the patent therefor, infringes the patent.”
. David. J. Kappos & Miling Y. Harrington, The Truth About OSS-FRAND: By All Indications, Compatible Models in Standards Settings, 19 Colum. Sci. & Tech. L. Rev. (forthcoming 2019), available at http://stlr.org/wp-content/
. Id. at 2 (internal citations omitted).
. See David J. Kappos, Open Source Software and Standards Development Organizations: Symbiotic Functions in the Innovation Equation, 18 Colum. Sci. & Tech. L. Rev. 259, 267 (2017), http://www.stlr.org/
. See, e.g., “For its part, OSS innovation has progressed at breathtaking speed, significantly due to the strong social network of the OSS community and its ethos of sharing.” Kappos and Harrington, supra note 2, at 1; “Open Source Software also provides efficiencies and network effects crucial to innovation. Unlike proprietary software, OSS gives developers access to the source code of computer programs developed by others working on a given open source project, and enables developer communities to share tools and build on common infrastructure.” Id. at 261.
. It is possible to create new licenses and have them certified by the OSI to be “open source.” But creating a new open source license is a rare and time-consuming process, the details of which are not relevant to the arguments presented here.
. Open Source Initiative, The Open Source Definition (1998), https://opensource.org/osd-annotated.
. See the list of currently approved licenses by the OSI, https://opensource.org/licenses/alphabetical.
. For information on who originally wrote various licenses, see Wikipedia, Comparison of free and open-source software licenses, available at https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses (accessed Jan. 18, 2019).
. See, e.g., “Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License.” Section 10 of the GNU General Public License, version 3: 10. Automatic Licensing of Downstream Recipients, https://www.gnu.org/licenses/gpl-3.0.en.html.
. See, e.g., “You are not required to accept this License. However, nothing else grants You permission to use, copy, modify or distribute the software or its derivative works.” RealNetworks Public Source License Version 1.0 (RPSL-1.0), https://opensource.org/licenses/RPSL-1.0.
. See Open Source Initiative, History of the OSI, available at https://opensource.org/history (accessed Dec. 1, 2018).
. Kappos & Harrington, supra note 2, at § I.
. Id. at § II.
. Id. at § IV.
. Id. at p. 2.
. The comments of the license stewards, id. at § III, are interesting but of questionable relevance. A court would not give private, hearsay statements by non-parties any interpretive weight. Even in terms of historical understanding, the individuals quoted were not present when these licenses were created by their institutions, and no one presents any evidence that they have special historical insight.
. The full text of the first principle of the OSD reads: “1. Free Redistribution: The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale. Rationale: By constraining the license to require free redistribution, we eliminate the temptation for licensors to throw away many long-term gains to make short-term gains. If we didn’t do this, there would be lots of pressure for cooperators to defect.” Open Source Initiative, The Open Source Definition (1998), https://opensource.org/osd-annotated.
. “Section 1 (OSD 1) and Section 7 (OSD 7) of the OSD impose requirements for free redistribution.” Kappos, supra note 2, at 2. “To remind ourselves of the conversations surrounding OSD-compliance and free redistribution attendant OSS….” Id. at 3.
. “However, nowhere in the OSD does it state that an OSD-compliant license also conveys a patent grant.” Id. at 3. “TransCore clearly involved patent rights and a patentee to begin with, unlike the OSD license context which is rooted in an affirmative copyright grant and no patent grant.” Id. at 4.
. N.B: Only the phrase “implied patent license” is a term of art. The categorization of other grants as “classical” or “express” is used here for clarity in referring to different styles of wording a patent grant.
. 35 U.S.C. § 271(a), supra note 1; see also 35 U.S.C. § 154(a)(1).
. Lawrence Rosen, Academic Free License (“AFL”) Version 3.0, (2002), available at https://opensource.org/licenses/AFL-3.0.
. For example, Kappos and Harrington say: “OSS authors who wish to extend a patent license already have the ability to do so through licenses like Apache 2.0 and GPL v3 that contain express patent license grant language.” Kappos & Harrington, supra note 2, at 7.
. Massachusetts Institute of Technology, MIT License (1988), available at https://opensource.org/licenses/MIT (emphasis added).
. Regents of the University of California, The 2-Clause BSD License (1999), available at https://opensource.org/licenses/BSD-2-Clause (emphasis added).
. According to federal law applicable to patents, a ‘license’ is essentially permission to use, make, or sell intellectual property and a ‘promise by the licensor not to sue the licensee.’” In re Davidson Hydrant Techs., Inc., No. 11-13349-WHD, 2012 Bankr. LEXIS 1120, at *13 (Bankr. N.D. Ga. Jan. 10, 2012).
. Viam Mfg., Inc. v. Iowa Exp.-Import Trading Co., 99-1280, 00-1038, 2000 U.S. App. LEXIS 22443, at *17 (Fed. Cir. Aug. 31, 2000).
. “[It] does appear that the marketing agreement at issue in Iowa Export-Import differed from the Agreement in at least one key way. The Iowa Export-Import agreement clearly used the word ‘sale,’ whereas the Agreement does not.” In re Davidson Hydrant Techs., Inc., supra note 25, at *20-21.
. GPLv2, at § 0.
. GPLv2, Preamble. Cf. § 7, which includes similar language.
. Kappos & Harrington, supra note 2, at 5.
. XimpleWare, Inc. v. Versata Software, Inc., 2014 U.S. Dist. LEXIS 68515 (N.D.Cal 2014).
. Id. at *15 (emphases added).
. Of the 81 currently accepted by OSI as open source: a) 38 include a classical patent grant; b) 32 contain an express grant to “use” the software, and sometimes include other rights, such as the rights to “sell”; c) five adopt the language of the GPLv2, which a court has held to include an express patent grant; and d) the final three are licenses written with reference to Canadian law.
. De Forest Radio Tel. Co. v. United States, 273 U.S. 236, 241 (1927).
. Kappos, supra note 2, at 6.
. Id. at 5.
. Wang Labs., Inc. v. Mitsubishi Elecs. Am., Inc. 103 F.3d 1571, 1583 (Fed. Cir. 1997)
. Id. at 1580-81 (emphasis added, internal citations omitted).
. Id. at 1581.
. See the breakdown of licenses at note 34.
. Oracle Am., Inc. v. Terix Comput. Co., Inc. No. 5:13-CV-03385 PSG, 2015 WL 2090191.
. Id. at *8 (N.D. Cal. May 5, 2015) (quoting A & M Records, Inc. v. Napster, Inc. 239 F.3d 1004, 1026 (9th Cir. 2001)) (emphasis added).
. Id. at *27-28.
. Kappos and Harrington further assert in a footnote that “an OSS license that conveys no patent rights involves neither the selling of a product nor the licensing of a patent and does not implicate patent exhaustion.” Kappos & Harrington, supra note 2, at note 14. However, this disregards LifeScan Scot., Ltd. v. Shasta Techs., LLC., 734 F.3d 1361 (Fed. Cir. 2013): “[A] patentee cannot evade patent exhaustion principles by choosing to give the article away rather than charging a particular price for it. Where a patentee unconditionally parts with ownership of an article, it cannot later complain that the approach that it chose results in an inadequate reward and that therefore ordinary principles of patent exhaustion should not apply.” Id. at 1374-1375, internal citations omitted. A transfer of software according to a license, regardless of the price charged for that license, is a transfer that implicates patent exhaustion.
. For example, the Ximpleware court found an express patent license based upon its examination of the text of the GPLv2. It did not look beyond the text at the OSD or any other parol evidence.
. Kappos, supra note 2, at 3.
. “There is no doubt that OSD-compliant licenses were designed to cover copyright and by extension, copyright royalties are not permitted.” Id.
. The Open Source Initiative, supra note 17.
. The copyright statute also mentions sale, but only in the context of the broader right to distribute copies: “The owner of copyright under this title has the exclusive rights… 3. to distribute copies or phonorecords of the copyrighted work to the public by sale or other transfer of ownership, or by rental, lease, or lending.” 17 U.S.C. § 106(3) (2010). In copyright licenses, this is usually called the right to “distribute,” whereas in patent licenses, the key word for this right is to “sell” or “offer to sell.”
. The full text of this element of the OSD reads: “6. No Discrimination Against Fields of Endeavor: The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. The Open Source Initiative, supra note 17.
. Id. at 3-4.
. See OSI License Review Archives (April 8, 2009), http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2009-April/thread.html (“For approval: MXM Public license” thread).
. See OSI License Discuss Archives (March 7, 2017), http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2017-March/thread.html (“Patent rights and the OSD” thread).
. Kappos, supra note 2, at 3.
. See OSI License Review Archives, http://lists.opensource.org/
. See OSI License Review Archives (April 14, 2009), http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2009-April/thread.html (“What would work instead of the MXM public license?” thread, in particular the first message by Bruce Perens, available at http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2009-April/000757.html).
. Kappos, supra note 2, at 7.
. See generally Eric S. Raymond, The Cathedral and the Bazaar (2000), available at http://www.catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/.
. Zend.com, Open source adoption: Risk factors for the enterprise (2017), available at https://blog.zend.com/2017/03/15/open-source-adoption-risk-factors-for-the-enterprise/.
. The Open Source Initiative, supra note 17.