The Developer’s Guide to Open Source Software Licenses – FOSSA

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.

Read More: Common Open Source Licenses

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.

Read More: Best Licenses for Commercialization

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.

Read More: Most Out-There Open Source Licenses

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?

  ‍
  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

  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.

Read More: How to Choose an Open Source License

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.

Read More: How to Apply an Open Source License