How to pick an open source license

You've made the decision to release your code as "open source". Ok, what does that mean, what is an open source license, and how do you pick the right one? This question comes up all the time so I thought I'd write up a simple decision tree to try to explain the choices.Many people use GPL without realizing the implications or understanding the other options. This isn't legal advice, and I'm not a lawyer, and I'm probably over-simplifying some of the points, but I hope you find it helpful.

First of all, if you write some code, it's your code and you get to decide how other people can use it. Period. Nobody but you can say how your code can be used, either by putting restrictions on it or taking them off, without your permission. That's a very important point to keep in mind while reading this article. 

The second point to keep in mind is that nobody but you can even use your code unless you explicitly give them permission. Another way of saying this is that all source code is closed and proprietary and off limits until you, the author, open it. 

Note: The text of all the licenses mentioned here can be found at opensource.org. 

Decision 1: Do you want to relinquish any control over how your code is used and distributed?

If yes, then don't copyright it, and don't license it. Put it in the public domain, and you're done. This is a good choice for examples, templates, and other illustrative code where the whole point is that you want everybody to feel free to use what you've written. [Alert readers pointed out that "public domain" is is not a good choice because in many jurisdictions you can't give up your copyright. Use a liberal license like MIT/BSD instead. -22jun/ebb]  Example: code listings in a book or article. 

If no, then Copyright the code (paste copyright notices all over it) and continue with decision 2.  

Hint: Just to make sure your intent is clear, either put in explicit copyright notices, or put in explicit notices that the code is in the public domain. Copyright is how you retain control. Without a copyright, there is no control. [Technically the notices might not be necessary but they don't hurt and are still recommended. -22jun/ebb]

Decision 2: Do you want to allow people to use your code in non open-source programs?

If yes, then continue to decision 3.

If no, then release your code under the GPL, a restrictive "free (libre) software" license that actively promotes user choice at the expense of direct commercial interests. For the most part, GPL'd code can only be used with other GPL'd code, and in fact if you start using [and distributing -22jun/ebb] some GPL code in a program you wrote then you either have to release your program under GPL as well or quit using that code. This is why GPL is sometimes described as "viral". Examples: Emacs,  Linux kernel.

Hint: Don't take this choice unless you really mean it. Many people use GPL without realizing the implications or understanding the other options, and thus lock the code away from a whole segment of potential users, so please read the rest of the choices first. 

Decision 3: If somebody uses your code in their program and sells their program for money, do you want some of that money? 

If yes, then you have two choices. The first choice (3a) is not to release it as open source at all, i.e., use closed source and you're done. This would preclude anyone from using your code in free (no cost) packages. And it would only allow people to use your code in commercial programs if they came to your first and worked out a deal for a commercial license. Note that even if the source is "closed" you can give permission if you like for certain people to have access to the source and use it in limited ways. Example: Microsoft Windows, Sun Java (sort of).

The second choice (3b) is dual license. I'll talk about licenses more in a moment, but dual license just means you give permission for people to use your code under two or more licenses. You pick one license (probably GPL) for free (no cost) programs, and one for commercial ($$$) programs. This is a good choice if you're trying to make a living off licensing fees for the code itself. Examples: MySQL, JBoss, SleepyCat. Continue to decision 4.

If no, then give permission for others to use your code under one or more "commercial friendly" licenses. This is a good choice if you want your code to get into as many hands as possible and either you don't care about the money or you plan to make money in other ways, for example by selling your own programs that use the code or from consulting or support. Examples: Apache HTTPD, Eclipse, Firefox. Continue to decision 4.

Decision 4:  If somebody uses [and distributes -22jun/ebb] your code and improves it (fixes bugs or adds features) do you want to make them give you the improvements back so you can use them too?

If yes, then use a "reciprocal" license. Any modifications to your code need to be made available under the same licensing terms as your original code. This is useful if you're worried somebody will take your code and go off on their own private "fork". Examples: Eclipse (EPL), Solaris (CDDL), and Firefox (MPL). Done.

If no, then use a non-reciprocal license. Often times the people using your code will send back improvements anyway, especially if you have a history of frequent releases and they get tired of having to re-merge in their changes every time. This is the most wide open type of license so it will get you the most exposure and users, but it can also relegate the original writer(s) to the sidelines. Example: FreeBSD (BSD).  Done.

In a follow-up article I'll explain how the most commonly used open source licenses fall in the categories like "commercial friendly" and "reciprocal", and address any concerns raised by commenters. So whether you agree or disagree with my points above please give me some feedback in the talkback section.