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

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.

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

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?

Topics

About the author

Scott K Peterson - 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.