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

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.

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.

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

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.

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.

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.

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

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.

Surveying open source licenses
(lwn.net 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.

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:

The widely-used
Python language
underwent major license changes in 2001 so that
version 2.1 and on would be GPL-compatible.

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.

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.

Zope also transitioned from their
“Zope Public License version 1” (which was GPL-incompatible) to a
GPL-compatible license.

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

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.

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

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

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

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.

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:

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.

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

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.

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

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

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.

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.

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.

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.

We are on an island nearly alone with the OPL... we can move from a tiny archipelago to the largest continent of open content under the flag of the CC BY SA.

Other organizations that have content we can reuse in Fedora and contribute back to, such as Wikipedia and GNOME, have switched or are switching to the CC BY SA...

If you’ve never looked at how much open content there is on e.g. flickr.com and Wikicommons, please look. For content authors, this is going from practically zero useful open media available to tens of millions of photographs, diagrams, and so forth that we can not only freely reuse, but we can contribute back to...

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.

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

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

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.

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.

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.

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.