Legal Matters: Licenses, Copyrights, Trademarks and Patents
Legal questions have assumed a somewhat more prominent role in
free software projects over the last decade or so. It is still the
case that the most important things about your project are its the
quality of its code, its features, and the health of its developer
community. However, although all open source licenses share the same
basic guarantees of freedom, their terms are not exactly the same in
all details. The particular license your project uses can affect
which entities decide to get involved in it and how. You will
therefore need a basic understanding of free software licensing, both
to ensure that the project's license is compatible with its goals, and
to be able to discuss licensing decisions with others.
Please note that I am not a lawyer, and that nothing in this
book should be construed as formal legal advice. For that, you'll
need to hire a lawyer or be one.For a deeper
understanding of how copyright law relates to free software, see
https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html, published by the Software Freedom Law
Center.
Terminology
In any discussion of open source licensing, the first thing that
becomes apparent is that there seem to be many different words for the
same thing: free software,
open source,
FOSS, F/OSS, and
FLOSS. Let's start by sorting those
out, along with a few other terms.
free software
Software that can be freely shared and modified,
including in source code form. The term was first
coined by Richard Stallman, who codified it in the GNU
General Public License (GPL), and who founded the Free
Software Foundation (https://www.fsf.org/) to promote the concept.
Although "free software" covers the
same set of softwareTechnically, there
are certain uncommon situations in which software can be
distributed in a way that meets only one of the Free
Software Definition and the Open Source Definition.
These are very rare edge cases, however; they do not
affect anything in this chapter, so I won't go into
detail about them here. To learn more about them, one
place to start is a conversation Alexandre Oliva
and I had in 2020, at https://identi.ca/lxoliva/comment/FzE-8xdyS1au9z22QKA-TA,
in which he gives some examples.
as "open source", the FSF,
among others, prefers the former term because it
emphasizes the idea of freedom, and the concept of
freely redistributable software as primarily a social
movement rather than a technical one. The FSF
acknowledges that the term is ambiguous — it could
mean "free" as in "zero-cost", instead of "free" as in
"freedom" — but feels that it's still the best term,
all things considered, and that the other possibilities
in English have their own ambiguities. (Throughout this
book, "free" is used in the "freedom" sense, not the
"zero-cost" sense.)
open source software
Free software under another name. The
different name is sometimes used to indicate a philosophical
difference, however. In fact, the term "open source"
was coined, by the group that founded the Open Source
Initiative (https://www.opensource.org/),
as alternative labeling for "free software". Their
goal at the time was largely to make such software a
more palatable choice for
corporations, by presenting it as a development
methodology rather than as a political
movement.Disclosure: Long after these
events, I served as a member of the Board of Directors
of the Open Source Initiative for three years, from
2011-2014. The ideological gap between the OSI and the
FSF was much smaller by then than it was when the OSI
was founded, in my opinion, and the two
organizations have increasingly found common ground on
which to cooperate. I remain a happy member of both,
and urge you to join them too: https://opensource.org/join and https://fsf.org/join.
While any license that is free is also open
source, and vice versa (with a few minor exceptions that
have no practical consequences),
people tend to pick one term and stick with it. In
general, those who prefer "free software" are more
likely to have a philosophical or moral stance on the
issue, while those who prefer "open source" either don't
view it as a matter of freedom, or are not interested in
advertising the fact that they do. See
for a more
detailed history of this terminological schism.
The Free Software Foundation has an
excellent — utterly unobjective, but nuanced and
quite fair — exegesis of the two terms, at https://www.fsf.org/licensing/essays/free-software-for-freedom.html.
The Open Source Initiative's take on it can be found at
https://opensource.org/faq#free-software.
FOSS,
F/OSS,
FLOSS
Where there are two of anything, there will soon
be three, and that is exactly what is happening with
terms for free software. Many people have started
using "FOSS" (or, more rarely, "F/OSS"), standing
for "Free / Open Source Software". Another variant
gaining momentum is "FLOSS", which
stands for "Free / Libre Open Source Software"
(libre is familiar from
many Romance languages and does not suffer from the ambiguities
of "free"; see
https://en.wikipedia.org/wiki/FLOSS for more).
All these terms mean the same thing:
software that can be modified and redistributed by
everyone, sometimes — but not always — with the
requirement that derivative works be freely
redistributable under the same terms.
DFSG-compliant
Compliant with the Debian Free Software Guidelines
(https://www.debian.org/social_contract#guidelines).
This is a widely-used test for whether a given license
is truly open source
(free, libre, etc). The
Debian Project's mission is to maintain an entirely free
operating system, such that someone installing it need
never doubt that she has the right to modify and
redistribute any or all of the system. The Debian Free
Software Guidelines are the requirements that a software
package's license must meet in order to be included in
Debian. Because the Debian Project spent a good deal of
time thinking about how to construct such a test, the
guidelines they came up with have proven very robust
(see https://www.debian.org/social_contract#guidelines),
and as far as I'm aware, no serious objection to them has
been raised either by the Free Software Foundation or
the Open Source Initiative. If you know that a given
license is DFSG-compliant, you know that it guarantees
all the important freedoms (such as forkability even
against the original author's wishes) required to
sustain the dynamics of an open source project. Since
2004, the Debian Project has maintained a list of known
DFSG-compliant licenses at https://wiki.debian.org/DFSGLicenses. All of the licenses
discussed in this chapter are DFSG-compliant.
OSI-approved
Approved by the Open Source Initiative. This is
another widely-used test of whether a license permits
all the necessary freedoms. The OSI's definition of
open source software is based on the Debian Free
Software Guidelines, and any license that meets one
definition almost always meets the other. There have
been a few exceptions over the years, but only involving
niche licenses and none of any relevance
here.There is one relatively new
license, the Cryptographic Autonomy License, version 1.0
(https://opensource.org/licenses/CAL-1.0, approved by
the OSI in 2020), that has unusual provisions regarding
data portability and that has caused some disagreement
over whether it truly meets the Open Source Definition.
Two good overviews of CAL-1.0 are Heather Meeker's at
https://heathermeeker.com/2020/02/15/cryptographic-autonomy-license-approved-by-osi/
and Jonathan Corbet's in Linux Weekly News at
https://lwn.net/Articles/797065/.
The OSI maintains a list of all
licenses it has ever approved, at
https://www.opensource.org/licenses/, so
that being "OSI-approved" is an unambiguous state: a
license either is or isn't on the list.
The Free Software Foundation also maintains a list
of licenses at https://www.fsf.org/licensing/licenses/license-list.html.
The FSF categorizes licenses not only by whether they
are free, but whether they are compatible with the GNU
General Public License. GPL compatibility is an
important topic, covered in
.
proprietary,
closed-source
The opposite of "free" or "open source." It means
software distributed under traditional, royalty-based
licensing terms, where users pay per copy, or under any
other terms sufficiently restrictive to prevent open
source dynamics from operating. Even software
distributed at no charge can still be proprietary, if
its license does not permit free redistribution and
modification.
Generally "proprietary" and "closed-source" are
synonyms. However, "closed-source" additionally implies
that the source code cannot even be seen. Since the
source code cannot be seen with most proprietary
software, this is normally a distinction without a
difference. However, occasionally someone releases
proprietary software under a license that allows others
to view the source code. Confusingly, they sometimes
call this "open source" or "nearly open source," etc,
but that's misleading. The
visibility of the source code is
not the issue; the important question is what you're
allowed to do with it: if you can't copy, modify, and
redistribute, then it's not open source. Thus, the
difference between proprietary and closed-source is
mostly irrelevant; generally, the two can be treated
as synonyms.
Sometimes commercial is
used as a synonym for "proprietary," but this is
carelessness: the two are not the same. Free software
is always commercial software. After all, free software
can be sold, as long as the buyers are not restricted
from giving away copies themselves. It can be
commercialized in other ways as well, for example by
selling support, services, and certification. There are
billion-dollar companies built on free software
today, so it is clearly neither inherently
anti-commercial nor anti-corporate. It is merely
anti-proprietary, or if you prefer anti-monopoly,
and this is the key way in which it differs from
per-copy license models.
public domain
Having no copyright holder, meaning that there is
no one who has the right to restrict copying of the
work. Being in the public domain is not the same as
having no author. Everything has an author, and even if a
work's author or authors choose to put it in the public
domain, that doesn't change the fact that they wrote
it.
When a work is in the public domain, material from
it can be incorporated into a copyrighted work, and the
derivative is thus under the same overall copyright as
the original copyrighted work. But this does not affect
the availability of the original public domain work.
Thus, releasing something into the public domain is
technically one way to make it "free," according to the
guidelines of most free software certifying
organizations (see https://opensource.org/faq#public-domain for more).
However, there are usually good reasons to use a license
instead of just releasing into the public domain: even
with free software, certain terms and conditions can be
useful, not only to the copyright holder but to
recipients as well, as the next section makes clear.
reciprocal or copyleft
A license that not only grants the freedoms under
discussion here but furthermore requires that those
freedoms apply to any derivative works.
The canonical example of a copyleft license is
still the GNU General Public License, which stipulates
that any derivative works must also be licensed under
the GPL; see for
more.
non-reciprocal, non-copyleft or permissive
A license that grants the freedoms under
discussion here but that does not
have a clause requiring that they apply to distributed
derivative works as well.
Two early and well-known examples of non-reciprocal
licenses are the BSD and MIT licenses, but the more
recent Apache Software License version 2
(https://www.apache.org/licenses/LICENSE-2.0) is
also very popular — increasingly so — and
somewhat better adapted to the legal landscape of modern
open source software development.
"Free Software" and "Open Source" Are the Same Licenses
Occasionally people will make the mistake of thinking that
copyleft licenses (like the GPL) comprise "free software", while the
non-reciprocal licenses comprise "open source". This is wrong, but it
comes up just often enough to be worth mentioning here. Both free
software and open source include both the
copyleft and non-copyleft licenses — this is something
that all the license-certifying organizations, including the FSF, the
OSI, and the Debian Project, have always agreed on. If you see
someone, particularly a journalist, making this mistake, please
politely correct them, perhaps by pointing them to this note (
https://producingoss.com/en/legal.html#free-open-same).
The last thing we need is yet more terminological confusion in the
free and open source software movement.
Aspects of Licenses
Although there are many different free software licenses
available, in the important respects they all say the same things:
that anyone can see and use the code, that anyone can modify the code,
that anyone can redistribute it both in original and modified form,
and that the copyright holders and authors provide no warranties
whatsoever (avoiding liability is especially important given that
downstream recipients might run modified versions without even knowing
it). The differences between licenses boil down to a few
oft-recurring issues:
compatibility with proprietary licenses
The non-reciprocal (non-copyleft) free licenses allow the covered code to be
used in proprietary programs. This does not affect the
licensing terms of the proprietary program: it is still
as proprietary as ever, it just happens to contain some
code from a non-proprietary source. The Apache License,
X Consortium License, BSD-style license, and the
MIT-style license are all examples of
proprietary-compatible licenses.
compatibility with other types of free licenses
Most of the commonly-used non-reciprocal free licenses
are compatible with each other, meaning that code under
one license can be combined with code under another, and
the result distributed under either license without
violating the terms of the other. Some of them are also
compatible with some of the copyleft licenses, meaning
that a work comprised of code under the non-reciprocal
license and code under the copyleft license can be
distributed as a combined work under the copyleft
license (since that's the license that places more
conditions), with the original code in each case
remaining under its original license. Typically these
compatibility issues come up between some non-reciprocal
license and the GNU General Public
License.Or its variant, the GNU Affero
GPL (see AGPL).
This topic is discussed in more detail in
.
attribution requirements
Some free licenses stipulate that any use of the
covered code be accompanied by a notice, whose placement
and display is usually specified, giving credit to the
authors or copyright holders of the code. These
licenses are often still proprietary-compatible: they do
not necessarily demand that the derivative work be free,
itself, merely that credit be given for its free parts.
protection of trademark
This is a type of attribution requirement.
Trademark-protecting licenses specify that the name of
the original software (or its copyright holders, or
their institution, etc) may not be
used to identify derivative works, at least not without
prior written permission. This restriction can be
implemented purely via trademark law anyway, whether or
not it is also stipulated in the copyright license, so
such clauses are somewhat legally
redundant — in effect, they amplify a
trademark infringement into a copyright infringement as
well.
Although attribution requirements insist that a certain
name be used, while trademark protections insist that it
not be used, they are both expressions of the same
concept: that the original code's reputation be
preserved, and not tarnished by associations beyond its
control.
patent snapback
Certain licenses (e.g., the GNU General Public
License version 3, the Apache License version 2, the
Mozilla Public License 2.0, and a few others) contain
language designed
to prevent people from using patent law to take away the
rights granted under copyright law by the
licenses. They require contributors to grant patent
licenses along with their contribution, covering any
patents licenseable by the contributor that would be
infringed by their contribution (or by the incorporation
of their contribution into the work as a whole). Then
they go further: if someone using software under the
license initiates patent litigation against another party,
claiming that the covered work infringes, the initiator
automatically loses all the
patent grants otherwise provided for that work by the
license, and in the case of the GPL-3.0 loses their right
to distribute under the license altogether.
Most of these stipulations are not mutually exclusive, and some
licenses include several. The common thread among them is that they
place certain easily satisfiable demands on the recipient in exchange
for the recipient's right to use the code under the freedoms granted
by the license.
The GPL and License Compatibility
The sharpest dividing line in licensing is that between
proprietary-incompatible and proprietary-compatible licenses, that is,
between the copyleft licenses and everything else.
The canonical
example of a copyleft license is the GNU General Public License (along
with its newer descendant, the Affero GNU General Public
License or AGPL, introduced later in this chapter in ), and one of the most important
considerations in choosing the GPL (or AGPL) is the extent to which it
is compatible with other licenses. For brevity, I'll refer just to
the GPL below, but most of this section applies to the AGPL as
well.
Because the primary goal of the GPL's authors is the promotion
of free software, they deliberately crafted the license to prevent
proprietary programs from being distributed with GPLed code in them.
Specifically, among the GPL's requirements (see https://www.fsf.org/licensing/licenses/gpl.html for its full text) are
these two:
Any derivative work — that is, any work
containing a nontrivial amount of GPLed code — must
itself be distributed under the GPL.
No additional restrictions may be placed on the
redistribution of either the original work or a derivative
work. (The exact language is: "You may not impose any
further restrictions on the exercise of the rights granted
or affirmed under this License.")
Through these two conditions, the GPL makes freedom
contagious. Once a program is copyrighted under the GPL, its terms of
redistribution are
reciprocalSome people use the
term viral to describe the GPL's
contagiousness; they do not always mean this pejoratively, but I still
prefer "reciprocal" because it's more descriptive and less connotative
of disease. — they are passed
on to anything else the code gets incorporated into, making it
effectively impossible to use GPLed code in closed-source programs.
However, these same clauses also make the GPL incompatible with
certain other free licenses. The usual way this happens is that the
other license imposes a requirement — for example, a credit clause
requiring the original authors to be mentioned in some way — that
is incompatible with the GPL's "You may not impose any further
restrictions..." language. From the point of view of the Free
Software Foundation, these second-order consequences are desirable, or
at least not regrettable. The GPL not only keeps your software free,
but effectively makes your software an agent in pushing
other software to enforce freedom as well, by
encouraging them to use the GPL.
The question of whether or not this is a good way to
promote free software is one of the most persistent holy wars on the
Internet (see ), and we won't
investigate it here. What's important for our purposes is that
GPL compatibility is something to consider when choosing a license. The
GPL is a popular open source license, and some important open source
packages are licensed under it. If you want your code to be able to be
mixed freely with GPLed code, then you should pick a GPL-compatible
license. Most of the GPL-compatible open source licenses are also
proprietary-compatible: that is, code under such a license can be used
in a GPLed program, and it can be used in a proprietary program. Of
course, the results of these mixings would not be
compatible with each other, since one would be under the GPL and the
other would be under a closed-source license. But that concern
applies only to the derivative works, not to the code you distribute
in the first place.
Fortunately, the Free Software Foundation maintains a list
showing which licenses are compatible with the GPL and which are not,
at https://www.gnu.org/licenses/license-list.html. All
of the licenses discussed in this chapter are present on that list, on
one side or the other.
Choosing a License
When choosing a license to apply to your project, use an
existing license instead of making up a new one. And don't just use
any existing license — use one of the widely-used,
well-recognized existing licenses.
Such licenses are familiar to many people already. If you use
one of them, people won't feel they have to read the legalese in order
to use your code, because they'll have already read that
license a long time ago. Thus, you reduce or remove one possible
barrier to entry for your project. These licenses are also of a high quality:
they are the products of much thought and experience; indeed most
of them are revisions of previous versions of themselves, and the
modern versions represent a great deal of accumulated legal and
technical wisdom. Unless your project has truly unusual needs, it is
unlikely you could do better even with a team of lawyers at your
disposal.
Below is a list of licenses that in my opinion meet these
criteria; in parentheses is the standard formal
abbreviationThe Software Package Data Exchange (SPDX)
project maintains a canonical list of licenses abbreviations, along
with whether the given license is OSI-approved, FSF-approved, or both,
at https://spdx.org/licenses/. for each license. If you have
nothing else to guide you and you want a copyleft license, then choose
either the GPL-3.0 or the AGPL-3.0 — the difference
between them will be discussed below — and if you want
a non-copyleft license, choose the MIT license. I've put those
licenses in boldface to reflect
this.
This list is not in order of preference, but rather in roughly
descending order from strong copyleft at the top to completely
non-copyleft at the bottom:
GNU General Public License version 3 (GPL-3.0
)
GNU Affero General Public License version 3 (AGPL-3.0
)
Mozilla Public License 2.0 (MPL-2.0
)
GNU Library or "Lesser" General Public License version 3 (LGPL-3.0
)
Eclipse Public License 1.0 (EPL-1.0
)
Apache License 2.0 (Apache-2.0
)
MIT license (MIT
)
BSD 2-Clause ("Simplified" or "FreeBSD") license (BSD-2-Clause
)
The exact provisions of each license differ in various interesting
ways (except for MIT and BSD, which differ only in uninteresting
ways and are basically interchangeable). There isn't space here to
explore all the possible ramifications of each license for your
project, but many good discussions of that sort are easily findable
on the Internet; in particular the Wikipedia pages for these licenses
tend to give good overviews.
Note that there are some arguments for choosing the Apache
License 2.0 as a default non-copyleft license, and they are nearly as
compelling as those for choosing MIT. In the end, I come down in
favor of MIT because it is extremely short, and both widely used and
widely recognized. While the
Apache License 2.0 has the advantage of containing some explicit
defenses against misuse of software patents, which might be important
to your organization depending on the kind of project you're
launching, the MIT license is fully compatible with all versions of
the GNU General Public License, meaning that you can distributed,
under any version of the GPL, mixed-provenance works that contain
MIT-licensed code. The GPL-compatibility situation for the Apache
License, on the other hand, is more complicated — by
some interpretations, it is compatible with GPL version 3 only.
Therefore, to avoid giving your downstream redistributors the headache
of having to read sentences like the preceding ones, I recommend
the MIT license as the default non-copyleft license for anyone who
doesn't have a reason to choose otherwise.
The mechanics of applying a license to your project are
discussed in .
The GNU General Public License
If you prefer that your project's code not be used in
proprietary programs, or if you at least don't care whether or not it
can be used in proprietary programs, the GNU General Public License,
version 3, is a good choice.
When writing a code library that is meant mainly to be used as
part of other programs, consider carefully whether the restrictions
imposed by the GPL are in line with your project's goals. In some
cases — for example, when you're trying to unseat a
competing, proprietary library that offers the same
functionalityOnce again, the report Open
Source Archetypes: A Framework For Purposeful Open Source
(https://opentechstrategies.com/archetypes), mentioned in , may be worth consulting if you want a
strategic view of potential purposes for an open source project and
how purpose affects structure. — it
may make more strategic sense to license your code in such a way that
it can be mixed into proprietary programs, even though you would
otherwise not wish this. The Free Software Foundation even fashioned
an alternative to the GPL for such circumstances: the GNU
Lesser GPLOriginally named the
GNU Library GPL, and later renamed by the
FSF. The LGPL has weaker reciprocity requirements
than the GPL, and can be mixed more easily with non-free code. The
FSF's page about the LGPL, https://www.gnu.org/licenses/lgpl.html, has a good discussion
of when to use it.
The "or any later version" Option: Future-Proofing the GPL
The GPL has a well-known optional recommendation that you
release software under the current version of the GPL while giving
downstream recipients the option to redistribute it under any
later (i.e., future) version of the license. The way to offer
this option is to put language like this in the license headers (see
) of the actual source
files:
This program is free software: you can redistribute it
and/or modify it under the terms of the GNU General Public License as
published by the Free Software Foundation, either version 3 of the
License, or (at your option) any later
version.
(Emphasis added.)
Whether you want to offer this option depends largely on how
likely you think the Free Software Foundation is to make GPL revisions
that you would approve of. I think the FSF has done a good job of
that so far, and I generally do include that option when I use the
GPL. That way I don't have to be responsible for updating my software's
licenses forever — which is good, since I won't
be around forever. Others can do it, either just to keep the software
license up-to-date with legal developments, or to solve some future
license compatibility problem that couldn't have been anticipated now
(for example, see the compatibility discussion in below).
Not everyone feels the same way, however; most notably, the
Linux kernel is famously licensed under the GNU GPL version 2
without the "or any later version" clause, and
influential kernel copyright holders, especially Linus Torvalds, have
expressed clearly that they do not intend to move its license to
version 3.0.
This book cannot answer the question of whether you should
include the option or not. You now know that you have the choice
and that different people come to different conclusions about
it.
The GNU Affero GPL: A Version of the GNU GPL for Server-Side Code
In 2007, the Free Software Foundation released a variant of the
GPL called the GNU Affero GPL. Its purpose was to bring
copyleft-style sharing provisions to the increasing amount of code
being run as hosted services — that is, software that
runs "in the cloud" on remote servers owned by someone other than the
user. This is software that users interact with only
over the network and that therefore is not directly distributed to its
users as executable or source code in the normal course of usage.
Many such services use GPLed
software, often with extensive modifications, yet could avoid
publishing their changes because they weren't actually distributing
code.
The AGPL's solution to this was to take the GPL (version 3) and add a
"Remote Network Interaction" clause, stating "...if you
modify the Program, your modified version must prominently offer all
users interacting with it remotely through a computer network ... an
opportunity to receive the Corresponding Source of your version ... at
no charge, through some standard or customary means of facilitating
copying of software." This expanded the GPL's enforcement
powers into the new world of remote application service providers. The Free
Software Foundation recommends that the GNU AGPL 3.0 be used for any
software that will commonly be run over a network.
Note that the AGPL-3.0 is not directly compatible with GPL-2.0,
though it is compatible with GPL-3.0. Since most software licensed
under GPL-2.0 includes the "or any later version" clause anyway, that
software can just be shifted to GPL-3.0 if and when you need to mix it
with AGPL-3.0 code. However, if you need to mix with programs
licensed strictly under the GPL-2.0 (that is, programs licensed
without the "or any later version" clause), the AGPL3.0 wouldn't be
compatible with that.
Although the history of the AGPL-3.0 is a bit complicated, the
license itself is simple: it's just the GPL-3.0 with one extra clause
about network interaction. The Wikipedia article on the AGPL is
excellent: https://en.wikipedia.org/wiki/Affero_General_Public_License
The Copyright Holder Is Special, Even In Copyleft Licenses
One common misunderstanding is that licensing your software
under the GPL or AGPL requires you to provide source code to anyone
who requests it under the terms of the license. But that's not quite
how it works. If you are the sole copyright
holder in a piece of software, then you are not bound by the copyright
terms you chose, because (essentially) you can't be forced to sue
yourself for copyright infringement. You can enforce the terms on
others, but it's up to you to decide whether and when those terms
apply to you. After all, because you had the software originally, you
never "distributed" it to yourself and thus are not bound by the
redistribution requirements of the license.
Of course, this only applies to situations where you own the
whole copyright. If you include others' GPL- or AGPL-licensed code in
your project and then distribute the result, you are no longer the sole
copyright holder, and so you are as bound by the original terms as
anyone else who uses and redistributes that code, either unmodified or
as part of a derivative work.
Is the GPL Free or Not Free?
One consequence of choosing the GPL (or AGPL) is the small
possibility of finding
yourself or your project embroiled in a dispute about whether or not
the GPL is truly "free", given that it places some restrictions on
how you redistribute the code — namely, the restriction that the
code cannot be distributed under any other license. For some people,
the existence of this restriction means the GPL is therefore "less
free" than non-reciprocal licenses. Where this
argument usually goes, of course, is that since "more free" must be
better than "less free" (after all, who's not in favor of freedom?),
it follows that those licenses are better than the GPL.
This debate is another popular holy war (see
). Avoid participating
in it, at least in project forums. Don't attempt to prove that the
GPL is less free, as free, or more free than other licenses. Instead,
emphasize the specific reasons your project chose the GPL. If the
recognizability of license was a reason, say that. If the enforcement
of free licensing on derivative works was also a reason, say that too,
but refuse to be drawn into discussion about whether this makes the
code more or less "free". Freedom is a complex topic, and there is
little point talking about it if terminology is going to be used as a
stalking horse for substance.
Since this is a book and not a mailing list thread, however, I
will admit that I've never understood the "GPL is not free" argument.
The only restriction the GPL imposes is that it prevents people from
imposing further restrictions. To say that this
results in less freedom has always seemed perverse to me. If the
retention of monopoly is somehow a freedom to be protected, then the
word "freedom" is no longer meaningful.
Contributor Agreements
There are three ways to handle copyright ownership for free code
and documentation that were contributed to by many people. The first
is to ignore the issue of copyright entirely (I don't recommend this).
The second is to collect a contributor license
agreement (CLA) from each person
who works on the project, explicitly granting the project the right to
use that person's contributions. This is usually enough for most
projects, and the nice thing is that in some jurisdictions, CLAs can
be sent in electronically. The third way is to get actual
copyright assignment (CA
from contributors, so that the project (i.e., some legal entity,
usually a nonprofit) is the copyright owner for everything. This way
is the most burdensome for contributors, and some contributors simply
refuse to do it; only a few projects still ask for assignment, and I don't
recommend that any project require it these days.Also,
actual copyright transferal is subject to national law, and licenses
designed for the United States may encounter problems elsewhere (e.g.,
in Germany, where it's apparently not possible to fully transfer
copyright).
Note that even under centralized copyright ownership, the
codeI'll use "code" to refer to both code and
documentation from now on. remains free, because
open source licenses do not give the copyright holder the right to
retroactively proprietize all copies of the code. So even if the
project, as a legal entity, were to suddenly turn around and start
distributing all the code under a restrictive license, that wouldn't
necessarily cause a problem for the public community. The other
developers could start a fork based on the latest free copy of the code
and continue as if nothing had happened.
Doing Nothing
Some projects never collect CLAs or CAs from
their contributors. Instead, they accept code whenever it seems
reasonably clear that the contributor intended it to be incorporated
into the project.
This can seem to work for a long time, as long as the project
has no enemies. But I don't recommend it. Someone may eventually
decide to sue for copyright infringement, alleging that they are the
true owner of the code in question and that they never agreed to its
being distributed by the project under an open source license. For
example, the SCO Group did something like this to the Linux project (see
https://en.wikipedia.org/wiki/SCO-Linux_controversies
for details). When this happens, the project will have no
documentation showing that the contributor formally granted the right
to use the code, which could make some legal defenses more
difficult.
Contributor License Agreements
CLAs probably offer the best tradeoff between safety and
convenience. A CLA is typically an electronic form that a developer
fills out and sends in to the project, or even a web-based checkbox
that the developer checks before completing their first contribution
to the project. In many jurisdictions, such email
submission or an online form is enough, though you should consult with
a lawyer to see what method would be best for your project.
Some projects use two slightly different CLAs, one for
individuals, and one for corporate contributors. But in both types,
the core language is the same: the contributor grants the
project a "...perpetual, worldwide, non-exclusive, no-charge,
royalty-free, irrevocable copyright license to reproduce, prepare
derivative works of, publicly display, publicly perform, sublicense,
and distribute [the] Contributions and such derivative
works." Again, you should have a lawyer approve any CLA,
but if you get all those adjectives into it, you're off to a good start.
When you request CLAs from contributors, make sure to emphasize
that you are not asking for actual copyright
assignment. In fact, many CLAs start out by reminding the reader of
this, for example like so:
This is a license agreement only; it does not transfer
copyright ownership and does not change your rights to use your own
Contributions for any other purpose.
Developer Certificate of Origin (DCO): An Easier Style of CLA
More and more projects are now using a particularly convenient
style of simple CLA known as a Developer Certificate of
Origin (DCO).
A DCO is essentially an attestation that the contributor intends
to contribute the enclosed code under the project's license, and that
the contributor has the right to do so. The contributor indicates her
understanding of the DCO once, early on, for example by emailing its
text from her usual contribution address to a special archive at the
project.The DCO text is provided by the project, but
you don't have to write your own from scratch; see https://developercertificate.org/ for example.
Thereafter, the contributor includes a "Signed-Off-By:" line in her
patches or commits, using the same identity, to indicate that the
corresponding contribution is certified under the DCO. This gives the
project the legal cover it needs, while giving contributors a
low-bureaucracy process for submitting their contributions. The DCO
relies on the project's native open source license for any trademark
or patent provisions, which in most cases is fine.
The simplification that makes DCOs work so well is that they set
the inbound license of the contribution to be the same as the outbound
license of the project. This avoids the sticky issues that a more
complex CLA can create, whereby the recipient of the CLA might reserve
the right to relicense the project (and thus all the past
contributions) under some different license in the future, possibly
even a proprietary license. DCOs are probably the minimum amount of
CLA a free software project should adopt, but for some circumstances a
more complex CLA may still be the better course.
Proprietary Relicensing
Some companies offer open source code with a
proprietary relicensing
scheme,This is sometimes also called dual
licensing, but that term is ambiguous, as it has
historically also referred to releasing open source software under two
or more open source licenses simultaneously. I am grateful to Bradley
Kuhn for pointing out this ambiguity and suggesting the more accurate
term. in which an open source version of the
software is available under the usual open source terms, while a
proprietary version is available for a fee.
Why would anyone want a proprietary version, when an open source
version is already out there? There are two separate answers,
reflecting the two different kinds of proprietary relicensing.
The first kind is about selling
exceptions to copyleft requirements, and is typically used
with code libraries rather than with standalone applications. The way
it works is that the library's owner (i.e., copyright holder), seeing
that some of the library's users want to incorporate it into their own
proprietary applications, sells them a promise to
not enforce the redistribution requirements of
the open source version's license. This only works when the open
source code is under a copyleft-style license, of
course — in practice it is usually the GPL or
AGPL.
With this promise in hand, the downstream users can use the
library in their proprietary product without worry that they might be
forced to share the source code to their full product under the copyleft
license. One well-known example of "selling exceptions" is the MySQL
database engine, which is distributed under the GPL version 2, but
with a proprietary license offering available for many years, first
from the Swedish company MySQL AB, and later from Oracle, Inc, which
purchased MySQL AB in 2008.
The second kind of proprietary relicensing, sometimes called the
freemium or open core
model, uses an open source version to
drive sales of a presumably fancier proprietary version (see
for a discussion of some
marketing pitfalls to avoid in this situation). Usually the
company offering the proprietary version is also the primary
maintainer of the open source version, in the sense of supplying most
of the developer attention (this is usually inevitable, for reasons
we'll get to in a moment). Furthermore, although in theory the
company could offer paid support for both the
open source and proprietary versions,In both cases usually hosted
as Software-as-a-Service (SaaS), just to be clear.
in practice they almost
always offer it only for the proprietary version, because then they
can charge two fees: a subscription fee for the software itself and a
fee for the support services, with only the latter having any marginal
cost to the supplier.
You might be wondering: how can the copyright holder offer the
software under a proprietary license if the terms of the GNU GPL
stipulate that the code must be available under less restrictive
terms? The answer is that the GPL's terms are something the copyright
holder imposes on everyone else; the owner is therefore free to decide
not to apply those terms to itself. In other
words, one always has the right to not sue one's self for copyright
infringement. This right is not tied to the GPL or any other open
source license; it is simply in the nature of copyright law.
Problems with Proprietary Relicensing
Proprietary relicensing, of both varieties, tends to suffer from
several problems.
First, it discourages the normal dynamics of open source
projects, because any code contributors from outside the company are
now effectively contributing to two distinct entities: the free
version of the code and the proprietary version. While the
contributor will be comfortable helping the free version, since that's
the norm in open source projects, she may feel less enthusiastic about
her contributions being useable in a monopolized proprietary product.
That is, unlike a straight non-copyleft license by which anyone has
the right to use the code as part of a proprietary work, here only
one party has that right, and other participants
in the project are thus being asked to contribute to an asymmetric
result.
This awkwardness is reflected and in some ways amplified by
the fact that in a proprietary relicensing scheme, the copyright owner
must collect some kind of formal agreement from each contributor (see
earlier in this chapter), in
order to have the right to redistribute that contributor's code under
a proprietary license. Because such an agreement needs to give the
collecting entity special, one-sided rights that a typical open source
contributor agreement doesn't include, the process of collecting
agreements starkly confronts contributors with the imbalance of the
situation, and some of them may decline to sign. (Remember, they
don't need to sign a contribution agreement in order to distribute
their own changes along with the original code; rather, the
company needs the agreement in order to
redistribute the contributor's changes under a proprietary
license. Asymmetry cuts both ways.)
Historically, many companies that have started out offering a
seemingly clear proprietary relicensing option — use
our product under open source terms, or buy a proprietary license so
you can use it under proprietary terms — have eventually
graduated to something closer to a "shakedown" model instead, in which
anyone who makes commercially significant use of the code ends up
being pressured to purchase a proprietary license as a way of
protecting their commercial revenue stream from harassment. The
precise legal bases on which this pressure rests differ from case to
case, but the overall pattern of behavior has been remarkably
consistent.
Naturally, neither the companies initiating these shakedowns nor
the parties who are its targets (most of whom eventually capitulate)
have anything to gain from going on the record about it, so I can only
tell you that I have heard of it informally and off-the-record from
multiple sources, at different projects and different companies.
One reason I generally advise companies who are serious about open
source development to stay away from proprietary relicensing is that,
if history is a reliable guide, the temptation to undermine the open
source license will be overwhelming to the point of being impossible
to resist.
Finally, there is a deep motivational problem for open source
projects that operate in the shadow of a proprietarily relicensed
version: the sense that most of the salaried development attention is
going to the proprietary version anyway, and that therefore spending
time contributing to the open source version is a fool's
game — that one is just helping a commercial entity
free up its own developers to work on features that the open source
community will never see. This fear is reasonable on its face, but it
also becomes a self-fulfilling prophecy: as more outside developers
stay away, the company sees less reason to invest in the open source
codebase, because they're not getting a community multiplier effect
anyway. Their disengagement in turn discourages outside developers,
and so on.
What seems to happen in practice is that companies that offer
proprietarily relicensed software do not get truly active development
communities with external participants. They get occasional
small-scale bug fixes and cleanup patches from the outside, but end up
doing most of the hard work themselves. Since this book
is about running free software projects, I will just say that in my
experience, proprietary relicensing schemes inevitably have a negative
effect on the level of community engagement and the level of technical
quality on the open source side. If you conclude that for business
reasons you want to try it anyway, then I hope this section will at
least help you mitigate some of those effects.Sometimes the
terms-of-service agreements for online software distribution
services — the Apple App Store, for
example — effectively force you to use proprietary
relicensing if you want to distribute copylefted software. I won't go
into detail here, but if you're distributing GPL-licensed or other
copylefted code from a place that restricts users from redistributing
what they download, you may be in this situation. For more
information, see Steven J. Vaughan-Nichols' article No GPL
Apps for Apple's App Store (https://www.zdnet.com/article/no-gpl-apps-for-apples-app-store/),
Richard Gaywood's followup article The GPL, the App Store,
and you (https://www.engadget.com/2011/01/09/the-gpl-the-app-store-and-you/),
and Pieter Colpaert's explanation of how the iRail and BeTrains projects used pro
forma dual-licensing to get around the problem,
About Apple store, GPL’s, VLC and BeTrains
(https://bonsansnom.wordpress.com/2011/01/08/about-apple-store-gpls-vlc-and-betrains/).
Thanks to reader Nathan Toone for pointing out this problem.
Trademarks
Trademark law as applied to open source projects does not differ
significantly from trademark law as applied elsewhere. This sometimes
surprises people: they think that if the code can be copied freely,
then that can't possibly be consistent with some entity controlling a
trademark on the project's name or logo. It is consistent, however,
and below I'll explain why, and give some examples.
First, understand what trademarks are about: they are about
truth in labeling and, to some degree, about endorsement. A trademarked
name or symbol is a way for an entity — the entity who
owns or controls that trademark — to signal, in an
easily recognizable way, that they approve of a particular product.
Often they are signaling their approval because they are the source of
the product, and purchases of that product provide a revenue stream
for them. But that is not the only circumstance under which someone
might want to enforce accurate attribution. For example,
certification marks are trademarked names or symbols that an entity
applies to someone else's product, in order to
signal that the product meets the certifying entity's
standards.
Importantly, trademarks do not restrict copying,
modification, or redistribution. I cannot emphasize this
enough: trademark is unrelated to copyright, and does not govern the
same actions that copyright governs. Trademark is about what you may
publicly call things, not about what you may do with those things nor
with whom you may share them.
One famous example of trademark enforcement in free and open
source software demonstrates these distinctions clearly.
Case study: Mozilla Firefox, the Debian Project, and Iceweasel
The Mozilla Foundation owns the trademarked name "Firefox",
which it uses to refer to its popular free software web browser of the
same name. The Debian Project, which maintains a long-running and
also quite popular GNU/Linux distribution, wanted to package Firefox
for users of Debian GNU/Linux.
So far, so good: Debian does not need Mozilla's permission to
package Firefox, since Firefox is free software. However,
Debian does need Mozilla's permission to call the
packaged browser "Firefox" and to use the widely-recognized Firefox
logo (you've probably seen it: a long reddish fox curling its body and
tail around a blue globe) as the icon for the program, because those
are trademarks owned by Mozilla.
Normally, Mozilla would have happily given its permission.
After all, having Firefox distributed in Debian is good for Mozilla's
mission of promoting openness on the Web. However, various technical
and policy effects of the Debian packaging process left Debian unable
to fully comply with Mozilla's trademark usage requirements, and as a
result, Mozilla informed Debian that their Firefox package could not
use the Firefox name or branding. No doubt Mozilla did so with some
reluctance, as it is not ideal for them to have their software used
without clear attribution. However, they could have given Debian a
trademark license and yet chose not to; presumably, this is because
Debian was doing something with the code that Mozilla did not want
affecting their own reputation.In fact, that was
indeed the reason, though we do not need to go into the details here
of exactly what changes Debian made to the Firefox code that Mozilla
disagreed with strongly enough to want to dissociate their name from
the result. The entire saga is recounted in more detail at https://en.wikipedia.org/wiki/Mozilla_software_rebranded_by_Debian.
Coincidentally, I'm writing these words on a Debian GNU/Linux system,
where Iceweasel, now fortunately able to be called Firefox again, has
long been my default browser — I just used it to check
that URL.
This decision by Mozilla did not mean that Debian had to remove
Firefox from their package list, of course. Debian simply changed
the name to "Iceweasel" and used a different logo. The underlying
code is still the Mozilla Firefox code, except for the minor bits
Debian had to change to integrate the different name and
logo — changes they were perfectly free to make, of
course, because of the code's open source license.
It is even consistent to license your project's logo artwork
files under a fully free license while still retaining a trademark on
the logo, as the following story of the GNOME logo and the fish
pedicure shop (I'm not making this up) illustrates.
Case study: The GNOME Logo and the Fish Pedicure Shop
The GNOME project (https://gnome.org/), which
produces one of the major free software desktop environments, is
represented legally by the GNOME Foundation (https://www.gnome.org/foundation/),
which owns and enforces trademarks on behalf of the project. Their
best-known trademark is the GNOME logo: a curved, stylized foot with
four toes floating close above it.You can see examples
at https://www.gnome.org/foundation/legal-and-trademarks/.
One day, Karen Sandler, then the Executive Director of the GNOME
Foundation, heard from a GNOME contributor that a mobile fish-pedicure
van (fish pedicure is a technique in which one places one's feet in
water so that small fish can nibble away dead skin) was using a
modified version of the GNOME logo. The central foot part of the
image had been slightly modified to look like a fish, and a fifth toe
had been added above, so that the overall logo looked even more like a
human foot but cleverly made reference to fish as well. You can see
it, along with discussion of other trademark issues GNOME has dealt
with, in the Linux Weekly News article where this story is told in
full: https://lwn.net/Articles/491639/.
Although GNOME does actively enforce its trademarks, Sandler did
not see any infringement in this case: the fish-pedicure business is
so distant from what the GNOME Project does that there was no
possibility of confusion in the mind of the public or dilution (if
you'll pardon the expression) of the mark. Furthermore, because the
copyright license on GNOME's images is an open
source license, the fish pedicure company was free to make their
modifications to the graphic and display the results. There was no
trademark violation, because there was no infringement within GNOME's
domain of activity, and there was no copyright violation, because
GNOME's materials are released under free licenses.
The point of these examples is to merely show that there is no
inherent contradiction in registering and maintaining trademarks
related to open source projects. This does not mean that a trademark
owner should do whatever they want with the marks, ignoring what other
participants in the project have to say. Trademarks are like any
other centrally-controlled non-forkable resource: if you use them in a way that
harms a significant portion of the project's community, then expect
complaints and pushback in return; if you use them in a way that
supports the goals of the project, then most participants will be glad
and will consider that use to be itself a form of contribution.
Patents
Software patents have long been a lightning rod issue in
free software, because they pose the only real threat against which
the free software community cannot defend itself. Copyright and
trademark problems can always be gotten around. If part of your code
looks like it may infringe on someone else's copyright, you can just
rewrite that part while continuing to use the same underlying
algorithm. If it turns out someone has a trademark on your
project's name, at the very worst you can just rename the project.
Although changing names would be a temporary inconvenience, it
wouldn't matter in the long run, since the code itself would still do
what it always did.
But a patent is a blanket injunction against implementing a
certain idea. It doesn't matter who writes the code, nor even what
programming language is used. Once someone has accused a free
software project of infringing a patent, the project must either stop
implementing that particular feature, or expose the project
and its users to expensive and
time-consuming lawsuits. Since the instigators of such lawsuits are
usually corporations with deep pockets — that's who has the
resources and inclination to acquire patents in the first
place — most free software projects cannot afford either to defend
themselves nor to indemnify their users, and must capitulate
immediately even if they think it
highly likely that the patent would be unenforceable in court. To
avoid getting into such a situation in the first place, free software
projects have sometimes had to code defensively, avoiding patented
algorithms in advance even when they are the best or only available
solution to a programming problem.
Surveys and anecdotal evidence show that the vast
majority of not only open source programmers but
of all programmers think that software patents
should be abolished entirely.See
https://groups.csail.mit.edu/mac/projects/lpf/Whatsnew/survey.html
for one such survey. Open source programmers tend to feel
particularly strongly about it, and may refuse to work on projects
that are too closely associated with the collection or enforcement of
software patents. If your organization collects software patents,
then make it clear, in a public and legally enforceable way, that the patents
would never be enforced when the infringement comes from open source
code, and that the patents are
only to be used as a defense in case some other party initiates an
infringement suit against your organization. This is not only the
right thing to do, it's also good open source public relations.
For example, RedHat pledged that open source projects are
safe from its patents, see
https://www.redhat.com/en/about/patent-promise.
Unfortunately, collecting patents purely for defensive purposes
is rational. The current patent system, at least in the United
States, is by its nature an arms race: if your competitors have
acquired a lot of patents, then your best defense is to acquire a lot
of patents yourself, so that if you're ever hit with a patent
infringement suit you can respond with a similar threat — then the
two parties usually sit down and work out a cross-licensing deal so
that neither of them has to pay anything, except to their patent
lawyers of course.
The harm done to free software by software patents is more
insidious than just direct threats to code development, however.
Software patents encourage an atmosphere of secrecy among firmware
designers, who justifiably worry that by publishing details of their
interfaces they will be making it easier for competitors to find ways
to slap them with patent infringement suits. This is not just a
theoretical danger; it has apparently been happening for a long time
in the video card industry, for example. Many video card
manufacturers are reluctant to release the detailed programming
specifications needed to produce high-performance open source drivers
for their cards, thus making it impossible for free operating systems
to support those cards to their full potential. Why would the
manufacturers withold these specs? It doesn't make sense for them to
work against software support; after all,
compatibility with more operating systems can only mean more card
sales. But it turns out that, behind the design room door, these
shops are all violating one another's patents, sometimes knowingly and
sometimes accidentally. The patents are so unpredictable and so
potentially broad that no card manufacturer can ever be certain it's
safe, even after doing a patent search. Thus, manufacturers dare not
publish their full interface specifications, since that would make it
much easier for competitors to figure out whether any patents are
being infringed. (Of course, the nature of this situation is such
that you will not find a written admission from a primary source that
it is going on; I learned it through a personal communication.)
Modern free software licenses generally have clauses to combat,
or at least mitigate, the dangers arising from software patents.
Usually these clauses work by automatically revoking the overall open
source license for any party who makes a patent infringement claim
based on either the work as a wholeRemember that a
patent may cover — or "read on", in patent
jargon — code that the patent
owner did not themselves write. It is thus not necessary for a party
to have contributed code to an open source project in order to claim patent
infringement by that project.
or on the claimant's contributions to the project. But
though it is useful, both legally and politically, to build patent
defenses into free software licenses in this way, in the end these
protections are not enough to dispel the chilling effect that the
threat of patent lawsuits has on free software. Only changes in the
substance or interpretation of international patent law will do
that.
Recent developments, such as the 2014 decision by the
U.S. Supreme Court against the patentability of abstract ideas, in
Alice Corp. v. CLS Bank (https://en.wikipedia.org/wiki/Alice_Corp._v._CLS_Bank_International),
have made the future of software patents unpredictable. But there is
so much money to be extracted via infringement claims, in particular
by "patent trolls" (https://en.wikipedia.org/wiki/Patent_troll) but in general by any entity with a large patent
portfolio and a lack of other revenue sources, that I am not
optimistic this fight will be over any time soon. If you want to
learn more about the problem, there are good links in
the Wikipedia article https://en.wikipedia.org/wiki/Software_patent. I've also written
some blog posts summarizing the arguments against software patents,
collected at https://www.rants.org/patent-posts/. As of this writing it's been
about ten years since the main posts there were published, but all the
reasons why software patents are a bad idea are just as true now as
they were then.
Since 2005, the Open Invention Network (https://openinventionnetwork.com/) has been providing a "patent
non-aggression community" for open source software. OIN members agree
to provide royalty-free cross-licensing for a broad set of patents
that read on widely-used open source software. Oversimplifying a bit,
joining OIN is essentially a way to say "Our company doesn't want to
enforce software patents on anyone else, at least not ones that affect
open source software, and we don't want anyone enforcing them on us
either." Membership is free and anyone may join. My company is a
member, and I encourage you to consider OIN membership for your
organization (if any) as well.
Further Resources
This chapter has only been an introduction to free software
licensing, trademark, and patent issues. Although I hope it contains
enough information to get you started on your own open source project,
any serious investigation of legal issues will quickly exhaust what
this book can provide. Here are some other resources:
https://opensource.org/licenses
The OSI license introduction page is a
well-maintained source of information about widely used
open source licenses, and offers answers to frequently
asked questions. It's a good place to start if you have a
general idea of what open source licenses do, but now need
more information, for example to choose a license for your
project.
Open (Source) for Business: A Practical
Guide to Open Source Software Licensing by
Heather Meeker. Published April 2015. https://www.amazon.com/Open-Source-Business-Practical-Licensing/dp/1511617772
Although organized around licensing and open source
legal concepts, this is a general guide to open source and
business, and the author has a lot of experience in the
field.
Intellectual Property and Open Source:
A Practical Guide to Protecting Code by Van
Lindberg. Published by O'Reilly Media, first edition
July 2008, ISBN: 978-0-596-51796-0
This is a full-length book on open source licensing,
trademarks, patents, contracting, and more. It goes into
much deeper detail than I could in this chapter.
https://www.oreilly.com/library/view/intellectual-property-and/9780596517960/
for details.
Make Your Open Source Software
GPL-Compatible. Or Else. by Dr. David
A. Wheeler, at
https://dwheeler.com/essays/gpl-compatible.html.
This is a detailed and well-written article on why
it is important to use a GPL-compatible license even if
you don't use the GPL itself. The article also touches on
many other licensing questions, and has a high density of
excellent links.