If you were on a desert island, which license would you take with you?

Open source licenses give the permission necessary to remove the restrictions created by copyright law.
330 readers like this.
sticky notes making a palm tree on an island

Opensource.com

First, we need to ask ourselves why we should bother choosing a license?

Are you:

  • presenting your software to the public?
  • representing your software in a way that leads others to believe they can copy it or build on it?

Then, yes, you should choose a license. Be fair to your visitors and back up the appearance of permission by expressly giving permission.

The copyright law defaults to author control of copying, modification, and distribution, so others need the author's permission to copy, modify, or distribute. If you would like others to be free to copy your software and possibly build on it, then you should choose a license. Open source licenses give the permissions needed to get that default copyright impediment out of the way.

Many licenses to choose from

OK. Let's assume that you do want to post a license for your software. Please do not write your own license. There are plenty to choose from. In fact, there are so many that you may feel paralyzed in which one to choose but never fear. Comparing one license to the next, the details can easily be intimidating, but these licenses are more similar than they appear. All open source licenses provide permission to copy and modify, and they all provide the permission to pass those rights to others. They all provide recipients of the software with the permissions needed to be able to build on and collaborate on development.

There is one primary dimension on which to choose the best license for your software: copyleft, or not.

My desert island list

If I were on a desert island, I probably would not need a license, but let's say I did. I'd stuff the MIT license in one pocket, put the GPLv3 in my backpack, and find a place to tuck the Apache license.

In what could be a huge multi-dimensional space, there is one dimension that is my starting point: copyleft ↔ not copyleft. All free software and open source licenses provide permission to copy and modify, and they all provide the permission to pass those rights to others. However, there are two importantly different variants of that last part: non-copyleft licenses permit a recipient to pass on the rights that they receive (often referred to as "permissive" licenses); copyleft licenses require that certain permissions be passed on.

GPLv3+ refers to current version of the most widely used copyleft license (passing on permissions to others is required). (The '+' refers to the following phrase in the standard GPL license notice: "either version 3 of the License, or (at your option) any later version".)

The MIT license is a simple license (less than 200 words) that represents the non-copyleft end of that dimension (passing on permissions to others is permitted).

Your license and patents

Patents have attracted growing attention over the years. As a result, GPLv3 addresses patents more robustly than does GPLv2. While versions 1.0 and 1.1 of the Apache license were variants of the BSD license, which does not expressly refer to patents, the Apache 2.0 divides the grant of rights into separate copyright and patent sections, with the patent section including a defensive termination feature.

The patent language in the Apache license has led to its reputation as a patent-protective license. However, GPLv3 has more robust patent language. And, while we have yet to see this play out in court, I believe that the grant of rights in the MIT License includes patent rights that may be similar to those in Apache (albeit without a defensive termination feature). Apache is good; but, its reputation may be a bit overstated. I include it because others may value simplicity less than I do.

Beyond the desert island

My desert island list is focused on choice of license for a new project that is not constrained by the licenses for related software. However, there may be license-selection factors that flow from your software's relationship to other software.

  • In many cases, it makes sense to choose the same license as already applies to other software in the relevant ecosystem, rather than to add licensing complexity with a different license.
  • Sometimes, the anticipated relationship with software under other licenses should be taken into consideration (such as planning to permit incorporating directly into software under a proprietary or copyleft license). This might bias toward MIT or suggest a copyleft license with narrower bounds than the GPL (LGPLv2.1, LGPLv3, MPL, EPL).

What others are saying about choosing a license

Others have shared their thoughts and opinions, which may, in turn, help you choose.

What struggles do you have with choosing a license? If you were on a desert island which licenses would you bring along?

Tags
User profile image.
Scott Peterson is a member of the Red Hat legal team. Long ago, an engineer asked Scott for legal advice on a curious document known as the GPL. That fateful question began a twisting path of exploration of the legal aspects of collaborative development, including both technical standards and open source software.

6 Comments

Interesting discussion. For me, however, there is no option and I would only take a small compact packet of the FSF's GPL collection (LGPL, GPLv3+, etc).

If I was also producing cultural or consumer works (ie Literature, art, etc) as opposed to software, I'd also bundle in the Peer Production License, as I take issue with CC.

Pretty hardline, but I believe that everything should be fed into the Commons.

What Matt ^^^ said. The FSF portfolio is pretty much all I need. They've got the GPL, the LGPL, the AGPL, and they even have an All Permissive license, so for small, trivial code snippets, you can more or less forego a license but still be licensed. I don't really have to look outside of the GNU bundle, personally (aside from the Creative Commons for non-code works).

In reply to by Matt Marshall (not verified)

Out of curiosity, what is the specific issue that you take with the Creative Commons licenses? Is it all of the licenses, or one specific variety of CC license that you have a problem with?

In reply to by Matt Marshall (not verified)

Hi Jason,

My issue with Creative Commons is that it reinforces the control of the producer of the work, rather than feed it into an actual 'Commons' where it belongs to everybody. To be clear; I think some restrictions need to be in place to prevent Capitalists from acquiring Commons property, but other than that once a cultural work exists it should exist as the common property of our entire species. This is admittedly a view rooted in Political Philosophy, as I believe that absolutely no work can be entirely original and draws upon the social and material conditions and culture of the time, and therefore inherently belongs to everyone the same way as does, for example, folklore.

Dmytri Kleiner elaborates on this critique much more elegantly than I can in his book "The Telekommunist Manifesto" (http://media.telekommunisten.net/manifesto.pdf)

The alternative he proposes is the 'Peer Production License' which is a modified version of one of the CC licenses adapted to reinforce the Commons as an entity.

In reply to by Jason van Gumster

I am going to offer my opinion on the flip side, and why I think that permissive licenses are becoming more popular. I dislike the complexity of copyleft licenses, compatibility, etc. I would rather see my work reused, and prefer to give the freedom to reuse my work in whatever way chosen so long as you give me credit. I think copyleft was important, and in some communities still is, but prefer to contribute to MIT, BSD, Apache licensed projects. I started out fully in the GPL or nothing camp, but over the years have moved to an MIT, BSD, CC-BY, even CC0 for data as science is hard enough without worrying too much about licensing, compliance, interactions, etc.

As the author of a moderately-large environmental-software package
(175,913 lines of code and 101,450 lines of documentation in the current release),
I'm afraid I consider the more-permissive licenses too much a license to steal:
I've had to deal with that more than once in the past.

FWIW.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.