First of all I’m not a lawyer and second I’m not trying to teach you how to choose a license. I am merely recording how I landed on the Mozilla Public License (MPL) as my favorite FOSS license. Also, I do not dislike, hate or aim to insult any other licenses, as all FOSS work is respectable.
I am starting a project that I want to be opensource and hosted on GitHub as I work on it. So I register an account there (yes shame on me, I haven’t got a GitHub account up til now) and start to poke around. Having been familiar with Google Code for a while, I look for a place to pick a license for my project. That option is nowhere to be found. Instead the Terms of Service basically says that I’m on my own with licenses. Hating licenses as much as I hate [company name removed], I think it’s a good time to learn about them.
Being a Gentoo user who happened to have read about handling licenses and know about license groups, I immediately think of these two lists:
- List of FSF approved software licences
- List of OSI approved software licences
There are just too many for me — a lazy reader of law and everything law-related. Luckily I found on the website of the Open Source Initiative, “License that are popular and widely used or with strong communities“. 8 doesn’t look like an incredibly small number, but it’s enough for me to drill down and read about them.
To speed up the process, I decide on the characteristics of the license of my dream, then filter the list. I want a license that:
- Requires those who benefits from my code to contribute back (like the GPL, but not like the GPL, see next item)
- Is not as restrictive as the GPL. To some extent I agree with the criticism: “That’s a bit like the person who made the nails you used claiming he has the right to your entire house.”
- Is preferably compatible with the GPL. To some other extent I like the idea of the GPL, so if somebody else uses my code and want to release their code as GPL they should be able to.
- Is easy to read and understand (added after reading the terms of the LGPL)
- Has anything else a license should give me: I shall have the credit for my work, people don’t sue me, blah blah blah
For each license in the list, I go to Wikipedia to find out the easy details and read the full text of the interesting ones:
Apache License: Too permissiveBSD licenses: Too permissiveGNU General Public License (GPL): Too restrictiveGNU Lesser General Public License (LGPL): Too complicated. I think it takes both a lawyer and a good software engineer to understand this text. When I try to read it I understand why it was previously named “Library General Public License”, but unless I have too, I don’t want to take this route.MIT license: Too permissive- Mozilla Public License (MPL)
- Common Development and Distribution License (CDDL)
- Eclipse Public License (EPL)
So here comes the little comparison of the 3 short-listed candidates. The MPL, the CDDL and the EPL all support weak copyleft (requirements 1 and 2). However there are small points that make the MPL more appealing to me:
- I don’t like the fact that the CDDL comes from Sun, which is dead. I think I’m being paranoid, but I’m uncomfortable to hear that I won’t receive updates for the license.
- I can’t seem to grasp the implications the EPL placed on patents and the US copyright law’s definition of derivative works (too long, isn’t it?).
- Both the CDDL and the EPL have some controversy associated with them. If only I were more knowledgeable about the law… For now I’ll try to stick with what I understand. The MPL also comes with the thing called the tri-license, which sounds crazy at first, but I have found that I like it.
- Both the CDDL and the EPL are GPL-incompatible. The MPL has a provision that allows another license as an alternate choice. I like the idea of providing my things in MPL, and allowing people to use it as GPL if they so wish.
So today I learned a lot about software licensing, which is tiring but also inspiring.
« File sharing with Python’s built-in HTTP server The move away from NTFS »

Nice breakdown, Phu