Open Source Licensing – Demystified?
By: Steve McMaster

I’m not sure how many of your listen to our podcast, but in Episode 023, we talked a little about open source licensing. Ian had gone on a mini-rant during the soundcheck about how there are too many different open source licenses, and they basically all say the same thing. So why complicate open source by having so many? I thought about this a lot over the next few days and did a lot of reading into open source licenses of my own. The results are interesting, to say the least.

To start, there are a couple really good resources for reading about open source licenses. The first is on the GNU website. It lists licenses for software, documentation, and even fonts. It also goes on to sort the licenses into GPL-compatible, GPL-Incompatible, and Non-Free Licenses. The thing to keep in mind while reading this website is that it tends to be a little biased. GNU, and the Free Software Foundation who supports them, very strongly believe in something called “copyleft”. According to Wikipedia, a “copyleft” is “a general method for making a program (or other work) free (libre), and requiring all modified and extended versions of the program to be free as well”. This is a philosophical decision above all else. In fact, Richard Stallman (the founder of the FSF) writes that copyleft is a form of “pragmatic idealism”, and that’s the reason GNU’s own license, the GPL, is written the way it is (see his whole article on the GNU website).

Anyways, the other site I found useful for comparing open source licenses is the Open Source Initiative. The OSI is a non-profit organization tasked with maintaining the “official” definition of Open Source, and they are recognized throughout the community for approving licenses as compliant with this definition. The OSI follows a much less idealistic philosophy, having roots in the business community. One of their original goals was to avoid the idealism inherent in the “Free Software” movement. Therefore, their site provides little philosophical commentary on the licenses. What they do provide is an arena to communicate with open source developers regarding the various licenses.

As part of my reading, I began to develop a sort of distaste for copyleft. Not only is it forcing your open source ideals on other people, but I’ve seen throughout my experience many problems created by the strong copyleft that some licenses (GPL v2) creates. Copyleft doesn’t only force your ideals on your own software — this in and of itself is not a problem, after all, its YOUR software. However, when the license you apply to your code prevents me from using someone else’s code with your code because they didn’t agree with your ideals, you’re forcing your ideals on that other software, and on whatever software I’m writing, too. It saddens me every time I think of this to know that the open source community, which in my opinion creates superior software 9 out of 10 times, feels it has to resort to something like this.

Until now, anytime Hurricane Labs has released software to the open source community, it has exclusively been under the GPL. However, after some careful consideration, we’ve decided to make a change. From this point forward, any software we release will be licensed under the license commonly referred to as the “MIT License” or the “Expat License” (you can view the license at the OSI website). In addition, we are retroactively applying this license to anything we’ve released in the past as a dual-license model. If you’ve already chosen to license our existing software under the GPL, you are free to continue doing so. However, you may choose in the future to license it under the terms of the MIT license instead.

The MIT license has many advantages, in our opinion, over the GPL. First and foremost, the MIT license is significantly shorter and simpler. The laymen’s summary of the MIT license (and please don’t take this as legal advice) is “use the software as you see fit, but if you redistribute it you must maintain this copyright license. Also, there is no warranty of any kind”. In addition, the MIT license does not enforce any sort of copyleft on the code. This means that if you have a commercial use for it, you can use our code in your closed source project, and the only condition is you must maintain the notice that the code is copyrighted by Hurricane Labs. There is no requirement that you maintain a method of obtaining the source code, no requirement that you open source your changes, etc. This should make using any code we’ve developed as simple as possible.

Licensing is a complex topic, be it Open Source licensing, commercial software licensing, or any other kind of licensing. There is a lot of legal jargon to it, and the big, long, “EULA”-esque licenses are difficult to understand. Open source licensing also brings with it a heated debate, as with almost any topic in open source it seems, with both sides of the argument feeling that their opinion is right. But not only that, but that the other side’s argument is as wrong as wrong can be. We chose a license based on what best fit all of the goals we were trying to achieve by releasing our code, and we feel the MIT license does this for us. It is not really a statement of philosophical beliefs. Instead, think of it as the result of applying the old “is this good for the company” to our open source licensing. I encourage you to look at licensing in terms of what achieves your goals, and not what people try to convince you are your goals. If the GPL, or any other license, fits your code the best, then by all means, that’s what you should be using. And don’t be afraid to change someday either. We weren’t.