Most surveys indicate that the vast majority of open source projects use the MIT license, the Apache license, and the GPL or their variants. If you have some code you are thinking of releasing under an open source license, and you want a quick overview of the broad-strokes differences between these licenses, you have come to the right place. This is not legal advice or a even detailed legal analysis; it’s a super-short, high-level overview for non-legal people.

First, short summaries of the licenses:

• The MIT, BSD, and ISC licenses are “permissive licenses”. They are extremely short and essentially say “do whatever you want with this, just don’t sue me.”
• The Apache license says “do whatever you want with this, just don’t sue me” but does so with many more words, which lawyers like because it adds specificity. It also contains a patent license and retaliation clause which is designed to prevent patents (including patent trolls) from encumbering the software project.
• The GPL licenses (GPLv3, GPLv2, LGPL, Affero GPL) all contain some kind of share-alike license. They essentially say “if you make a derivative work of this, and distribute it to others under certain circumstances, then you have to provide the source code under this license.” The important thing to know here is that “derivative work” and “certain circumstances” both require some legal analysis to understand the meaning and impact for your project.

The MIT License. The main argument for MIT or any other permissive license over GPL is that more people may end up using your software. Even if all of the downstream user-developers don’t open-source their contributions, many of them will. There are non-legal reasons for others to contribute, the main one being that if they don’t, they either have to fork (foregoing improvements on the trunk) or maintain a closed-source branch and keep integrating changes from the open-source mainline.

The MIT license is sort of like a loss-leader in a way: “Hey, it’s free, no legal restrictions, why not try it out?”. So they do. Then, later, they realize they want to be part of the open source collaboration, to get features and bugfixes and avoid messy merges.

You have to be ok with someone else taking your MIT-licensed software building another commercial closed-source application (or plugins or add-ons) based on it. For example, Mac OSX used many parts of BSD. BSD is under an MIT-like license. Apple could not have done that with Linux (not without open-sourcing OSX anyway), because Linux is GPL licensed. On the other hand, Apple has contributed things back to FreeBSDbecause of the resultant similarity.

The Apache License. The Apache license has a similar philosophy to the MIT, but uses more words. The wordiness creates greater specificity about contributors’ obligations, which might help in a dispute.  But it also can be a turnoff — “Do I need to have my lawyer look at this?” comes up more with Apache than MIT. It works well for organizations or projects that are larger and managing more contributors, but don’t care about others commercializing the work. It also can help bring on board organizations that are more concerned about software patents or patent trolls.

The GPL Licenses.  The GPL has name recognition. Developers like it out of a sense of fairness (“I open sourced my code so you should too”). Some of the most-installed open source software is GPL-licensed, such as Linux, WordPress, and Wikipedia’s underlying software, MediaWiki. Wikipedia’s content is (mostly) under the Creative Commons BY-SA license, which has similar share-alike features to the GPL. For individual contributors who want assurances of openness and transparency, and to avoid a BSD-into-OSX situation, the GPL provides assurance that other contributors will be held to the same licensing terms. While the GPL can be a turnoff for some corporations, it can create community among individuals.

The GPL sharing provisions involve nuance and ambiguity.  Companies adopting GPL software have to ask “are we going to end up having to release our other software that integrates with this under the GPL?” Just getting through the hurdle of doing that legal-technical analysis can bog down adoption of the GPL’d software; and even when a company does a thoughtful analysis, the end result is sometimes “yeah, we’d rather not risk it”. Some companies have blanket policies against the GPL, either out of misunderstanding, an abundance of caution, a desire to not engage in complex legal-technical analyses, or a combination of all of the above. I’ve also seen startups  avoid incorporating GPL software in their products because potential acquirers avoid it. If you are releasing software under a GPL license, it is also necessary to determine what the sharing criteria are, which vary between the different GPL licenses and can affect when downstream users have to release their source code.

What Are You Afraid Of? Another way of looking at it is that you’re picking a license based on what you are afraid of. All of these licenses assume you’re afraid of being sued. The MIT license is if you’re afraid no one will use your code; you’re making the licensing as short and non-intimidating as possible. The Apache License you are somewhat afraid of no one using your code, but you are also afraid of legal ambiguity and patent trolls. With the GPL licenses, you are afraid of someone else profiting from your work (and ambiguity, and patent trolls). This is a radical simplification, but if nothing else it can be a helpful framework in discussing with your attorney what license makes sense for your software.

This post is licensed CC-BY-ND. Joseph Morris is an attorney, and occasionally a programmer, based in Oakland.