This essay argues that developers of open source software / Free Software (OSS/FS) should use an existing widely-used license compatible with the General Public License (GPL), such as the GPL, LGPL, MIT/X, or BSD-new licenses. This article was previously printed, with a number of changes, as an article at OsOpinion.
This essay is a call to all those developers who are developing open source software / Free Software (OSS/FS, also called FLOSS or FOSS). OSS/FS developers: Please, where possible, use an existing widely-used license for your software that is known to be compatible with the GNU General Public License (GPL), such as the GPL, LGPL, original MIT/X, or BSD-new licenses. And, if you create your own license - and please try not to - make sure that your new license is compatible with the GPL. You don’t need to use the GPL - not even the Free Software Foundation (FSF), the developer of the GPL and its most avid proponent, claims that absolutely all software must be GPL-licensed. (For example, see the endorsement by FSF’s Richard Stallman of Ogg Vorbis license changes, and note that the FSF developed and maintains the Lesser GPL as a compromise license.) But make sure that your OSS/FS software’s license is GPL-compatible, i.e., that you can combine your code with code released under the GPL into one larger program. The rest of this essay explains why and how to do so.
Why a GPL-compatible license? Because if your OSS/FS project isn’t GPL-compatible, there’s a significant risk that you’ll fail to receive enough support from other developers to sustain your project.
Many OSS/FS developers prefer the GPL, because they believe the GPL (1) provides a better quid-pro-quo for developers, (2) establishes collaboration between people and companies better than consortia, (3) protects their work in today’s less-than-kind environment, and/or (4) encourages increasing the amount of Free Software. Examples of such thinking include Jeremy Allison's "Freedom Fighters" (which points out that NetApp's improvements to BSD-licensed code are not contributed back but its improvements to GPL-licensed code have been), as well as Eben Moglen's claims that BSD-style licenses are "a really good license for your competitor to use". Moglen's point is that he believes a business should use a license which requires others to give back their changes (like the GPL) if it does not want to provide a free lunch to its competitors. Many people argue for the GPL, though the view that the GPL is a good or necessary license is not a universally-held position by OSS/FS developers (e.g., see Montague).
But even if you don’t like the GPL yourself, many potential co-developers do... and your project is more likely to be successful if you accommodate them. Usually even avid GPL proponents will support OSS/FS programs with other GPL-compatible licenses, if you choose to not use the GPL. For example, the FSF has long supported the X Window System (X11), even though it’s released under the MIT/X license. However, if your license isn’t GPL-compatible, developers may create a competitor instead so they can take advantage of GPL’ed code.
And there’s a lot of GPL’ed code to take advantage of:
Karl Fogel's "Producing Open Source Software: How to Run a Successful Free Software Project says that "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 - you should pick a GPL-compatible license."
You ignore this amount of code and support at your project’s peril.
Want more evidence that GPL compatibility is important? Several large, high-profile OSS/FS projects have undergone painful changes to make themselves GPL-compatible:
Multiple major projects don’t undergo painful license changes unless they have a reason to do so. The GPL is so popular that GPL compatibility is now an important requirement in a license. Eirik Eng, president of Trolltech (owner of Qt), explained Trolltech’s actions by saying, “lately the GPL has been used more and more for newly opened source [software].” The article "Replacing init with Upstart" notes that when the authors were starting their "Upstart" project, they looked at existing systems as a starting point, and Sun's SMF and Apple's program 'launchd' "were immediately ruled out due to licence issues. It was important for us that the solution be uncontroversially free so that other distributions might adopt it; many had already rejected these for GPL incompatibility reasons."
Sun’s Solaris operating system was released under the CDDL, a GPL-incompatible FLOSS license. Sun has every right to release their software under whatever license they choose (within the law), of course. However, Groklaw’s 2005 article “Sun Responds to Criticism of CDDL” states that because the CDDL is not GPL-compatible, Sun will not gain the community support it hopes to garner from using the CDDL. The article predicts that “The result will be, though, that Linux will continue to develop more quickly and it will bury Sun’s license and its code... Sun is free to cut itself off from that, if it so chooses, but it will reap what it sows. If they imagined that the world would drop the GPL and adopt the CDDL instead, I trust by now they realize that isn’t going to happen... I seriously doubt that any license that is GPL/LGPL incompatible will be widely adopted.” Which was a remarkably accurate prediction. In 2008, Theodore Ts’o noted that "Open Solaris [has failed to develop] an Open Source development community... from a business standpoint, I wonder if Sun will really be able to sustain their Solaris engineering team if they will really be doing all of the work themselves... With Linux, we have a major advantage in that kernel improvements are coming from multiple companies in the ecosystem, instead of being paid for by a single company... it’s not clear how Sun justifies their Solaris engineering costs to their shareholders." Indeed, Emily Ratliff did a few calculations and found that "Linus [Torvalds] gets more patches [for Linux] while he is brushing his teeth than OpenSolaris gets in a week". Solaris' failure to gain a wider development community became a major Slashdot discussion topic in April 2008 when Roy Fielding resigned. This failure to gain a community is certainly caused by more than licensing issues, but license incompatibilities appear to be part of the story, as Michael Dolan notes in 2008.
In November 2006 Sun announced that they would be releasing their implementation of Java. The license? The GPL, along with a few LGPL-like-exceptions for their library - and not the CDDL.
There’s also recent evidence that GPL compatibility is important from one project that’s tried to go from GPL-compatible to GPL-incompatible: XFree86. The XFree86 project historically led development of a popular X server, and traditionally the vast majority of its code used the simple “MIT/X” open source license that is GPL-compatible. The XFree86 president, David Dawes, decided to change the XFree86 license to one that wasn’t GPL-compatible, primarily to give developers more credit. In the end, this change led to a mass exodus, as nearly all developers and users immediately abandoned XFree86, because of this attempt to switch to a GPL-incompatible license. See my appendix on XFree86 for more detailed information about this.
Samba's Volker Lendecke stated that any European Commission remedies involving Microsoft's release of data would require the use of a GPL-compatible license. So even data releases - not just software code - are being examined to see if they are GPL-compatible.
There are many GPL-incompatible licenses that you should avoid releasing software under if at all possible. We've already mentioned the CDDL; here are some others:
All advertising materials mentioning features or use of
this software must display the following acknowledgement:
This product includes software developed by the University of
California, Berkeley and its contributors."
This made it incompatible with the GPL, as well as introducing
practical problems
noted by the FSF.
The problem is that when code is merged together (and it is), and everyone
adds their own name (they did), people couldn't advertize without
listing potentially hundreds of people - making this completely
clause impractical as software scaled.
In June 1999, after two years of discussions, the
University of California removed this clause from the license of BSD.
Thus, this is an obsolete license that should no longer be used; use licenses
such as the "new BSD" aka "modified BSD" or "3-clause BSD" license instead.
There are reasons for an OSS/FS project to be GPL-incompatible, but weigh any such notions with an extremely critical eye. Sometimes a program or library was originally proprietary, and can only be released as OSS/FS under GPL-incompatible conditions. If so, the code had better be good and essentially complete when it’s released, because many developers won’t get involved with it. Many OSS/FS projects are already saddled with a GPL-incompatible license, and it’s just too hard to change. Some include other requirements they believe are critical, such as adding more patent clauses for licenses, defense, or mutual termination (such as the IBM public license).
But remember that these supposed benefits may not outweigh their many disadvantages. Note all the projects listed above that switched from a GPL-incompatible license to a GPL-compatible one. An example of the problems - in fact, one of the more important ones - is that the OpenSSL license is widely viewed as being GPL-incompatible (including by FSF lawyers, GNOME, and Debian, based on detailed independent analysis). While the OpenSSL developers claim it’s GPL-compatible and “support” the use of OpenSSL by GPL’ed software, the legal minefields are such that OpenSSL often has to worked around, or abandoned by switching to a different program (as CUPS did). The usual alternatives for OpenSSL are Mozilla Network Security Services (NSS) and GNU Transport Layer Security (GNU TLS).
Indeed, the proliferation of OSS/FS licenses in general has been identified by many as a problem to be resolved. It was an issue noted in Fink’s LinuxWorld 2005 address, and others supported this view such as Groklaw. This is not a new observation; Bruce Perens noted back in 1999, “Do not write a new license if it is possible to use one of the ones listed here. The propagation of many different and incompatible licenses works to the detriment of Open Source software because fragments of one program cannot be used in another program with an incompatible license.” Eric S. Raymond’s Software Release Practice HOWTO strongly states (as a heading!) “don’t write your own license if you can possibly avoid it,” and he suggests that developers use “one of the standard licenses carried on the OSI site if at all possible.” The Open Source Initiative's License Proliferation Committee Report recommended addressing this by categorizing licenses; unsurprisingly the category "Licenses that are popular and widely used or with strong communities" included the MIT/X, BSD-new, LGPL, and GPL licenses. If you doubt that license proliferation can be a problem, just look at Fedora's Licensing Guidelines and Fedora's Licensing page - they are setting up complex licensing documentation that can be electronically recorded and analyzed, just to assure license compliance.
While it’s possible to relicense OSS/FS software to make it GPL-compatible, it can be quite difficult -- you’re much better off avoiding a mistake, and starting off GPL-compatible in the first place. Changing licenses usually requires approval of the relicensing from every copyright holder and a rewrite of the code where the approval wasn’t granted. When OSS/FS projects get large this is incredibly difficult, because after many years it’s often impossible to contact all of the contributors. Thankfully, many projects don’t have to endure this transformation, because they’ve avoided it to start with. The W3C, for example, explicitly states that all its software releases are OSS/FS and are compatible with the GPL. This statement shows that they believe GPL compatibility is very important, and this policy eliminates the problems that would come from GPL incompatibility.
It's worth noting that the GPL has a very strong legal basis, which is attractive to many people. The GPL is easy to comply with (it doesn't even require money to do so), but people do take its requirements seriously. Eben Moglen is a lawyer who's been enforcing the GPL for years, and has excellent evidence that the GPL really is enforceable. He also explain's the GPL's legal basis, which turns out to be very strong. Paralegal Pamela Jones has written another explanation of the GPL's legal basis for laymen; as both note, the GPL is a license, not a contract, which makes it unusually easy to enforce. "Taking the Case: Is the GPL Enforceable?" by Jason B. Wacha (General Counsel, MontaVista Software) is a detailed legal analysis by a lawyer showing that "the GPL is an enforceable agreement." A German court has found that the GPL is legally enforceable, for the very reasons Moglen and Jones stated. This was in response to some enforcement actions by netfilter. In 2006, a U.S. court found that the GPL was quite legitimate; Daniel Wallace tried to invalidate the GPL in Daniel Wallace vs. Free Software Foundation, and not only was Wallace's suit dismissed, but Wallace was ordered to pay costs as well. In this case, the judge (John Daniel Tinder, United States District Court) also declared that "[T]he GPL encourages, rather than discourages, free competition and the distribution of computer operating systems, the benefits of which directly pass to consumers. These benefits include lower prices, better access and more innovation." This was appealed, and the U.S. Court of Appeals (7th circuit) formally ruled in 2006 that the GPL does not violate U.S. antitrust rules, and that "the GPL and open-source software have nothing to fear from the antitrust laws" - creating an even stronger defense against future cases. The proven legal strength of the GPL is attractive to many people who must choose a license for their open source software. But this strength comes from taking its requirements seriously - which means that people must take incompatibility seriously too.
So, how do you make sure that your software is GPL-compatible? Fortunately, there are three easy ways to do this:
If you’re considering the BSD-new license, Bruce Perens, the FSF, and I recommend using the MIT/X license instead (the FSF calls this the X11 license). There are several reasons to prefer the MIT/X license over BSD-new. First, MIT/X is much simpler, a good thing in a license. Second, a few non-lawyers have claimed that BSD-new isn’t GPL-compatible; I don’t think this is a real issue, but is instead a misunderstanding of the law, since expert lawyers on the topic from both Red Hat and the Free Software Foundation have refuted this claim. Finally, there isn’t the confusion of having two different common licenses with the same name.
You can use another pre-existing license known to be GPL-compatible, though using an unusual license risks causing developers to not support your project (some developers won’t want the risk and trouble of working under an unfamiliar and unusual license). My FLOSS License Slide shows how several common licenses are compatible (or not).
If you can’t use any of these easier approaches, then it’s still possible to use a GPL-compatible license, but at that point you need a lawyer’s help - and in general I do not recommend it. That's because license analysis can quickly become very complicated. For example, the FSF developed the GPL and maintains a list of licenses that it believes to be compatible and not compatible with the GPL. Note the number of subtle points brought out in their analysis! My point isn’t to debate their legal analysis (which not everyone agrees with); I just want to show that determining GPL compatibility can be complicated, so there are excellent reasons to keep things simple. Some advice is available from the FSF, but since they may not be the owners of the software, there may be more room for disagreement than you might think. And in addition, when revisions of the GPL are released, new problems are likely to arise. It is likely to be much more difficult to upgrade licenses if you have an odd one-off license. In short, the best way to make a program GPL-compatible is to keep things simple.
If you’re submitting changes to an existing OSS/FS project that uses a GPL-incompatible license, include a note in your submission that you’re dual-licensing your changes with a GPL-compatible license (such as the GPL, LGPL, or MIT/X license); that will make it much easier for the project to dual-license the entire program later.
If you release software under the GPL (solely or as a dual-license), you should include the "version X or later" clause as recommended in the GPL itself and used by nearly all GPL users. Using the "version X or later" phrase makes transition to updated GPL text really easy, and guarantees future compatibility as the GPL gets updated and clarified as new situations arise. Other text in the GPL limits what those later versions will say, and new versions of the GPL cannot decrease what you can do with the original work. Most proprietary licenses of today have clauses anticipating changes in terms as years go by - adding "or later" is just a different way to do it. A few companies just cannot bring themselves to say 'version 2 or later' though; in such cases, they should designate a proxy who will be authorized to release the code under a later version of the license as those new versions become available, and establish a process to examine the later versions and give permission once review determines it's okay. But I believe the "version X or later" approach is really the better approach if you choose to use the GPL; the whole point of the GPL is to ensure that you can gain access to later improvements to a program, and GPL revisions are created specifically to protect against attacks on that access.
Which version of the GPL should be your base? For many years, GPL version 2 was the only real choice, but in 2007 GPL version 3 was released. GPL version 3 has a number of improvements if your goal is to ensure that recipients can modify their software; for example, it eases international enforcement (by changing U.S.-centric terms to broader terms), adds better patent defenses, is compatible with more licenses (in particular the Apache Public License and the Affero GPL), and counters "Tivoization" (users must be able to modify GPL'ed software they receive). More detailed commentary on GPLv3 is available, including those by Glyn Moody, Mark Radcliffe, and Luis Villa. Palamida is tracking which projects are updating to GPL version 3, a process which seems to be going well. "GPL version 2 or later" gives maximum compatibility, but since nearly all projects have the "or later" clause, it isn't really much more compatible than "GPL version 3 or later" for most people. I expect that there will be a gradual migration of many projects from "GPL version 2 or later" to "GPL version 3 or later". So for most projects, "GPL version 3 or later" is probably the best choice, since it lets you take advantage of the GPL version 3 improvements.
In short, make sure that your OSS/FS software is GPL-compatible, or your OSS/FS project may never have the support you wanted.
If you’re looking for a cautionary tale of how things can go badly because of a GPL-incompatible license, you need look no further than the tragic story of XFree86’s demise. The XFree86 project historically led development of a popular X server, and traditionally the vast majority of its code used the simple “MIT/X” open source license that is GPL-compatible. At one time, if you used a Unix-like system and a graphical user interface, you were very likely to be using XFree86... that’s how widespread it was.
The XFree86 president, David Dawes, decided to change the XFree86 license to one that wasn’t GPL-compatible, primarily to give developers more credit. This proposed license change caused a serious uproar. Jim Gettys, a well-respected developer and co-founder of X, strongly opposed this change to the XFree86 license, even though he’s not a strong advocate of the GPL. Richard Stallman asked that something be worked out. An article at Linux Today and a discussion at Freedesktop.org showed that Red Hat, Debian, SuSE, Gentoo, Mandrake, and OpenBSD planned to drop XFree86 if they switched to this new license.
Not all parties objected because of GPL incompatibility; OpenBSD’s Theo de Raadt’s objection was that the new license made the code “less free”, rather than specifically about GPL compatibility. But many others specifically protested this proposed change on the grounds that a GPL-incompatible license is unacceptable. Branden Robinson performed a detailed XFree86 license analysis (available from the mailing lists of XFree86 and The Open Group; a shorter version was posted by Debian). In this detailed analysis, he pleaded that XFree86 repair the few licensing problems currently in the code base and keep the program GPL-compatible, saying, “The path to clearing away GPL-incompatibilities due to the BSD advertising clause for the entire XFree86 source tree (as of XFree86 4.3.0, anyway) seems fairly short. Given that, it seems a shame to entrench a similar incompatibility both broadly and deeply.” The XFree86 mailing list from February 2004 includes many statements from individuals stating that GPL compatibility is important to them.
Since the XFree86 folks wouldn’t switch to a GPL-compatible license, the X.Org Foundation (formed January 2004) announced its own version of X on April 6, 2004. One of its key enhancements was that “only files without the new XFree86 1.1 license are included in the X11R6.7.0 release.” The X.org foundation home made it even clearer that GPL compatibility was the key problem; it says that “The X.Org repository is based on XFree86 4.4 RC2. Just before its 4.4 release, XFree86 adopted a new license possibly incompatible with the GPL. For this reason, we have recreated its tree as closely as possible without importing files affected by the new license.”
Unlike most forks, which get no or lukewarm support, the X.Org foundation fork was immediately endorsed by many key organizations, including Novell’s SUSE, Red Hat, HP, TrollTech, and FSF Europe among others. FreeBSD later left XFree86, and as noted above, the leader of OpenBSD had already stated that he did not support XFree86’s approach. By July 2004, Linux Weekly News (LWN) could honestly report that nearly all XFree86 developers had switched over to the new GPL-compatible fork, leaving XFree86 mostly dead. The primary discussion topic in the new fork’s mailing list was what new features and design improvements should be made first, with the presumption that whatever XFree86 did was irrelevant. The transition was swift, and can be shown by examining the “XFree86 forum” mailing list; the June 2003 archive of this list had 20 messages about XFree86 (plus 13 irrelevant spam), and all 20 were technical discussions related to improving the program. By June 2004 there were only 13 relevant postings in the whole month (plus 62 spam messages), and instead of being all technical discussions, many of those messages were acknowledgements between list members that XFree86 had been abandoned by most of its developers and users or were a discussion about how FreeBSD might possibly stay with XFree86 (FreeBSD later left XFree86, quashing this hope). For example, William M. Quarles re-posted an instant messaging conversation stating that “Most of the major distributions have either left XFree86 behind and switched to X.org, or are [still] using XFree86 4.3 [the old unmaintained version].”
Now it’s true that there were more issues than GPL incompatibility. There had been various calls for restructuring the organization of developers, and for opening up (and speeding up) development. But none of those issues caused a sudden exodus of developers and users. All projects (proprietary and OSS/FS) have discussions about their structure and progress, and rarely do they lead to an immediate abandonment by all users and developers at once. The issue (or at least the final straw) that caused the mass exodus by users from XFree86 was the effort to switch to a GPL-incompatible license. It’s clear that trying to switch a popular OSS/FS program from a GPL-compatible license to a GPL-incompatible license can be met with stiff and swift resistance.
There are many information resources about the GNU General Public Licence (aka GPL). The GPL itself is available on-line. The GPL Frequently Asked Questions (FAQ) has more information from its author. Groklaw maintains a page of resources about the GPL. Mitchell L. Stoltz's "The Penguin Paradox: How the Scope of Derivative Works in Copyright Affects the Effectiveness of the GNU GPL, 85 B.U. L. Rev. 1439 (2005) discusses the GPL and the law's definitions of derivative works.
There are a large number of OSS/FS licenses that exist, though the vast majority of software is covered by the five most common ones. Some are "protective", like the GPL or Affero GPL - they work to protect the software from being turned into a proprietary product, including as part of a larger work. Some are "permissive", such as the BSD-new and MIT/X license; they permit turning the program into a proprietary work. and some licenses like the LGPL are compromises between "protective" and "permissive" - the LGPL, for example, protects the component (usually a library) but permits its insertion into a larger proprietary work. The FSF maintains a list of licenses and some analyses of them. The Open Source Initiative's license list lists licenses that it has determined are open source software licenses.
The Free Software Foundation (FSF) advocates use of the GNU General Public License (GPL), but even they gladly accept the use of software not under the GPL as part of their GNU project.
The following are "GNU packages" not under a copyleft license:
|
David A. Wheeler enjoys
learning and writing about OSS/FS and IT security,
and spends far too much of his spare time on them.
He is the author of papers such as
Why
Open Source Software / Free Software (OSS/FS)? Look at the Numbers!,
How to Evaluate Open Source Software/Free Software (OSS/FS) Programs,
Open Source Software (OSS) in U.S. Government Acquisitions,
FLOSS License Slide,
Open Source Software/Free Software (OSS/FS) References, and the
Secure Programming
for Linux and Unix HOWTO.
He has also developed several OSS/FS programs such as
flawfinder and
sloccount.
He also plays the piano and guitar.
It is rumored that he doesn’t actually sleep, which would explain a lot.
You can see his web page at
http://www.dwheeler.com
for additional evidence of this.
|
|