zooko.com

*introduction | *current events | *projects | *stuff

Quick Reference For Choosing a Free Software Licence

All hyperlinks which lead to a different web site are in this pretty green color: sample link

The latest version of this document can be found at http://zooko.com/licence_quick_ref.html.

QUICK REFERENCE FOR CHOOSING A FREE SOFTWARE LICENSE, version 4.0.0.0, 2008-02-26

Licence
  |           hackers like to accept code under it
  |             | must share source of redistributed derived work
  |             |   | must share source of redistributed version
  |             |   |   |
  |             |   |   |
  v             v   v   v
 ---           --- --- ---
permissive      Y1  N   N
GNU LGPL        Y1  N   Y
GNU GPL         Y1  Y   Y

Key:

Explanations of columns:

Explanations of rows:

Please use the Other Resources listed below to find out more about these licences.

Disclaimers

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 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 licences is much needed. In particular, this document would be useless if 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 simple terms.)

Bugs

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.

Bias

My goal in writing this document is to provide information for people who are choosing a free software licence 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 your own value-judging eyes. Peter Lowe <pgl@yoyo.org> has written an interactive web page that does this for you: http://pgl.yoyo.org/lqr/

An even more insidious example of my bias is what I've omitted. I tried to pick only the licences which free software/open source hackers might seriously be considering using. Moreover, I have deliberately omitted licences which are "overshadowed" by another licence which has substantially similar characteristics but is more widely known and used. The goal of this document is to help people choose a licence for their own code, not to provide a map of all extant licences, and I assume that authors prefer a widely known and used licence over an equivalent but obscure one, or -- gack! -- inventing Yet Another Free Software Licence of their own.

Issues

What About Public Domain?

According to these messages from the license-discuss mailing list: [1, 2, 3, 4, 5], it is not possible to voluntarily place your software into the public domain under United States law. The legal experts who wrote those messages say that the common belief that one can put one's work into the public domain simply by writing "This work is hereby placed in the public domain.", it a myth. They assert that this does not have the intended legal effect. 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 they are harmed by using the code..

Other experts, notably the Creative Commons, disagree, and say that the "I place this into the public domain." incantation does work.

I don't have the expertise to tell which of these groups of experts is right, but I can say that you might as well just use a permissive license such as BSD-new. I can think of no reason to use a legally uncertain public-domain-incantation when you could use a permissive licence. If you want your source code to be freely usable, then you should use the permissive licence.

Update: I recently met someone who refused to use some source code because it was under the "public domain incantation", and he didn't believe that it would be legal to use it under his country's legal system. He may have been wrong -- I have no idea -- but the fact that such people as he exists is reason to use a permissive licence instead of the public domain declaration.

The Licence Does Not Restrict The Copyright Holder!

The most common misunderstanding about software licences is that giving someone else a copy of your source code under a licence 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 Licence X, or publish it so that anyone may use it under the terms of Licence X, that this does not subject you to the terms of Licence 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!

For example, if I give you permission to make copies of a book that I wrote, 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 book.

But What About Patches?

However, there is a catch. Suppose you publish your code under Licence 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 licence to use the patch and to use the combined work derived from combining the patch with the original source tree. I do not know if this assumption is legally sound.

This appears to be an open issue. Nobody really knows.

Other Resources

Mark Webbink, Senior Vice President and General Counsel of Red Hat, Inc. wrote an article explaining the legal issues and the major differences between open source licences. Understanding Open Source Software - by Red Hat's Mark Webbink, Esq.

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

David Wallace Croft has written a pithy table comparing five licences and "public domain" against three licensee requirements: "Open Source License Comparison".


Based on "licence_quick_ref.html", originally written in 2001 through 2008 by Zooko, and posted to "http://zooko.com/licence_quick_ref.html".

written in 2001 through 2008 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 through 2008 by Zooko...') and retain the line above (that begins: 'Based on "licence_quick_ref.html"...').

Zooko O'Whielacronx
Last modified: 2008-02-26