Which Licence To Choose

Bad Idea No. 1: Choose a non-Open-Source Licence
Bad Idea No. 2: Choose a non-GPL-Compatible Licence
Bad Idea No. 3: Choose a Custom Licence
Bad Idea No. 4: “Same Terms as Perl”
Bad Idea No. 5: Under the Public Domain
Bad Idea No. 6: Using the GPL or the LGPL

Now that we covered the controversy of whether some licences are open-source/free software or not, let’s move on to which licence you should choose. I’ll start with some bad ideas of what not to do.

Bad Idea No. 1: Choose a non-Open-Source Licence

Well, I’m not sure it is a bad idea, but choosing a licence for a non-FOSS program is out of the scope for this document. I’m not going to stop you from trying, but neither can I help you with the licence choice. My best advice is to consult a lawyer.

Bad Idea No. 2: Choose a non-GPL-Compatible Licence

David A. Wheeler wrote about why it is important to pick a GPL-compatible licence for one’s software project.

Now, since version 2 of the GPL is incompatible with version 3, and vice-versa (due to the additional restrictions imposed by version 3) you shouldn’t choose GPLv2-only or GPLv3-only or GPLv3-and-above, because some projects may be licensed only under one of them. Also, the version 3 of the LGPL is incompatible with the GPLv2, so you shouldn’t choose it either. GPL-version-2-or-above or LGPL-version-2.1-or-above should be OK in this respect.

Bad Idea No. 3: Choose a Custom Licence

You shouldn’t phrase your own licence and hope it will be considered open-source and GPL-compatible as there are plenty of open-source licences to choose from. Creating your own licence may put your users and you under risk of abuse and will contribute to the problem of licence proliferation, and may confuse your users who will need to read your unusual licence in order to study it.

Using your own custom licence deprives you of the benefit of using a well-reviewed, well-understood and debugged licence. This is similar to writing your own program from scratch instead of using an existing, well-tested software solution. (Thanks to Omer Zak for this analogy.)

So, don’t do that.

Bad Idea No. 4: “Same Terms as Perl”

I originally wrote about the problem of saying your code is “licensed under the same terms as Perl itself” (which is prevalent for CPAN modules and other Perl code) on my Perl blog. It was also covered on Perlbuzz and covered there again. I’m only going to summarise these arguments here, and conclude by saying that using the Artistic Licence Version 2.0 or later, or a GPL-compatible permissive licence such as the MIT/X11 Licence would be preferable.

Essentially, the licence of perl (the Perl implementation) has changed several times since its inception - from a non-free licence, to the GPL, to a dual GPL and Artistic licensing. Furthermore, the Artistic license is not considered free and GPL compatible by the Free Software Foundation, so it’s not a wise choice, and the GPL has its share of problems too (see below) so it’s not a wise choice either.

Bad Idea No. 5: Under the Public Domain

It is not wise to licence one’s code under the Public Domain because the Public Domain is not widely understood or accepted internationally, and because licensing code under the Public Domain may not be possible. Rick Moen gives more reasons under “Public Domain” in the Licensing and Law section of his knowledge base.

If you’re interested in making your software as-close-to-PD-as-possible, you should choose the MIT/X11 Licence or a similar licence such as the ISC licence.

Bad Idea No. 6: Using the GPL or the LGPL

The GNU General Public Licence (GPL) and GNU Lesser General Public Licence (LGPL) contain many additional restrictions to the concept of copyleft, and are very misunderstood, over-hyped, and don’t maintain compatibility with newer versions. Even the LGPL is reportedly problematic

The GPL and LGPL are of more political nature than other similar FOSS licences, and as such should be avoided. I recommend using the Sleepycat licence, which is a strong-copyleft licence, that is compatible with GPLv2 and above, instead of the GPL and the Artistic 2.0 (or above) licence instead of the LGPL. And naturally permissive, non-copyleft, open-source licences such as the MIT X11 Licence are an option. What the Sleepycat licence says is that code distributed under it, must remain under it, and that one must release the source code for publicly-distributed binaries that link against it. However, from my understanding, as opposed to the GPL, this source code doesn’t have to be completely free. It doesn’t have the additional restrictions on licences compatibility that the GPL has, nor does it have the other obscure and not-well-understood restrictions that the GPL has.

I read the GPLv2 originally once and couldn’t understand it. The LGPLv2 or the GPLv3 would likely prove to be more problematic. I find it harder to trust lengthy documents that I am unable to understand. I had no problem understanding the Sleepycat licence, the Artistic 2.0 licence, or the MIT X11 and BSD licences, so I can better recommend them instead.

One fact I should note is that the GPL often stands against the Hacker’s attitude as presented by Eric Raymond in the document “How to become a Hacker”. It states that:

  • The world is full of fascinating problems waiting to be solved.

  • No problem should ever have to be solved twice.

For example, the Free Software Foundation now started the GNU PDF project that is licensed under the GPL version 3, because all the other Free software PDF projects are GPL version 2 only. So because the GPL was used, the same problem need to be solved twice.

Another case where it happened was this story of an the Inkscape set operations patch:

Once before, someone had contributed a patch to add boolean operations, but that patch relied on a polygon clipping library provided under an incompatible license. There’s little more frustrating than having a solution in hand, only to be hamstrung by legal problems. Even though it was an important feature for us, we regretfully postponed development of it into the distant future on our roadmap and proceeded with other work.

Furthermore, the OpenBSD project are now re-implementing a lot of software that is only available as GPL or similar licences, under BSD-style licences, due to OpenBSD’s more pedantic licensing policy.

And finally, often one can build upon non-GPL-like-code and not release the derived work as free and open source software, without it causing any harm, and actually causing a lot of good. Which is otherwise prevented if the code is GPLed.