I have some code that I'd like to release (open source); what license should I use?

That's the question I'm asking myself but it clearly isn't the right question to ask here.  More to the point are: What should I consider when choosing an open source license?  What are the differences between common licenses?  (Or even: What are are the right questions to be asking?)

It's definitively not an easy question. I'm in the same boat right now. I used to be a big fan of the GPL but in some ways I also like the BSD style licenses due to the amount of code it can be mesh with. I am not a lawyer so this not legal advice ;p

The questions come down to what kind of rights do you want to retain on the code when it's redistributed. GPL will force your users who redistribute the code in binary format to also provide the source and all the changes they made in to the code. It does not mean that they have to give back those changes if all they are doing is using it. Also all derivative works, like application that link to a GPL licensed library to open up that code too. (To avoid that you can licenses libraries under the LGPL)

BSD style licenses usually only force the users to keep the copyright statement you put in the header of the code on all future redistribution but makes not requirement on them to provide the code or anything, just that they keep the copyright statement. 

Most licenses are almost all just tweaks on these basic ones. 

I don't really know which one is best. There issues when trying to mesh GPL and BSD code together for example.

http://opensource.org/ has some good info on the different licenses.

Hope that helps.

Choosing a license doesn't limit you (the author). It's setting a default for what others may do with your work. Anyone is always able to contact you for different licenses. For example you can distribute the code under the GPL license and also sell proprietary licenses. You can change the license later if you choose.

The biggest difference is that the BSD license does not ensure that users of third party libraries are able to improve the code. The purpose of the GPL is to guarantee that.

There are no issues in meshing GPL and modified BSD code unless someone is trying to prevent users from using the source code.

Originally posted by Judd Storrs:
The GNU GPL fact seems to confirm this is no longer an issue with the revised BSD license: 

So forget what I said about that :) 

Licensing discussions do tend to be somewhat hormonal; here I express
my own hormones:

http://nipyworld.blogspot.com/2011/01/gp...

Here was our licensing discussion and why we chose BSD:

http://nipy.sourceforge.net/nipy/stable/...

Apart from the hormonal discussion:
1) For an application, chose GPL or BSD to taste
2) For a library, if you chose GPL, or even LGPL, someone will likely
find that they cannot use your library for a licensing reason, and
write a competitive BSD-licensed library.

From a rational perspective, I think the improvements made with Apache 2.0 over BSD/MIT as adopted by the ITK folks are intuitive.

Rationale and implementation details for Apache 2.0 in ITK

However, it would be useful to get some feedback from any lawyers on the forum. Especially as to how these licenses traverse geographical boundaries within and across countries.

Let me try to condense my experience with licensing from the distributor perspective into few points.


1. Choose a STANDARD license! Serious! NO exceptions.
---------------------------------------------------------------

This is the list of options: http://www.opensource.org/licenses

These licenses are well understood. it is known how they can be combined, what is possible and what is not. Any custom license is potentially dangerous. Written by people who might not know what they are doing, might focus on a particular national jurisdiction, a particular use case, add unnecessary/uneffective usage restrictions, ... The outcome of this is avoidable hassle, complications with legal compliance, difficulty to create derived software, hindering legal distribution. What sounds like a fancy license in the US might be illegal in the EU.


2. Enforce free software culture OR encourage widespread use (unconditionally)
-----------------------------------------------------------------------------------------

The basic decision is: copyleft or not.

GPL-style licenses (copyleft) enforce "open-sourcing" of derived software. That has many benefits for humanity. Not naming them here ... (too many)

More permissive (non-copyleft) licenses (e.g. BSD-style) don't do that. The advantage is that it removes the need to come up with a more permissively licensed implementation that can go into proprietary products. It POTENTIALLY encourages collaboration instead of fragmentation. However, it needs more than a license to make that work.

If you want to have your code used as much as possible: Go permissive!
If you want to make sure your work only goes into something free and open (so you could benefit from it yourself): Go copyleft.


3. Trust the law
-----------------

Do not put stuff into a license that is not yours to enforce.

Adding "Not FDA certified: You must not use this in clinical practice" is not good/necessary/relevant.

Every person operating medical equipment for patient treatment knows that they need to restrict themselves to certified products. If they don't, they go to prision/pay lots of money/loose their insurance/job/ etc. Hence, they won't use non-FDA-certified products to start with. If they do nevertheless it is not your problem. Here is what the BSD license says about that:

... THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL ... BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES.

If you nevertheless put the above sentence in the licence, your software is no longer free software (even if the rest says GPL). Even if somebody would like to take it, and actually put it through a certification process they couldn't, because it says: "You must not use this in clinical practice" -- so why bother.

Always see (1)


4. A license is not the place for politics/moral
---------------------------------------------------

Anything that restricts the freedom of use for ANY purpose turns software into a non-free product that makes it difficult to combine/derive/distribute. If you intend to develop free software, don't put:

"Must not use for nuclear bombs"
"Must not use for abortion"
"Must not use for animal research"

even

"Not for commerical use"
"Only for research"

will make it non-free! Instead of requiring "non-commercial" better go for GPL. "only for research" -> (3)

Always see (1)


----

The Debian Free Software Guidelines (DFSG) represent a widely acknowledged, human readable, 10-point checklist to assess whether something is a "good" license (valid beyond the scope of Debian).

http://www.debian.org/social_contract#gu...

Hard to come up with any additional bit of wisdom to compelment Michael's reply, so I will just cite a paper from mloss.org people, which I have mentioned to Christian in private correspondence:

http://jmlr.csail.mit.edu/papers/v8/sonnenburg07a.html

The Need for Open Source Software in Machine Learning

in Appendix A it covers some basic considerations behind choosing a license for your project.

Originally posted by Michael Hanke:
You may also want to have a look at:

http://www.opensource.org/docs/definitio...

This "Open Source Definition" has been derived from the Debian Free Software Guidelines and has been annotated to further facilitate the enlightment process ;-)

I wonder if even this is too generous?! If you click to list by name at the above link, you will see loads of "standard" licences. Listing by category instead, the complete list of those that are "popular and widely used or with strong communities" is:
 Apache v2, BSD-3-clause, FreeBSD, GPL, LGPL, MIT, Mozilla, CDDL and Eclipse

Now, if you look at
 http://www.gnu.org/licenses/license-list.html
you find that they seem to have objections to Mozilla, CDDL and Eclipse. They also object to the vagueness of the term "MIT licence".

This basically leaves:
  Apache 2, BSD-3-clause, FreeBSD, GPL, LGPL
Where the main differences between Apache 2 and BSD-3-clause/FreeBSD seem to be in verbosity (e.g. Apache 2 defines all its terms; FreeBSD is very short).

Demonstrably, some people are happier with GPL or LGPL and others with Apache2, so it's good to have a choice of these three, but is there any need for any new projects to use anything other than one of these three main licences? Things would be simpler for everyone (users, developers and lawyers) if the current plague of licences could be reduced!

Best,
Ged

Originally posted by Ged Ridgway:
Yes, everything would be simpler if people would limit themselves to these -- and I don't see a need for more. However, I'm approaching the topic from the "please, please don't do at least these mistakes" -- possibly being disillusioned after too many discussion on sanitizing awkward licenses. Even if people go with the full range of OSI-approved licenses it would be a huge improvement of the status quo.

Michael

Thanks to all for your replies -- this information is valuable and certainly a good start for me.

More practically, what do I have to do to establish a license for some software? Michael, if I'm not misrepresenting our private correspondence, you have recommended noting the license in each file I distribute, including the full text of the license in the distribution, and including a (dated) copyright notice in each file (or is this complimentary to the actual licensing?).  Is that it?

Also, do people ever change a license mid-project?  How is that done?

And what does it mean for licenses to be compatible?

Originally posted by Christian Haselgrove:
If you want to relicense the code you have to figure out everyone who has copyrights on parts of the code to relicense and get their permission. For large project it's almost impossible (Linux is an example where Linus Torvalds explained why moving from GPLv2 to GPLv3 would require asking thousands of people for permission, including the dead developers). For small projects you might be the sole author and thus have the copyright on all the code and be able to do it. Some projects like MySQL and most of the GNU tools ask for copyright reasingment from developers. This is an option but many developers are against this completely. You could check the document then the FSF ask people to sign for submiting code to GNU projects and also speak to a lawyer if you want to go that route. 

The GPL has a nice little explanation on what to put where : http://www.gnu.org/licenses/gpl.html (look at the bottom of the page) it's a similar process for BSD code. You should put a copyright statment and license statment in all your files. Alternatively some project put it in a LICENSE file at the top of their source code tree. 

To be compatible means you can take code under two different licenses and use them together in a project. For example if you create a new project that under the GPL and want to use BSD code for some stuff that would be fine. The opposite won't work (BSD project using GPL code) since the GPL requires all derivative code to also be GPL. Librairies usually will use the LGPL to allow the projects using it to choose another license. The LGPL isn't as broad on what constitute derivative work.

Originally posted by Nicolas kassis:
and such compatibility opens additional doorway for "relicensing" --
e.g. if originally project is under some permissive license (e.g. MIT)
you could go to more restrictive one (e.g. GPL) for derivative work,
thus making whole project GPL-ed (without asking any permission from the
copyright holders) -- you would just need to keep listing original
license/copyrights for that work under less-restrictive license as well.  It is
the going from more restrictive to more permissive one which usually
requires consulting all copyright holders/contributors... and it is indeed the fun of GPL v2 vs v3
"incompatibility":

http://www.gnu.org/licenses/gpl-faq.html
Is GPLv3 compatible with GPLv2?

  No. Some of the requirements in GPLv3, such as the requirement to
  provide Installation Information, do not exist in GPLv2. As a result, the
  licenses are not compatible: if you tried to combine code released under both
  these licenses, you would violate section 6 of GPLv2.

  However, if code is released under GPL “version 2 or later,” that is compatible
  with GPLv3 because GPLv3 is one of the options it permits.

Originally posted by Christian Haselgrove: As far as how to state the license and the copyright that is all fine. The copyright statement has to be dated because copyright expires with some delay (different between juridictions) -- typically 60 to 100 years. That's why you also need to update the date. Often you get something like

(c) 2006-2011 Michael Hanke 

As far a changing the license, the copyright owner has super-powers. The copyright holder can arbitrily change the license at any point. It is also possible to dual-license code (open-source and commercial license, see Qt some years ago). For dual-licensing the copyright holder can also change licenses that are incompatible to each other. Anything goes.  Of course with multiple copyright holder that only applies to the respectives pieces of code one owns. That's why it is important to note that in each file.

If you are not the copyright holder you can still take some code and change the license -- IF the original license permits it. For example, I can always take BSD licensed code and relicense it under the GPL -- as long as I appropriately list the original copyright holders. I cannot, however, take GPL code and relicense it under a closed-source, or even more permissive license.

Regarding how the license change is done: You get the permission of all copyright holders and change the license information in the code, while keeping the copyright statements intact. That's it.

Thanks again to all for this information.  I have set up a NITRC project to act as a (sub-)clearinghouse for licensing information.  I invite everyone to participate; please fill in the gaps in the information, ask a question, or argue a point.

Please see http://www.nitrc.org/projects/licensing/.