A great many developers, myself included, believe that it is important to spend at least some time contributing to open-source software projects. These projects will hopefully be licensed (if you haven’t got a license on your open-source project, you’re doing it wrong), to ensure that your contributions are used in the way you (or the project maintainer) wants them to be used.
This means that when you create your pet open-source project (at the minute, mine is Minimalog), one of the first things you’ll want to do is determine which open-source license you want to use.
This will be your first problem. According to a quick count, Wikipedia lists more than 42 licenses in their comparison page. This is an overwhelming quantity of choice!
Never fear. In the next five minutes, I’ll do my best to distill these choices down to something more palatable. This is going to be absurdly reductionist, and so I recommend doing more research on your own if you remain unsure.
The Non-Starters
Right off the bat we can get rid of quite a few licenses. It is always safest to use the more widely-used licenses. In part, this is because they have been widely tested, both in terms of getting other people to comply with them and in court (such as in Germany not once but twice ). More importantly, developers who care about licenses will tend to get wary around licenses with which they are unfamiliar.
The licenses seen most often are the following: the Apache license, the BSD license, the GPL (GNU General Public License), the LGPL (GNU Lesser General Public License), and the MIT license. Of these licenses, the Apache license is seen pretty infrequently outside of Apache Software Foundation software. This is obviously not an indictment of the license itself, but it means developers will be less familiar with it. For that reason, I would only use the Apache license if I was absolutely sure I wanted it and nothing else.
Of the remaining four licenses, two of them (BSD and MIT) are considered to be ‘permissive’, with the GPL and LGPL being called ‘copyleft’ licenses. To understand the difference, we will go briefly into what each term means.
The ‘permissive’ licenses are likely to be what a layperson thinks of when (or indeed if) they think about open-source software. These licenses require almost no effort to comply with. To comply with these licenses, the person or organisation using the code simply has to reproduce the license and copyright notice. Otherwise, they may do as they wish with the code, including bundling it up and selling it as-is.
In contrast, the GPL is a ‘copyleft’ license. This is a much more complicated idea. To begin to understand it, it helps to know that the GPL is written and maintained by the Free Software Foundation (whose website is unexpectedly ugly). The FSF is an organisation started by Richard Stallman, who is notoriously wacky (I mean it, take a look at his Wikiquote page sometime) when it comes to Free Software. The entire purpose of this license is to make it impossible for someone who uses the code to make changes that they do not then make available freely and openly.
As an example, if Minimalog was licensed under the GPL, you would not be free
to make changes to it, release it in a binary and sell it as “Steve’s
Superawesome Superblog Software”, no matter how much you liked the
alliteration, unless you also released your changed software under the same
license. More dramatically, the GPL is also viral. If I release a software
library licensed under the GPL (for example, if I had written
libdvdcss, and I do wish
I had), you download the source and build it into a dynamic library (such as a
.dll or .so) which you then link against your own proprietary code in
order to use, guess what? The FSF argues that your work counts as a
‘derivative work’, which means that you also need to release it under the GPL.
Now, it’s not actually that dramatic. The FSF also provides the LGPL, which as far as I can tell exists to solve this one use case. A library provided under the LGPL can be linked against without forcing your work to use the LGPL as well.
Ethical Issues
It’s clear that there’s a question of ethics involved in this choice. Stallman and the FSF do not want to be considered part of the ‘Open Source Software’ movement, as they think that open-source is not enough: software must also be free as in freedom. Whether I agree or disagree with this perspective is a subject for another time.
The only ethical choice I’m going to consider is this one: do you want other people to be able to profit from the use of your code, or not? The permissive licenses allow people almost limitless ability to use your code as they please, including incorporating it directly into proprietary software. The GPL does not.
Communities
Interestingly, a bit of a divide in license choice has begun to appear in the software community. If you sit and browse through an open-source repository storage, such as GitHub, or Bitbucket, or Google Code, or Sourceforge, you’ll find that desktop developers tend to favour the GPL, while web developers tend to favour MIT/BSD.
Obviously, this is a wild generalisation: the BSD UNIXes, for instance, clearly use the BSD license, despite being operating systems. However, in general, the more of the code is part of a web backend, the more likely it’s licensed permissively. Consider some of the big desktop projects: the GNU tools are GPL (obviously), the Linux kernel is GPL, VLC is GPL, and MySQL is GPL(ish). Then, consider some of the big web tools: nginx is BSD(ish), Ruby on Rails is MIT, Django is BSD, Twitter Bootstrap is Apache (which is permissive), and jQuery is either GPL or MIT (which means, functionally, it’s MIT). This shows a pretty major divide between the two camps.
This is likely to be a cultural divide. Web developers seem to me to be part of an entrepreneurial culture that lives and breathes around the idea of creating ‘startups’. This is all well and good, but it means that these developers want to be able to wrap their tools into their proprietary software stacks if possible. As an example, if Ruby on Rails was licensed under the GPL, it is reasonably likely that any Rails web app would need to be licensed under the GPL as well, which means you could download and launch Twitter or GitHub yourself with minimal effort. This is unlikely to be in the interests of those two organisations, or any other startup that wants to rapidly expand.
How To Choose
The secret is that really, it’s easy. If you want to prevent people from making changes to your work without providing them back to you, use the GPL. If you want people to use your name when they use your work in something, use MIT or BSD. If you honestly don’t care at all, use the WTFPL (the Do What The Fuck You Want To Public License). That’s the only decision you need to make.