The Developer’s Guide to Open Source Software Licenses

Open source software has become an integral part of product development for organizations of all shapes and sizes. While engineering teams once relied primarily on proprietary code, open source now comprises more than 90% of the components of modern applications.
‍
As open source software has grown in popularity, managing compliance with legal and intellectual property requirements has meant that open source software licenses have also taken on increased importance. Licenses tell the world the conditions under which they can and can’t use an open source project. Ultimately, licenses ensure that open source software developers — the community of minds behind many of today’s most innovative technologies — are able to protect their creations as they see fit.

There are hundreds of different open source licenses, most of which can be grouped into two categories:

Permissive Licenses

These place little restriction on how others can use your source code and re-share your software. They also generally have a high level of license compatibility, meaning you can legally combine multiple pieces of software and distribute them together.

Copyleft Licenses

These require that anyone who releases a modified open source program must also release the source code for that program. This type of license generally allows users to change and re-share your creation as long as they also include their source code for others, too.

Common Licenses

Best License for Commercialization

Most Out-There Licenses

How to Choose a License

How to Apply a License

Common Open Source Software Licenses

More than 60% of open source projects use one of the following three licenses: MIT (permissive), GPL (copyleft), or Apache 2.0 (permissive). Here are they key elements of each:

MIT
Under this license, users can essentially do anything with the software as long as they include the original copyright and license notice in the copy of the software. The MIT License is also easily integrated into software with copyleft licenses because it has few regulations on software reuse.
GPL
The GPL license family (specifically GPL v2 and GPL v3) are commonly used copyleft licenses. If others develop software using a component with a GPL license, they must release their full source code and give their users the same rights they received. This license was created to protect software from becoming proprietary, or private, which is why many programmers like this license.
Apache 2.0
This license gives users the freedom to do what they want with the software, but it requires them to include the original copyright and license notice, state any significant changes, and include the NOTICE file if there is one. These elements make the Apache License 2.0 a little less permissive than the MIT License.

Best Open Source Software Licenses for Commercialization

If you are interested in profiting from the software you’ve developed, an open source license that lends itself to commercialization is often the best choice.

Although some revenue-generating open source projects use permissive licenses, GPL and copyleft licenses seem to occupy the majority in value. This isn't surprising. Intuitively, stronger licenses should allow you to capture more direct value from your creations.

At the same time, of course, developers may worry that copyleft licenses will deter potential users from adopting your software. And if no one uses your software, then you've failed before you've started.

Most Out-There Open Source Licenses

No one can accuse the open source community of lacking a sense of humor. Although software is generally serious business, developers can choose from several out-of-the-box, unexpected, and downright funny licenses.
‍
For example, the Beerware License allows users to do anything with your project material as long as the original copyright is retained. If the users like and happen to meet the author, they are obligated to buy the author a beer. (In some versions, users are encouraged to drink a beer in honor of the author.)
‍
Then there’s the WTFPL license. As the name suggests, this is a (very) permissive license which allows users to do whatever they want with your software.
‍
On the other end of the spectrum is the Passive Aggressive License. This license is brilliantly named: It essentially states that users are allowed to copy, modify, and distribute the source code — but can’t actually run, execute, or use the software built from the source code. Hence, passive aggressive.

How to Choose the Right Open Source License

Deciding which open source license to use with your project can be challenging. After all, there are dozens upon dozens of license types, sometimes with only slight differences. Although each developer will have their own priorities, it can be helpful to consider several questions to start your selection journey.

Do you intend for your code to be part of a broader open source ecosystem?
Many open source communities have a few favorite licenses they use; consider selecting a license that’s been vetted and accepted by your community of choice.
How do you want others to use your project? 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.
Who is your target user?
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.
‍
There are a number of real-world examples that add context to the licensing decision. Open source software like Babel, .NET Core, and Rails uses the MIT license, which is permissive. Notice how these projects are used by companies to build their programs.
‍
On the other hand, Ansible and Bash use GNU GPLv3, a copyleft license. 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.

How to Apply an Open Source License

Once you’ve selected an open source license, you’ll need to apply it to your project. In the most common scenario, you will want to place a file named LICENSE at the root of your project sources.
‍
Many modern SaaS tools such as GitHub and GitLab will allow you to choose a license when the repository is first created. This is, perhaps, the single simplest way you can ensure your projects contain the right legal protections from the start.

Once you start the “Create new repository” workflow, GitHub will present you with the following screen and a relevant checkbox toward the bottom. Checking the box opens up the drop-down with numerous licensing options. For existing projects without a license, just drop the LICENSE text file at the top of the repo, commit, push, and cut a new release.

For Partners

For Industries

For Role / Org