Do you know the best license for your project?

Some companies want to keep their projects closed-source in order to profit from their products. However, there are several benefits to keeping the source open including:

• Community contribution and feedback
• Allowing controlled free use of your products

We want our projects to be financially sustainable while supporting the open-source space. Let's take a look at the licensing options for open-source projects on GitHub.

Option 1 - No License

As per GitHub's documentation, no author is obligated to choose a license for their project. Without a license, the default copyright laws will apply.

Pros

• No Effort: No effort required on the author's part.
• Some control: Retains some control of the source-code.

Cons

• Not Permissive: Generally, users will have no permission from the author to use, modify or share the software. However, GitHub allows users to Fork and view code as a part of their terms.

Option 2 - MIT

The MIT License is a well known license trusted by many open-source projects.

Examples include:

• Dotnet
• Ruby on Rails

Pros

• Permissive: Allows for commercial and private use as well as distribution and modification of the author's software.
• Collaboration + Community: Promotes an open and collaborative environment with community feedback.
• Short and simple: The text of the license is simple and quick to understand.

Cons

• Limited Patent Protection: The MIT License doesn't include explicit patent grants or protections.
• Lack of clarity on Trademarks: The license doesn't address the use of Trademarks associated with the software

Option 3 - Copyleft (e.g. GPL)

A copyleft license like the Gnu Public License promote and protect the principals of open-source software. Though they may also introduce complexities and potential limitations that users may be deterred by.

Examples include:

• Ansible
• Bash

Pros

• Collaboration + Community: Promotes an open and collaborative environment with community feedback.
• Protection Against Exploitation: Guards against consumers taking the source code and making proprietary modifications in a closed environment.

Cons

• Complexity: Some developers and organizations may find a copyleft license to be too complex and stringent.
• Perceived Risk: Copyleft licenses may discourage contributors or participators through perceived risk.

Option 4 - Proprietary

Companies often use a proprietary license when they prefer to have fine-grained control over their intellectual property.

Examples include:

• Mozilla
• Duende

Pros

• Better control: Authors have fine-grained control over their source code and how it's used.
• Benefits of community development: Authors can still benefit from the community engaging with their source code

Cons

• Cost: Drafting and iterating upon your license will cost time and money.
• Bad actors: Authors will need to be vigilant of bad actors abusing the license and choose to pursue them.

Option 5 - Functional Source License (FSL)

Sentry introduced the FSL as a way to support the open-source community whilst retaining control over their IP.

Examples of projects with this license include:

• Sentry
• GitButler

Pros

• Protection: Retains control over source code for up to 2 years
• Free and Open-Source Software (FOSS) Values: Automatically converts to MIT/Apache 2.0 licensing after 2 years
• Continual Iteration: Pushes the author to continually iterate on their project or risk third-parties competing with a forked version of the project.

Cons

• Not strictly Open-Source: While Sentry values FOSS, this license does not meet the strict definition of open-source.