But make sure that your FLOSS software’s license is GPL-compatible,
i.e., that
, 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,
and/or (4) encourages increasing the amount of
Examples of such thinking include
(which points out that NetApp’s improvements to
BSD-licensed code are not contributed back but its improvements to
GPL-licensed code have been),
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.
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 , though
the view that the GPL is a good or necessary license is
not a universally-held position by FLOSS developers
(e.g., see ).
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:
Freshmeat.net (now )
reported on
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.
SourceForge.net reported on
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.
Another way to get SourceForge statistics - and many others - is through
FLOSSmole is a tool for querying data about FLOSS repositories,
and they make it easy to analyze data from many sources.
In my paper
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
(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.
hosts 1,986 mostly-GPL projects (as of November 11, 2003) and
strongly encourages GPL-compatible licenses.
lists FLOSS software.
On September 24, 2002, I downloaded their entire directory, and found
that it had 1550 entries, of which %) 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.
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?
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.
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.
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%).
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.
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:
The widely-used
underwent major license changes in 2001 so that
version 2.1 and on would be GPL-compatible.
The popular text editor
became GPL-compatible, after a
Linux Journal magazine has awarded vim as the most popular editor
multiple times, so this isn’t an obscure program.
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.
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
from their perspective).
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
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
This long history makes it clear that both sides believe
that GPL compatibility is an important advantage in a FLOSS license.
The toolkit
(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
“history of licensing has sparked many debates.”
The WINE project originally had the BSD-old license, a GPL-
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).
from the MPL to the GPL (both FLOSS licenses, but MPL versions before 2.0 are GPL-incompatible).
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.”
CeCILL, CeCILL-B, and CeCILL-C.
They considered GPL-compatibility important, even when creating a new
The CeCILL license is very similar to the GPL and is explicitly
compatible with the GPL.
(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
In June 2010
in part because the old license was GPLv3 and GPLv2 incompatible.
In late 2011, the
Mozilla foundation released MPL version 2.0 license
and one of the key changes is that the
(see also the
In December 2012 it was announced that the
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".
was relicensed from the Lucent Public License to GPL version 2.
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
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 distribu 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.
states that
because the CDDL is not GPL-compatible,
Sun will not gain the community support it hopes to garner from using
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.
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
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.
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 there has to be an intent to cause people
to stop using the previous project, and switch to the new project instead.
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’ the problem was GPL incompatibility.
This attempted change led to a mass exodus from XFree86,
as nearly all developers and users immediately abandoned XFree86.
for more detailed
information about this.
Samba’s
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
, 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:
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
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 shou 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 i 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
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&# (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.
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 “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.
and rewrote the Artistic license to resolve all the identified problems.
Fedora (a very popular Linux distribution) no longer permits projects
that use Artistic 1.0, and for
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.
Avoid using the “Creative Commons” licenses for software.
explains more.
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 C
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
if you want to use the Creative Commons search engine.
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
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- don’t duplicate their mistake.
Indeed, there was a time when Google code would not accept MPL
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 th 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
It was an issue noted in
and others supported this view such as
Customers find a long list of licenses co
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
(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.”
“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.”
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
- 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.,
standard licenses would be used instead.
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 , was
Apache License 2.0, new and simplified BSD licenses,
GPL, LGPL, MIT, MPL, CDDL, CPL 1.0, and Eclipse Public License (EPL).
Even t the MPL, CDDL, CPL, and EPL have a vanishingly
small numbers of projects that use them.
Similarly,
(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.
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,
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.
excellent evidence that the GPL really is enforceable.
He also explain’s the GPL’s legal basis, which turns out to be very strong.
; as both note,
the GPL is a license, not a contract, which makes it unusually easy to enforce.
is a detailed legal analysis by a lawyer showing that
“the GPL is an enforceable agreement.”
for the very reasons Moglen and Jones stated.
This was in response to some
shows that the GPL is quite enforceable there.
More recently,
In 2006, a U.S. court found that the GPL
Daniel Wallace tried to invalidate the GPL in
, 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
- 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.
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.”
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.
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 t
However, as of 2009,
it appears that the emerging common “consensus” license for
copyrighted works other than software is the
So, make sure that the
, or a license compatible with it,
is one of the licenses you use to release freely reusable material.
Historically,
and related
projects were released under the GNU Free Documentation License (GFDL),
but as of May 2009
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.
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:
We are relicensing from the OPL (Open Publications License) 1.0.
Please read that, it is well reasoned and makes compelling arguments,
even more so because it is from the OPL’s author. He wrote that two
years ago, but quotes himself from 2003 when he recommended using a
Creative Commons license instead. ‘Nuff said.
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.
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 )
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
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 is essentially a release to the public domain, in a way that
is legally meaningful in all jurisdictions).
A similar problem happens with fonts.
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:
One way, of course, is to use the
Another is to use a different
license that is known to be GPL-compatible, in particular the
(modified BSD) licenses.
Obviusly there are several licenses you can choose while remaining
GPL-compatible.
has a really helpful table showing licenses and whether or not
they are compatible.
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,
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-
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).
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.
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
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.
, 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.
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’
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 m
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
More detailed commentary on GPLv3 is available, including those by
a process which seems to be
“GPL version 2 or later” gives maximum compatibility, but since nearly all
projects have the “or later” clause, it isn’t really much more compatible
than “GPL version 3 or later” for most people.
I expect that there will be a gradual migration of many projects from
“GPL version 2 or later” to “GPL version 3 or later”.
So for most projects, “GPL version 3 or later” is probably the best choice,
since it lets you take advantage of the GPL version 3 improvements.
In short, make sure that your FLOSS software is GPL-compatible,
and that you use one of the few standard FLOSS licenses
(GPL, LGPL, BSD-new, MIT, and possibly the Apache 2.0 license).
Otherwise, your FLOSS project may never have the support you hoped for.
If you’re looking for a cautionary tale of how things can go badly
because of a GPL-incompatible license,
you need look no further than the tragic story of XFree86’s demise.
The XFree86 project historically led development of a popular X server,
and traditionally the vast majority of its code used the simple
“MIT/X” open source license that is GPL-compatible.
At one time, if you used a Unix-like system and a graphical user interface,
you were very likely to be using XFree86... that’s how widespread it was.
The XFree86 president, David Dawes, decided to change the
XFree86 license to one that wasn’t GPL-compatible, primarily
to give developers more credit.
This proposed license change caused a serious uproar.
even though he’s
not a strong advocate of the GPL.
An article 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
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
a shorter version was posted by
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.”
Quexo [fsf.org], xquery implementation using Kawa to compile to java bytecode. Under the Kawa license, which means an X11-style license.
Speex [fsf.org], an audio compression codec for voice, under the Xiph.org license (a modified BSD)
(My thanks to
who identified many of these.)
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
He has also developed several FLOSS programs such as
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.