Legal Matters: Licenses, Copyrights, Trademarks and Patents

Legal Matters: Licenses, Copyrights, Trademarks and Patents Legal questions have assumed a somewhat more prominent role in free software projects over the last decade or so. It is still the case that the most important things about your project are its the quality of its code, its features, and the health of its developer community. However, although all open source licenses share the same basic guarantees of freedom, their terms are not exactly the same in all details. The particular license your project uses can affect which entities decide to get involved in it and how. You will therefore need a basic understanding of free software licensing, both to ensure that the project's license is compatible with its goals, and to be able to discuss licensing decisions with others. Please note that I am not a lawyer, and that nothing in this book should be construed as formal legal advice. For that, you'll need to hire a lawyer or be one. Terminology In any discussion of open source licensing, the first thing that becomes apparent is that there seem to be many different words for the same thing: free software, open source, FOSS, F/OSS, and FLOSS. Let's start by sorting those out, along with a few other terms. free software Software that can be freely shared and modified, including in source code form. The term was first coined by Richard Stallman, who codified it in the GNU General Public License (GPL), and who founded the Free Software Foundation (fsf.org) to promote the concept. Although "free software" covers the same set of software as "open source", the FSF, among others, prefers the former term because it emphasizes the idea of freedom, and the concept of freely redistributable software as primarily a social movement rather than a technical one. The FSF acknowledges that the term is ambiguous—it could mean "free" as in "zero-cost", instead of "free" as in "freedom"—but feels that it's still the best term, all things considered, and that the other possibilities in English have their own ambiguities. (Throughout this book, "free" is used in the "freedom" sense, not the "zero-cost" sense.) open source software Free software under another name. The different name is sometimes used to indicate a philosophical difference, however. In fact, the term "open source" was coined by the group that founded the Open Source Initiative (opensource.org) as a deliberate alternative to "free software". Their goal at the time was largely to make such software a more palatable choice for corporations, by presenting it as a development methodology rather than as a political movement.Disclaimer: Years after these events, I served as a member of the Board of Directors of the Open Source Initiative for three years, from 2011-2014. The ideological gap between the OSI and the FSF is much smaller these days than it was when the OSI was founded, in my opinion, and lately the two organizations have increasingly found common ground on which to cooperate. I remain a happy member of both, and urge you to join them too: opensource.org/join and fsf.org/join. While any license that is free is also open source, and vice versa (with a few minor exceptions that have no practical consequences), people tend to pick one term and stick with it. In general, those who prefer "free software" are more likely to have a philosophical or moral stance on the issue, while those who prefer "open source" either don't view it as a matter of freedom, or are not interested in advertising the fact that they do. See in for a more detailed history of this terminological schism. The Free Software Foundation has an excellent—utterly unobjective, but nuanced and quite fair—exegesis of the two terms, at www.fsf.org/licensing/essays/free-software-for-freedom.html. The Open Source Initiative's take on it is (or was, in 2002) spread across two pages: web.archive.org/web/20021204155022/http://www.opensource.org/advocacy/case_for_hackers.php#marketing and web.archive.org/web/20021204155022/http://www.opensource.org/advocacy/free-notfree.php [sic]. FOSS, F/OSS, FLOSS Where there are two of anything, there will soon be three, and that is exactly what is happening with terms for free software. The academic world, perhaps wanting precision and inclusiveness over elegance, seems to have settled on FOSS, or sometimes F/OSS, standing for "Free / Open Source Software". Another variant gaining momentum is FLOSS, which stands for "Free / Libre Open Source Software" (libre is familiar from many Romance languages and does not suffer from the ambiguities of "free"; see en.wikipedia.org/wiki/FLOSS for more). All these terms mean the same thing: software that can be modified and redistributed by everyone, sometimes—but not always—with the requirement that derivative works be freely redistributable under the same terms. DFSG-compliant Compliant with the Debian Free Software Guidelines (debian.org/social_contract#guidelines). This is a widely-used test for whether a given license is truly open source (free, libre, etc.). The Debian Project's mission is to maintain an entirely free operating system, such that someone installing it need never doubt that she has the right to modify and redistribute any or all of the system. The Debian Free Software Guidelines are the requirements that a software package's license must meet in order to be included in Debian. Because the Debian Project spent a good deal of time thinking about how to construct such a test, the guidelines they came up with have proven very robust (see en.wikipedia.org/wiki/DFSG), and as far as I'm aware, no serious objection to them has been raised either by the Free Software Foundation or the Open Source Initiative. If you know that a given license is DFSG-compliant, you know that it guarantees all the important freedoms (such as forkability even against the original author's wishes) required to sustain the dynamics of an open source project. Since 2004, the Debian Project has maintained a list of known DFSG-compliant licenses at wiki.debian.org/DFSGLicenses. All of the licenses discussed in this chapter are DFSG-compliant. OSI-approved Approved by the Open Source Initiative. This is another widely-used test of whether a license permits all the necessary freedoms. The OSI's definition of open source software is based on the Debian Free Software Guidelines, and any license that meets one definition almost always meets the other. There have been a few exceptions over the years, but only involving niche licenses and none of any relevance here. The OSI maintains a list of all licenses it has ever approved, at opensource.org/licenses/, so that being "OSI-approved" is an unambiguous state: a license either is or isn't on the list. The Free Software Foundation also maintains a list of licenses at fsf.org/licensing/licenses/license-list.html. The FSF categorizes licenses not only by whether they are free, but whether they are compatible with the GNU General Public License. GPL compatibility is an important topic, covered in later in this chapter. proprietary, closed-source The opposite of "free" or "open source." It means software distributed under traditional, royalty-based licensing terms, where users pay per copy, or under any other terms sufficiently restrictive to prevent open source dynamics from operating. Even software distributed at no charge can still be proprietary, if its license does not permit free redistribution and modification. Generally "proprietary" and "closed-source" are synonyms. However, "closed-source" additionally implies that the source code cannot even be seen. Since the source code cannot be seen with most proprietary software, this is normally a distinction without a difference. However, occasionally someone releases proprietary software under a license that allows others to view the source code. Confusingly, they sometimes call this "open source" or "nearly open source," etc., but that's misleading. The visibility of the source code is not the issue; the important question is what you're allowed to do with it: if you can't copy, modify, and redistribute, then it's not open source. Thus, the difference between proprietary and closed-source is mostly irrelevant; generally, the two can be treated as synonyms. Sometimes commercial is used as a synonym for "proprietary," but this is carelessness: the two are not the same. Free software is always commercial software. After all, free software can be sold, as long as the buyers are not restricted from giving away copies themselves. It can be commercialized in other ways as well, for example by selling support, services, and certification. There are billion-dollar companies built on free software today, so it is clearly neither inherently anti-commercial nor anti-corporate. It is merely anti-proprietary, or if you prefer anti-monopolistic, and this is the key way in which it differs from per-copy license models. public domain Having no copyright holder, meaning that there is no one who has the right to restrict copying of the work. Being in the public domain is not the same as having no author. Everything has an author, and even if a work's author or authors choose to put it in the public domain, that doesn't change the fact that they wrote it. When a work is in the public domain, material from it can be incorporated into a copyrighted work, and the derivative is thus under the same overall copyright as the original copyrighted work. But this does not affect the availability of the original public domain wok. Thus, releasing something into the public domain is technically one way to make it "free," according to the guidelines of most free software certifying organizations (see opensource.org/faq#public-domain for more). However, there are usually good reasons to use a license instead of just releasing into the public domain: even with free software, certain terms and conditions can be useful, not only to the copyright holder but to recipients as well, as the next section makes clear. copyleft A license that not only grants the freedoms under discussion here but furthermore requires that those freedoms apply to any derivative works. The canonical example of a copyleft license is still the GNU General Public License, which stipulates that any derivative works must also be licensed under the GPL; see later in this chapter for more. non-copyleft or permissive A license that grants the freedoms under discussion here but that does not have a clause requiring that they apply to derivative works as well. Two early and well-known examples of permissive licenses are the BSD and MIT licenses, but the more recent Apache Software License version 2 (apache.org/licenses/LICENSE-2.0) is also very popular—increasingly so—and somewhat better adapted to the legal landscape of modern open source software development. "Free Software" and "Open Source" Are the Same Licenses. Occasionally people will make the mistake of thinking that copyleft licenses (like the GPL) comprise "free software", while the permissive licenses comprise "open source". This is wrong, but it comes up just often enough to be worth mentioning here. Both free software and open source include both the copyleft and non-copyleft licenses — this is something that all the license-certifying organizations, including the FSF, the OSI, and the Debian Project, have always agreed on. If you see someone, particularly a journalist, making this mistake, please politely correct them, perhaps by pointing them to this note ( producingoss.com/en/terminology.html#free-open-same). The last thing we need is yet more terminological confusion in the free and open source software movement. Aspects of Licenses Although there are many different free software licenses available, in the important respects they all say the same things: that anyone can modify the code, that anyone can redistribute it both in original and modified form, and that the copyright holders and authors provide no warranties whatsoever (avoiding liability is especially important given that people might run modified versions without even knowing it). The differences between licences boil down to a few oft-recurring issues: compatibility with proprietary licenses Some free licenses allow the covered code to be used in proprietary programs. This does not affect the licensing terms of the proprietary program: it is still as proprietary as ever, it just happens to contain some code from a non-proprietary source. The Apache License, X Consortium License, BSD-style license, and the MIT-style license are all examples of proprietary-compatible licenses. compatibility with other types of free licenses Most free licenses are compatible with each other, meaning that code under one license can be combined with code under another, and the result distributed under either license without violating the terms of the other. The major exception to this is the GNU General Public License, which requires that any work using GPLed code be itself distributed under the GPL, and without adding any further restrictions beyond what the GPL requires. The GPL is compatible with some free licenses, but not with others. This is discussed in more detail in later in this chapter. enforcement of crediting Some free licenses stipulate that any use of the covered code be accompanied by a notice, whose placement and display is usually specified, giving credit to the authors or copyright holders of the code. These licenses are often still proprietary-compatible: they do not necessarily demand that the derivative work be free, merely that credit be given to the free code. protection of trademark A variant of credit enforcement. Trademark-protecting licenses specify that the name of the original software (or its copyright holders, or their institution, etc.) may not be used to identify derivative works, at least not without prior written permission. This restriction can be implemented purely via trademark law anyway, whether or not it is also stipulated by the copyright license, so such clauses can be somewhat legally redundant — in effect, they amplify a trademark infringement into a copyright infringement as well. Although credit enforcement insists that a certain name be used, and trademark protection insists that it not be used, they are both expressions of the same concept: that the original code's reputation be preserved, and not tarnished by association. patent snapback Certain licenses (e.g., the GNU General Public License version 3, the Apache License version 2, the Mozilla Public License 2.0, and a few others) contain language designed to prevent people from using patent law to take away the rights granted under copyright law by the licenses. They require contributors to grant patent licenses along with their contribution, covering any patents licenseable by the contributor that would be infringed by their contribution (or by the incorporation of their contribution into the work as a whole). Then they go further: if someone using software under the license initiates patent litigation against another party, claiming that the covered work infringes, the initiator automatically loses all the patent grants otherwise provided for that work by the license, and in the case of the GPL-3.0 loses their right to distribute under the license altogether. protection of "artistic integrity" Some licenses (the Artistic License, used for the most popular implementation of the Perl programming language, and Donald Knuth's TeX license, for example) require that modification and redistribution be done in a manner that distinguishes clearly between the pristine original version of the code and any modifications. They permit essentially the same freedoms as other free licenses, but impose certain requirements that make the integrity of the original code easy to verify. These licenses have not caught on much beyond the specific programs they were made for, and will not be discussed in this chapter; they are mentioned here only for the sake of completeness. I do not recommend licensing new code under them. Most of these stipulations are not mutually exclusive, and some licenses include several. The common thread among them is that they place demands on the recipient in exchange for the recipient's right to use and/or redistribute the code. The GPL and License Compatibility The sharpest dividing line in licensing is that between proprietary-incompatible and proprietary-compatible licenses, that is, between the copyleft licenses and everything else. The canonical example of a copyleft license is the GNU General Public License (along with its network-oriented variant, the Affero GNU General Public License or AGPL, introduced later in this chapter in ), and one of the most important considerations in choosing the GPL or AGPL is the extent to which it is compatible with other licenses. For brevity, I'll refer just to the GPL below, but most of this applies to the AGPL as well. Because the primary goal of the GPL's authors is the promotion of free software, they deliberately crafted the license to make it impossible to mix GPLed code into proprietary programs. Specifically, among the GPL's requirements (see fsf.org/licensing/licenses/gpl.html for its full text) are these two: Any derivative work—that is, any work containing a nontrivial amount of GPLed code—must itself be distributed under the GPL. No additional restrictions may be placed on the redistribution of either the original work or a derivative work. (The exact language is: "You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License.") With these conditions, the GPL succeeds in making freedom contagious. Once a program is copyrighted under the GPL, its terms of redistribution are reciprocalSome people use the term viral to describe the GPL's contagiousness; they do not always mean this pejoratively, but I still prefer "reciprocal" because it's more descriptive and less connotative of disease.—they are passed on to anything else the code gets incorporated into, making it effectively impossible to use GPLed code in closed-source programs. However, these same clauses also make the GPL incompatible with certain other free licenses. The usual way this happens is that the other license imposes a requirement—for example, a credit clause requiring the original authors to be mentioned in some way—that is incompatible with the GPL's "You may not impose any further restrictions..." language. From the point of view of the Free Software Foundation, these second-order consequences are desirable, or at least not regrettable. The GPL not only keeps your software free, but effectively makes your software an agent in pushing other software to enforce freedom as well. The question of whether or not this is a good way to promote free software is one of the most persistent holy wars on the Internet (see in ), and we won't investigate it here. What's important for our purposes is that GPL compatibility is something to consider when choosing a license. The GPL is by far the most popular open source license, having more than twice as many projects released under it as under the next most popular licensesThis statistic is based on an aggregation of several license count sources, combined with some reasonable definitional assumptions.. If you want your code to be able to be mixed freely with GPLed code—and there's a lot of GPLed code out there—then you should pick a GPL-compatible license. Most of the GPL-compatible open source licenses are also proprietary-compatible: that is, code under such a license can be used in a GPLed program, and it can be used in a proprietary program. Of course, the results of these mixings would not be compatible with each other, since one would be under the GPL and the other would be under a closed-source license. But that concern applies only to the derivative works, not to the code you distribute in the first place. Fortunately, the Free Software Foundation maintains a list showing which licenses are compatible with the GPL and which are not, at gnu.org/licenses/license-list.html. All of the licenses discussed in this chapter are present on that list, on one side or the other. Legal Diligence: What to Check Before You Release 1 Sep 2014: If you're reading this note, then you've encountered this section while it's still being written; see producingoss.com/v2.html for details. possv2 todo: things that will be mentioned here: the Chart.js "apology to open source" event, a note about GPL-compatibility, and some of the things discussed in opentechstrategies.com/resources#oss-licensing. Choosing a License When choosing a license to apply to your project, use an existing license instead of making up a new one. And don't just use any existing license — use one of the widely-used, well-recognized existing licenses. Such licenses are familiar to many people already. If you use one of them, people won't feel they have to read the legalese in order to use your code, because they'll have already done so for that license a long time ago. Thus, you reduce or remove one possible barrier to entry for your project. They are also of a high quality: they are the products of much thought and experience; indeed most of them are revisions of previous versions of themselves, and the modern versions represent a great deal of accumulated legal and technical wisdom. Unless your project has truly unusual needs, it is unlikely you could do better, even with a team of lawyers at your disposal. Below is a list of licenses that in my opinion meets these criteria; in parentheses are the standard formal abbreviation for the license and an authoritative URL for its full text. This list is not in order of preference, but rather in roughly descending order from strong copyleft at the top to completely non-copyleft at the bottom. The exact provisions of each license differ in various interesting ways (except for BSD and MIT, which differ only in uninteresting ways), and there isn't space here to explore all the possible ramifications of each for your project. However, many good discussions of that sort are available on the Internet; in particular the Wikipedia pages for these licenses generally give good overviews. If you have nothing else to guide you and you want a copyleft license, then choose either the GPL-3.0 or the AGPL-3.0 — the difference between them will be discussed below — and if you want a non-copyleft license, choose Apache-2.0. I've put those licenses in boldface to reflect this. GNU General Public License version 3 (GPL-3.0, gnu.org/licenses/gpl.html) GNU Affero General Public License version 3 (AGPL-3.0, gnu.org/licenses/agpl.html) Mozilla Public License 2.0 (MPL-2.0, mozilla.org/MPL) GNU Library or "Lesser" General Public License version 3 (LGPL-3.0, gnu.org/licenses/lgpl.html) Eclipse Public License 1.0 (EPL-1.0, eclipse.org/legal/epl-v10.html) (Note that version 2 of the EPL was almost ready as of mid-2014, and may be out by the time you read this.) Apache License 2.0 (Apache-2.0, apache.org/licenses/LICENSE-2.0) BSD 2-Clause ("Simplified" or "FreeBSD") license (BSD-2-Clause, opensource.org/licenses/BSD-2-Clause) MIT license (MIT, opensource.org/licenses/MIT) The mechanics of applying a license to your project are discussed in in . The GNU General Public License If you prefer that your project's code not be used in proprietary programs, or if you at least don't care whether or not it can be used in proprietary programs, the GNU General Public License is a good choice. When writing a code library that is meant mainly to be used as part of other programs, consider carefully whether the restrictions imposed by the GPL are in line with your project's goals. In some cases—for example, when you're trying to unseat a competing, proprietary library that offers the same functionality—it may make more strategic sense to license your code in such a way that it can be mixed into proprietary programs, even though you would otherwise not wish this. The Free Software Foundation even fashioned an alternative to the GPL for such circumstances: the GNU Lesser GPLOriginally named the GNU Library GPL, and later renamed by the FSF). The LGPL has looser restrictions than the GPL, and can be mixed more easily with non-free code. The FSF's page about the LGPL, gnu.org/licenses/lgpl.html, has a good discussion of when to use it. The "or any later version" Option: Future-Proofing the GPL. The GPL has a well-known optional recommendation that you release software under the current version of the GPL while giving downstream recipients the option to redistribute it under any later (i.e., future) version. The way to offer this option is to put language like this in the license headers (see in ) of the actual source files:

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

(Emphasis added.) Whether you want to offer that option depends largely on how likely you think the Free Software Foundation is to make GPL revisions that you would approve of. I think the FSF has done a good job of that so far, and I generally do include that option when I use the GPL. That way I don't have to be responsible for updating the licenses myself forever — which is good, since I won't be around forever. Others can do it, either just to keep the software license up-to-date with legal developments, or to solve some future license compatibility problem that couldn't have been anticipated now (for example, see the compatibility discussion in below). Not everyone feels the same way, however; most notably, the Linux kernel is famously licensed under the GNU GPL version 2 without the "or any later version" clause, and influential kernel copyright holders, especially Linus Torvalds, have expressed clearly that they do not intend to move its license to version 3.0. This book cannot answer the question of whether you should include the option or not. You now know that you have the choice, at least, and that different people come to different conclusions about it. The GNU Affero GPL: A Version of the GNU GPL for Server-Side Code In 2007, the Free Software Foundation released a variant of the GPL called the GNU Affero GPL The history of the license and its name is a bit complicated. The first version of the license was originally released by Affero, Inc, who based it on the GNU GPL version 2. At the time, this was commonly referred to as the AGPL. Later, the Free Software Foundation decided to adopt the idea, but by then they had released version 3 of their GNU GPL, so they based their new Affero-ized license on that and called it the "GNU AGPL". The old Affero license is now rarely used and is more or less deprecated, but to avoid ambiguity, say "AGPL-3.0" or "GNU AGPL" to make it clear that you're referring to the modern GNU version of the license.. Its purpose is to bring copyleft-style sharing provisions to the increasing amount of code being run as hosted services — that is, software that runs "in the cloud" on remote servers, that users interact with only over the network, and that therefore is never directly distributed to users as executable or source code. Many such services use GPL'd software, often with extensive modifications, yet could avoid publishing their changes because they weren't actually distributing code. The AGPL's solution to this was to take the GPL and add a "Remote Network Interaction" clause, stating "...if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network ... an opportunity to receive the Corresponding Source of your version ... at no charge, through some standard or customary means of facilitating copying of software." This expanded the GPL's enforcement powers into the new world of application service providers. The Free Software Foundation recommends that the GNU AGPL 3.0 be used for any software that will commonly be run over a network. Note that the AGPL-3.0 is not directly compatible with GPL-2.0, though it is compatible with GPL-3.0. Since most software licensed under GPL-2.0 includes the "or any later version" clause anyway, that software can just be shifted to GPL-3.0 if and when you need to mix it with AGPL-3.0 code. However, if you need to mix with programs licensed strictly under the GPL-2.0 (that is, programs licensed without the "or any later version" clause), the AGPL3.0 wouldn't be compatible with that. Although the history of the AGPL-3.0 is a bit complicated, the license itself is simple: it's just the GPL-3.0 with one extra clause about network interaction. The Wikipedia article on the AGPL is excellent: en.wikipedia.org/wiki/Affero_General_Public_License Is the GPL free or not free? One consequence of choosing the GPL (or AGPL) is the possibility—small, but not infinitely small—of finding yourself or your project embroiled in a dispute about whether or not the GPL is truly "free", given that it places some restrictions on how you redistribute the code—namely, the restriction that the code cannot be distributed under any other license. For some people, the existence of this restriction means the GPL is therefore "less free" than non-copyleft licenses. Where this argument usually goes, of course, is that since "more free" must be better than "less free" (after all, who's not in favor of freedom?), it follows that those licenses are better than the GPL. This debate is another popular holy war (see in ). Avoid participating in it, at least in project forums. Don't attempt to prove that the GPL is less free, as free, or more free than other licenses. Instead, emphasize the specific reasons your project chose the GPL. If the recognizability of license was a reason, say that. If the enforcement of a free license on derivative works was also a reason, say that too, but refuse to be drawn into discussion about whether this makes the code more or less "free". Freedom is a complex topic, and there is little point talking about it if terminology is going to be used as a stalking horse for substance. Since this is a book and not a mailing list thread, however, I will admit that I've never understood the "GPL is not free" argument. The only restriction the GPL imposes is that it prevents people from imposing further restrictions. To say that this results in less freedom has always seemed to me like saying that outlawing slavery reduces freedom, because it prevents some people from owning slaves. (Oh, and if you do get drawn into a debate about it, don't raise the stakes by making inflammatory analogies.) Contributor Agreements possv2 6 Sep 2014: If you're reading this note, then you've encountered this section while it's undergoing substantial revision; see producingoss.com/v2.html for details. possv2 todo: discuss Developer Certificates of Origin (DCOs) too. There are three ways to handle copyright ownership for free code and documentation that were contributed to by many people. The first is to ignore the issue of copyright entirely (I don't recommend this). The second is to collect a contributor license agreement (CLA) from each person who works on the project, explicitly granting the project the right to use that person's contributions. This is usually enough for most projects, and the nice thing is that in some jurisdictions, CLAs can be sent in by email. The third way is to get actual copyright assignment (CA from contributors, so that the project (i.e., some legal entity, usually a nonprofit) is the copyright owner for everything. This way is the most burdensome for contributors, and some contributors simply refuse to do it; only a few projects still ask for assignment, and I don't recommend that any project require it these days.Also, actual copyright transferral is subject to national law, and licenses designed for the United States may encounter problems elsewhere (e.g., in Germany, where it's apparently not possible to transfer copyright). Note that even under centralized copyright ownership, the codeI'll use "code" to refer to both code and documentation, from now on. remains free, because open source licenses do not give the copyright holder the right to retroactively proprietize all copies of the code. So even if the project, as a legal entity, were to suddenly turn around and start distributing all the code under a restrictive license, that wouldn't cause a problem for the public community. The other developers would simply start a fork based on the latest free copy of the code, and continue as if nothing had happened. Doing Nothing possv2 todo 6 Sep 2014: I'm not so sure about the advice in this section anymore. The legal landscape has changed, and I've learned more. For the moment I'm letting it stand, until I have a chance to talk to a few more people. Most projects never collect CLAs or CAs from their contributors. Instead, they accept code whenever it seems reasonably clear that the contributor intended it to be incorporated into the project. Under normal circumstances, this is okay. But every now and then, someone may decide to sue for copyright infringement, alleging that they are the true owner of the code in question and that they never agreed to its being distributed by the project under an open source license. For example, the SCO Group did something like this to the Linux project, see en.wikipedia.org/wiki/SCO-Linux_controversies for details. When this happens, the project will have no documentation showing that the contributor formally granted the right to use the code, which could make some legal defenses more difficult. Contributor License Agreements CLAs probably offer the best tradeoff between safety and convenience. A CLA is typically an electronic form that a developer fills out and sends in to the project. In many jurisdictions, email submission or an online form is enough. A secure digital signature may or may not be required; consult a lawyer to find out what method would be best for `your project. Most projects use two slightly different CLAs, one for individuals, and one for corporate contributors. But in both types, the core language is the same: the contributor grants the project a "...perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute [the] Contributions and such derivative works." Again, you should have a lawyer approve any CLA, but if you get all those adjectives into it, you're off to a good start. When you request CLAs from contributors, make sure to emphasize that you are not asking for actual copyright assignment. In fact, many CLAs start out by reminding the reader of this:

This is a license agreement only; it does not transfer copyright ownership and does not change your rights to use your own Contributions for any other purpose.

Here are some examples: Individual contributor CLAs: apache.org/licenses/icla.txt code.google.com/legal/individual-cla-v1.0.html Corporate contributor CLAs: apache.org/licenses/cla-corporate.txt code.google.com/legal/corporate-cla-v1.0.html Proprietary Relicensing Schemes Some companies offer open source code with a proprietary relicensing schemeThis is sometimes also called dual licensing, but that term is ambiguous, as it has historically also referred to releasing open source software under two or more open source licenses simultaneously. I am grateful to Bradley Kuhn for pointing out this ambiguity and suggesting the more accurate term., in which an open source version of the software is available under the usual open source terms, while a proprietary version is available for a fee. Why would anyone want a proprietary version, when an open source version is already out there? There are two separate answers, reflecting the two different types of proprietary relicensing. The first kind is about selling exceptions to copyleft requirements, and is typically used with code libraries rather than with standalone applications. The way it works is that the library's owner (i.e., copyright holder), seeing that some of the library's users want to incorporate it into their own proprietary applications, sells them a promise to not enforce the redistribution requirements of the open source version's license. This only works when the open source code is under a copyleft-style license, of course — in practice it is usually the GPL or AGPL. With this promise in hand, the downstream users can use the library in their proprietary product without worry that they might be forced to share the source code to the full product under the copyleft license. One well-known example of "selling exceptions" is the MySQL database engine, which is distributed under the GPL version 2, but with a proprietary license offering available for many years, first from the Swedish company MySQL AB, and later from Oracle, Inc, which purchased MySQL AB in 2008. The second kind of proprietary relicensing, sometimes called the freemium model, uses an open source version to drive sales of a presumably fancier proprietary version. Usually the company offering the proprietary version is also the primary maintainer of the open source version, in the sense of supplying most of the developer attention (this is usually inevitable, for reasons we'll get to in a moment). Furthermore, although in theory the company could offer paid support for both the open source and proprietary versions, in practice they almost always only offer it for the proprietary version, because then they can charge two fees: a subscription fee for the software itself and a fee for the support services, with only the latter having any marginal cost to the supplier. You might be wondering: how can the copyright holder offer the software under a proprietary license if the terms of the GNU GPL stipulate that the code must be available under less restrictive terms? The answer is that the GPL's terms are something the copyright holder imposes on everyone else; the owner is therefore free to decide not to apply those terms to itself. In other words, one always has the right to not sue one's self for copyright infringement. This right is not tied to the GPL or any other open source license; it is simply in the nature of copyright law. Proprietary relicensing of both kinds tends to discourage the normal dynamics of open source projects, however. The problem is that any code contributors from outside the company are now effectively contributing to two distinct entities: the free version of the code and the proprietary version. While the contributor will be comfortable helping the free version, since that's the norm in open source projects, she may feel less enthusiastic about her contributions being useable by a monopolized proprietary product — that is, unlike a straight non-copyleft license by which anyone has the right to use the code as part of a proprietary work, here exactly one party controls that right, and other participants in the project are thus being asked to contribute to an asymmetric result. This awkwardness is reflected and in some ways amplified by the fact that in a proprietary relicensing scheme, the copyright owner must collect some kind of formal agreement from each contributor (see earlier in this chapter), in order to have the right to redistribute that contributor's code under a proprietary license. Because such an agreement needs to give the collecting entity special rights that a typical open source contributor agreement doesn't include, the process of collecting agreements means that contributors are starkly confronted with the imbalance of the situation, and some of them may decline to sign. (Remember, they don't need to sign a contribution agreement in order to distribute their own changes along with the original code; rather, the company needs the agreement in order to redistribute the contributor's changes, especially under a proprietary license. Asymmetry cuts both ways.) There is also a deeper motivational issue with open source projects that operate in the shadow of a proprietarily relicensed version: the sense that most of the salaried development attention is going to the proprietary version anyway, and that therefore spending time contributing to the open source version is a fool's game — that one is just helping a commercial entity free up its own developers to work on features that the open source community will never see. This fear is reasonable on its face, but it also becomes a self-fulfilling prophecy: as more outside developers stay away, the company sees less reason to invest in the open source code base, because they're not getting the community multiplier effect. Their disengagement in turn discourages outside developers, and so on. What seems to happen in practice is that companies that offer proprietarily relicensed software do not get truly active development communities with external participants. They get occasional small-scale bug fixes and cleanup patches from the outside, but end up doing most of the hard work with internal resources. Since this book is about running free software projects, I will just say that in my experience, proprietary relicensing schemes inevitably have a negative effect on the level of community engagement and the level of technical quality on the open source side. If you conclude that for business reasons you want to try it anyway, then I hope this section will at least help you mitigate some of those effects. Trademarks 1 Sep 2014: If you're reading this note, then you've encountered this section while it's still being written; see producingoss.com/v2.html for details. Patents Software patents are the lightning rod issue of the moment in free software, because they pose the only real threat against which the free software community cannot defend itself. Copyright and trademark problems can always be gotten around. If part of your code looks like it may infringe on someone else's copyright, you can just rewrite that part. If it turns out someone has a trademark on your project's name, at the very worst you can just rename the project. Although changing names would be a temporary inconvenience, it wouldn't matter in the long run, since the code itself would still do what it always did. But a patent is a blanket injunction against implementing a certain idea. It doesn't matter who writes the code, nor even what programming language is used. Once someone has accused a free software project of infringing a patent, the project must either stop implementing that particular feature, or face an expensive and time-consuming lawsuit. Since the instigators of such lawsuits are usually corporations with deep pockets—that's who has the resources and inclination to acquire patents in the first place—most free software projects cannot afford the latter possibility, and must capitulate immediately even if they think it highly likely that the patent would be unenforceable in court. To avoid getting into such a situation in the first place, free software projects are starting to code defensively, avoiding patented algorithms in advance even when they are the best or only available solution to a programming problem.Sun Microsystems and IBM have also made at least a gesture at the problem from the other direction, by freeing large numbers of software patents—1600 and 500 respectively—for use by the open source community. I am not a lawyer and thus can't evaluate the real utility of these grants, but even if they are all important patents, and the terms of the grants make them truly free for use by any open source project, it would still be only a drop in the bucket. Surveys and anecdotal evidence show that not only the vast majority of open source programmers, but a majority of all programmers, think that software patents should be abolished entirely.See groups.csail.mit.edu/mac/projects/lpf/Whatsnew/survey.html for one such survey. Open source programmers tend to feel particularly strongly about it, and may refuse to work on projects that are too closely associated with the collection or enforcement of software patents. If your organization collects software patents, then make it clear, in a public and irrevocable way, that the patents would never be enforced on open source projects, and that they are only to be used as a defense in case some other party initiates an infringement suit against your organization. This is not only the right thing to do, it's also good open source public relations. For example, RedHat has pledged that open source projects are safe from its patents, see redhat.com/legal/patent_policy.html. Unfortunately, collecting patents for defensive purposes is a rational action. The current patent system, at least in the United States, is by its nature an arms race: if your competitors have acquired a lot of patents, then your best defense is to acquire a lot of patents yourself, so that if you're ever hit with a patent infringement suit you can respond with a similar threat—then the two parties usually sit down and work out a cross-licensing deal so that neither of them has to pay anything, except to their intellectual property lawyers of course. The harm done to free software by software patents is more insidious than just direct threats to code development, however. Software patents encourage an atmosphere of secrecy among firmware designers, who justifiably worry that by publishing details of their interfaces they will be giving technical help to competitors seeking to slap them with patent infringement suits. This is not just a theoretical danger; it has apparently been happening for a long time in the video card industry, for example. Many video card manufacturers are reluctant to release the detailed programming specifications needed to produce high-performance open source drivers for their cards, thus making it impossible for free operating systems to support those cards to their full potential. Why would the manufacturers do this? It doesn't make sense for them to work against software support; after all, compatibility with more operating systems can only mean more card sales. But it turns out that, behind the design room door, these shops are all violating one another's patents, sometimes knowingly and sometimes accidentally. The patents are so unpredictable and so potentially broad that no card manufacturer can ever be certain it's safe, even after doing a patent search. Thus, manufacturers dare not publish their full interface specifications, since that would make it much easier for competitors to figure out whether any patents are being infringed. (Of course, the nature of this situation is such that you will not find a written admission from a primary source that it is going on; I learned it through a personal communication.) Some free software licenses have special clauses to combat, or at least discourage, software patents. The GNU GPL, for example, contains this language: 7. 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. [...] It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. The Apache License, Version 2.0 (apache.org/licenses/LICENSE-2.0) also contains anti-patent requirements. First, it stipulates that anyone distributing code under the license must implicitly include a royalty-free patent license for any patents they might hold that could apply to the code. Second, and most ingeniously, it punishes anyone who initiates a patent infringement claim on the covered work, by automatically terminating their implicit patent license the moment such a claim is made: 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. 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. Although it is useful, both legally and politically, to build patent defenses into free software licenses this way, in the end these steps will not be enough to dispel the chilling effect that the threat of patent lawsuits has on free software. Only changes in the substance or interpretation of international patent law will do that. To learn more about the problem, and how it's being fought, go to endsoftpatents.org/. The Wikipedia article en.wikipedia.org/wiki/Software_patent also has a lot of useful information on software patents. I've also written a blog post summarizing the arguments against software patents, at www.rants.org/2007/05/01/how-to-tell-that-software-patents-are-a-bad-idea/. Further Resources This chapter has only been an introduction to free software licensing issues. Although I hope it contains enough information to get you started on your own open source project, any serious investigation of licensing issues will quickly exhaust what this book can provide. Here is a list of further resources on open source licensing: Understanding Open Source and Free Software Licensing by Andrew M. St. Laurent. Published by O'Reilly Media, first edition August 2004, ISBN: 0-596-00581-4. This is a full-length book on open source licensing in all its complexity, including many topics omitted from this chapter. See oreilly.com/catalog/osfreesoft/ for details. Make Your Open Source Software GPL-Compatible. Or Else. by David A. Wheeler, at dwheeler.com/essays/gpl-compatible.html. This is a detailed and well-written article on why it is important to use a GPL-compatible license even if you don't use the GPL itself. The article also touches on many other licensing questions, and has a high density of excellent links. creativecommons.org Creative Commons is an organization that promotes a range of more flexible and liberal copyrights than traditional copyright practice encourages. They offer licenses not just for software, but for text, art, and music as well, all accessible via a user-friendly license selector; some of the licenses are copylefts, some are non-copyleft but still free, others are simply traditional copyrights but with some restrictions relaxed. The Creative Commons web site gives extremely clear explanations of what it's about. If I had to pick one site to demonstrate the broader philosophical implications of the free software movement, this would be it.