zooko at zooko.com
zooko at zooko.com
Wed Aug 15 14:37:31 UTC 2001
Many thanks to everyone who provided feedback and encouragement. I've revised
the document quite a bit, trying to incorporate your suggestions, and you can
see the latest version at:
Also, I'll append the latest version to this e-mail.
One question I have is that <forrest at mibsoftware.com> suggested that I add
licenses. As I mention in the document, I explicitly want to cover a *minimal*
set of licenses, but if there is a license that you think really ought to be
added, please let me know (and also let me know what values it should have in
By the way, I've received notice that the license_quick_ref.html will be posted
to newsforge.com soon, so I expect a lot more hits.
------- begin appended license_quick_ref.txt
[*]introduction | [*]current events | [*]stuff
Quick Reference For Choosing a Free Software License
All hyperlinks which lead to a different web site are marked with this
QUICK REFERENCE FOR FREE SOFTWARE LICENSES, version 0.8.3, 2001-08-15
| Community likes to accept code under it
| | Combine with proprietary and redistribute
| | | Combine with GPL and redistribute
| | | | Must share source of redistributed version
| | | | | Must contribute patents
| | | | | | Indemnify against lawsuits
| | | | | | |
| | | | | | |
v v v v v v v
--- --- --- --- --- --- ---
X11/BSD-new Y Y Y N N N
GNU LGPL Y Y Y Y N N
GNU GPL Y? N Y Y N N
Mozilla PL 1.1 N? Y N1 Y? ? ?
Common PL Y2 Y N3 Y Y Y
* "?" means I'm not sure.
* "1" MPL 1.1 can be specifically amended to allow combining with GPL,
according to the FSF's license list[-->]
* "2" the "Common Public License", which was written by IBM and which
serves as the template from which the IBM Public License is generated,
is little-known, but liked by those who know of it; However, the
community strongly dislikes having to deal with unfamiliar licenses,
because they raise unexplored legal issues
* "3" Modules under Common PL cannot be combined with modules under GPL,
even though the FSF wishes that they could. The reason is that the
Common PL forbids you from extending an open source app with some code
on which you have a patent, and then redistributing the resulting
new-app unless you accompany it with a patent license that allows
people to use it. RMS didn't think of that when he wrote the GPL, and I
predict that the FSF will add something like it in a future version of
the GPL, but in the meantime there is the ironic situation that since
the Common PL is more restrictive than the GPL license, it is illegal
to redistribute an app made up of combined GPL and Common PL code. By
the way, since a lot of extant free software is licensed under "Version
2 of the GPL or any later version"[-->], if the FSF were to come up
with a new version of the GPL which allowed linking with Common PL'ed
code, then you could immediately combine your Common PL'ed and GPL'ed
code together and ship the resulting app as soon as you heard the news.
Or even before you heard the news, as long as the new version of the
GPL was already in existence at that time. Weird, eh?
Explanations of columns:
* "Community likes to accept code under it" -- I intend this to mean
whether members of the community like to use source code under this
license, instead of whether members of the community like to create new
source code under this license. This is because I'm assuming that the
reader has already created their own source code, and I'm assuming that
they want their source code to be used as widely possible by members of
the open source/free software community. The difference between these
two meanings of "likes it" is shown up by the case of the GPL: a
hypothetical open source/free software hacker may prefer to create
source code under the GPL, but may prefer to use source code licensed
to her under a license that permits her to combine the licensed source
code with proprietary source code. This is obviously subjective (maybe
the community doesn't really like The Frobozz Public License, but my
biased perspective makes me think that they do), but it is a very
important factor when deciding what license to use. If you feel that my
summary above is inaccurate, please let me know.
* "Combine with proprietary and redistribute" -- Is it legal to accept
code from its author under the terms of this license, combine it with
proprietary code, and ship the resulting application to a third person
without giving them freely licensed source code of the proprietary
* "Combine with GPL and redistribute" -- It is legal to accept code from
its author under the terms of this license, combine it with GPL'ed
code, and ship the resulting application to a third person?
* "Combine with MPL and redistribute" -- It is legal to accept code from
its author under the terms of this license, combine it with MPL'ed
code, and ship the resulting application to a third person?
* "Must share source of proprietary version" -- Does this license forbid
the recipient of the source code from modifying it and shipping his
modified version to a third party without giving them the source?
* "Must contribute patents" -- Does this license require that if the
recipient combines the code with his own contribution and then ships
the resulting combined app, that he must contribute a license to any
patents that he holds that would restrict usage of the resulting app.
* "Indemnify against lawsuits" -- Does this license protect the original
author from damages that might result from a lawsuit incurred by the
use that the recipient puts the code to?
This Is Not Legal Advice
I am not a lawyer, and this is not legal advice. I do not accept any
responsibility or liability for the consequences of any actions you may take
after reading this document.
(Note: some lawyers have already written to me to suggest that this document
looks like legal advice, and that this could get me into trouble. While I
sincerely appreciate their help, I am unsure how to proceed. Apparently the
only way to be safe against the accusation of having given "legal advice" is
to write with such ambiguity and obfuscation that nobody can learn anything
from what you've written. Presumably this culture of fear increases the
demand for lawyers' services. I value speaking plainly, and I feel that
plain discussion of software licenses is much needed. In particular, this
document would be useless if it all specifics were removed in favor of
cautious generalities. Therefore, I simply reiterate that I am not a lawyer
and that I am not acting as one in describing my understanding of the law in
There are probably incorrect statements in this document -- I have already
discovered several such "bugs" from earlier versions. If you see one, please
inform me so that I can fix it.
My goal in writing this document is to provide information for people who
are choosing a free software license for their own projects. My goal in this
document is not advocacy.
Nonetheless, my biases will inevitably show through in places. One prominent
example of my bias is that I arranged it so that the answer is "Y" for all
the features that I personally like. For example, in the case of "Must share
source of redistributed version", I could have called it "Can redistribute
proprietary version", and NOT'ed all the values, but I wanted to be able to
scan across a row counting "Y"'s as good and "N"'s as bad. If you think that
allowing recipients of your code to alter the code and ship proprietary
versions is good, then I suggest you make a copy of the table, remove the
"Not" from that column heading, and NOT all the values in that column. Then
it will be easier for you to read with value-judging eyes. (By the way, it
would be cool if someone would write a CGI script which asks you to enter
your own preference and then shows you this quick reference card with the
An even more insidious example of my bias is what I've omitted. I tried to
pick only the licenses which free software/open source hackers might
seriously be considering using. The Sun Community Source License and the
Microsoft Shared Source License, for example, do not appear.[footnote 1]
Moreover, I have deliberately tried to omit licenses which are
"overshadowed" by another license which has substantially similar
characteristics but is more widely known and used. The goal of this document
is to help people choose a license for their own code, not to provide a map
of all extant licenses, and I assume that authors prefer a widely known and
used license over an equivalent but obscure one, or (gack!) inventing Yet
Another Free Software License of their own.
What About Public Domain?
According to these messages on the opensource.org license-discuss mailing
list: [1[-->], 2[-->], 3[-->], 4[-->], 5[-->]], it is not clear that it is
even possible to voluntarily place your software into the public domain
under United States law. There is a common myth that one can do so simply by
creating a work and writing "This software/work/text is hereby placed in the
public domain.", but that does not do, legally, what it is commonly believed
to do. For example, it might later be possible for you to assert your
ownership over the code and forbid others to use it. Also, it might be
possible for a user to sue you as the author of the code.
If you want your source code to be usable in that way, then you should
consider using the X11 or modified BSD license, which add only the
restrictions that the copyright notice and disclaimer of warranty remain
The License Does Not Restrict The Copyright Holder!
The most common misunderstanding about software licenses is that giving
someone else a copy of your source code under a license restricts what you
are allowed to do with your source code. The truth is, if you write some
code, and give it to someone else under the terms of License X, or publish
it so that anyone may use it under the terms of License X, that this does
not subject you to the terms of License X! You are the author of the code,
and you hold the copyright, and giving someone permission to use the code
does not restrict you to using the code in only the way that they are
allowed to use it!
Now it may be that some licenses do contain clauses which constrain the
original author. I'm not sure whether any of the five licenses in our quick
reference contain any such clauses, nor, if they, do whether they are
legally enforceable. But the important myth that I wish to dispel is the
notion that giving someone permission to use your source code automatically
restricts how you may use your source code. For example, if I give you
permission to make copies of a document that I have written, but only if you
stand on your head while doing so, this does not mean that I must stand on
my head whenever I make copies of my document.
But What About Patches?
However, there is a catch. Suppose you publish your code under License X,
and then another person writes a patch that fixes bugs and adds features,
and sends you the patch, and you add the patch to your own source tree and
publish a new version. Now, what rights do you have to the contents of the
patch? And how did including the patch into your source code affect your
rights to the source code?
This is a murky area. People who have thought about it seem to be of the
opinion that if the patch is sufficiently small and simple, then it has no
legal effect, but that if it is a large and complex patch, that you need
permission from the author of the patch (who is, naturally, the holder of
the copyright to the patch) before you can "combine" the patch with your
source code and ship the resulting "derived work".
But suppose that you and the author of the patch didn't discuss the matter?
Now it gets really murky. It might be the case that the author of the patch
could later sue you for having used his patch in a way that he didn't want,
but on the other hand a court might rule that by sending the patch to you,
it was understood that he was giving you the right to use it. Most actual
hackers seem to assume that submitters of patches are automatically granting
the recipient a license to use the patch and to use the combined work
derived from combining the patch with the original source tree. As far as I
know, this assumption is not supported by any legal fact.
This appears to be an open issue to me and I hope that the community,
especially the legally trained members of the community, will speak up.
Explanations of rows:
Please use the FSF's list of free software licenses[-->] and
opensource.org's list of open source licenses[-->] to find out more about
* "X11/BSD-new" is listed on the FSF's site as "The X11 license" and "The
modified BSD license". The modified BSD license is listed on the
opensource.org site as "The BSD license". The opensource.org site does
not include the X11 license, but it does list "The MIT license", which
is very similar to X11/BSD-new, except that X11/BSD-new forbid the
recipient from using the name of the author to endorse or promote
products, and the MIT license does not.
* "GNU LGPL" is listed on the FSF's site as "The GNU Lesser General
Public License (or GNU LGPL for short)". It is listed on the
opensource.org site as "The GNU Library or 'Lesser' Public License
* "GNU GPL" is listed on the FSF's site as "The GNU General Public
License (or GNU GPL for short)". It is listed on the opensource.org
site as "The GNU General Public License (GPL)".
* "Mozilla PL 1.1" is listed on the FSF's site as "The Mozilla Public
License (MPL)". It is listed on the opensource.org site as "The Mozilla
Public License 1.1 (MPL 1.1)".
* "Common PL" is a "license template", with spaces where you can write
the name of the author of the software. The IBM Public License v1.0 is
what you get when you take the Common Public License v0.5 and write in
"International Business Machines" in the spaces. The IBM Public License
is listed on the FSF's site as "IBM Public License, Version 1.0". The
IBM Public License is listed on the opensource.org site as "The IBM
Public License". Neither site mentions the Common Public License
itself, which you can find on IBM's developerWorks site[-->].
An up-to-date and accurate list of free software/open source licenses[-->]
is maintained by the FSF. It is a useful reference even if you do not share
the FSF's values with respect to source licenses. If this document and the
FSF's list disagree on a point of fact or a point of law, then it is very
likely a bug in this document and I would like to know about it.
opensource.org hosts a mailing list specifically about this issue. You can
browse the archives[-->]. They also have a list of licenses[-->] that meet
the Open Source Definition. As of this writing the list on opensource.org
appears to be less up-to-date and comprehensive than the list on the FSF's
footnote : That was a joke, mentioning Microsoft's so-called "Shared
Source" license. That license is in no way a free software or open source
Based on "license_quick_ref.html", originally written by Zooko in 2001 and
posted to "http://zooko.com/license_quick_ref.html".
written in 2001 by Zooko; You may copy and use this document in unmodified
form. Alternatively, you may copy and use this document in modified form,
provided that you remove this line (that begins: 'written in 2001 by
Zooko...') and retain the line above (that begins: 'Based on
Last modified: Wed Aug 15 07:18:50 PDT 2001
More information about the License-discuss