For all its benefits, one aspect of open source software does cause headaches: understanding the legal terms that control its development and use. For starters, scores of licenses have been created that the Open Source Initiative recognizes as meeting the definition of an “open source license.” While the percentage of these licenses that are in wide use is small, there are significant and important differences between many of these popular licenses. Moreover, determining what rights are granted in some cases requires referring to what the community thinks they mean (rather than their actual text), and in others by the context in which the license is used.
Rather like interpreting the applicability of the U.S. Constitution to modern life, except that there is no Supreme Court available to call the coin toss when people disagree.
In part as a result of this complex legal landscape, the founders of an open source project will sometimes use a mechanism in addition to an open source license when they want to provide additional or more specific rights relating to patents that may be infringed through the modification, distribution or use of code they contribute to project software. That mechanism is often referred to as a “patent pledge” or “patent non-assertion pledge,” and in the course of this blog entry I’ll try and explain why and when this mechanism may be used, and how the benefits it conveys relate, compare, and add to the rights provided under open source licenses.
First off, let’s talk about what a patent pledge is, and how it compares to a patent grant of rights under an open source license:
• An open source license may either expressly or impliedly include an affirmative grant of rights relating to patents, such as the right to use, modify, distribute and (under some open source licenses) sublicense software covered by the patent. Absent such a license, the developer, distributor or user would be infringing the patent owner’s intellectual property rights without permission, and could therefore be sued by the patent owner.
• A patent pledge is in some ways a mirror image of a patent license. But instead of granting a license to the patent, it commits the patent owner not to sue someone using, modifying or distributing open source software covered by the patent even though no license has been granted. It is often conditioned upon the user or developer not doing certain things in return (I’ll come back to what those thing are later).
As you can see from this high level comparison, in principle both mechanisms can accomplish exactly the same result. When it’s remembered that many open source licenses apply automatically to “downstream” parties (e.g., developers in other projects that incorporate the code and make further changes to it, end-users that modify the software, etc.), the practical differences become even more blurred.
That said, why do we need two different mechanisms for dealing with the same patent issues at all? If the same or similar terms can already be found in an existing, approved open source license, why not just use that license instead?
The reasons usually arise from the context in which the pledge is made. For example, a decade ago a number of the largest IT companies in the world, including IBM, Sun Microsystems, Oracle, and Nokia, among others, made public pledges not to assert specified patents they owned (over 500, in the case of IBM) against users of Linux (and in some cases other popular open source software as well, such as OpenOffice). The reason was to assure those users that they could acquire and use the named open source products without worrying about being sued for patent infringement by the companies making the pledges.
The motivation for these public – and publicized – pledges arose from certain law suits then in process, and in particular those brought in 2003 and afterwards by SCO Group against IBM and Novell (among others). Those suits claimed that the use of the Linux operating system infringed rights acquired by SCO Group, and some of the companies sued weren’t vendors, like IBM, but ordinary end users, like Chrysler Corporation.
The intellectual property rights (IPR) policies of many standards organizations take the same approach, although in this context the practice is often referred to using a different name. Rather than committing to grant a license to vendors with respect to patent claims that would be “necessarily infringed” by a product implementing a standard, a company subject to such a policy simply commits not to sue the vendor with respect to these “necessary claims.” For the party implementing the standard, this is even better than a RAND license, since the implementer doesn’t have to bother negotiating a license.
A third and more recent example can be found where those contributing to a given open source project agree to provide an additional layer of intellectual property protection over and above the rights that that are already conveyed by the open source license chosen for that code base.
Let’s look at two common open source licenses as examples for why this additional level of commitment might be useful. In the BSD License, the most commonly used “permissive” license, the grant of intellectual property rights is extremely short, reading in its entirety as follows:
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
While the balance of the license makes several references to copyrights, nowhere in this statement, or in any of the other text of this very brief license, is there any reference to patent rights at all. Normally, a commercial license includes very specific terms addressing what specific IPR rights are intended to be conveyed.
The main assurance a downstream developer or user of software licensed under the BSD license has that it will not be sued for patent infringement is the consensus that has accumulated over time among developers and users that a patent license is implied by the brief language found in the license.
Partly as a reaction to nervousness upon the part of lawyers, some second generation open source licenses include specific terms addressing patents. For example, the popular Apache license 2.0 includes the following text:
3. Grant of Patent License.
Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted.
In point of fact, the patent rights intended to be conveyed under the BSD license are generally assumed to be exactly the same, but the user of software licensed under the Apache license can show a judge and jury, within the four corners of the document itself, exactly what the contributor of the software in question intended.
Open source licenses can also include additional terms, conditions and obligations that could never be implied under one of the very short “permissive” licenses. The GNU General Public License, versions 2.0 and 3.0, for example include a variety of very significant terms and restrictions. And even the permissive Apache license goes on to read as follows:
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.
Like the patent pledge, this is also a term borrowed from the world of standards development, where it’s often referred to as a right of “defensive suspension.” The concept is that if someone sues you regarding the use of the same open source software (or a product implementing the same standard), you should be able to defend yourself in the same manner, thereby leveling the playing field between the two parties.
So what does all of this have to do with patent pledges?
As I said, a patent pledge can be used to provide additional protections to users of software that the open source license itself does not provide. So if a given project is under a very short permissive license, a group of companies can decide to provide an additional umbrella over the project code through this device. Up to a point, they can also customize the pledge without introducing incompatibility issues that might inhibit the inclusion of the code in question into code subject to other more restrictive licenses.
Several projects employ patent pledges today in addition to their underlying open source licenses. One which I recently helped structure and launch is the OpenDOF Project opted to distribute project code under the ISC License, which is even more brief than the BSD License. The entire license comprises only a copy right notice, a warranty disclaimer, and the following grant language:
Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.
As you can see, while the ISC language is somewhat more explicit about what you can do (“use, modify, and/or distribute for any purpose with or without a fee”) than the BSD License (“Redistribution and use in source and binary forms, with or without modification”) any rights relating to patents are implied rather than stated.
OpenDOF also adopted an IP Policy that includes a “patent non-assertion pledge” that provides explicit language relating to rights that may be only implied under the ISC License. These additional assurances will make future releases of core code more commercially attractive when the same code has been approved under the certification program that the project intends to launch and support.
The patent pledge language included in the OpenDOF IP Policy is detailed and extensive, and you should refer to the policy itself and related information provided by OpenDOF for a full understanding of them. However, the following are excerpts of some of the more fundamental aspects:
Each Pledging Entity [i.e., a code contributor] promises that the Pledging Entity will not bring a Lawsuit or other legal proceeding against any entity for patent infringement under any of its Pledged Patent Claims. .
Each entity making the pledge does so solely with respect to its own contributed code, subject to several reservations, expressed as follows:
The preceding Pledge does not apply to any infringement of the Pledged Patent Claims (a) by Contributions made by others, (b) that arises from any modification of the Contribution after its submission by the Contributor, or (c) that arises from combination of the Contribution with other code or hardware.
Each pledge also includes the right to revoke the pledge under certain circumstances, expressed in part as follows:
Each Pledging Entity reserves the right to terminate its Pledge (“Permitted Termination”) with respect to any Pledge Recipient if the Pledge Recipient or any of its Affiliates files a Lawsuit alleging infringement of a patent by Alliance Code in a Compliant Base Implementation, other than a Lawsuit or other legal proceeding that would have been subject to a Pledge but for a Permitted Termination (an “Offensive Claim”).
Just as does the Apache license, the above language allows any and every entity providing a pledge to revoke its pledge with regard to a plaintiff even if it has not itself been sued. Thus, a suit brought against any user is treated as a violation of the conditions of the pledges made by every contributor of code, entitling each of them to terminate its own pledge to the plaintiff.
The moral of the story is that by whatever name – patent pledge, patent non-assertion pledge, or covenant not to sue – this mechanism can provide an attractive, useful and flexible way to augment the rights included an open source license. For that reason, we can expect it to be used with increasing frequency.
Sign up for a free subscription to Standards Today today!
Have you discovered The Alexandria Project?