Editor’s Note: This post was written by guest contributors David J. Kappos and Miling Y. Harrington. Mr. Kappos is a partner at Cravath, Swaine & Moore LLP. Previously, he served as the Under Secretary of Commerce and Director of the United States Patent and Trademark Office from August 2009 – January 2013. Ms. Harrington is an associate at Cravath, Swaine & Moore LLP. 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.
Recent decades have witnessed unparalleled technological achievements in the telecommunications, consumer electronics, and, now, autonomous vehicle space with a pace of innovation that only continues to accelerate. Both open source software (OSS) and standard essential patents (SEPs) have been integral structural supports for this innovation. SEPs and the associated policies of standard development organizations (SDOs), such as FRAND (“fair, reasonable and non-discriminatory”) licensing, insure that the best technology is adopted into standards, allowing implementers to create standardized and interoperable products for consumers at reasonable prices. 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. As innovative products evolved to encompass the most cutting edge IP, it was only natural that OSS would find its way into standards. However, some questions remain as to whether OSS is inherently compatible with FRAND licensing.
In the ongoing debate over open source licenses and their integration with standard essential patents governed by FRAND licensing (“OSS-FRAND”), two arguments are often presented against the application of FRAND to open source: (1) FRAND licensing is detrimental for innovation and (2) open source licenses are inherently incompatible with FRAND licensing. As we’ve previously discussed, neither of these arguments are true.[1] Now, a third argument counters that compliance with the Open Source Definition (OSD) has always been understood to preclude patent royalties.[2] We examined the historical record to understand whether such a generalization could be made about the open source community. Before we turn to the evidence that this concept was neither widely accepted nor frequently discussed, let us first unpack the background and reasoning behind why some think OSD-compliant licenses and patent royalties cannot coexist and explain why that view is incorrect.
I. The OSD Does Not Address Patent Rights
The Open Source Initiative, an organization that serves as an arbiter of acceptable open source licenses, maintains a set of parameters (the Open Source Definition or OSD) which must be satisfied for a license to be considered an open source license.[3] The OSD covers distribution, derived works, source code and non-discrimination, among other license parameters. Section 1 (OSD 1) and Section 7 (OSD 7) of the OSD impose requirements for free redistribution. OSD 1 requires that “the license shall not require a royalty or other fee for such sale.” OSD 7 concerns distribution of licensed software and states: “The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties,” precluding the execution of a separate license that would include royalties. There is no doubt that OSD-compliant licenses were designed to cover copyright and by extension, copyright royalties are not permitted. However, nowhere in the OSD does it state that an OSD-compliant license also conveys a patent grant.
II. The OSI Archives Do Not Evidence Consensus on Patent Rights
Despite the lack of any actual indication of an intention to convey patent rights, some advocates contend that an implied patent license exists in OSD-compliant licenses, thereby creating an OSD 1 and OSD 7–based conflict with patent royalties contemplated by OSS-FRAND. While this may be the position of some advocates, the question of whether the open source community generally had reached this consensus remained open. We set out to learn whether there is evidence to support an assertion of community consensus. We found no such consensus.
To remind ourselves of the conversations surrounding OSD-compliance and free redistribution attendant OSS, we examined all OSI License Discuss and License Review archives available from April 1999 to June 2018 for discussions mentioning OSD 1 or OSD 7.[4] We found that the community primarily discussed OSD 1 or OSD 7 in the context of analyzing whether specific licenses were OSD-compliant, with scant reference to patents. In over one hundred separate mentions each of OSD 1 and OSD 7 in the License Discuss archives, only seven of these instances contemplated OSD-compliant licenses to include a patent license. Likewise, we encountered around 40 mentions of OSD 1 and 60 mentions of OSD 7 in the License Review archives, only six of which supported the view that OSD-compliant licenses include a patent license. Furthermore, these views were contemporaneously challenged. For example, two of the six License Review mentions supporting the patent license view occurred in an April 8, 2009 thread where the opposing position was also presented.[5] However, there is no indication that a consensus view emerged within the community following this discussion. Even as recently as 2017, the License Discuss lists continued to debate whether the OSD generally covered intellectual property rights beyond copyright.[6] With around a dozen mentions (less than 4%) of OSD 1/OSD 7 requiring patent licensing out of over 300 discussions directed specifically to the OSD 1/OSD 7 licensing issues, and no conclusion of any kind being reached or even proposed, we cannot conclude that any “consensus” was reached. If anything, the data suggests the opposite conclusion—that the issue of patents was not assumed or overlooked; it was affirmatively raised by a few outliers; it did not get traction with the community, and like many other outlier comments, it was left unadopted; deemed rejected by omission.
III. There Is No Implied License in OSD
The view that a patent license can be implied from an OSD-compliant license seems to be rooted in a theory of legal estoppel. Proponents cite TransCore LP v. Electronic Transactions Consultants Corp. for judicial support.[7] However, TransCore is inapposite to the OSD license context. The TransCore court found that a covenant not to sue on an earlier issued patent as part of a settlement agreement created an implied patent license to a later-issued, related patent, and the patent-holder was legally estopped from suing for infringement of the later-issued patent. Regarding legal estoppel, the court stated: “The basic principle is, therefore, quite simple: ‘Legal estoppel refers to a narrow[ ] category of conduct encompassing scenarios where a patentee has licensed or assigned a right, received consideration, and then sought to derogate from the right granted.’”[8] 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. The OSD context also doesn’t lend itself to a “narrow category of conduct.” To the contrary, implying a patent licensee based on a free, unsigned, automatic copyright license would sweep in a broad array of conduct. Furthermore, although the Federal Circuit discussed legal estoppel in Wang Laboratories, Inc. v. Mitsubishi Electronics. America, Inc., 103 F.3d 1571, (Fed. Cir. 1997), its ultimate finding of an implied patent license was rooted in equitable rather than legal estoppel.[9] While legal estoppel analysis looks for “an affirmative grant of consent or permission to make, use, or sell; i.e. a license,” equitable estoppel analysis “focuses on ‘misleading’ conduct suggesting that the patentee will not enforce patent rights.”[10] Equitable estoppel has even less of a basis to be applied broadly to OSD licenses as a class.
Our research was unsuccessful in finding any court case that has considered whether patent licenses are implied by open source licenses in the absence of express language. But the caselaw surrounding implied licenses indicates that courts are hesitant to imply a license where one is not expressly set forth. The District of Delaware quoted the Federal Circuit in the recent case Endo Pharmaceuticals Inc. v. Amneal Pharmaceuticals, LLC, 224 F.Supp.3d 368 (D. Del. 2016), “[J]udicially implied licenses are rare under any doctrine,” in concluding that defendant Teva had not demonstrated facts supporting an implied patent license.[11] Likewise, the Northern District of California has stated, “’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.’”[12] The implied patent license inquiry in general is narrow and fact-specific,[13] and thus unsuited to any untethered genus, including OSD-compliant licenses as a class.
In summary, our research revealed no legal support for application of an implied patent license to OSD-compliant license agreements.[14] Instead, all extant case law, including recent court decisions, indicate 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.
IV. Key License Authors Had No Expectation of Granting Patent Rights
Given the lack of support for community consensus of a patent license during the early development of open source norms, and the lack of support in the case law, we surveyed the expectations of other important stakeholders. At the technology transfer offices of Berkeley and MIT, institutions credited with starting the eponymous and immensely popular, permissive BSD and MIT licenses respectively, the consensus is that these two licenses do not cross into patents. “MIT takes a pragmatic approach,” said Daniel Dardani, MIT’s chief software and information technology licensing officer. He continued, “The words of the license do not include any mention of patents, so we do not view a patent license as being granted. In fact, as a general rule, the TLO has avoided using open source licenses with express patent grant language. To imply a patent grant from licenses that otherwise do not contain such express language would create potential conflicts given MIT’s substantial and diverse portfolio of patented technologies, many of which are exclusively licensed to companies.”[15] This position is shared by Berkeley’s Office of Technology Licensing (OTL). Curt Theisen, the Associate Director of the OTL, adds, “The Berkeley OTL has never taken the position that the BSD includes a patent grant. In fact, we regularly advise our community members that the BSD license is an excellent OSS license to use because it permits broad licensing of software with minimal restrictions and maximum compatibility with other software and licenses.”[16] Both Berkeley’s and MIT’s views fit into the broader consensus that permissive licenses, unlike copyleft licenses, do not contain restrictive language and are compatible with FRAND licensing.[17] We are thus compelled to conclude that the view of certain OSD-compliant licenses necessarily granting patent rights causing incompatibility with FRAND is neither rooted in the past nor serves the interests of the present.
V. A Forced OSS-FRAND Free Patent License Disturbs the Innovation Ecosystem
Turning finally to the bigger picture, it is important to understand that OSD-compliant licenses in the context of OSS-FRAND cannot be examined in isolation. The software they cover is integrated into highly sophisticated products (such as smart phones) that encompass intellectual property covering myriad functions and components. To declare OSD-compliant licenses to be incompatible with patent royalties both over-extends the reach of the software license to functions and components beyond the scope of the license, and “solves” a problem that is already amply addressed by existing safeguards.
Given the integration of open source software into widely varying products containing innovations beyond the software, an implied patent license to the software inherently extends to those further innovations. This creates the unavoidable consequence of open source software undermining patent rights well beyond the software—an extreme result that could not have been intended or contemplated by anyone.
Moreover, such a measure is not necessary to protect technology implementers from unfair royalties. For one, 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. Furthermore, the FRAND system of licensing, which is required by standard development organizations, mandates reasonable terms and conditions—including reasonable royalties, and requires treating similarly situated licensees similarly. This existing system achieves a balance between making technologies available to implementers at a reasonable cost and rewarding and incentivizing innovators and creates no structural barriers against the adoption of open source. In fact, integrating open source into the current standards regime is as the European Commission puts it, a “win-win situation: on one side the alignment of open source and standardization can speed-up the standards development process and the take-up of…[standards] and on the other side standards can provide for interoperability of open source software implementations.”[18]
Because we observed conflicting positions regarding whether OSD-compliant licenses grant patent rights, we decided to examine the facts and law behind them. We found no significant support for the notion that OSD-compliant licenses convey patent rights —neither in the form of case law nor a community consensus. Instead, we found significant support for the opposite conclusion: that OSD-compliant licenses should not be assumed to grant patent licenses unless there is express language that states so. So in short, an OSS licensor can choose to grant a patent license or, like MIT and Berkeley, choose not to do so, and preserve the ability for OSS and SEPs to work in tandem in advancing innovation.
[1] 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) (available at http://www.stlr.org/cite.cgi?volume=18&article=kappos).
[2] Ensuring Openness Through and In Open Source Licensing, Open Source Initiative https://opensource.org/node/906 (last visited Oct. 7, 2018).
[3] The Open Source Definition (Annotated), Open Source Initiative https://opensource.org/osd-annotated (last visited Oct. 5, 2018).
[4] See OSI License Review Archives, http://lists.opensource.org/pipermail/license-review_lists.opensource.org/ and OSI License Discuss Archives, http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/.
[5] See OSI License Review Archives http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2009-April/thread.html at April 8, 2009 (“For approval: MXM Public license” thread).
[6] See OSI License Discuss Archives, http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2017-March/thread.html at March 7, 2017 (“Patent rights and the OSD” thread).
[7] Christian H. Nadan, Closing the Loophole: Open Source Licensing & the Implied Patent License, 26 Computer & Internet Law. 1 at 3 (Aug. 2009) (citing 563 F.3d 1271 (Fed. Cir. 2009)).
[8] 563 F. 3d at 1279 (quoting Wang Labs., Inc. v. Mitsubishi Elecs. Am., Inc., 103 F.3d 1571, 1582 (Fed. Cir. 1997))
[9] 103 F.3d at 1582 (Fed. Cir. 1997) (finding that Wang’s behavior over six years including repeatedly attempting to convince Mitsubishi to join the SIMMs market, providing Mitsubishi with designs, purchasing SIMMs from Mitsubishi, lobbying for Wang’s design to become an industry standard and receiving payment from Mitsubishi, were enough for Mitsubishi to infer that it had consent to use Wang’s patents).
[10] Id. at 1581.
[11]Endo Pharm. Inc. v. Amneal Pharm, LLC, 224 F.Supp.3d 368, 382 (D. Del. 2016) (quoting Wang Labs., Inc., 103 F.3d at 1581).
[12] Oracle Am., Inc. v. Terix Computer Co., Inc., No. 5:13-CV-03385 PSG, 2015 WL 2090191, at *8 (N.D. Cal. May 5, 2015) (quoting A & M Records, Inc. v. Napster, Inc., 239 F.3d 1004, 1026 (9th Cir. 2001)).
[13] See, e.g., Brian Cook, Clearing A Path for Digital Development: Taking Patents in Eminent Domain Through the Adoption of Mandatory Standards, 82 S. Cal. L. Rev. 97, 103 (2008).
[14] Some have also argued that regardless of whether a patent license can be implied, the theory of patent exhaustion somehow applies in the OSS context, preventing a patent owner from asserting its patent against users of its distributed code and thereby precluding the receipt of patent royalties. Nadan, supra note 5, at fn. 31. However, it is only “a patentee’s decision to sell a product [that] exhausts all of its patent rights in that item.” Impression Products, Inc. v. Lexmark Intern., Inc., 137 S. Ct. 1523, 1526 (2017). Permitting one’s software to be distributed under 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. We are aware of no case that has found the exhaustion doctrine to apply in the circumstances involved with open source licenses.
[15] Personal communication with D. Dardani, (March 19, 2018).
[16] Personal communication with C. Theisen, (June 12, 2018).
[17] Kappos, supra note 1.
[18] Communication from the Commission to the European Parliament, the Council and the European Economic and Social Committee Setting out the EU approach to Standard Essential Patents, COM (2017) 712 final (Nov. 29, 2017).