MacKuba

There are many posts and articles that compare available open source licenses. A lot of them aren’t objective and are biased towards some kinds of licenses based on author’s own preferences.

Well, I have to disappoint you, this one isn’t going to be any different :)

After the VLC incident last week I got kind of fed up with GPL. I had licensed a few of my projects under GPL before, but I decided I don’t want to use a license that’s so restrictive that it makes it impossible to put an app on AppStore, even if it’s shared for free and the source code is available. So I did some research to find what other licenses made sense for me. As usual, I spent way more time on this that I should have, and the notes below are the result. (Note that I haven’t actually read the whole text of most of these – I’m not that crazy.)

Update (6.07.2017): I’ve added a section below about the “Very Simple Public License” (VSPL) that I started using in my projects as a simpler replacement for MIT.

---

According to the Open Source Initiative, there are about 10 open source licenses that can qualify as “popular” (with the GPL family being definitely the most popular of these, followed by Artistic license (thanks to Perl) and MIT license – according to one report), and several more that are popular in some communities. They can be divided into a few categories, which can be arranged roughly in order from the most permissive (those that let you do anything with the code) to the most restrictive (those that put the most restrictions on how the code can be reused, in order to ensure that it stays free and open).

At the top, there are what I would call “I don’t care” licenses. There’s public domain, which isn’t really a license, but rather a way of saying that you give up any rights to the code and make it belong to everyone. This isn’t recommended though, because apparently the law in some countries doesn’t allow that (which doesn’t make much sense to me, but whatever).

There are at least two not very serious licenses which have essentially the same meaning as public domain. I’m talking about the Beerware license and WTFPL (“Do What The Fuck You Want To” license). I really like these because they pretty well represent my opinion about the legalese bullshit that most licenses are so full of. Author of the Beerware license writes:

I have had it with lawyers trying to interpret freedom. If I write software which I intend to give away, I don’t want to have to stick several pages of legalese on it to make sure nobody exploits it or any such meta-bable. If I have decided that I’ll give away some code I’ve written, I going to give it away, period, none of this “unless it is worth a million to somebody” rubbish.

My thoughts exactly.

---

Next in line are so called permissive licenses. It’s a category of licenses that let you do almost whatever you want with the code, provided that you keep the copyright comments and acknowledge that the code was written by the person who wrote it. Other than that, you can do pretty much anything – you can compile the code and sell it as is, add it to a GPL project, or a proprietary project, or whatever. These licenses tend to be short and simple, though they always include at least a line or two of some SCREAMING CAPS legalese crap.

The licenses that belong to this family are:

• MIT license – very short and very popular. Almost all open source Ruby code is available under this license.
• BSD license – also quite popular. I don’t like it as much as MIT, because I never know what exactly I’m required to do if I want to use it in a closed source app.
• Apache license – rather less popular at the moment, at least in the programming communities that I care about. It has a similar meaning, but is way longer – basically, it tells in 86 lines what BSD license manages to tell in 9.

Update (6.07.2017):

Out of these, I used to prefer MIT since it was the simplest and the most popular one. However, it still includes a few things that really annoy me:

• it still uses weird legal language, words that you normally never come across unless you’re a lawyer, making it hard to understand for normal people (especially non-native speakers): what the hell is tort? merchantability? furnished software?
• even the parts that use commonly understood words are way overcomplicated and sound like something out of a historical movie
• THE WHOLE THIRD PARAGRAPH IS WRITTEN IN CAPS. WHY THE HELL DO YOU NEED TO SHOUT AT ME? does it make the copyright weaker if you write the license in normal case?
• the whole 8 lines is basically just a couple of things repeated over and over, just put in different words

So at some point I decided to write my own license that just “refactors” MIT, extracting the bare minimum from it to still keep the intended meaning. I called it Very Simple Public License (VSPL), and here is the complete text:

Copyright (c) 2017 <your name>

You can modify, distribute and use this software for any purpose without any
restrictions as long as you keep this copyright notice intact. The software is
provided without any warranty.

See? Does it really need to get any more complex than this?

If you like this license, feel free to use it in your own projects (let me know if you do!).

---

If permissive licenses seem too permissive to you, there’s another family of weak copyleft licenses. These have restrictions that make sure that the code always stays open and licensed under the same license (otherwise you could relicense it to MIT and then do whatever else you want, which would defeat the whole purpose). However, they usually let you combine the code with non-open-source code, i.e. add the code to your existing closed source programs.

This category includes licenses like:

• MPL (Mozilla Public License)
• CDDL (Common Development and Distribution License, by Sun)
• EPL (Eclipse Public License)
• CPL (Common Public License, older version of EPL)

They all have a set of rules that work more or less as described above. This means that if you take a MPL-licensed app, add some features to it and then merge it with your proprietary app and start selling it, it’s perfectly fine, as long as you put the files that originally came from the open project (with your modifications) somewhere online and mention that in your app’s docs. Of course you don’t have to share any part of the app that didn’t come from the open project.

One side effect is that these licenses are usually incompatible with GPL (more below).

There’s also LGPL (Lesser GPL), which is often used for Linux libraries (like GTK). It’s similar to the ones above, but there’s an important difference that makes the “copyleft” effect stronger. LGPL code can only be combined with closed source code if it’s included as a dynamic library. It isn’t allowed to include code as a static library that generates a single executable file from LGPL code and proprietary code.

---

The last category is strong copyleft licenses, which basically means GPL. Strong copyleft means that you can’t combine GPL code with code under any other license (whether it’s open source or not), unless you make entire project GPL. That’s why GPL is called “viral”, because it “infects” all other code that it touches.

This makes GPL incompatible with most weak copyleft licenses, because they insist that you keep the code licensed under the original license, and GPL insists on converting everything to GPL, and you obviously can’t do both of these.

GPL has also a set of additional restrictions (less in GPLv2, more in GPLv3) that are intended to protect the user’s freedom. Apparently, they are are the reason why GPL apps can’t be put on the AppStore – Apple’s DRM which is added to all apps seems to break some of these restrictions.

There’s also a variant of GPL named AGPL (Affero GPL, after the company that came up with the idea). It differs from GPL in that it adds one more restriction that if GPL code is used in public in a way that only makes the app accessible through the network, it still counts as distribution and you have to comply with the terms of the license. This means that if you use GPL code in your webapp, you don’t have to share the code, but if you use AGPL code in your webapp, you do have to share the whole code.

This category also includes EUPL, European Union Public License prepared recently by the EU government and modeled after GPL. The problem with this one is that no one uses it and few people have even heard about it – and honestly, I don’t expect this to change in future.

In general I don’t like GPL, because I think there’s just more restrictions in it than I would ever want. If there’s no way to make an app available to iPhone users no matter what you do, then something’s wrong with that. I also have an impression that GPL was designed not only as a way to promote open source, but also as a weapon in a political fight to destroy all proprietary software. Just read this text they wrote about why LGPL isn’t recommended. It almost sounds like Father Rydzyk speaking to his followers… “But we should not listen to these temptations, because we can achieve much more if we stand together” – are you kidding me?…

---

There are a few licenses which don’t exactly belong to any of these categories, or which are confusing enough that I don’t know where they belong. These include:

MS-PL – Microsoft Public License (aka Microsoft Permissive License). I actually really like this license in terms of text – it’s very short (you can actually read all of it), and it’s one of the most readable open source licenses I have seen (kudos to Microsoft for that, and also for slowly changing their approach to open source).

The problem is that it kind of seems specifically designed to be annoying to open source developers, and knowing Microsoft, you can’t be sure this isn’t exactly the case. The license is basically permissive for proprietary apps and weak copyleft for open source apps. If you want to add it to open source code, you have to keep it under MS-PL, which limits your options a bit. But if you add it to closed source code and only distribute the binary, you don’t have to do anything. In this way, it doesn’t seem to be good for anyone, because if someone wants to add restrictions, it’s not restritive enough, and if someone doesn’t want restrictions, it’s too restrictive…

Artistic License, used by most Perl code. The problem with it is that no one seems to understand what kind of license this is. I’ve read several explanations, and they ranged from “it’s like BSD” to “it’s almost like GPL”. It also includes a weird condition that if you make any changes to the original code, you have to document in detail what exactly was changed – which seems very annyoing to me.

MS-RL – Microsoft Reciprocal License (aka Microsoft Community License). This is a copyleft license which is almost identical to MS-PL, except it adds one more clause. This clause is however ambiguous enough that it’s not completely sure if this is effectively a GPL kind of license or a MPL/EPL kind of license, which is kind of important. This might be one case where the license is actually too short rather than too long…

---

Having that sorted out, I figured I would choose some standard licenses for my own projects to make things more consistent. I couldn’t choose a single license for everything, but I grouped the kinds of projects I wrote or plan to write in future into such categories:

• examples, demo code, mostly for adding to blog posts – these are specifically intended only to be reused in other people’s code, and usually don’t have much value other than serving as an example, so WTFPL is perfect for that
• libraries, Ruby gems, Cocoa pods – these are also shared with the purpose of being added to other people’s code; I could also use WTFPL for these, but WTFPL has the disadvantage of sounding as if I don’t give a shit about the code, and also, these might be things that I actually feel a little proud about, so it would be kind of nice to keep my name there… so for such things, I’m going to use MIT VSPL (examples: Sparkler, twitter-top)
• applications which aren’t important, are abandoned or serve mostly as an example or a way for me to learn a framework or language – I’ll also use MIT or VSPL for these to make it easier to reuse code from them (examples: xBlip, iRubyTime)

• applications which I rather care about (if I decide to share their code at all) – in this case, I wouldn’t be very happy if someone took such an app, made some changes and started selling it as a “pro” version, making money on something that I provided for free. Call me selfish, but I just don’t think that would be very fair.

  On the other hand, I don’t want to impose crazy restrictions like GPL which in extreme cases makes the app unusable for users (like with VLC). I also don’t mind if someone takes my code and makes it a part of a bigger proprietary project which they make money on – after all, they would be really selling their own app which my code would only be a part of.

  That’s why I think that for this kind of projects the MPL/EPL/CDDL family of licenses is a perfect choice, at least for me. This ensures to some degree that my code isn’t used in a way I don’t like (or at least makes it clear what my intentions are), but doesn’t make things too restrictive and viral as with GPL. Your closed code doesn’t close my open code, and my open code doesn’t open your closed code – which seems like a fair deal to me.

  Out of the three, I chose EPL because it’s much shorter and simpler than the other two.