Make Your Open Source Software GPL-Compatible. Or Else.

by David A. Wheeler

Released 2002-05-06, revised 2014-02-16

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.

GPL-incompatible licenses risk lack of support (GPL most popular)

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:

  1. (now reported on November 10, 2003 that 69.66% of the 32,592 software branches (packages) it tracked are GPL-licensed (the next two most popular licenses were the LGPL, 5.29%, and the BSD licenses which combined to 4.82%). Some Freshmeat branches are proprietary, but clearly the GPL is the leading FLOSS license in this set. You can also see the latest statistics.
  2. reported on November 10, 2003 that the GPL accounted for 71% of the 45,736 projects it hosted with OSI-approved open source licenses (next most popular were the LGPL, 10%, and the BSD licenses, 7%). Not all SourceForge projects are active or have produced much code, but nevertheless this gives reasonable evidence that the GPL is widely used. You can also see the latest statistics. Another way to get SourceForge statistics - and many others - is through FLOSSmole. FLOSSmole is a tool for querying data about FLOSS repositories, and they make it easy to analyze data from many sources.
  3. In my paper More than a Gigabuck: Estimating GNU/Linux’s Size, I found that Red Hat Linux, one of the most popular GNU/Linux distributions, had over 30 million physical source lines of code in version 7.1, and that 50.36% of the lines of code were licensed solely under the GPL (the next most common were the MIT license, 8.28%, and the LGPL, 7.64%). If you consider the lines that are dual licensed (licensed under both the GPL and another license, allowing users and developers to pick the license to use), the total lines of code under the GPL accounts for 55.3% of the total.
  4. Savannah hosts 1,986 mostly-GPL projects (as of November 11, 2003) and strongly encourages GPL-compatible licenses.
  5. The FSF’s free software directory lists FLOSS software. On September 24, 2002, I downloaded their entire directory, and found that it had 1550 entries, of which 1363 (87.9%) used the GPL license, 103 (6.6%) used the LGPL license, 32 (2.0%) used a BSD or BSD-like license, 29 (1.9%) used the Artistic license, 5 (0.3%) used the MIT license, with other licenses being even rarer. The FSF prefers the GPL license, so the FSF directory statistic may be biased in the percentage of GPLed software it registers, but the directory still provides strong additional evidence that the GPL is a widely used license for FLOSS.
  6. Eric S. Raymond’s “Homesteading the Noosphere” (section 2) reported that in July 1997 about half the software packages with explicit license terms at North Carolina’s Metalab (formerly Sunsite) used the GPL. At the time Metalab was the largest FLOSS software archive.
  7. The Who is Doing It (WIDI) study examined the BerliOS SourceWell list of applications. Of the 1136 applications tracked at that time, the top three were the GPL at 85.9% (976/1136), LGPL at 4.6% (52/1136), and BSD-style at 2.8% (32/1136).
  8. What about what’s used, rather than what’s developed? A 2003 MITRE survey of U.S. Department of Defense (DoD) use of FLOSS found that 52% of the reported FLOSS applications were released under the GPL; the next-largest licenses were BSD (6%), Apache (5%), various “Community” (4%), and LGPL (3%). Even if you claimed that all non-GPL licenses were simply BSD variants (which is not true), the GPL had a simple majority of the licenses of FLOSS in use.
  9. A survey of FLOSS developers in Asia by Shimizu et al. in 2003-2004 found that across Asia, 64.7% preferred “GPL-compatible” licenses (presumably they meant GPL or LGPL licenses) while 15% preferred BSD-style, and in Japan, 42% preferred “GPL-compatible” licenses while 30.2% preferred BSD style licenses.
  10. Black Duck Software's "Open Source License Data" reports that the most popular licenses (in order for those above 2%) are GPLv2 (32.65%), Apache 2.0 (12.84%), GPLv3 (11.62%), MIT (11.28%), BSD license 2.0 (6.83%), Artistic (6.27%), LGPL 2.1 (6.19%), and LGPL 3.0 (2.62%). Here's the top 20 licenses in Black Duck's database.
  11. Surveying open source licenses ( article, April 2013) discusses license survey challenges (it's hard to do) and some efforts to measure licenses anyway. The article includes results from Walter van Holst, who examined the software index Freecode (formerly Freshmeat) and determined that in 2013 58% of the OSS code uses some version of the GPL.

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.

Other projects and license authors show GPL compatibility important

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:

  1. The widely-used Python language underwent major license changes in 2001 so that version 2.1 and on would be GPL-compatible.
  2. The popular text editor vim became GPL-compatible, after a long legal discussion. Linux Journal magazine has awarded vim as the most popular editor multiple times, so this isn’t an obscure program.
  3. Mozilla also underwent a complex relicensing scheme, again, to resolve perceived incompatibilities between their older licenses (particularly the MPL) and the GPL. As discussed below, they eventually rewrote their MPL license to make it GPL-compatible.
  4. Zope also transitioned from their “Zope Public License version 1” (which was GPL-incompatible) to a GPL-compatible license.
  5. The University of California at Berkeley released a large quantity of code (the Berkeley Software Distribution, BSD) that became the basis of the various *BSD systems. The original BSD license included an awkward advertizing requirement that was GPL-incompatible. After many requests (including notes that the license was GPL-incompatible), Berkeley decided to change the license in 1999, making this code GPL-compatible (the FSF has a page discussing the original BSD advertizing clause from their perspective).
  6. Apache changed their license to “version 2.0”, and one of their goals was to be “compatible with other open source licenses, such as the GPL”. Unfortunately, the Apache Software Foundation believes Apache License version 2.0 is compatible with the GPL version 2, while the Free Software Foundation’s legal team asserts that Apache License version 2.0 is not GPL-compatible. Since that time, the FSF and Apache Software Foundation have worked together, and GPL version 3 is known to be compatible with the Apache License version 2.0 (Apache co-founder Brian Behlendorf is delighted by the Apache 2.0 / GPLv3 license compatibility). This long history makes it clear that both sides believe that GPL compatibility is an important advantage in a FLOSS license.
  7. The toolkit Qt (the basis of KDE) originally had a GPL-incompatible license. Its owners now dual-license Qt with the GPL so that Qt is GPL-compatible.
  8. As noted in Wine history, the Wine project’s “history of licensing has sparked many debates.” The WINE project originally had the BSD-old license, a GPL-incompatible license; this incompatibility with the GPL drove the developers to switch to the GPL-compatible X11 license in January 2000. Many developers expressed concern about appropriation of the code by commercial entities, so in March 2002 the developers agreed to switch Wine to the LGPL license. The “ReWind” project was created for those who wanted an X11-licensed codebase, but most developers decided to focus their efforts on synchronizing with the LGPL’ed Wine, and the vast majority of development and new features appear there first. The Wine project reports that shortly after changing the license to the LGPL, development began to pick up at a greater pace (more patches began to appear, the leader Alexandre made more CVS commits, and more applications were reported to work).
  9. Alfresco relicensed their enterprise content management program from the MPL to the GPL (both FLOSS licenses, but MPL versions before 2.0 are GPL-incompatible). Stephen Shankland’s article on Alfresco reports Matt Asay (Alfresco’s vice president of marketing) saying that moving to the GPL removes some barriers, and allows Alfresco able to easily integrate with other GPL projects. It also quotes 451 Group analyst Raven Zachary saying that, “Alfresco’s use of the GPL license for its Community Edition allows for potentially greater community contributions due to license familiarity and established standards.”
  10. Three French public research organisations launched a project that wrote new Free Software licenses conforming to French law: CeCILL, CeCILL-B, and CeCILL-C. They considered GPL-compatibility important, even when creating a new licenses. The CeCILL license is very similar to the GPL and is explicitly compatible with the GPL. The CeCILL Frequently Asked Questions (FAQ) (from its authors) says, “CeCILL is nevertheless compatible with the GNU GPL: when a software under CeCILL is integrated with a software under the GPL, the resulting work can be distributed under the GNU GPL.” Note that the FSF agrees that the CeCILL is compatible with the GPL.
  11. In June 2010 Google relicensed their WebM implementation of the VP8 multimedia codec, in part because the old license was GPLv3 and GPLv2 incompatible.
  12. In late 2011, the Mozilla foundation released MPL version 2.0 license and one of the key changes is that the new MPL is GPL-compatible (see also the FSF statement about the MPL).
  13. In December 2012 it was announced that the European Union's "EUPL" open source licence will be updated to become compatible with GPLv3. One report said that, "the main reason to update the licence is to remove barriers [of] using software licensed under the EUPL", and that "Making it explicitly compatible with the GPLv3 should increase interoperability".
  14. In 2014 Plan 9 was relicensed from the Lucent Public License to GPL version 2. The Lucent license is believed to be GPL-incompatible.

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.

Some GPL-incompatible licenses to avoid

There are many GPL-incompatible licenses that you should avoid releasing software under if at all possible. Here are some examples:

  1. Avoid the original (“4-clause”) BSD license. The original BSD license included a clause now called the “obnoxious BSD advertising clause”. This stated that:
        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.
  2. Avoid the “Academic Free License” (AFL). It has been claimed that the AFL was a “compatible upgrade” from “licenses such as BSD and MIT”, but this is a misleading claim; as the FSF notes, “the modified BSD license and the X11 license (aka MIT) are GPL-compatible, but the AFL is not.” (at least version 1.1 and 2.1 are incompatible, and I believe that AFL version 3 is incompatible as well). The AFL has some nice properties from a legal point of view, but its GPL-incompatibility is a serious failing that completely dwarfs those advantages. Projects such as SHPTRANS have noted the AFL incompatibility as a serious problem, and have chosen to not use the AFL for this reason. At one time some people in the OSI recommended the AFL, but as of July 30, 2007 the OSI lists the AFL license as being “redundant with more popular licenses”, and pointedly does not include it with “Licenses that are popular and widely used or with strong communities”.
  3. For now, avoid the “Common Public License” 1.0 (CPL), though this may change. The CPL is not nearly as popular as the GPL, LGPL, BSD-new, or MIT/X11 licenses, but it has more uses than most other licenses. The CPL is even in the OSI’s list of “Licenses that are popular and widely used or with strong communities”. Some other licenses, such as the Eclipse license, are based on the CPL. It is known that the CPL is incompatible with GPLv2, so for the moment it is probably best avoided. However, it is possible that the CPL is compatible with GPL version 3, which would make it much more palatible and similar to the Apache 2.0 license (which is incompatible with GPLv2 but compatible with GPLv3). At the moment, I’d wait until there’s been lengthy legal analysis to settle the matter.
  4. Avoid the “Open Software License” (OSL). This is supposed to be a strongly protective license like the GPL. But it’s incompatible with the GPL, and almost no one uses this license, so any such code cannot use or be used by the vast majority of FLOSS projects. The FSF also believes that the distribution terms make normal development processes illegal, creating a severe practical problem. Again, at one time some people in the OSI recommended the OSL, but as of July 30, 2007 the OSI lists the OSL license as being in the category “Other/Miscellaneous licenses”, and pointedly does not include it with “Licenses that are popular and widely used or with strong communities”.
  5. Avoid the “Artistic 1.0” license (from Perl). Although intended to be an OSS license, the Artistic 1.0 license is a poorly crafted license that creates all sorts of legal problems. The Free Software Foundation (FSF) says it is not a free license because its text is vague and open to misinterpretation. The Perl community, which developed it, agreed with this assessment and rewrote the Artistic license to resolve all the identified problems. The OSI has “superseded” the license, recommending strongly that all users move to Artistic 2.0.. Fedora (a very popular Linux distribution) no longer permits projects that use Artistic 1.0, and for Fedora 10 plans to remove all projects that use only the Artistic 1.0 license. Actually, this license is probably compatible with the GPL, but it’s so hard to figure out what it means that I include it here. I recommend using the MIT or BSD-new licenses instead of the Artistic licenses where you reasonably can.
  6. Avoid using the “Creative Commons” licenses for software. The Creative Commons FAQ says, “Creative Commons licenses are not intended to apply to software. They should not be used for software... [they don’t distinguish, as needed,] between object and source code... We strongly encourage you to use one of the very good software licenses available today [instead].” Jay Tuley’s “5 reasons to not choose a CC license for code” explains more. The debian-legal Summary of Creative Commons 2.0 Licenses recommends that authors who wish to create works compatible with Debian’s “Debian Free Software Guidelines” should not use any of the licenses in the Creative Commons license suite; licenses with the “NonCommercial” or “NoDerivs” license elements are fundamentally incompatible with FLOSS, authors who use or are planning to use the Attribution 2.0 license should consider a similar Free Software license such as a BSD- or MIT-style license..., and Authors who use or are planning to use the Attribution-ShareAlike 2.0 license should consider a similar Free Software license such as the GNU General Public License [GPL]. The Creative Commons has “wrapped” the GPL and LGPL if you want to use the Creative Commons search engine.
  7. Avoid the Mozilla Public License (MPL) version 1.0, version 1.1, and the Incompatible With Secondary Licenses clause of version 2.0. The Mozilla Public License (MPL) was originally created by Mozilla, but its GPL-incompatibility caused so many problems that Mozilla eventually re-licensed their work under a GPL/LGPL/MPL triple license. Other former MPL users like Alfresco have abandoned the MPL. It's important to note that even the original creator of the MPL 1.0 and 1.1 abandoned it as their sole license, because of GPL-incompatibility; don’t duplicate their mistake. Google no longer lists the MPL as a recommended license, even though they once did. Indeed, there was a time when Google code would not accept MPL projects; Google code now allows any OSS license, but it still does not include the MPL as a recommended license. The more recent MPL version 2.0 is compatible with the GPL, due to a lot of hard license analysis work... making the MPL compatible with the GPL was one of the main reasons the MPL was updated. However, MPL version 2.0 has optional "incompatible With secondary licenses" clause, and if you include it the software is no longer GPL-compatible (so do not include that clause).
  8. Avoid the CDDL. This Sun creation is similar to the MPL. Yet the original creator of the MPL no longer uses it (exclusively), and the experience of OpenSolaris shows that the license is a real stumblingblock. CDDL-based projects tend to have relatively small levels of participation, and I think a key reason is the license.
  9. Avoid the “NASA Open Source Agreement” version 1.3. This is one of those rare cases where the OSI has accepted a license as being an open source software license (per the open source definition), but the FSF has determined that the license is not a Free Software license (per the Free Software definition). The problem is that it requires that changes be your “original creation”. FLOSS software development depends on combining code from third parties, so if that is interpreted literally, this agreement would prohibit practically all real work and would certainly be GPL-incompatible. It’s best to avoid this license. NASA has told me that they are in the process of changing this license to remove this silly restriction; that would make it better, though I do not know if their result will be GPL-compatible.

Consider GPL incompatibility carefully

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.

License proliferation considered harmful

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.”

Other things to consider

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.

A related issue: Use the standard license (CC-BY-SA) for other works

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...

Making your FLOSS software GPL-compatible

So, how do you make sure that your software is GPL-compatible? Fortunately, there are three easy ways to do this:

  1. One way, of course, is to use the GPL.
  2. Another is to use a different license that is known to be GPL-compatible, in particular the LGPL, MIT/X, or BSD-new (modified BSD) licenses. Obviusly there are several licenses you can choose while remaining GPL-compatible. The FSF maintains a list of licenses it has determined to be GPL-compatible. The Fedora Core Licensing page has a really helpful table showing licenses and whether or not they are compatible. Don’t use the old/original BSD license, which is generally accepted as being GPL-incompatible and has many practical problems; even Berkeley has switched to the new BSD license for their software. You might also consider using the Apache 2.0, but note that while it is compatible with GPL version 3, the developers of the GPL are confident that it is not compatible with GPL version 2.

    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).

  3. A third alternative is to dual license (or even triple license) the program. That is, release it under more than one license simultaneously, one of which is GPL-compatible (such as the GPL or LGPL), and let the user pick which license they’ll use. Widely-used projects such as Perl, Mozilla, and Qt do this. (the Mozilla project even uses a triple license (MPL/GPL/LGPL)). The Debian Free Software Guidelines (DFSG) FAQ notes that “The GPL is particularly common in dual licenses because it allows the code to link with the large body of GPLed code available including many important libraries, and to be incorporated into other GPLed works... This is almost always due to a project starting with a home-brewed GPL-incompatible license, then realizing they’d made a mistake and finding relicensing in this fashion to be the most convenient resolution.” One problem with dual licensing is that you can only incorporate code from elsewhere that is compatible with all of the licenses. Thus, dual licensing can make it impossible to legally use some potentially useful code for as long as you maintain the multiple licenses. It’s one of the more reasonable ways to fix a mistake, but it’s better to avoid mistakes in the first place... especially when there’s clear evidence that using a GPL-incompatible license is a mistake for FLOSS projects.

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.

Appendix A: The Cautionary Tale of XFree86

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 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 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, 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.

Appendix B: Information about the GPL and other Licenses

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.

Appendix C: GNU projects not under a copyleft license

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:

(My thanks to Javier Candeira who identified many of these.)

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 for additional evidence of this.

Picture of David A. Wheeler