The Elephant in the Room: Patent Value and Open Source Software

advertisement
The Elephant in the Room: Patent Value and Open Source Software
Originally prepared for the AIPLA 2011 Spring Meeting, April 2011
Michele Herman
Davis Wright Tremaine LLP
and
Joanne Montague
Davis Wright Tremaine LLP
I.
Background
Rarely do we think about what tractors and medical devices have in common. Yet both tractors
and medical devices in operation today incorporate open source software (“OSS”). OSS is
software that is licensed under an OSS license. There are hundreds of OSS licenses and unique
OSS licenses can be crafted by any software developer. In general, the terms of an OSS license
state that a recipient of the OSS is free to copy, modify, and redistribute the OSS in source or
executable form, with or without modifications. The most notable observation about OSS,
however, is that today it can be found in nearly every product that includes software and in
applications that run on virtually any device, and within the infrastructure that runs nearly any
type of business.
Some OSS licenses are very permissive in that the only requirements for compliance include
reproduction of the copyright notice and OSS license in each copy of the OSS that is distributed.1
Other OSS licenses are quite restrictive despite being “royalty-free.”2 These restrictive licenses,
also known as copyleft or reciprocal licenses, require the source code to be made available to
downstream recipients including a distributor’s own modifications and additions along with the
copyright notice and the OSS license. Some restrictive OSS licenses may attach very broadly,
however, to “additions” and “modifications” so that the restrictive OSS license covers substantial
proprietary software that may be combined with the OSS and distributed together.
It should be clear that those developing the OSS cannot obtain a direct return on their investment
then by charging royalties or other fees associated with the OSS and that those using OSS with
their own proprietary software may place their own software at risk of also being subject to the
OSS licensing terms. It seems illogical then that the development and use of OSS would be so
pervasive.
There are many valid reasons for the widespread acceptance of OSS. Several business models
leverage OSS. Information and Communications Technology (“ICT”) service-based businesses
that provide ICT support, integration, customization, and/or maintenance rely on their customers
purchasing a solution of hardware, software, and such services. If the software is free, customers
may be willing to pay for the services so long as the total cost of the solution meets the
customers’ expectations and needs. Some device makers that traditionally invest their R&D
dollars into hardware development have fewer internal resources to expend on software
development. Such device manufacturers may find that they can limit their R&D investment in
software development by investing in OSS community development projects because the costs of
such projects are shared by others with the same motivation and the software is not needed to
differentiate their products.
Increasingly, users of OSS have become cognizant of the various legal risks associated with
using OSS. For example, failure to comply with the OSS license terms can result in
1
The BSD License and the MIT License are two such examples of very permissive OSS licenses. OPEN SOURCE INITIATIVE, THE
BSD LICENSE, available at http://www.opensource.org/licenses/bsd-license.php [hereinafter BSD LICENSE]; OPEN SOURCE
INITIATIVE, THE MIT LICENSE, available at http://www.opensource.org/licenses/mit-license.php [hereinafter MIT LICENSE ].
2
The GPLv2 License is one such example. FREE SOFTWARE FOUNDATION, INC., GNU GENERAL PUBLIC LICENSE, VERSION 2
(1991), available at http://www.gnu.org/licenses/gpl-2.0.html [hereinafter GPLV2].
April 2011
Page 1
infringement claims.3 Users that combine OSS with their own proprietary software are
becoming more aware of risks that their proprietary software could become subject to the terms
of restrictive OSS licenses requiring such users to release their source code for free should they
distribute the software to their own customers or partners.4 Yet relatively few users have been
concerned about the impact of OSS distribution on their patent portfolios. Indeed, until recently,
many users erroneously believed that since OSS was freely distributed it was also free from
patent infringement claims. Further, some OSS developers believe that patent licensing in
general is inconsistent or even prohibited under OSS licensing models. In recent months, these
myths have been largely extinguished with a multitude of patent lawsuits filed against the
Android platform or devices running the Android platform.5
In addition, several common OSS licenses include defensive revocation provisions that can
impact the value of a party’s patent portfolio if the party is using OSS licensed under a license
with such provisions. If a recipient of the OSS threatens or sues an OSS licensor or a party using
the licensed OSS, the OSS license may permit or result in license termination. The type and
scope of claims and the action taken that may trigger such defensive revocation provisions vary
from one OSS license to the next. But to the extent that the OSS is crucial to a user’s product or
operations, the defensive revocation provision may be tantamount to a patent grant back as such
user may not from a business perspective be able to assert certain patent claims against an OSS
licensor or OSS distribution.
Finally, software including OSS must often conform to ICT standards to enable interoperation,
communication, and information exchange with other products and services. Such standards are
often developed under patent policies that permit participants in the standards setting process to
license their essential patent claims to implementers of the standard under reasonable and nondiscriminatory (“RAND”) terms and conditions either with RAND compensation or without
compensation, the latter being referred to as a RAND-RF commitment (RAND license terms on
3
Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008); Press Release, Best Buy, Samsung, Westinghouse, and Eleven Other
Brands Named in SFLC Lawsuit (Dec. 14, 2009), http://www.softwarefreedom.org/news/2009/dec/14/busybox-gpl-lawsuit/;
Press Release, Free Software Foundation, Free Software Foundation Files Suit Against Cisco for GPL Violations (Dec. 11,
2008), http://www.fsf.org/news/2008-12-cisco-suit; Press Release, Software Freedom Law Center, SFLC Files GPL Violation
Lawsuit Against Extreme Networks, Inc. (July 21, 2008), http://www.softwarefreedom.org/news/2008/jul/21/busybox/; Press
Release, Software Freedom Law Center, SFLC Files Another Round of GPL Violation Lawsuits on Behalf of BusyBox
Developers (June 10, 2008), http://www.softwarefreedom.org/news/2008/jun/10/busybox/.
4
See, e.g., David Goldberg, Quick Counsel: Open Source Software, ASSOC. OF CORP. COUNSEL, Nov. 30, 2010, available at
http://www.acc.com/legalresources/quickcounsel/QuickCounsel_Open_Source_Software.cfm?makepdf=1; Paul C. Remus &
Kristin A. Mendoza, The Risks of Using Open Source Software: Using It in Proprietary Software or Products Can Have Serious
Implications for Evaluating the Value of a Business, ALLBUSINESS, Feb. 27, 2009, available at
http://www.allbusiness.com/legal/contracts-law-licensing-agreements/11816286-1.html.
5
See Amended Complaint, In re Certain Handheld Electronic Computing Devices, Related Software and Components Thereof,
No. 337-TA-769 (ITC Apr. 8, 2011); Amended Complaint, In re Certain Mobile Devices, Associated Software, and Components
Thereof, No. 337-TA-744 (ITC Oct. 12, 2010); Complaint, In re Certain Personal Data and Mobile Communications Devices and
Related Software, No. 337-TA-710 (ITC Mar. 2, 2010); Complaint, Microsoft Corp. v. Barnes & Noble, Inc., No. 2:11-cv-00485
(W.D. Wash. Mar. 21, 2011); Amended Complaint, Oracle Am., Inc. v. Google, Inc., No. 3:10-cv-03561 (N.D. Cal. Oct. 27,
2010); Complaint, Gemalto S.A. v. HTC Corp., No. 6:10-cv-561 (E.D. Tex. Oct. 22, 2010); Complaint, Microsoft Corp. v.
Motorola, Inc., No. 2:10-cv-01577 (W.D. Wash. Oct. 1, 2010); Complaint, NTP, Inc. v. High Tech Computer Corp., No: 3:10-cv00472 (E.D. Va. July 8, 2010); Complaint, NTP, Inc. v. LG Elecs. Mobilecomm U.S.A., Inc., No: 3:10-cv-00468 (E.D. Va. July
8, 2010); Complaint, NTP, Inc. v. Google Inc., No: 3:10-cv-00469 (E.D. Va. July 8, 2010); Complaint, NTP, Inc. v. Motorola,
Inc., No: 3:10-cv-00471 (E.D. Va. July 8, 2010); Complaint, Apple Inc. v. HTC Corp., No. 1:10-cv-00544, (D. Del. June 21,
2010); Complaint, Apple Inc. v. HTC Corp., No. 1:10-cv-00167 (D. Del. Mar. 2, 2010); Complaint, Apple Inc. v. HTC Corp.,
No. 1:10-cv-00166 (D. Del. Mar. 2, 2010).
April 2011
Page 2
a royalty-free basis). Because some OSS developers believe that RAND and RAND-RF licenses
are inconsistent with or even prohibited by OSS licensing models, they have argued that patent
policies used by standards setting organizations (“SSOs”) must be changed to accommodate OSS
licensing practices. Such changes if made would not only be unnecessary as they are based on a
misunderstanding of the issues but would adversely affect innovation, competition, and user
choice, as well as devalue patent portfolios of those participating in the relevant SSOs.
There is currently little case law on point to help assess the various risks to a party’s patent
portfolio associated with using OSS and few OSS users have analyzed these risks in detail.
Given the lack of official guidance or even generally held industry views, this paper will explore
some possible issues observed by the author and their potential impact on patent portfolios of
OSS users when incorporating OSS into products that they distribute to their customers or
partners. Part II provides a brief overview of sample OSS licenses and some issues regarding
how to properly interpret the scope of the OSS license. Part II also evaluates the impact of a
recent Federal Circuit case, TransCore LP v. Electronic Transactions Consultants Corp.,6 on the
scope of any patent licenses that may be granted under an OSS license. Part III discusses the
impact of OSS-related patent licenses on an OSS licensor’s patent portfolio. Part IV analyzes the
scope of patent grant backs that might be extracted from OSS users based on defensive
revocation provisions included in many OSS licenses. Part V investigates the compatibility of
patent licensing with OSS license models and the impact of proposed changes to SSO patent
policies on participants’ patent portfolios.
II.
OSS: Express and Implied Patent Licenses
Many OSS licenses are presumed to be primarily copyright licenses. Copyright licenses grant
permission to “reproduce,” “prepare derivative works,” “distribute,” “perform,” and/or “display”
the copyrighted software. All of the quoted permissions are the exclusive rights of a copyright
holder enumerated in 17 U.S.C. § 106. Yet few OSS licenses grant only these statutory rights.
Instead many OSS licenses grant recipients permission to “use” the software, a term used in the
patent statutes.7 OSS licenses also incorporate grants, for example, to “copy” or “redistribute”
the software; terms not precisely specified in either the patent or copyright statutes. On the one
hand, a court might infer that because “use” is a statutory patent term, by granting recipients
permission to “use” the software, patent rights necessary to implement the OSS are implied. On
the other hand, a court might infer that no patent rights have been granted because the permission
to “use” the software is not sufficiently clear since no mention is made of patents and other terms
are used without any recognized statutory analogue. It is therefore not clear whether a court
would find that a patent “use” right was intended or effective.
Software, unlike other copyrighted materials, moreover, blurs the lines between the exclusive
rights conferred under the patent and copyright statutes. For example, software is often “made,”
an exclusive patent right, by “reproducing” the software to produce another copy of the software.
“Using” the software requires the software to be compiled and copied into a computer’s memory.
6
563 F.3d 1271 (Fed. Cir. 2009).
35 U.S.C. § 271(a) 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.” (emphasis added).
7
April 2011
Page 3
The act of “using” the software, therefore, may require the preparation of a derivative work in
addition to the right to reproduce the derivative work.8 Software may be sold, but it is often
distributed under a license. It is unclear whether the distribution of software under a license is
equivalent to selling the software under the patent laws.9
A.
OSS Licenses Without Express Patent Grants
Several common OSS licenses illustrate how the rights granted to recipients of OSS are blurred
as a result of the language of the license. For example, the Apache Software License v. 1.1 and
the BSD License, common permissive OSS licenses, both state:
Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met: …10
A party might argue that it reasonably interprets this language to grant both patent and copyright
licenses to recipients of the OSS to make an unlimited number of copies of the software, make
changes to that software, run the software with or without the modifications by compiling such
software or modified software, and sell and/or distribute the software with or without
modifications. On the other hand, a party might argue that because the drafters added an explicit
patent grant of limited scope to a later version of the license, the Apache License, Version 2.0
(“Apache License 2.0”),11 the drafters did not consider the terms of the earlier version sufficient
to grant any patent rights.12
The MIT License, another commonly used permissive OSS license, provides:
8
17 U.S.C. § 117(a) states “…it is not an infringement for the owner of a copy of a computer program to make or authorize the
making of another copy or adaptation of that computer program provided: (1) that such a new copy or adaptation is created as an
essential step in the utilization of the computer program in conjunction with a machine and that it is used in no other manner…”;
See DSC Communs. Corp. v. Pulse Communs., Inc., 170 F.3d 1354, 1361 (Fed. Cir. 1999) (stating “[a]s we have seen, section
117 limits the copyright owner's exclusive rights by allowing an owner of a copy of a computer program to reproduce or adapt
the program if reproduction or adaptation is necessary for the program to be used in conjunction with a machine”).
9
E.g., Acacia Subsidiary Settles Patent Litigation with Red Hat, BUSINESS WIRE, Apr. 29, 2011, available at
http://www.businesswire.com/news/home/20110429005167/en/Acacia-Subsidiary-Settles-Patent-Litigation-Red-Hat; Caroline
McCarthy, Linux Patent Suit Ruled Against Google, CNET NEWS, Apr. 21, 2011, available at http://news.cnet.com/830113577_3-20056192-36.html#ixzz1KHVsMRyw; Complaint, Bedrock Computer Techs. LLC v. Software Techs., Inc., No. 6:09cv-00269 (E.D. Tex. June 16, 2009); Verdict Form, Bedrock Computer Techs. LLC v. Google Inc. No. 6:09-cv-00269 (E.D. Tex.
Apr. 15, 2011).
10
THE APACHE FOUNDATION, APACHE LICENSE, VERSION 1.1 § 1 (2000), available at http://www.apache.org/licenses/LICENSE1.1 (emphasis added); BSD LICENSE, supra note 1, § 1 (emphasis added).
11
THE APACHE FOUNDATION, APACHE LICENSE, VERSION 2.0 § 3 (2004), available at http://www.apache.org/licenses/LICENSE2.0.html [hereinafter APACHE LICENSE 2.0].
12
Commentators have argued that “…the University of California made no patent grant in the BSD license. Indeed, later in the
license the University specifically used the phrase this software is provided by the copyright holders and contributors, suggesting
by its absence that there are no patent holders or that those patent holders are not granting anything in the license.” LAWRENCE
ROSEN, OPEN SOURCE LICENSING 78 (2005). Other than in the context of patent exhaustion for the sale of goods, the courts have
only inferred a patent grant when all the elements of equitable or legal estoppel are proven by the litigant. Thus, the issue of
whether a court might determine that a patent right is given by the use of terms such as “use” remains one for which reasonable
arguments could be advanced for either position, and it is not certain which way the courts may ultimately rule.
April 2011
Page 4
Permission is hereby granted, … 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 …13
Again, it could be argued that it is reasonable for a recipient of OSS licensed under the MIT
License to assume that it was receiving grants to both copyright and patent rights based on the
express language of the MIT License grant, but the absence of any mention of patents may
indicate that patent rights are not being conferred by the license.
The GNU General Public License, Version 2 (“GPLv2”), the quintessential restrictive or copyleft
license, is careful to craft the license grant in terms that closely track exclusive rights granted by
the copyright statute. The relevant license text provides:
You may copy and distribute verbatim copies of the Program's source code as you
receive it, in any medium, provided that …14
You may modify your copy or copies of the Program or any portion of it, thus
forming a work based on the Program, and copy and distribute such modifications
or work under the terms of Section 1 above, provided that …15
You may copy and distribute the Program (or a work based on it, under Section 2)
in object code or executable form under the terms of Sections 1 and 2 above
provided that you also do one of the following …16
Note that there is no mention that the license grant is limited to copyright permissions. As
discussed above, software unlike other copyrighted materials may uniquely implicate both patent
and copyright rights depending on one’s interpretation of the rights granted to licensees.
Consequently, one might reasonably argue that a GPLv2 licensor is granting rights under both
patent and copyright licenses under the GPLv2. Conversely, one could reasonably argue that the
GPLv2 explicitly mentions patents in the preamble and in sections 7 and 8, yet fails to include an
express patent grant. A court might find that the authors of the license could have made an
express patent grant, as they later did in the GNU General Public License, Version 3,17 and their
failure to do so creates an ambiguity that does not rise to the level of inferring a patent grant
based on the bare terms of the license.
B.
OSS Licenses with Express Patent Grants
Because OSS licenses all permit downstream licensees to modify the software, there is also a
question as to whether or not any patent licenses would flow to the modifications and/or the
combination of the modifications and the OSS distributed by the licensor. To avoid confusion
about the extent and scope of patent licenses associated with OSS licenses, many OSS licenses
include an express patent license. For example, the Apache License 2.0 provides:
13
MIT LICENSE, supra note 1 (emphasis added).
GPLV2, supra note 2, § 1 (emphasis added).
15
Id. § 2 (emphasis added).
16
Id. § 3 (emphasis added).
17
FREE SOFTWARE FOUNDATION, INC., GNU GENERAL PUBLIC LICENSE, VERSION 3 § 11 (2007), available at
http://www.gnu.org/licenses/gpl-3.0.html.
14
April 2011
Page 5
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.18
It would appear that the Apache License 2.0 therefore expressly limits the patent grants to a
party’s own additions or modifications, alone or combined with the software that party received
under the Apache License 2.0. In other words, if party A licenses a Work under the Apache
License 2.0 and party B adds X to that Work and distributes X plus the Work to party C under
the Apache License 2.0, then party C would expect to receive a patent license from B (not A) to
X alone and X in combination with the Work.
Interestingly, the Apache License 2.0 narrowly defines Contributions as follows:
‘Contribution’ shall mean any work of authorship, including the original version
of the Work and any modifications or additions to that Work or Derivative Works
thereof, that is intentionally submitted to Licensor for inclusion in the Work by the
copyright owner or by an individual or Legal Entity authorized to submit on
behalf of the copyright owner. For the purposes of this definition, ‘submitted’
means any form of electronic, verbal, or written communication sent to the
Licensor or its representatives, including but not limited to communication on
electronic mailing lists, source code control systems, and issue tracking systems
that are managed by, or on behalf of, the Licensor for the purpose of discussing
and improving the Work, but excluding communication that is conspicuously
marked or otherwise designated in writing by the copyright owner as ‘Not a
Contribution.’19
The language requiring that the contribution be intentionally submitted to the Licensor may
significantly impact the expectation stated above. C, in the example above, may expect a patent
license from B if B submits X to A to be incorporated in the Work and A distributes X plus the
Work to C. Such a licensing model makes sense in the context of a community development
project such as those hosted by the Apache Software Foundation (“ASF”) in which contributions
are submitted to the ASF for inclusion in certain projects and the project code is licensed by the
ASF under the Apache License 2.0.
With this understanding, however, we must re-evaluate the first example in which B adds X to
the Work and directly distributes the Work. In that case, B may be the licensor for the entire
Work that now includes X by definition, in which case the patent license for the Work including
X arguably applies to B.
18
19
APACHE LICENSE 2.0, supra note 11, § 3 (emphasis added).
Id. § 1 (emphasis added).
April 2011
Page 6
Other licenses, such as the Common Development and Distribution License Version 1.0
(“CDDL”), expressly provide for the result described above where B is only licensing patents
with regard to X and the combination of X plus the work. The language in the CDDL by way of
comparison to the Apache License 2.0 provides:
[E]ach Contributor hereby grants You a world-wide, royalty-free, non-exclusive
license: … (b) under Patent Claims infringed by the making, using, or selling of
Modifications made by that Contributor either alone and/or in combination with
its Contributor Version (or portions of such combination), to make, use, sell, offer
for sale, have made, and/or otherwise dispose of: (1) Modifications made by that
Contributor (or portions thereof); and (2) the combination of Modifications made
by that Contributor with its Contributor Version (or portions of such
combination).20
The CDDL defines Modifications as follows:
1.9. Modifications means the Source Code and Executable form of any of the
following:
A.
Any file that results from an addition to, deletion from or
modification of the contents of a file containing Original Software
or previous Modifications;
B.
Any new file that contains any part of the Original Software or
previous Modification; or
C.
Any new file that is contributed or otherwise made available under
the terms of this License. 21
It follows then that under the CDDL, patent licenses will be limited to those files set forth in the
definition of Modifications.
Another common license is the Eclipse Public License – v 1.0 (“EPL”), which provides:
Subject to the terms of this Agreement, each Contributor hereby grants Recipient
a non-exclusive, worldwide, royalty-free patent license under Licensed Patents to
make, use, sell, offer to sell, import and otherwise transfer the Contribution of
such Contributor, if any, in source code and object code form. This patent license
shall apply to the combination of the Contribution and the Program if, at the time
the Contribution is added by the Contributor, such addition of the Contribution
causes such combination to be covered by the Licensed Patents. The patent
license shall not apply to any other combinations which include the Contribution.
No hardware per se is licensed hereunder.22
and
20
OPEN SOURCE INITIATIVE, COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL), VERSION 1.0 § 2.2, available at
http://www.opensource.org/licenses/cddl1.php [hereinafter CDDL].
21
Id. § 1.9.
22
ECLIPSE , ECLIPSE PUBLIC LICENSE - V 1.0 § 2(b), available at http://www.eclipse.org/legal/epl-v10.html [hereinafter EPL].
April 2011
Page 7
‘Contribution’ means:
a) in the case of the initial Contributor, the initial code and documentation
distributed under this Agreement, and
b) in the case of each subsequent Contributor:
i) changes to the Program, and
ii) additions to the Program;
where such changes and/or additions to the Program originate from and
are distributed by that particular Contributor. A Contribution ‘originates’
from a Contributor if it was added to the Program by such Contributor
itself or anyone acting on such Contributor’s behalf. Contributions do not
include additions to the Program which: (i) are separate modules of
software distributed in conjunction with the Program under their own
license agreement, and (ii) are not derivative works of the Program.23
Since the patent grant under the EPL is limited to the specific changes, not the entire file to
which changes are made or in which the OSS code is included, the patent grant under the EPL is
even narrower than the patent grant in the CDDL.24
C.
Impact of Case Law on the Scope of OSS Patent Licenses
1.
Intel Corp. v. Broadcom Corp., 173 F. Supp. 2d 201 (D. Del. 2001)
An implied license will likely not be found when the license includes an express patent license.25
In Intel Corp. v. Broadcom Corp., an agreement contemplated a joint development effort to be
accomplished through the exchange of proprietary technology, including patent rights.26 The
agreement explicitly set forth the terms of patent licenses to be exchanged between the parties.27
Broadcom asserted that another provision, which dealt with Intel’s non-patent intellectual
property rights in the deliverables, implicitly contained a patent license broader than the express
patent license.28 The federal district court rejected the assertion, stating “[w]hile it is true that
patent licenses may be implied by language or conduct of the owner, . . . where an agreement
contains a specific provision expressly defining the scope of the patent license implied licenses
23
Id. § 1.
A number of weaker copyleft licenses follow the CDDL model, such as the OCLC Research Public License 2.0, the Reciprocal
Public License Version 1.1, and the Reciprocal Public License (RPL) Version 1.5. OPEN SOURCE INITIATIVE, OCLC RESEARCH
PUBLIC LICENSE 2.0 (2002), available at http://www.opensource.org/licenses/oclc2; OPEN SOURCE INITIATIVE, RECIPROCAL
PUBLIC LICENSE VERSION 1.1 (2002), available at http://www.opensource.org/licenses/rpl1.0.php [hereinafter RPL 1.1]; OPEN
SOURCE
INITIATIVE,
RECIPROCAL
PUBLIC
LICENSE
(RPL)
VERSION
1.5
(2007),
available
at
http://www.opensource.org/licenses/rpl1.5. A number of weaker copyleft licenses follow the EPL model, such as the Mozilla
Public License Version 1.1 and the Common Public License Version 1.0. MOZILLA, MOZILLA PUBLIC LICENSE VERSION 1.1,
available at http://www.mozilla.org/MPL/MPL-1.1.html [hereinafter MPL 1.1]; OPEN SOURCE INITIATIVE, COMMON PUBLIC
LICENSE (CPL) VERSION 1.0, available at http://www.opensource.org/licenses/cpl1.0.php [hereinafter CPL].
25
Intel Corp. v. Broadcom Corp., 173 F. Supp. 2d 201, 213 (D. Del. 2001). See, e.g., Atlas Corp. v. U.S., 895 F.2d 745, 754–55
(Fed. Cir. 1990) (stating “[t]he existence of an express contract precludes the existence of an implied contract dealing with the
same subject, unless the implied contract is entirely unrelated to the express contract”); Wal-Noon Corp. v. Hill, 119 Cal. Rptr.
646, 650 (Cal. Ct. App. 1975) (stating “[t]here cannot be a valid, express contract and an implied contract, each embracing the
same subject matter, existing at the same time”).
26
Intel Corp. v. Broadcom Corp., 173 F. Supp. 2d at 212–13.
27
Id. at 213.
28
Id.
24
April 2011
Page 8
dealing with the same subject matter are not generally recognized.”29 It would appear that under
Intel Corp. v. Broadcom Corp., an OSS license that includes an express patent grant to some
specific patent rights may preclude a finding of broader implied patent rights.
2.
TransCore LP v. Electronic Transactions Consultants Corp., 563 F.3d
1271 (Fed. Cir. 2009)
In 2009, the Federal Circuit entered its decision in TransCore,30 which if interpreted broadly,
provides that a patent holder could be legally estopped from enforcing patent rights that it owns
against a licensee when the patent rights are necessary to exercise the license at issue. TransCore
manufactures, sells, and installs automated toll collection systems, and is the assignee of several
patents related to automated toll collection system technology.31 In 2000, TransCore sued Mark
IV Industries, its competitor, for patent infringement.32 In the settlement agreement, Mark IV
agreed to pay $4.5 million in exchange for an unconditional covenant not to sue and a release of
existing claims:
. . .TCI hereby agrees and covenants not to bring any demand, claim, lawsuit, or
action against Mark IV for future infringement of [listed issued patents] . . . This
Covenant Not To Sue shall not apply to any other patents issued as of the
effective date of this Agreement or to be issued in the future.33
Several years later, ETC won a bid to install and test a new tolling system, which was bought
from Mark IV.34 TransCore sued ETC for infringement of three of the patents that were part of
the earlier settlement agreement and another related patent that was necessary to implement the
licensed portion of the tolling system (“Necessary Patent”), which had been pending before the
USPTO at the time of the settlement.35
The Federal Circuit held36 that the rights to the related patent that was not identified in the
settlement agreement “were exhausted by the authorized sales under an implied license to
practice that patent by virtue of legal estoppel.”37 Legal estoppel applies when “a patentee has
licensed or assigned a right, received consideration, and then sought to derogate from the right
granted.”38 The court reasoned that the Necessary Patent was broader than and necessary to
practice at least one of the patents included in the settlement and in order for Mark IV to obtain
the benefit of its bargain with TransCore, Mark IV must be permitted to practice the Necessary
Patent to the same extent it may practice the patents listed in the settlement agreement.39 The
court determined that because Mark IV is permitted to practice the Necessary Patent, TransCore
29
Id.
TransCore LP v. Elec. Transactions Consultants Corp., 563 F.3d 1271 (Fed. Cir. 2009).
31
Id. at 1273.
32
Id.
33
Id.
34
Id.
35
Id. at 1273–74.
36
The Federal Circuit also concluded that “a non-exclusive patent license is equivalent to a covenant not to sue” because a patent
holder cannot convey an affirmative right to practice a patent, it can only convey a freedom from suit. Id. at 1275.
37
Id. at 1278.
38
Id. at 1279.
39
Id.
30
April 2011
Page 9
is legally estopped from asserting the Necessary Patent against Mark IV in derogation of the
rights granted to Mark IV under the three earlier-issued patents.40 The court provided that the
language of the settlement agreement stating “[t]his Covenant Not To Sue shall not apply to any
other patents . . . to be issued in the future” is not contrary to this determination.41 The court
explained that “[t]his language may protect TransCore against broad claims that future patents
generally are impliedly licensed, but it does not permit TransCore to derogate from the rights it
has expressly granted and thus does not preclude a finding of estoppel.”42
The release also included a provision that stated “[n]o express or implied license or future release
whatsoever is granted to MARK IV or to any third party by this Release.”43 Despite this
provision, the court nonetheless implied a license within the scope of the covenant not to sue.
Although there is no case law directly on point, under TransCore’s legal estoppel holding, an
OSS recipient might argue, under a broad interpretation of the holding, that it has an implied
patent license from upstream licensors to the extent that such patent rights would be necessary to
avoid any derogation from the OSS license granted to the recipient even if the OSS license does
not expressly grant such patent licenses. Conversely, the patent holder might argue that this
interpretation is too broad because in TransCore, there was a settlement agreement, the
settlement agreement contained an express patent grant, a later issued patent was necessary to
practice that express patent grant, and there clearly was consideration. 44 In the case of a
copyright-only OSS license, the patent holder could argue that there is no settlement agreement
that a court would be reluctant to disturb, there is no patent grant to derogate from, and no
consideration was provided by the licensee.
Although TransCore did not specifically address whether downstream code modifications could
result in an implied patent license, the court also specifically noted that the scope of the laterissued patent was broader than the earlier patents and rights in the later-issued patent were
necessary to practice the earlier patents. The court also took into consideration that the one
accused of infringement was not receiving the benefit of the bargain it had made in its agreement
unless it had a license to the later-issued broader patent. Applying this reasoning to downstream
code modifications, on the one hand, there is a plausible argument that a patent holder has
conveyed an implied patent license for at least some downstream modifications made by
recipients of the code the patent holder has distributed under an OSS license. On the other hand,
this interpretation could lead to an ever-expanding scope of patent licensing, resulting in claims
that all combinations of the OSS and modifications of the OSS with any other functionality
create in an implied patent license for every downstream user. Courts may be hesitant to start
down that slippery slope.
40
Id.
Id.
42
Id.
43
Id. at 1277.
44
It should be noted that consideration for the license was a factor in the TransCore decision. Whether or not an OSS license is
an agreement pursuant to which a downstream recipient can show consideration in exchange for the license was not addressed in
TransCore and is beyond the scope of this paper.
41
April 2011
Page 10
D.
Impact of Commercial Licensing Practices on the Scope of OSS Patent
Licenses
Many software developers bundle their proprietary code along with OSS and distribute the
bundle under a commercial license. Permissive OSS licenses allow software distributors to
redistribute the OSS under commercial terms. Copyleft OSS licenses require redistribution
under the same copyleft license. As a result, many commercial entities carve out OSS from their
commercial licenses when they distribute copyleft OSS, but not when they distribute OSS
licensed under permissive OSS licenses.
1.
Redistribution under Commercial Terms
OSS subject to commercial terms is arguably not licensed by the commercial software distributor
under any terms other than the distributor’s own commercial terms. But permissive OSS
licenses all require that the software distributor reproduce the OSS license along with any
applicable copyright notices when distributing the OSS. There is a question, therefore, whether
there is an expectation that all downstream recipients of the commercial software reproduce the
license and notices with all copies of the software that such downstream recipients may make.45
If such an expectation or requirement exists, then there may be a reasonable argument that the
distributor is also distributing the OSS under the terms of the applicable OSS license.
Most commercial licenses will also include a “no-implied license” provision like the one in
TransCore. As in TransCore, however, it is unclear whether a court would find that a distributor
that distributes OSS bundled with proprietary software under commercial terms has granted
recipients of the OSS it distributes implied patent licenses notwithstanding the “no-implied
license” provision in the commercial license agreement.
2.
Excluding OSS from Commercial Licenses
As mentioned above, most software distributors that distribute copyleft OSS will expressly
exclude such OSS from their commercial license terms in order to comply with the terms of the
copyleft license. The distributor may state that the OSS is licensed exclusively by the authors or
copyright owners of such OSS and not by the distributor. In doing so, it would appear less likely
that the distributor would nonetheless be found to have itself licensed the OSS it distributes.46
If the distributor modifies or adds to the copyleft code, the copyleft license will require the
distributor to license its copyrights and patents in connection with its modifications and additions
according to the terms of the copyleft license even if the OSS is excluded from the terms of the
commercial agreement.
45
See Heather Meeker, Outsource Software Development and Open Source: Coming of Age in the 2000s, 24 SANTA CLARA
COMPUTER & HIGH TECH. L.J. 869, 880 (2008) (advising outsource providers that “[g]athering the [copyright] notices to be
included for open source can be time consuming, so it is best to gather them in a central source as you perform development.
Doing so will save your customer the time and effort of backtracking.”).
46
An analogy may be drawn to the example when there is a pass through of a manufacturer’s warranties from the manufacturer
through the distributor to the customer. The warranty in this example is actually being made by the manufacturer to the
consumer.
April 2011
Page 11
The impact of commercial licensing in connection with OSS bundled with or integrated into
proprietary software raises a series of complex and unresolved issues. For this reason, patentees
distributing OSS along with their proprietary software should consider clearly stating in their
commercial license agreements that any OSS included with the proprietary software distribution
is being licensed solely by the authors and owners of the OSS and not by the patentee.
III.
Impact of OSS Distribution on Patent Portfolios
Many commercial software developers and others that use OSS in their products, services, or
operations may have significant patent portfolios. Such commercial “users” do not always
evaluate the impact of their OSS distribution on their patent portfolios. As discussed above in
detail, there may be risks that the distribution of OSS could result in broad patent licenses.
While a user may not be interested in asserting patents against downstream recipients of the OSS
the user distributes, such users may want to preserve the value in their patents for other purposes.
For example, a patent that reads on OSS that the user distributes might also read on a
competitor’s proprietary software product. The user may want to enforce such patent against its
competitor to either enjoin the sale of the competitor’s product or at least extract a royalty in an
effort to create a cost differential between its own products and its competitor’s products. The
user may also wish to preserve value in patents that read on OSS distributed by the user for
defensive purposes and to secure freedom from suits against its own products and services. To
the extent that there would be a viable argument that a reasonable royalty for the patent is zero,
the patent would have little value in a defensive countersuit or in a cross-license.
Establishing a reasonable royalty for a patent is not a precise science under the law. In the U.S.,
the courts typically will apply the Georgia-Pacific47 factors as a framework for determining a
reasonable royalty in a patent infringement suit. Although there are fifteen factors that a court
might consider under Georgia-Pacific,48 the first factor is particularly relevant in this context; the
47
Georgia-Pacific Corp. v. U.S. Plywood Corp., 318 F. Supp. 1116, (S.D.N.Y. 1970), modified and aff’d, 446 F.2d 295 (2d Cir.
1971).
48
The fifteen factors identified by the district court in Georgia-Pacific are: “(1) The royalties received by the patentee for the
licensing of the patent in suit, proving or tending to prove an established royalty. (2) The rates paid by the licensee for the use of
other patents comparable to the patent in suit. (3) The nature and scope of the license, as exclusive or non-exclusive; or as
restricted or non-restricted in terms of territory or with respect to whom the manufactured product may be sold. (4) The licensor's
established policy and marketing program to maintain his patent monopoly by not licensing others to use the invention or by
granting licenses under special conditions designed to preserve that monopoly. (5) The commercial relationship between the
licensor and licensee, such as, whether they are competitors in the same territory in the same line of business; or whether they are
inventor and promotor. (6) The effect of selling the patented specialty in promoting sales of other products of the licensee; the
existing value of the invention to the licensor as a generator of sales of his non-patented items; and the extent of such derivative
or convoyed sales. (7) The duration of the patent and the term of the license. (8) The established profitability of the product
made under the patent; its commercial success; and its current popularity. (9) The utility and advantages of the patent property
over the old modes or devices, if any, that had been used for working out similar results. (10) The nature of the patented
invention; the character of the commercial embodiment of it as owned and produced by the licensor; and the benefits to those
who have used the invention. (11) The extent to which the infringer has made use of the invention; and any evidence probative
of the value of that use. (12) The portion of the profit or of the selling price that may be customary in the particular business or in
comparable businesses to allow for the use of the invention or analogous inventions. (13) The portion of the realizable profit that
should be credited to the invention as distinguished from non-patented elements, the manufacturing process, business risks, or
significant features or improvements added by the infringer. (14) The opinion testimony of qualified experts. (15) The amount
that a licensor (such as the patentee) and a licensee (such as the infringer) would have agreed upon (at the time the infringement
began) if both had been reasonably and voluntarily trying to reach an agreement; that is, the amount which a prudent licensee -who desired, as a business proposition, to obtain a license to manufacture and sell a particular article embodying the patented
April 2011
Page 12
royalty that was agreed upon in other deals. An infringer could conceivably argue that the
reasonable royalty determination should account for the fact that a patentee licensed the patent
for free to all for its OSS distribution. Patentees would likely respond that there would be
substantial differences in the circumstances in which it licensed its patent for free.49 The
question, however, is how much weight a court might give to the infringer’s argument. To the
extent that there is no current case law directly on point, patentees may want to balance the
possible risks of royalty-free patent licenses with the importance of preserving value in their
patents that may be licensed, either through an express or implied license, associated with OSS
distribution.
Still further, a party’s right to use the OSS may be terminated under some OSS licenses if that
party asserts certain patent claims. Such “defensive revocation” clauses may be tantamount to a
broad patent grant back if the OSS is a critical component of a commercial user’s products,
services, or operations. The scope and trigger of such defensive revocation provisions are
discussed in more detail in Part IV, but patentees should also recognize that such defensive
revocation provisions, depending on the circumstances, may devalue a commercial user’s patent
portfolio.
IV.
Defensive Revocation and Effective Patent Grant Backs
As discussed above, several OSS licenses include defensive revocation provisions that may
effectively require a user to forgo enforcement of its patents against the OSS and/or its licensors.
For example, anytime the OSS used or distributed is important to a user’s business, is not easily
replaceable, or is required by the user’s customers, the user may have no practical choice but to
preserve its permission to use the OSS. Defensive revocation provisions vary in terms of their
scope and the manner in which they are triggered. There are, however, at least three general
ways to categorize these provisions: (1) the user loses its OSS license (copyrights and patents) if
the user claims that the OSS infringes the user’s patent; (2) the user loses the patent licenses
granted through the OSS license if the user claims that a licensor is infringing the user’s patent;
and (3) the user loses its OSS license (copyrights and patents) if the user claims that the licensor
infringes a user’s patent.
A.
Lose OSS License Based on Claims Against Licensors on Account of OSS
The Mozilla Public License Version 1.1 (“MPL”) and a number of company-specific OSS
licenses, such as the Nokia Open Source License Version 1.0a and the Sun Public License
Version 1.0, fall into category (1) above. These licenses provide:
If You initiate litigation by asserting a patent infringement claim (excluding
declaratory judgment actions) against [Initial Developer] or a Contributor (the
[Initial Developer] or Contributor against whom You file such action is referred to
as ‘Participant’) alleging that:
invention -- would have been willing to pay as a royalty and yet be able to make a reasonable profit and which amount would
have been acceptable by a prudent patentee who was willing to grant a license.” Id. at 1120.
49
When analyzing licenses relating to Georgia-Pacific factor 1, the Federal Circuit stated “comparisons of past patent licenses to
the infringement must account for ‘the technological and economic differences’ between them.” Wordtech Sys., Inc. v. Integrated
Networks Solutions, Inc., 609 F.3d 1308, 1319–20 (Fed. Cir. 2010).
April 2011
Page 13
(a) such Participant’s Contributor Version directly or indirectly infringes any
patent, then any and all rights granted by such Participant to You under Sections
2.1 [Initial Developer copyright and patent licenses ] and/or 2.2 [Contributor
copyright and patent licenses] of this License shall, upon 60 days notice from
Participant terminate prospectively, …50
The Open Software License v. 3.0 (“OSL”) offers another variation of a category (1) defensive
revocation provision in that the entire OSS license is revoked upon the assertion of patent claims
against the licensed OSS work.
Termination for Patent Action. This License shall terminate automatically and
You may no longer exercise any of the rights granted to You by this License as of
the date You commence an action, including a cross-claim or counterclaim,
against Licensor or any licensee alleging that the Original Work infringes a
patent. This termination provision shall not apply for an action alleging patent
infringement by combinations of the Original Work with other software or
hardware.51
The OSL defensive revocation, however, is triggered when asserting against any licensee of the
OSS whereas the MPL variety of defensive revocation provisions are triggered when the
assertion is against the initial developer or contributor.
B.
Lose Patent License Based on Patent Claims Against the OSS Licensors
The Apache License 2.0 and the EPL fall into category (2) above. The Apache License 2.0
provides:
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. 52
The EPL similarly provides:
If Recipient institutes patent litigation against any entity (including a cross-claim
or counterclaim in a lawsuit) alleging that the Program itself (excluding
combinations of the Program with other software or hardware) infringes such
50
MPL 1.1, supra note 24, § 8.2; OPEN SOURCE INITIATIVE, NOKIA OPEN SOURCE LICENSE (NOKOS LICENSE) VERSION 1.0A § 8.2,
available at http://opensource.org/licenses/nokia.html [hereinafter NOKOS LICENSE]; OPEN SOURCE INITIATIVE, SUN PUBLIC
LICENSE VERSION 1.0 § 8.2, available at http://www.opensource.org/licenses/sunpublic.php [hereinafter SUN PUBLIC LICENSE ].
51
OPEN SOURCE INITIATIVE, THE OPEN SOFTWARE LICENSE (“OSL”) V. 3.0 § 10, available at http://opensource.org/licenses/osl3.0.php.
52
APACHE LICENSE 2.0, supra note 11, § 3.
April 2011
Page 14
Recipient’s patent(s), then such Recipient’s rights granted under Section 2(b)
[patent license] shall terminate as of the date such litigation is filed.53
Unlike the category (1) licenses, the Apache License 2.0 and EPL defensive revocation
provisions are triggered by instituting an action against any recipient of the OSS and the scope of
the defensive revocation is limited to the patent rights granted to the user. Like the category (1)
licenses, the Apache License 2.0 and EPL defensive revocation provisions, however, are limited
to patent infringement claims asserted against the OSS licensed by the user. The MPL and a
number of company-specific OSS licenses in addition to the defensive revocation provisions
quoted above also provide:
If You initiate litigation by asserting a patent infringement claim (excluding
declaratory judgment actions) against Initial Developer or a Contributor (the
Initial Developer or Contributor against whom You file such action is referred to
as ‘Participant’) alleging that: …
(b) any software, hardware, or device, other than such Participant’s Contributor
Version, directly or indirectly infringes any patent, then any rights granted to You
by such Participant under Sections 2.1(b) [Initial Developer patent licenses] and
2.2(b) [Contributor patent licenses] are revoked effective as of the date You first
made, used, sold, distributed, or had made, Modifications made by that
Participant.54
As a result, these licenses have defensive revocation provisions that fall into both categories (1)
and (2).
C.
Lose OSS License Based on Patent Claims Against OSS Licensor
Other company-specific OSS licenses, such as the Apple Public Source License Version 2.0 and
the RealNetworks Public Source License Version 1.0, have defensive revocation provisions that
fall into category (3). As an example, the Apple Public Source License Version 2.0 provides:
This License and the rights granted hereunder will terminate: …
(c) automatically without notice from Apple if You, at any time during the term of
this License, commence an action for patent infringement against Apple; provided
that Apple did not first commence an action for patent infringement against You
in that instance.55
Similarly the RealNetworks Public Source License Version 1.0 provides:
The term of this License is perpetual unless terminated as provided below. This
License and the rights granted hereunder will terminate: . . .
53
EPL, supra note 22, § 7.
MPL 1.1, supra note 24, § 8.2. See NOKOS LICENSE, supra note 50, § 8.2; SUN PUBLIC LICENSE, supra note 50, § 8.2.
55
APPLE, APPLE PUBLIC SOURCE LICENSE VERSION 2.0 § 12.1 (2003), available at http://www.opensource.apple.com/license/apsl/.
54
April 2011
Page 15
(c) automatically without notice from Licensor if You, at any time during the term
of this License, commence an action for patent infringement against Licensor
(including by cross-claim or counter claim in a lawsuit);56
The RealNetworks Public Source License Version 1.0 also provides that it will terminate:
(d) upon written notice from Licensor if You, at any time during the term of this
License, commence an action for patent infringement against any third party
alleging that the Covered Code itself (excluding combinations with other software
or hardware) infringes any patent (including by cross-claim or counter claim in a
lawsuit).57
The defensive revocation provision in the RealNetworks Public Source License Version 1.0 is
therefore also triggered based on a patent claim against any party to the extent the infringement
claim is on account of the licensed OSS, not any product or service.
D.
Other Variations Among Defensive Revocation Provisions
It should be evident from the quoted language above that each defensive revocation provision
may vary in other ways as well. For example, must the user actually file a patent infringement
lawsuit or simply threaten to file a lawsuit to trigger the defensive revocation? There are also
differences among the provisions as to whether the revocation occurs automatically or is left to
the discretion of the OSS licensors.58 Some of the OSS licenses address which rights survive
after revocation and other do not.59 Some OSS licenses with defensive revocation provisions
include language defining valuation mechanisms for the patents licensed pursuant to the OSS
license after revocation. 60 Still further, some of these provisions clarify whether or not
revocation may be triggered by claims of indirect infringement and/or combinations.61
56
OPEN SOURCE INITIATIVE, REALNETWORKS PUBLIC SOURCE LICENSE VERSION 1.0 § 11.1, available at
http://www.opensource.org/licenses/real.php.
57
Id.
58
See OPEN SOURCE INITIATIVE, THE ACADEMIC FREE LICENSE 3.0 § 10, available at http://opensource.org/licenses/afl-3.0.php
(“This License shall terminate automatically...as of the date You commence an action…”) [hereinafter AFL 3.0]; OPEN SOURCE
INITIATIVE, ARTISTIC LICENSE 2.0 § 13 (2006), available at http://www.opensource.org/licenses/artistic-license-2.0.php (“...this
Artistic License to you shall terminate on the date that such litigation is filed.”); THE CODE PROJECT, THE CODE PROJECT OPEN
LICENSE (CPOL) 1.02 § 9(b), available at http://www.codeproject.com/info/cpol10.aspx (“...your License from such contributor
to the Work ends automatically.”); CDDL, supra note 20, § 6.2 (providing a sixty day window within which the claim may be
withdrawn or the parties may enter into written agreement); MPL 1.1, supra note 24, § 8.2(a) (providing a sixty day window
within which the claim may be withdrawn or the parties may enter into written agreement).
59
See CPL, supra note 24, § 7 (“…Recipient’s obligations under this Agreement and any licenses granted by Recipient relating
to the Program shall continue and survive.”); MPL 1.1, supra note 24, § 8.4 (“In the event of termination…, all end user license
agreements (excluding distributors and resellers) which have been validly granted by You or any distributor hereunder prior to
termination shall survive termination.”); NOKOS LICENSE, supra note 50, § 8.4; SUN PUBLIC LICENSE, supra note 50, § 8.4.
60
See MPL 1.1, supra note 24, § 8.3 (“If You assert a patent infringement claim…, then the reasonable value of the licenses
granted by such Participant… shall be taken into account in determining the amount or value of any payment or license.”);
NOKOS LICENSE, supra note 50, § 8.3; SUN PUBLIC LICENSE, supra note 50, § 8.3.
61
See AFL 3.0, supra note 58, § 10 (“This termination provision shall not apply for an action alleging patent infringement by
combinations of the Original Work with other software or hardware.”); CDDL, supra note 20, § 6.2 (“…alleging that the
Participant Software…directly or indirectly infringes any patent…”).
April 2011
Page 16
To the extent that OSS licensed under a license with a defensive revocation provision is being
used as a key component of a product or service or in connection with core business operations,
patentees should carefully evaluate the scope and triggers for such defensive revocation before
becoming reliant on such OSS.
V.
RAND Patent Licensing and OSS Distribution
As mentioned above, OSS is software that is released under an OSS license. The Open Source
Initiative (“OSI”) has developed a definition having ten criteria, the open source definition
(“OSD”), against which it evaluates OSS licenses to determine whether or not a license meets
these criteria.62 Of the ten requirements of the OSD, a few are said to be inconsistent with
RAND or RAND-RF licensing commitments. In particular, the following requirements of an
OSI-approved OSS license are of interest:
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.
3. Derived Works
The license must allow modifications and derived works, and must allow them to
be distributed under the same terms as the license of the original software.
7. Distribution of License
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.
8. License Must Not Be Specific to a Product
The rights attached to the program must not depend on the program’s being part
of a particular software distribution. If the program is extracted from that
distribution and used or distributed within the terms of the program’s license, all
parties to whom the program is redistributed should have the same rights as those
that are granted in conjunction with the original software distribution.
10. License Must Be Technology-Neutral
No provision of the license may be predicated on any individual technology or
style of interface.63
In other words, OSS must be available royalty-free, and the OSS license must permit
modifications to the code, permit code extraction and reuse separate from the product in which
the code was originally included, and must not require downstream recipients of the code to
62
Open Source Initiative, The Open Source Definition, http://opensource.org/docs/osd (last visited Apr. 26, 2011) [hereinafter
OSD]. The Open Source Definition is only one definition of an open source license. Other definitions may be valid as well.
63
Id. §§ 1, 3, 7, 8, 10.
April 2011
Page 17
provide an “explicit gesture of assent” to establish a contract.64 This section focuses on the
perceived friction these requirements of the OSD can cause in connection with RAND/RANDRF patent licensing, though to understand these points of friction, one must understand OSS
distribution and use models. The question, however, is not whether RAND licensing creates
friction with the OSD or any specific OSS license but rather whether software that benefits from
a RAND patent license may be distributed under a particular OSS license.
A.
Open Source Software Distribution
According to the OSD, recipients of OSS, whether in source or executable form, must not be
required to physically accept the terms of the OSS license, e.g., by click through agreement, to
use and distribute the code.65 As a result, OSS licenses are self-executing and are embedded in
the OSS itself. If the OSS is downloaded, for example, by a user in source form, the actual OSS
license will generally be included as text in the source code comments. When the source code is
compiled, the comments will be stripped from the resulting executable files and there may be no
retention of the OSS license. If the OSS is downloaded in executable form, there are typically
text files accompanying the executable files designated as “Notice.txt,” “Readme,” “License.txt,”
and other similarly named files that contain the OSS licenses. Since there is no negotiation over
terms, no requirement to acknowledge the terms, and the existence of the OSS license may not
be apparent, those downloading the OSS may erroneously perceive that there are no license
terms and conditions with the OSS they download.
B.
OSS Business Models
While OSS must be available for free, many entities still profit from OSS. OSS can reduce
development and testing costs if the OSS can be developed by a community of developers
working for free. However, most cutting edge and innovative software today is still developed
by paid developers employed by corporate employers that retain ownership in the software. For
many products and services that require truly innovative software, those products and services
will generally use software developed in a traditional manner and distributed under a non-OSS
license. Employers also pay their employees, however, to participate in communities so that the
development costs for non-differentiating software can be distributed across the community
participants including the employers that support the projects.66
OSS, irrespective of development model, can nonetheless be given away to drive sales of higher
value software, complementary hardware, complete IT solutions, and related services. For
example, Oracle promotes and invests in Linux, the free software operating system, so that it can
sell its high end databases to corporate IT customers to run on their free Linux servers.67 OSS
64
Id.
Id. § 7.
66
For example, the Open Handset Alliance, which originated Android and was led by Google, has many mobile operator, handset
manufacturer, semiconductor, software, and commercial companies as members. See Android, Open Source Project, Philosophy
and Goals, http://source.android.com/about/philosophy.html (last visited Apr. 26, 2011); Open Handset Alliance, Members,
http://www.openhandsetalliance.com/oha_members.html (last visited Apr. 26, 2011). In another example, IBM joined the
community to collaborate on the development of OpenOffice. IBM Joins OpenOffice.org Community, PRWEB, Sept. 10, 2007,
available at http://www.prweb.com/releases/openoffice.org/IBM/prweb552157.htm.
67
See Oracle, Oracle Linux, http://www.oracle.com/us/technologies/linux/index.html (last visited Apr. 26, 2011).
65
April 2011
Page 18
can underpin a profitable software support service such as IBM’s Global Services Division,
which reported revenues of over $56 billion in 2010.68
C.
Points of Perceived Friction
As discussed above, most SSOs operate under a patent policy that results in participating
patentees providing assurances that they will license essential patent claims on RAND or
RAND-RF terms. Although there may be different views as to what terms and conditions of a
patent license are RAND, there is generally some common ground for agreement. For example,
most will agree that a RAND patent license may include reasonable royalties. This is perhaps
the most contentious term for those who wish to implement an ICT standard and distribute the
implementation under an OSS license. For this reason, some SSOs have adopted RAND-RF
policies that prohibit reasonable royalties. However, even with a RAND-RF patent policy there
are a number of common patent license terms that are said to create tension for OSS distributors
and users. For this reason, some users are advocating that SSOs not only change their RAND
policies to RAND-RF policies but that they change them to self-executing patent non-asserts or
covenants not to sue (“CNS”).69
Such CNS policies take away the freedom of standards development participants and
implementers to negotiate mutually acceptable terms. More importantly, the value of patents
subject to such policies is substantially diminished. Not only is the patentee unable to seek a
reasonable royalty or fee but the patentee cannot require other RAND terms such as reciprocity
and reasonable termination provisions.70 Such CNS policies also preclude a patentee from
conditioning its license in a RAND manner to avoid patent exhaustion since the CNS is selfexecuting, contains all the terms and conditions, and applies to all parties. Patent policies that
68
Total Global Services is made up of Global Technology Services ($38B) and Global Business Services ($18B). Press Release,
IBM, IBM Reports 2010 Fourth-Quarter and Full-Year Results, http://www.ibm.com/investor/4q10/press.phtml (last visited Apr.
26, 2011). See also Press Release, IBM, IBM Awarded Contract to Modernize the U.S. Government’s Acquisition and
Procurement System (Feb. 18, 2010), available at http://www-03.ibm.com/press/us/en/pressrelease/29436.wss (“The project will
include the integration of nine key GSA applications into a single system -- based on open source software -- designed to
simplify the entire acquisition and procurement process”); Chris Preimesberger, Red Hat CEO Likens Company to Facebook,
Wikipedia in Collaborative Innovation, EWEEK.COM, Aug. 18, 2009, available at http://www.eweek.com/c/a/Linux-and-OpenSource/Red-Hat-CEO-Likens-Company-to-Facebook-Wikipedia-in-Collaborative-Innovation-489559/ (Red Hat CEO discusses
its business model of monetizing enterprise and technical services based on software that is licensed for free).
69
For example, the OpenAjax Alliance IPR Policy states “Each Member and Contributor, on behalf of itself and its Affiliates,
covenants not to assert its Covered Claims against any Covered Product created by the Alliance, by any Member, or by any other
party…” OPENAJAX ALLIANCE, MEMBERS AGREEMENT FOR THE OPENAJAX ALLIANCE Attachment A § 2.2 (Aug. 16, 2006),
available at http://www.openajax.org/process/OpenAjax%20Members%20Agreement%20Final%2020060816.pdf [hereinafter
OPENAJAX IPR POLICY]. OASIS also has a non-assertion mode, that states “Each Obligated Party in a Non-Assertion Mode TC
irrevocably covenants that…it will not assert any of its Essential Claims covered by its Contribution Obligations or Participation
Obligations against any OASIS Party or third party…” OASIS, INTELLECTUAL PROPERTY RIGHTS (IPR) POLICY § 10.3.1 (2010),
available at http://www.oasis-open.org/policies-guidelines/ipr-2010-07-28 [hereinafter OASIS IPR POLICY].
70
Some do have very limited narrow defensive termination provisions, but they may be inadequate for patentees that are
frequently the subject of patent infringement suits. For example, the OpenAjax Alliance IPR Policy states “…the covenant may
be suspended or terminated with regard to any Member or any other party that asserts a patent in litigation against a Covered
Product or otherwise knowingly asserts or threatens to initiate a lawsuit which would assert that all Covered Products would
infringe a patent owned or controlled by it…” OPENAJAX IPR POLICY, supra note 69, Attachment A § 2.2. And the OASIS
policy states “The covenant described in Section 10.3.1 may be suspended or revoked by the Obligated Party with respect to any
OASIS Party or third party if that OASIS Party or third party asserts an Essential Claim in a suit first brought against, or attempts
in writing to assert an Essential Claim against, a Beneficiary with respect to a Covered Product that implements the same OASIS
Final Deliverable.” OASIS IPR POLICY, supra note 69, § 10.3.2.
April 2011
Page 19
devalue patents are not only harmful to standards development, innovation, and competition,71
but changes to SSO policies to move away from RAND license commitments are not necessary
to accommodate OSS distribution.
1.
Reasonable Royalties or Fees Are Not Prohibited by OSS Distribution
Models
The OSD requires that OSS be available for free.72 Specifically, the OSS license that grants
recipients the right to copy, modify, and further distribute both the source and the executable
code must be free. That does not mean that the OSS licensor cannot “sell” copies of the
software, but it is unlikely many will pay for something they can get for free somewhere else.
To obtain value from its OSS, some entities may offer other software, hardware, and/or services
bundled with the OSS to shift costs and create an incentive for paying customers, as discussed
above. Given that much OSS is created or distributed, often indirectly, by one or more
commercial entities so that those entities can make a profit related to their use of OSS, it is
reasonable to expect those entities to pay a RAND royalty or fee for an OSS implementation of
an ICT standard when making, using, or selling the implementation if it infringes another’s
patent. In other words, if a user is profiting from the use of the OSS in its products, services, or
operations, it should not be relieved of its responsibilities to avoid infringement just because it
relies on OSS.
While it may be difficult to track all OSS distributions since no licenses are executing or even
acknowledged, there are clearly financial terms that can be associated with patent licenses that
cover OSS distribution. For example, Red Hat recently settled a patent dispute with Firestar in
which it is has been reported that Red Hat paid an undisclosed amount to Firestar for a license
permitting Red Hat to distribute its branded Linux distributions73 and for Red Hat customers to
use Red Hat distributions.74 It appears then, that the license is tailored to extract fees based on
Red Hat revenues or profits, and not necessarily free distributions of Linux that may be available
from Red Hat.
Similarly, as mentioned above, there have been numerous patent infringement lawsuits filed
against the Android platform or devices running the Android platform. 75 Although none of these
71
See Michele K. Herman, Negotiating Standards-Related Patent Licenses: How the Deal is Done, Part I, LANDSLIDE, Sept.–
Oct. 2010, available at http://www.dwt.com/LearningCenter/BooksPublications?find=364466; Michele K. Herman, Negotiating
Standards-Related Patent Licenses: How the Deal is Done, Part II, LANDSLIDE, Nov.–Dec. 2010, available at
http://www.dwt.com/LearningCenter/BooksPublications?find=364461.
72
OSD, supra note 62, § 1.
73
Linux is OSS and is released under GPLv2. See Daniel Lyons, Linux Licensing, FORBES.COM, Mar. 9, 2006, available at
http://www.forbes.com/2006/03/09/torvalds-linux-licensing-cz_dl_0309torvalds1.html.
74
Chris Kanaracus, Red Hat Settles Patent Suits with Firestar, DataTern, INFOWORLD, June 11, 2008, available at
https://www.infoworld.com/d/developer-world/red-hat-settles-patent-suits-firestar-datatern-293.
75
See Amended Complaint, In re Certain Handheld Electronic Computing Devices, Related Software and Components Thereof,
No. 337-TA-769 (ITC Apr. 8, 2011); Amended Complaint, In re Certain Mobile Devices, Associated Software, and Components
Thereof, No. 337-TA-744 (ITC Oct. 12, 2010); Complaint, In re Certain Personal Data and Mobile Communications Devices and
Related Software, No. 337-TA-710 (ITC Mar. 2, 2010); Complaint, Microsoft Corp. v. Barnes & Noble, Inc., No. 2:11-cv-00485
(W.D. Wash. Mar. 21, 2011); Amended Complaint, Oracle Am., Inc. v. Google, Inc., No. 3:10-cv-03561 (N.D. Cal. Oct. 27,
2010); Complaint, Gemalto S.A. v. HTC Corp., No. 6:10-cv-561 (E.D. Tex. Oct. 22, 2010); Complaint, Microsoft Corp. v.
Motorola, Inc., No. 2:10-cv-01577 (W.D. Wash. Oct. 1, 2010); Complaint, NTP, Inc. v. High Tech Computer Corp., No: 3:10-cv00472 (E.D. Va. July 8, 2010); Complaint, NTP, Inc. v. LG Elecs. Mobilecomm U.S.A., Inc., No: 3:10-cv-00468 (E.D. Va. July
8, 2010); Complaint, NTP, Inc. v. Google Inc., No: 3:10-cv-00469 (E.D. Va. July 8, 2010); Complaint, NTP, Inc. v. Motorola,
April 2011
Page 20
cases have been resolved to date, it is likely that at least some of the patents-in-suit will be found
valid, infringed, and enforceable. These lawsuits are not likely to result in sweeping industrywide injunctions but rather are likely to result in some parties ultimately negotiating patent
licenses that will cover the distribution of Android-based mobile phones. Consequently, some
form of royalty-bearing or fee-based license will necessarily be compatible with OSS
distribution.
It should be clear from the practical nature of commercial business transactions that RAND
royalties and/or fees can be compatible with OSS distribution and use. Consequently, SSOs need
not modify their RAND policies to accommodate OSS business models.
2.
Physical Acceptance of a Patent License Does Not Conflict with the
OSD
The OSD makes it clear that an OSS license cannot be conditioned on the recipient of the OSS
accepting any additional license: “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.”76
Nothing in the nature of RAND or RAND-RF licensing in the standards context requires that a
distributor of an OSS implementation of an ICT standard in turn require recipients of its OSS
implementation to sign the RAND or RAND-RF patent license with another party before
copying, modifying, or redistributing the OSS implementation. It is true that recipients that copy
in order to make or use the implementation, copy in order to modify, or distribute modified or
unmodified copies of the implementation may need the RAND or RAND-RF license to avoid
infringement, but the OSD does not place that burden on the initial OSS distributor. Indeed,
OSS distributors that know that the OSS distribution includes an implementation of an ICT
standard for which a patent owner has declared essential patent rights should notify the
downstream recipients of the OSS distribution. The MPL, the Reciprocal Public License
Version 1.1, and other common OSS licenses assume that in some cases the OSS distributor may
have entered into a patent license, and as a consequence, such OSS licenses require the
distributor to notify its downstream recipients of the patent license. 77
The OSD also makes it clear that the OSS license must not be conveyed using any particular
technical approach that requires physical assent to the terms of the OSS license.78 It is worth
repeating that this requirement of the OSD applies to the OSS license and not any other
intellectual property licenses that may be needed to avoid infringement when copying,
modifying, or redistributing the code. The fact that one may need to separately sign an
agreement to obtain a patent license to avoid infringing activity with respect to an OSS
implementation of an ICT standard does not run afoul of the OSD unless the use of the OSS
Inc., No: 3:10-cv-00471 (E.D. Va. July 8, 2010); Complaint, Apple Inc. v. HTC Corp., No. 1:10-cv-00544, (D. Del. June 21,
2010); Complaint, Apple Inc. v. HTC Corp., No. 1:10-cv-00167 (D. Del. Mar. 2, 2010); Complaint, Apple Inc. v. HTC Corp.,
No. 1:10-cv-00166 (D. Del. Mar. 2, 2010).
76
OSD, supra note 62, § 7.
77
MPL 1.1, supra note 24, § 3.4(a); RPL 1.1, supra note 24, § 6.3(a); NOKOS LICENSE, supra note 50, § 3.4(a); SUN PUBLIC
LICENSE, supra note 50, § 3.4(a).
78
OSD, supra note 62, § 7.
April 2011
Page 21
implementation is conditioned on the recipient signing that other agreement. Understandably,
the need to execute a separate patent license that does not flow and self-execute with the OSS
implementation itself may seem onerous to some, but there is just as much reason to read and
understand any self-executing OSS licenses that accompany an OSS distribution as there is to
read and understand any other license that may apply to the OSS distribution.
In sum, so long as the OSS distributor does not itself condition the OSS license on a recipient
executing a patent license with a third party, there is no violation of the OSD. As a result, a
software developer may distribute its OSS implementation of an ICT standard even if that
implementation infringes third party patents especially if the third parties offer all recipients a
patent license under RAND or RAND-RF terms and conditions.
3.
Field-of-Use Limitations Are Not in Conflict with OSS Licensing
Most standards-related patent licenses are granted to permit licensees to make, use, sell, offer to
sell, and import an implementation of the standard in the licensee’s conformant product.
Moreover, most of such patent licenses do not grant the license to the licensee for any purpose
other than this standards-related purpose, yet OSS licenses will specify that any recipient is free
to modify the code for any purpose and in any way. In this regard, the standards-related RAND
license does not prohibit these modifications; it simply is silent as to whether the patent owner
will grant any additional patent rights. Implementers choosing to distribute an implementation of
an ICT standard under an OSS license should thus consider obtaining a patent license that
exceeds the scope of the standard-related license commitment before distributing their OSS
implementation of the standard, or at least put downstream recipients of the OSS implementation
on notice with language to the effect that the implementation includes patented technology
licensed only for the purpose of conforming to the standard.
The tension, however, lies in the possibility that such a broader patent license may not be RAND
and may not even be available at all since SSO patent policies do not require patent owners to
grant licenses for anything but a conforming implementation of the SSO’s standard. Thus, a
downstream notice on OSS implementations of ICT standards makes good sense. As discussed
above, the MPL, the Reciprocal Public License Version 1.1, and other common OSS licenses
already require distributors of software under these licenses to include appropriate intellectual
property rights notices so that downstream recipients know that they might need additional
patent licenses and can make an informed decision about requesting such licenses. 79
Limiting a RAND/RAND-RF license to the licensee’s product, such as limiting a license to a
conforming implementation of a standard, may also cause unwarranted concerns for OSS
distribution. The OSD makes it clear that an OSS license cannot be specific to a product to
ensure that any OSS code that is generally included in products can be freely removed, further
modified, and redistributed.80 In contrast, most RAND or RAND-RF patent licenses for
implementations of ICT standards are limited to a licensee’s conformant product and are
personal to the licensee. In many cases, the license will extend to the licensed product through
79
MPL 1.1, supra note 24, § 3.4(a); RPL 1.1, supra note 24, § 6.3(a); NOKOS LICENSE, supra note 50, § 3.4(a); SUN PUBLIC
LICENSE, supra note 50, § 3.4(a).
80
OSD, supra note 62, § 8.
April 2011
Page 22
the licensee’s chain of distribution and to the licensee’s end users, but not to parties that extract
the OSS implementation from the commercial product.
The fact that a third party patent license does not expressly grant unlimited patent rights, but is
instead limited to a licensee’s commercial products within its commercial chain of distribution,
has no impact on OSS distribution. In other words, a software developer may distribute its
implementation of an ICT standard under an OSS license as long as that developer does not
condition the OSS license on the acceptance of a third party patent license limited to a licensee’s
conformant products. The availability of a third party RAND or RAND-RF license for
conformant implementations limited to the software developer’s commercial products and chain
of distribution will not conflict with the OSD’s requirement that the OSS license not be limited
to a product since the third party RAND/RAND-RF license is a separate license offered by a
different party.
4.
Prohibitions on Sublicensing Are Not in Conflict with OSS
Distribution
The nature of software conveyances may also be a source of complication. Unlike other
products that are sold outright, software is not typically sold but rather licensed. The patent
statute does not provide for an exclusive right of distribution, or even a right to practice the
invention, but rather provides the right to exclude others from making, using, selling, offering to
sell, and importing the invention.81 It is thus unclear whether a patent license granting the right
“to distribute” includes a sub-license to intermediary distributors to make copies of the software
and redistribute those copies.82 It is therefore unclear whether or not one may extract an OSS
implementation of a standard from a product that has been licensed under a RAND or RAND-RF
patent license and distribute such code, or modified versions of the code, under the OSS license.
As a result of this concern, many OSS distributors believe that RAND or RAND-RF patent
licenses must be sub-licensable to be consistent with OSS distribution models. Like the field-ofuse being limited to conforming implementations of the standard in a licensed product, a
prohibition on sublicenses commonly found in patent licenses, and often expressly permitted by
SSO patent policies, does not mean that the patent owner will not grant such additional rights.
Furthermore, the failure to expressly include the right to sublicense will not, in and of itself,
preclude the right to distribute the OSS implementation. As discussed above, so long as the OSS
distributor does not require the execution of a separate patent license, there is no violation of the
OSD.
The concern with sub-licensing, however, can be resolved in most cases by making a patent
license available to all, for example, by posting the license on a publicly accessible website that
any potential distributor of the OSS implementation can download and accept. Some OSS
developers and distributors view this physical “acceptance” of a patent license as a blocking
81
35 U.S.C. § 271(a) 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.”
82
If there are no conditions on the right to distribute, the patent will be exhausted. Quanta Computer, Inc. v. LG Elecs., Inc., 553
U.S. 617, 636–37 (2008) (In finding that patents were exhausted, the court stated “[n]othing in the License Agreement restricts
Intel’s rights to sell its microprocessors and chipsets to purchasers who intend to combine them with non-Intel parts”).
April 2011
Page 23
factor to OSS distribution. As discussed in detail above, this is an unfortunate misperception and
it should not prevent adoption and distribution of OSS implementations of standards.
D.
The Liberty or Death Clause of the GPL/LGPL Is Not in Conflict with
RAND or RAND-RF Licensing
All of these perceived frictions are exacerbated by a provision in most of the GNU licenses83
known as the “Liberty or Death” clause. 84 Most of the GNU licenses are by design intended to
convey a license for software that is not subject to any patent restrictions whatsoever. For
example, the preamble of the GPLv2 states:
Finally, any free program is threatened constantly by software patents. 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. 85
Section 7 of the GPLv2, however, embodies the “Liberty or Death” requirement.
If, as a consequence of a court judgment or allegation of patent infringement or
for any other reason (not limited to patent issues), conditions are imposed on you
(whether by court order, agreement or otherwise) that contradict the conditions of
this License, they do not excuse you from the conditions of this License. If you
cannot distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you may not
distribute the Program at all. For example, if a patent license would not permit
royalty-free redistribution of the Program by all those who receive copies directly
or indirectly through you, then the only way you could satisfy both it and this
License would be to refrain entirely from distribution of the Program.86
One may read this provision broadly as requiring a party to forgo distribution of any software
under the GPLv2 if that party has accepted a third party patent license that contains restrictions
that conflict with provisions of the GPLv2, such as the free right to copy or distribute the
software with or without modifications. Some argue that any party that has accepted such a
patent license or is even aware of such a patent license would violate Section 7 of the GPLv2 if
(i) that party distributed software under the GPLv2, and (ii) that distribution would also be
subject to the patent license. If this is the case, it would be hard to imagine that any substantial
software programs, e.g., Linux or Open Office, could be distributed under the GPLv2 since such
software would almost certainly be covered by patents that are licensed through cross licenses,
83
Free Software Foundation, GNU Operating System, Licenses, http://www.gnu.org/licenses/licenses.html (last visited Apr. 26,
2011).
84
Richard Stallman, Presentation at the Third International GPLv3 Conference § 7 (June 22, 2006), available at
http://fsfe.org/projects/gplv3/barcelona-rms-transcript.en.html (“There was one particular important change, which was the
addition of section 7. The ‘Liberty or Death’ clause, as I’ve generally thought about it, which says that if someone has conditions
imposed on him that don’t allow him to distribute the software in a way that respects all the freedoms stated in the GPL, then he
can’t distribute at all.”).
85
GPLV2, supra note 2, § preamble.
86
Id. § 7.
April 2011
Page 24
portfolio licenses, and other business transactions where the terms of such licenses do not permit
free unrestricted use of those patents to all recipients.87
Even assuming such arguments would be persuasive, Section 7 does not prohibit distribution of
software under the GPLv2 unless the distributor must itself impose obligations on downstream
recipients as a result of the patent license that would be inconsistent with the terms of the
GPLv2. As long as the third party patent licensor does not require its licensees to impose
restrictions on their downstream recipients then there would be no violation of the GPLv2 when
the patent licensee distributed the licensed software under the GPLv2.
In the case of a RAND or RAND-RF license, all downstream recipients would be able to obtain
their own license from the third party patent licensor. It is not clear that the patent licensor
would grant a license without the typical standards-related field-of-use limitations discussed
above, but as long as the patent licensor does not require the distributor to condition its GPLv2
distribution on recipients obtaining a patent license, there is no conflict with Section 7 of the
GPLv2.
Unfortunately, this misunderstanding, that the GNU licenses prohibit distribution if the software
contains patented technology licensed by a third party under RAND or RAND-RF terms and
conditions, is often cited as a reason why SSO patent policies must preclude the use of patented
technology unless it will be made available royalty free and without restrictions.88 Such
arguments are often made to governments considering legislation, regulations, and procurement
policies involving standards and patents.89 If such policies were adopted, they would eliminate
87
Indeed, in a recent case, Google was found to infringe a patent covering the Linux Kernel. See Caroline McCarthy, Linux
Patent Suit Ruled Against Google, CNET NEWS, Apr. 21, 2011, available at http://news.cnet.com/8301-13577_3-2005619236.html#ixzz1KHVsMRyw. A number of companies have settled patent disputes involving OSS where the accused infringer
agreed to a patent license and fees. See Acacia Subsidiary Settles Patent Litigation with Red Hat, BUSINESS WIRE, Apr. 29, 2011,
available at http://www.businesswire.com/news/home/20110429005167/en/Acacia-Subsidiary-Settles-Patent-Litigation-RedHat. See also Viktor Ustijanoski, Canonical – Ubuntu Licenses H.264, DETECTOR PRO ONLINE TECH. MAG., May 7, 2010,
available at http://www.detector-pro.com/2010/05/ubuntu-licenses-h-264.html; Canonical Clarifies Its H.264 Licence, THE H
OPEN, May 5, 2010, available at http://www.h-online.com/open/news/item/Canonical-clarifies-its-H-264-licence-993182.html;
MPEGLA,
Summary
of
AVC/H.264
License
Terms,
http://www.mpegla.com/main/programs/avc/Documents/AVC_TermsSummary.pdf (last visited Apr. 26, 2011) (listing a
summary of AVC/H.264 license terms, including royalty terms); MPEGLA, AVC/H.264 Licensees,
http://www.mpegla.com/main/programs/AVC/Pages/Licensees.aspx (last visited Apr. 26, 2011) (listing AVC/H.264 licensees,
including Roku, Inc., which sells a Linux-based set top box device, and Canonical). Non-monetary RAND restrictions in
covenants suggest that GPLv2 § 7 does not provide an absolute block to these types of terms. For example, both IBM’s
Interoperability Specifications Pledge and Microsoft’s Open Specification Promise include at least two non-monetary RAND
terms, a prohibition on sublicensing and a scope restriction in the form of limiting coverage to “Covered Implementations.” See
IBM, Interoperability Specifications Pledge, July 9, 2009, available at http://www-03.ibm.com/linux/ossstds/isplist.html;
Microsoft,
Microsoft
Open
Specifications
Promise,
Feb.
1,
2007,
available
at
http://www.microsoft.com/interop/osp/default.mspx. Red Hat’s Deputy General Counsel Mark Webbink stated, “the OSP
[Microsoft’s Open Specifications Promise] gives sufficient flexibility to implement the listed specifications in software licensed
under free and open source licenses.” Id. Adobe Systems Inc. has issued a “Public Patent License,” which similarly covers
Compliant Implementations of the ISO 32000-1: 2008 – PDF 1.7 standard. See Adobe Systems Inc., Public Patent License, ISO
32000-1: 2008 – PDF 1.7, http://www.adobe.com/pdf/pdfs/ISO32000-1PublicPatentLicense.pdf (last visited Apr. 26, 2011).
88
In some cases, these arguments are not mere misunderstandings. Those parties with OSS business models as discussed above
will derive more profits from other software, hardware, and services that they sell or license if the OSS they give away is royaltyfree since their customers are paying for the entire package or solution and do not care how the fees are allocated across the OSS
components, other software, hardware, and/or services.
89
See, e.g., Letter from Karsten Gerloff, President, Free Software Found. Eur., to European Comm’n Directorates Gen., Revision
of the EIF: FSFE Responds to BSA’s Claims re Standardisation, Patent Licensing 1–3 (Oct. 15, 2010), available at
http://fsfe.org/projects/os/bsa-eif-letter-fsfe-response.pdf; Letter from Tom B. Rabon, Executive Vice President, Red Hat, Inc., to
April 2011
Page 25
patent holders rights to seek RAND royalties on their standards-essential patent claims, or even
use such patent claims effectively for other purposes such as freedom to operate or defensive use.
In sum, it should be clear that after a careful analysis of the various OSS licenses, there is no
reason to require SSOs to modify RAND-based patent policies to accommodate OSS
distribution. To the extent that such changes are occurring, such changes, e.g., to RAND-RF or
even CNS obligations, will negatively affect the value of patent portfolios of those parties
participating in the relevant SSOs.
VI. Conclusion
Despite the widespread use of OSS, there has been little analysis or guidance concerning how
OSS may affect a party’s patent portfolio when that party uses or distributes such OSS. OSS
licenses themselves raise several interesting issues regarding the scope of patent licenses that
may be granted by parties distributing OSS. The situation is made more complex, rather than
simplified, when the OSS is bundled with or integrated into products and services that are subject
to commercial license agreements. In addition, certain OSS licenses include defensive
revocation provisions that can be tantamount to a broad patent grant back when the OSS subject
to such a license is critical software that cannot be easily replaced by the user. Finally, there is a
growing trend to modify SSO RAND-based patent policies that tends to devalue the patent
portfolios of patentees that participate in those SSO’s standards development projects. Such
trends are occurring based on an erroneous belief that the changes are needed to accommodate
OSS distribution.
European Comm’n, Directorate-Gen. for Competition, Red Hat Response to Public Consultation on H.C. Agreements 2010 4–5
(June 25, 2010), available at http://ec.europa.eu/competition/consultations/2010_horizontals/redhat_en.pdf.
April 2011
Page 26
Download