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.
- Which open source software license should I use?, an article by Stephen R. Walli
- The GitHub-sponsored choosealicense.com project shows that, even with simplified characteristics, a comparison table can look overwhelming. That project suggests that you start by considering three licenses: That's my list! No, that's their list. Interesting choices.
- In choosealicense.com and GitHub's license picker Richard Fontana discusses the original version of the project.
- Ten years ago, Jeff Atwood wrote Pick a License, Any License. He closes by saying, "It's a minefield, people. All I'm saying is this: The next time you release code into the wild, do your fellow developers a favor and pick a license—any license."
- The Free Software Foundation has a great deal of information about licenses, including How to choose a license for your own work.
- Finally, the Open Source Initiative information about licenses includes convenient access to the text of the licenses that it has approved as meeting its Open Source Definition, as well as a short list of "Popular Licenses."
What struggles do you have with choosing a license? If you were on a desert island which licenses would you bring along?
6 Comments