Finally! All done!
You’ve worked your fingers to the bone nights and weekends writing the one tool you know no developer can live without. You’ve finished your open source project (version 0.0.1, anyway).
Then it hits you. You’ve forgotten something. Something significant: You haven’t chosen the open source license you’ll use with your project.
In other words, you haven’t decided how you will get your software in the hands of others, and even before that, if you actually want others to use your software.
Most open source developers thrive on seeing their projects become successful, and nothing says "successful" more than thousands of Github stars and hundreds of pull requests and contributors. Assuming you are much like the millions of open source developers, you likely want to see your library “see the light” — i.e. be used by other open source projects, or even by large or small corporations.
What stands between your software and the larger community of developers is the explicit permission — the license — that you attach to your creation. This license lets everyone else know under what conditions they can and can not use this wonder of your creativity.
But how do you know the right license to choose?
Not to worry. In this post, we’ll talk about your options and how to choose a license that fits your needs.
And whether you’ve written 1,000 lines of code or haven’t even begun working on that incredible new library, you’ll have the tools you need to make sure your code is protected and shared the way you want it to be.
(An important note: There are two additional parts to the process of applying an open source license. These are a copyright statement and a warranty disclosure. While this blog will focus narrowly on choosing the right open source license for your project, we'll address the copyright statement and warranty disclosure in a future post.)
Why Do You Need an Open Source License?
An open source license outlines the responsibilities taken on by those who use your software.
Open source software is often distributed widely and used in other software programs. So it’s important to tell others how to use it. Using a specific license also gives your software legal protection. You can use it to take legal action against those who violate the terms of the license.
So, do you need an open source license for your project?
If you plan to use the code yourself, with no commercial applications, and are not planning to share it with anyone, then you don’t need one.
But if you plan to release your software for others, including companies, to use, you need a license to dictate how you want your software to be used and distributed.
If that’s the case, how do you decide which license works for you?
Open Source Licenses 101
There are two basic types of open source licenses: permissive and copyleft.
Permissive licenses live up to their name by allowing users to do just about anything they want with the code. Users don’t have to republish any changes they make and typically only have to give attribution to the original authors in the form of a comment within the code.
Copyleft licenses require that anyone who changes your code for their software also has to release their code. For example, if you use an open source library to build your software, you’ll need to open up your code for others to operate under the same license.
Standard permissive licenses include the MIT license, Apache License 2.0, and the BSD License.
Standard copyleft licenses include the GPL license and the MPL-2.0 License.
Since licenses are legally binding, you’ll have to carefully consider which one to choose when writing your open source code.
The Open Source License Decision Tree
So, what are the factors to consider when choosing an open source license?
Once you’ve decided that you want to release your code to the world because you know every REST API on the planet can’t live without it, you’ll need a license to protect yourself.
The first question is if your code will be part of a broader open source ecosystem — many open source communities have a few favorite licenses they use. If it will be, consider using the licenses vetted and accepted by your community.
If you’re on your own, first ask yourself how you want others to use your software. Are you building an open source library others will use to create their software?
If you choose a permissive license, users can take your code, change it, and use it in their proprietary software without releasing the code.
If you choose a copyleft license, anyone who uses your code will have to share their code in the same way.
Many open source licenses dictate how or if the software can be used in commercial applications. You can choose if companies can use your libraries in commercial applications and the requirements and restrictions under which they can do so.
Be mindful of your target audience. A large enterprise company with lots of intellectual property within its application may not want to use your library if it means they can’t keep their code under wraps. Or they may shy away from using your software if it prevents them from distributing their software commercially.
Simplicity matters, too. There’s no need to hire a lawyer and spend hours agonizing over the license when all you care about is the code.
For example, the MIT license is permissive and straightforward. It allows others to do whatever they want to the software as long as they include the original copyright and license notice in their copy of the software.
Babel, .NET Core, and Rails use the MIT license. Notice how these projects are used by companies to build their programs.
However, the GNU GPLv3 license is a copyleft license used by Ansible and Bash. Companies are more likely to use these tools but not modify them, whereas the open source community may alter and redistribute them without any issues.
Adding a License to Your Open Source Project
You'll need a license file that contains the license text included in your project repository. You will distribute this file along with your source code.
Typically, this is a file called LICENSE or LICENSE.txt or LICENSE.md at the very root of your project. However, in some languages, such as Ruby, licenses are built straight into the RubyGem gemspec.
If you’re using GitHub to store your project, you can apply a license in just a couple of easy steps.
First, create a new GitHub project.
On the “create new repository” screen, you’ll see an option to add a license. Simply choose your license from the dropdown box.
After Github creates the repository, you’ll see a license file inside the project.
And just like that, your project has an open source license.
If you’ve already created your project without a license, simply perform the above steps or go to a project with the license you want and copy the file to your project.
Protect Your Open Source Projects
Choosing an open source license is an essential part of open source development. But it doesn’t have to be scary.
We hope this guide helps you feel more confident in choosing a license that fits your project’s needs. You can also check out TL;DR legal for more information about popular open source licenses and how they work.
Note: We on the FOSSA Editorial Team are not lawyers, so if you are seeking legal advice, we suggest you speak directly to a legal team that specializes in open source licensing.