This essay argues that developers of Free-libre / open source software (FLOSS, aka OSS/FS) should use an existing widely-used license compatible with the General Public License (GPL), particularly the GPL, LGPL, MIT/X, or BSD-new licenses. It also argues against FLOSS license proliferation; where possible, you should only select FLOSS licenses from that list (with the possible addition of Apache 2.0). 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 Free-libre / open source software (FLOSS, aka FOSS or OSS/FS). Developers: Please, where possible, use an existing widely-used (standard) license for your software, one that is known to be compatible with the GNU General Public License (GPL). In particular, please select the GPL, LGPL, the MIT/X, or BSD-new license (or possibly the Apache 2.0 license). If you create your own license - and please try very hard to not create a new license - at least 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 FLOSS software’s license is GPL-compatible, i.e., that you can combine your code with code released under the GPL into one larger program, and select one of the “standard” FLOSS licenses. The rest of this essay explains why and how to do so.
Why a GPL-compatible license? Because if your FLOSS 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 FLOSS 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), ITPro’s “Strip Mining of Open Source”, and 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. Linus Torvalds' BBC interview explains why some developersa and organizations like the GPL (in his case version 2), as he believes it "is a very simple 'tit-for-tat' model: I'll give you my improvements, if you promise to give your improvements back. It's a fundamentally fair licence, and you don't have to worry about somebody else then coming along and taking advantage of your work. And the thing that then seemed to surprise people, is that that notion of 'fairness' actually scales very well... if your competition doesn't put in the same kind of effort that you do, then they can't reap the same kinds of rewards you can: if they don't contribute, they don't get to control the direction of the project, and they won't have the same kind of knowledge and understanding of it that you do". 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 FLOSS developers (e.g., see Montague). The paper "Copyright vs. Copyleft Licensing and Software Development" (Massimo D'Antoni and Maria Alessandra Rossi) developed a theoretical model and found that, according to their model, "1. the GPL is better suited than the BSD to coordinate and encourage joint effort[s] by many (possibly small) developers [e.g., end-user application development]; while 2. the BSD is better suited than the GPL to generate positive spillovers to other developers, when no feedback is required [e.g., standard-setting]."
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 FLOSS 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 FLOSS projects have undergone often-painful changes to make themselves GPL-compatible, and the same is true for organizations that write licenses:
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, which they had used earlier in the Solaris release. When gaining confidence of a community mattered, a GPL-compatible license was chosen.
Here’s more evidence: Some projects who tried to switch from a GPL-compatible license to a GPL-incompatible license have been forked, with their original leaders essentially removed from office. A “fork” is an attempt to create a competing project by copying from an existing project and convincing developers and users to switch to the competing project instead. Forks in the FLOSS world are essentially like a “vote of no confidence” in a parliament. The ability to have a fork is an important safeguard in FLOSS, because the ability to fork prevents leaders from becoming tyrannical. But forks rarely succeed; the situation has to be remarkably bad to cause the overwhelming majority of developers and distributors to switch to something else. (I am not talking about version control branches, which are sometimes called forks especially with git; there has to be an intent to cause people to stop using the previous project, and switch to the new project instead. Rick Moen has an article about forking, if you want more details.) Yet there have been successful forks caused because the project lead attempted to impose a GPL-incompatible license on others. That’s compelling evidence that GPL-compatibility is critically important to other developers and users.
XFree86 is perhaps the best-known example of a fork caused by an attempt to change licenses. 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 in 2004 to one that wasn’t GPL-compatible, primarily to give developers more credit. The problem wasn’t giving credit; the problem was GPL incompatibility. This attempted change led to a mass exodus from XFree86, as nearly all developers and users immediately abandoned XFree86. 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.
More recently, in 2011 the US Department of Justice and the German Federal Cartel Office directed CPTN (a holding company owned by Microsoft Inc., Oracle Corp., Apple Inc. and EMC Corp.) had to change how they acquired Novell’s software patents so that the open source community is protected, and in particular, the Wall Street Journal reported that the “all of the patents acquired will be subject to the GNU General Public License (GPL)”. This makes it appear that one requirement will be that patents must be granted for use to any program released under the GPL... but perhaps not for programs not compatible with the GPL.
There are many GPL-incompatible licenses that you should avoid releasing software under if at all possible. Here are some examples:
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 a FLOSS 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 FLOSS 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 FLOSS 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.
Indeed, the proliferation of FLOSS licenses in general has been identified by many as a problem to be resolved. It was an issue noted in HP Vice President Martin Fink’s LinuxWorld 2005 address, and others supported this view such as Groklaw. Customers find a long list of licenses completely bewildering; it’s hard to figure out what can be legally combined, and corporations can easily find themselves spending huge sums of money on legal advice if they have to start to examine more than the top few licenses. As noted in Serdar Yegulalp’s “The Open Source Licensing Implosion” (InformationWeek, Aug 8, 2008), “It’s not just that there are “too many open source licenses,” but that the consequences for blithely creating new ones are finally becoming concrete... It was easier to get away with a broad proliferation of licenses back when open source was still a relatively rare and exotic variety of bird in the software bestiary. Now that open source is becoming (gasp) a mainstream phenomenon, using one of the less-common licenses or coming up with one of your own works against you more often than not... It’s not the programmers that will determine what open source licenses are the best -- it’s the software consumers. They’ll be the ones narrowing down the forest of licensing to a few well-pruned and -maintained trees. The better for us all not to get lost amongst them.”
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.”
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. They also specifically consider if a license is GPLv2 and GPLv3 compatible, clearly demonstrating the importance of GPL compatibility.
Fink’s complaint did cause some improvement, e.g., Intel publicly abandoned its own FLOSS license so standard licenses would be used instead. The Open Source Initiative’s License Proliferation Committee Report, a group kicked off after Fink’s comments, 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. Their full list, as of 2006-09-19, was Apache License 2.0, new and simplified BSD licenses, GPL, LGPL, MIT, MPL, CDDL, CPL 1.0, and Eclipse Public License (EPL). Even this list is overlong; the MPL, CDDL, CPL, and EPL have a vanishingly small numbers of projects that use them.
Similarly, John Cowan’s FLOSS license wizard (as of August 2008) only recommends a few FLOSS licenses, depending on your purposes. The only FLOSS licenses it will recommend are the GPLv3, LGPLv3, revised BSD, and Apache 2.0 licenses.
On August 14, 2008, I did a quick check of Google Code, and found that they only permit the following licenses: Apache 2.0, Artistic/GPL, GPLv2, GPLv3, LGPL, MIT, and new BSD. Note that all of them are GPL-compatible (Apache 2.0 is only compatible with GPLv3 though not GPLv2). As noted above, they once accepted the GPL-incompatible MPL 1.1, but no longer.
InformationWeek’s “The Open Source Licensing Implosion” of August 2008 correctly notes that “the consequences for blithely creating new [FLOSS licenses] are finally becoming concrete [for many]... the vast majority of open source products out there use a small handful of licenses... The rest tend to be outriders or derivatives... It was easier to get away with a broad proliferation of licenses back when open source was still a relatively rare and exotic variety... Now that open source is becoming (gasp) a mainstream phenomenon, using one of the less-common licenses or coming up with [your own license] works against you more often than not... [communities will be concerned] if you’re using a license that hasn’t been given a public shakedown of sorts... software consumers [will narrow] down the forest of licensing to a few well-pruned and -maintained trees. The better for us all not to get lost amongst them.”
While it’s possible to relicense FLOSS 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 FLOSS 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 FLOSS 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 especially attractive to many developers. The GPL is easy to comply with (it doesn’t even require money to do so), but people do need take its (few) 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. “Enforcement of the GNU GPL in Germany and Europe” by Till Jaeger shows that the GPL is quite enforceable there. More recently, in June 2013 the German Regional Court of Hamburg [Landgericht Hamburg] found FANTEC GmbH guilty of violating the GNU GPL in their media player FANTEC 3DFHDL. 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.
More generally, there is increasing evidence that FLOSS licenses really are enforceable. Robert A. Guth’s “Ruling Bolsters Open-Source Software: A Licensing Agreement Is Declared Enforceable Under Copyright Law” (Wall Street Journal, August 14, 2008; Page B6) reported that the Court of Appeals for the Federal Court ruled in August 2008 that another license (the Artistic License) was enforceable under copyright law. This supported “a basic tenet behind open-source software and other creations that the general public is allowed to freely modify and distribute... Some legal experts said the ruling could help support the legal underpinnings of other open-source projects. ‘It’s a clear statement that if someone doesn’t follow the conditions you put into an open- source license, you have a copyright claim,’ said Wendy Seltzer, a fellow at the Berkman Center for Internet & Society at Harvard Law School.” Here’s the ruling; here is Bruce Perens’ summary. "Why the GPL licensing cops are the good guys" by Simon Phipps (InfoWorld, June 1, 2012) explains for most people (like most enterprises) following the GPL is a non-problem, but those who develop and distribute software (e.g., electronics manufacturers) do need to pay attention to (and follow!) the license... and that people who develop GPL'ed software are successfully defending their rights.
But the GPL’s wide use also makes it easy to find help in how to comply with it. The Software Freedom Law Center’s “A Practical Guide to GPL Compliance” shows the simple steps that nearly all organizations can easily apply so they can stay compliant. The rules are actually pretty simple.
As a related issue, copyrighted works other than software (such as documentation) should be released under a standard license if you intend for it to be freely reusable. Years ago, it wasn’t clear what that license would be; open content licensing was a mess.
However, as of 2009, it appears that the emerging common “consensus” license for copyrighted works other than software is the Creative Commons (CC) Attribution-Share Alike (CC-BY-SA) license. So, make sure that the CC-BY-SA license (unported version 3.0), or a license compatible with it, is one of the licenses you use to release freely reusable material.
Historically, Wikipedia and related projects were released under the GNU Free Documentation License (GFDL), but as of May 2009 Wikipedia switched to using the CC-BY-SA license as its primary license. Most Wikipedia material is now dual-licensed (it is available under both the GFDL and CC-BY-SA license), but the CC-BY-SA is the only license that applies to all of its material. One rationale for making this change was that: “Without the change, we could not share text with projects that use the Creative Commons Attribution/Share-Alike Licenses. The Creative Commons licenses are used by hundreds of thousands of authors world-wide (see statistics), having quickly become the most widely used legal tool to release rights on works other than software. This interoperability barrier with other non-profit organizations and online communities who share knowledge freely is therefore counter to Wikimedia’s mission.” It’s interesting to note that Richard Stallman and the FSF, the author of the GFDL, specifically worked to make this change possible.
In 2009, Fedora did a massive relicense (including the Fedora wiki and guides) to CC-BY-SA, saying, “Why? Because it is vital that Fedora get off a content island and join the rest of the world... To be honest, this change is probably a bit overdue”. Some of the reasons given were:
Again, there’s no requirement that CC-BY-SA be the only such license, but in nearly all cases it is unwise to use a license that is not compatible with the common standard license... for all the same reasons as apply to software. For example, there are lots of negatives to using the GFDL, the OPL, or the various Creative Commons “non-commericial” (-NC) licenses (for more on the latter, see The Case for Free Use: Reasons Not to Use a Creative Commons -NC License) if your goal is to enable use of others’ work and future reuse of your work. In short, by using a standard license, or a license compatible with one, your work can use and be combined with others’ work.
It’s interesting to note that an open textbook bill has been introduced by Senator Durbin. These suggest we will be seeing a lot more open content in the future.
So, how can you do this? You can do this by releasing your copyrighted work under CC-BY-SA as at least one of its licenses. You can also do this by releasing it under a compatible license, such as the CC-BY (Creative Commons-Attribution) license and the CC0 license (CC0 is essentially a release to the public domain, in a way that is legally meaningful in all jurisdictions).
A similar problem happens with fonts. Red Hat commissioned development of the "Liberation" fonts, and Bitstream created the Bistream Vera font family - but because their licenses were peculiar, and there was no effort to create a community to improve them (e.g., for internationalization), these fonts are being supplanted by other fonts with more standard licenses and supportive communities.
Now, getting back to software...
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 FLOSS 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.
If you choose the GPL, 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 FLOSS software is GPL-compatible, and that you use one of the few standard FLOSS licenses (GPL, LGPL, BSD-new, MIT, and possibly the Apache 2.0 license). Otherwise, your FLOSS project may never have the support you hoped for.
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.”
Most forks get little support and soon die, but 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 FLOSS ) 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 FLOSS 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.
If you are using or modifying software released under the GPL, look at The Software Freedom Law Center (SFLC)’s A Practical Guide to GPL Compliance. As noted in How the GPL is enforced, a depressing number of companies simply take GPL-licensed software and use it in ways not permitted by the license, even though they sell products with far more complex licenses that they expect their users to follow. “The numerous cases in recent times... all followed the same pattern: a manufacturer uses GPL-licensed software in his device firmware, but neither advises device purchasers of their rights to the software, nor gives them access to the source code, as the GPL requires. An offender is initially contacted directly, without publicity, and an attempt is made to settle the matter amicably... [and if one is not reached, a complaint is made and] in the end there’s usually an agreement and no court verdict... All of the agreements look very similar: the company admits the infringement, retrospectively informs its customers, has to appoint a responsible person to prevent any future infringements of the GPL, and pays compensation... Companies really shouldn’t fall into the trap again and again... [because guidance like the SFLC’s is available].”
There are a large number of FLOSS 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. FOSSology is a FLOSS tool that reports licenses identified in source code.
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 FLOSS 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 or FLOSS)? 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 FLOSS 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
https://dwheeler.com
for additional evidence of this.
|
|