One potentially confusing part of creating your own open source project is choosing a license. An open source license is a legal document that specifies what people can and cannot do with your project. For example, can someone modify your code and distribute it as their own? Can they include your code as part of their own proprietary project? The open source license you choose determines the answers to those questions.
There are dozens of open source licenses, and each one has its own unique features. Knowing this, the process of choosing the right license for your project can be quite daunting. How do you know which one is right for you?
Luckily, choosing an open source license is not quite as difficult as it might seem. Most licenses fit into one of two broad categories: copyleft licenses or permissive licenses. Depending on how you want other people to use your project, you can narrow your choice down to one of these two categories.
Let’s break down these two major categories and learn about the licenses that fall into each one.
A copyleft license requires that any modified version of an open source project also be released under the same license as the original project.
For example, if you released an open source project with a copyleft license, anyone who modifies your code must then release their code, including any of the changes they made, under the same license as your project.
The idea of copyleft licenses is fundamental to open source software. In fact, the first copyleft license was invented by the developers of the GNU operating system, the foundational project of the free software movement!
The original copyleft license (and oldest open source license in general) is the GNU General Public License, or GPL. GPL was created in 1989 by the same developers who built the GNU operating system, and is still one of the most popular open source licenses in use today. A 2015 analysis by GitHub showed that about 25% of GitHub projects used GPL version 2 or version 3.
GPL is known as strong copyleft license. This means that any software that uses a project licensed under GPL must also be licensed under GPL. Because GPL is an open source license, this means that any project using even a bit of GPL-licensed software must also be open source.
Other copyleft licenses are not quite as strict as GPL. Take for example the GNU Lesser General Public License, or LGPL. Like GPL, LGPL requires anyone who modifies a project to release their modifications under the LGPL license. Unlike GPL, however, the LGPL license has no requirements for software that only use the licensed project. This is why LGPL is referred to as a weak copyleft license.
Unlike with GPL, companies who write proprietary code are free to use projects licensed under LGPL. Because of this, LGPL is considered a more commercial-friendly alternative to the GPL license.
You can learn more about copyleft licenses on the Open Source Initiative website.
The other general category of open source licenses is permissive licenses. Permissive licenses are different from copyleft licenses in that they do not put restrictions on people modifying or redistributing a project.
For example, if a private company wanted to fork an open source project, add some proprietary changes, and redistribute the project, this would be totally within their right as long as the project was under a permissive license.
One permissive license that has gained popularity in recent years is the MIT license. The MIT license is one of the simplest licenses in use today, comprising a total of 172 words. Unlike the copyleft licenses discussed in the previous section, the MIT license does not impose many restrictions: anyone can copy, modify, or redistribute MIT-licensed code however they want.
The main requirement made by the MIT license is that any modified version of the code contain the text of the original license, including a copyright statement. That’s it!
Because of its simplicity, the MIT license has become a popular choice, with 44% of GitHub projects using the license in 2015. Some of the most prominent open source projects that use the MIT license include Ruby on Rails, Node.js, and React.
Other popular permissive licenses include BSD, Apache, and the Mozilla Public License (MPL). You can learn more about permissive licenses from the Open Source Initiative website.
Choosing the Right License
Now that you have all this information, how do you choose the open source license? There are a few considerations to make:
First, you should ask yourself if you would be comfortable with someone else creating or distributing a proprietary version of your project. If you are, then a permissive license might be right for you. If you’re not, then a copyleft license would probably be better suited.
If you’re interested in using a copyleft license, you have to decide if you’d like your open source code to be used in proprietary software (likely made by private companies). If so, a weak copyleft license will be a good fit. Otherwise, use a strong copyleft license.
When it comes to choosing an individual license within one of these categories, it can help to look at other projects in the same ecosystem to see what licenses they use. And remember, if any of your project’s dependencies are licensed under GPL, you must also license your project under GPL or replace that dependency.
If you’re looking for more guidance, choosealicense.com is a site developed by GitHub specifically for the purpose of helping you choose an open source license.
Do I Need to Choose a License?
At this point, you may be wondering if you even need to choose a license at all! Many people make the assumption that if they don’t add an open source license to their project, then people are free to use their code however they want. Actually, the opposite is true: if you do not add a license to your project, you are legally preventing people from using or modifying your code.
All original code that we write falls under copyright, meaning that nobody else can copy or distribute someone else’s original work. By adding open source licenses to our projects, we give others explicit legal permission to use and modify our code.
If you do not want others to modify your code, then it is okay to omit an open source license on your project. Otherwise, it is important to include a license specifying what others can and cannot do with your code.
For more information on this topic, visit choosealicense.com.
Choosing a license is an important part of creating an open source project, but it can also be overwhelming! By identifying your top priorities for your project, you can find the type of license that’s right for you and narrow down your list of choices. Remember that this article does not constitute legal advice. If licensing is critical to your project’s success, be sure to consult a lawyer.