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:
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:
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.
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.
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.
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.