Friday, August 3, 2012

OSS licenses summarized in one sentence

Up until now, I've used the GPL for all of my open-source ventures because they've mostly been things that I've just been working on for fun, on the side. My newest project isn't by any means a startup, but it is more involved than anything I've done before so I'd like to use more discretion when choosing a license. The problem is, many licenses are just legal mumbo jumo, and their "summaries" tend to copy/pasted portions from the license itself. So without further ado, here's a very, very simplified version of many of the popular open-source licenses from a developer's standpoint, which might just help you decide in general what route to take.

The Licenses

More Restrictive:
  • GPL - GNU Public License v2
    Your source code can be redistributed and changed, but any changes must also be redistributed under the GPL (meaning no proprietary forks), and any code you use with this code must also be under the GPL.
  • GPL - GNU Public License v3
    Identical to the GPLv2 with the several additions (patents, restrictive hardware, DRM., etc), most of which you will most likely not have to be concerned about if you're not a giant multi-billion dollar company, or Linus Torvalds.

Less Restrictive:
  • LGPL - Lesser GNU Public License
    Like the normal GPL, but allows it to be dynamically linked with non-GPL applications, and it also adds the "attribution requirement" -acknowledging your work when creating a derivative; this is used a lot for libraries that want to be under the GPL, but want non-GPL programs to be able to use them.
  • MPL - Mozilla Public License
    As far as I can tell, identical to the LGPL, except that people can use any code you release via static linking while the LGPL only allows dynamic; static linking means combining the source code into an executable, whereas dynamic means keeping it separate, like in a DLL file.
  • OSL - Open Source License
    Very similar to the LGPL, even including the attribution right; the main difference is that when anyone distributes your "work" (not sure if that means just code or includes binaries) or any derivative, they must make a "reasonable effort" to make sure that whomever is using it agrees to the license.
    ("You must make a reasonable effort under the circumstances to obtain the express assent of
    recipients to the terms of this License.")
  • MIT License
    There are no restrictions on what people can or can't do with your code, it just must be accompanied by the license; quite simply, as FossWire puts it, "Here's the source code, do whatever you want with it, but if you have problems, it's your problem."
  • BSD License
    Essentially identical to the MIT license, only anyone who uses your works to create a derivative are not allowed to use your name to promote their derivative; you can also include a clause that forces them to include "This includes code under the BSD license" in their program.
  • Apache 2.0 LicenseEssentially an extension of the BSD License, adding on a requirement that anyone who changes your work must mark the files in which changes were made; it also handles things that are more the concerns of big companies like patents and trademarks.
  • zlib/libpng License
    Anyone can use your code for anything they wish, but anyone who uses your code cannot claim that they wrote it and altered versions need to be identified as not being the original.
  • WTFPL - Do What The Fuck You Want To Public License
    Anyone can do, quite literally, whatever they want with your code.
    (This license is not endorsed by the Open Source Initiative.)

Believe it or not, there really aren't a lot of good resources on what license to choose, from what I've found; most of them just copy and paste information directly from the license, as if that's supposed to be some kind of summary. And this list is certainly not supposed to be the resource to end all resources, it's supposed to help point you in the right direction. After reading this, hopefully you can narrow it down to 1 or 2 and then do research on them to make sure that they are what you are after.

More Resources

That being said, I did find a very, very excellent slideshow on this matter called "Making Sense of Open Source Licenses". I only wish that I could listen to whatever lecture went along with it. He basically divides them up into the following categories:

  • Give Me Credit: BSD, MIT, Apache
  • Give Me Fixes: LGPL, MPL
  • Give Me Everything: GPL 
He also makes some good points such as:
"Different licenses create different communities."

Another good resource is an article on "How to choose a free software license" that basically breaks down a developer's motivations and then suggest licenses from there. There are a ton of resources like this, but this one seems to get to the heart of the matter much better. He doesn't really branch beyond the GPL and BSDL though.

Another neat site I found was called TLDRLegal which lays out licenses in a very, very easy to understand manner. The explanations could use a little work, but the three categories of "Can", " Can't", and "Must" really help.

By far, the best resource I found is a site is a PDF on OReilly's website that walks you through the licenses actual texts and explains what they mean in plain English. Not quite one sentence, but probably the next step after choosing a license to investigate.

Lastly, whilst researching, I just happened to find an excellent comment on StackExchange:
A friend of mine once pointed out that licenses tell you what the license authors were scared of.
If you're scared of having your name dragged through the mud, then the BSD license will seem better. If you're scared of having your software put into a proprietary piece of software, then the GPL will seem better. Whatever the license, the author chooses it because it protects them against what they are afraid of.
Different people have different concerns and so use different licenses.
To me, this is interesting because it kind of examines the other side of the coin as the previous article: consider not only what you want, but also what you don't want.

Final Notes

Please note that -as a developer writing this article- every one of these licenses permits you to sell your software -even the GPL. Also, as owner of the code (assuming the code you're using is...ya know, yours), you can release one version of your program under one license, say, the GPL, and then release another version under another, such as BSD or even closed source. The only thing to keep in mind is that with some of the more restrictive licenses, you cannot change what license a version of your software that has already been released is available under: you can only change what future versions will be under.

Dual-licensing is another thing to take into consideration, but the term itself is really kind of misleading; it makes it sound like the code is subject to 2 licenses, but that is not the case. In reality, your code is essentially under the least restrictive license, but gives the user the ability to distribute it under any of the more restrictive licenses. You're mostly going to see dual-licensing with Copy-left licenses; it makes no sense to license something under BSD/GPL because someone can just release a derivative under the BSD license, making the GPL utterly useless.

I hope this was helpful, and make sure to read the full text of the license before deciding on one.

PS - It actually took quite a bit of research to find out the nuances between some of these, such as the MPL and the LGPL, or the BSD and the MIT, but some people ask the dumbest questions. "What's the difference between the GPL and MIT?" Wow, really? They only happen to be directly opposite.

No comments:

Post a Comment