[Sugar-devel] License notices in GPLvN-or-later software
brett at fsf.org
Mon Apr 25 12:10:17 EDT 2011
In the discussion about the proposal to move Sugar to GPLv3+, there's
been some disagreement about what can and can't be done with the
project's license notices and the like. Questions about this are
getting bounced up to me through different channels -- so much that
cjb asked if I could answer questions here directly. So here I am.
I think a big reason this conversation has been difficult is because a
lot of the terms, like "relicensing," are not well-defined. Usually
the context makes their real meaning clear enough, but since we're
talking about future plans here, I suspect that people mean different
things by it. So I'm going to try to step away from that kind of
language and work through the mechanics of what is or isn't required,
and why. I'll start by talking about the licensing of the software on
a sort of abstract level, and then move on to what that means for
license notices specifically.
### Licensing programs with multiple licenses
In the free software world, it rarely makes sense to talk about
"changing the license" for a program. Here I'm talking about
releasing unchanged software under a new license, not a project's
decision to release future versions under a new license. When this
happens, it's almost always the case that what's really happening is
that the software is now available under another license in addition
to all the license(s) it was available under previously. None of the
old licenses are revoked, the software may still see wide distribution
under one or more of those old licenses, and often they're still
readily available from the original VCS repository.
So when we say things like "You can't change the license on the
software," it would be more accurate to say something like "You can't
distribute the software under a particular license unless its
copyright holders give you permission." The distinction here is
important when software is released under multiple licenses.
Normally when we think of software released under multiple licenses,
we think of dual-licensed software like Perl or Mozilla's tri-license.
When software is distributed this way, you may distribute it further
under the terms of any single one of the licenses, or some combination
of them. This is the principle that lets projects get GPL
compatibility by dual-licensing under a GPL-compatible license. If
you had to respect *all* the licenses when you distributed such
software, this common licensing strategy wouldn't work. It only works
because developers who need GPL compatibility, because they're
combining the work with GPL-covered code, are able to follow the terms
of the compatible license, and only that compatible license. And
that's fine, because the copyright holders gave them permission to
distribute the work under that license -- as well as permission to
distribute it under another, GPL-incompatible license.
Software released under some version of the GPL "or (at your option)
any later version" works on exactly the same principles (at least,
once a later version of the GPL becomes available). Right now,
software that's GPLv2-or-later is, practically speaking,
dual-licensed: you can distribute it under the terms of GPLv2 and/or
People who say that "You can't change the license of a GPLv2-or-later
program to GPLv3-or-later" have a good general principle in mind, but
are misapplying it. It would translate to "You can't distribute a
GPLv2-or-later program under GPLv3-or-later without the copyright
holders' permission." But that statement doesn't mean much. The
copyright holders already gave recipients permission to distribute the
program under GPLv3-or-later: that's the whole point of the -or-later
So there's no problem if a party receives code under GPLv2-or-later,
and distributes it under GPLv3-or-later. Now let's look at what
happens with the license notices if they do that.
### Notices on works under multiple licenses
Maintaining copyright notices on a work -- the lines like "Copyright
2011 John Doe" -- is required by copyright law. Maintaining license
notices is a condition of almost every free software license. (Off
the top of my head, the only exception I can recall is the WTFPL --
'nuff said.) In GPLv3, this condition is in section 4; it says that
when you convey the work, you must "keep intact all notices stating
that this License and any non-permissive terms added in accord with
section 7 apply to the code."
If a party distributes a work under GPLv3-or-later, they are only
required to include license notices that refer to GPLv3-or-later. A
party who converts GPLv2-or-later notices on a work to GPLv3-or-later
notices is in compliance with this condition, as long as they follow
all the other conditions in GPLv3 when they distribute the work. And
one of those conditions is that they *must* include a copy of the text
Please don't read this condition too strictly, though. It's
acceptable to distribute a work under GPLv3 with GPLv2-or-later
notices on it: such notices make it sufficiently clear that GPLv3 can
also apply to the work, and so they fulfill the condition in GPLv3
section 4. But nothing compels a distributor to leave the original
license notices completely untouched, or otherwise tell recipients,
"This specific work is available under all these different licenses."
None of this is unique to the GPL, either; the same is true in other
situations where a program has multiple licenses. For example, a
distributor who receives tri-licensed code from Mozilla may choose to
distribute the work only under one of those licenses. If they do,
they may remove all the notices about the tri-license, and instead
replace them with the notices required by the license they're using.
We don't think distributors should change license notices merely
because they can; that needlessly discourages cooperation with the
original developers. But it often makes a lot of practical sense to
do so. You might think that recipients appreciate having fine-grained
license information about every file in the project, so they might use
that piece under whatever available license best suits their needs.
Instead, this benefit is often outweighed by the fact that such
scattered license notices make it difficult to make definitive
statements about what you can and can't do with the whole project.
I've seen projects before that suffer from this: any individual file
could be released under one of several different licenses, with little
apparent rhyme or reason about what licenses are used where. It's
difficult for me to imagine that this granularity provides benefits
that justify the lack of clarity for the project as a whole.
Consistent license notices help create shared understanding about what
can be done with the project, and what the conditions are.
A party who receives a work under GPLv2-or-later may distribute it
under GPLv3-or-later; the copyright holder has given them permission
to do so. Such a distributor must include a copy of GPLv3 with the
work, and may update the license notices to say that the work is
distributed under the terms of GPLv3-or-later, so long as they
otherwise comply with the conditions in GPLv3.
License Compliance Engineer, Free Software Foundation
Support the FSF by becoming an Associate Member: http://fsf.org/jf
More information about the Sugar-devel