Open-source Licensing

And what license to go with for your commercial offering

In the last few years, I have invested in several developer-infrastructure companies, including Hasura, Testsigma, and 100ms. At each one of these companies, we have taken an open-source strategy to engage with the community and get product feedback early.

One of the key decisions that the founders had to make early on in their journey of launching open-source products is, “Which license to choose for making their open-source code available?” As we started answering this question, we realized the open source licensing norms, especially for commercially inclined companies are in a state of flux. In this post, I decided to unpack some of the popular options, as well as the decisions that other larger companies have made in this regard.

But before we begin please read this standard IANAL warning:

I am not a lawyer, and my post and conclusions below are my own personal inference of each license, as well as what I would do if I were launching a commercial open-source product in the market today. Please seek proper legal advice before following any of the content, tips or advice mentioned in this article.

I am also not sure whether I managed to get every legal aspect right in this article, so please feel free to point out any errors and I will publish edits over time.

To kick off, we firstly need to agree on what are open-source licenses? The definition of open-source is governed by OSI, the Open-Source Initiative. You can see a list of OSI approved licenses. Anything that OSI has not approved is, by definition, not open-source. Yet some of these fall under other categories of licenses which are generally called “Source-available”. In my post, I am clubbing the source available licenses such as SSPL within open-source licenses conversation but I repeat again: SSPL is Not an Open Source License

There are primarily two categories of licenses out there, Weak and Strong. Here is a table that reflects a summarized comparison of the more popular ones:

Popular License Choices

We compare these licenses on the following parameters:

• Is the license OSI-approved?
• Does it mandate Copy-left i.e. all modified and extended versions of the code need to also follow the original license?
• Does it allow Redistribution i.e. can some one distribute your code as a service?
• Does it allow Derived Work Redistribution i.e. can some one modify the code and then provide it as a service?
• Does it allow Monetization i.e. can some one redistribute and sell your code as a service?

Permissive (Weak) Licenses

MIT

• One of the most flexible Open-source licenses out there, it’s the default choice for people who want to publish truly open-source code and care very less about risk of copying/monetization
• It does require the original copyright and license notice to be included either in the distributed source code or software
• However, there are no restrictions regarding redistribution or monetization
• It is also compatible with many other open source licenses, meaning that MIT-licensed code can be used in other open source projects that use different licenses

Apache

• Almost as permissive as MIT license, this license was developed to combat frivolous patent lawsuits. The license grants you a patent license along with a copyright license
• It requires license notifications and copyrights on the distributed code and/or as a notice in the software
• However, derivative works, larger projects, or modifications are allowed to carry different licensing terms when distributed and are not required to provide source code
• Similar to MIT license, If someone decides to create open source projects in direct competition to your commercial offering, they’re allowed to do so without your permission. It gives the community the control and power they deserve for contributing to and evangelizing your project

Copyleft (Strong) Licenses

These licenses were created to deter attempts by third party organizations (mostly cloud providers) to use open source work for commercial gains.

Copyleft as a concept is simple. It mandates that if someone modifies the software and distributes their own version, the modified version must copy the same license as the original version.

There are multiple types of licenses with copyleft characteristic:

AGPL

• The AGPL or Affero GPL, a version of the General Public License (GPL) aims to enforce full copyleft rights on all software that use it
• Note that here I talk only about AGPL, instead of GPL, as it was derived from GPL keeping in mind server-side applications, which is the predominant way software is distributed today
• The license started becoming popular in an attempt to protect derived works of the original open-source code to be commercially offered by third parties

The key clause in this license is: “your modified version must prominently offer all users interacting with it remotely through a computer network … an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge…”

• The definition of modified version or derived work in the license is fairly broad, and potentially opens up even a genuine user towards potential lawsuit if they are building on top of your software and allowing their customers to “interact remotely” with the software
• Because of this strong copyleft nature, the license puts some teams off of open-source packages as it potentially forces all other code they may write to become AGPL-ed software. A good example of this is Google’s strict internal policy against using AGPL software.

SSPL

• Recently, MongoDB and Elastic came up with their own version of non-open source but “source-available open core” software license by further modifying the AGPL license to specifically cater to the software being provided as a “service” instead of a “remote network interaction”
• More importantly, SSPL requires that those making SSPL-licensed software available to third-parties (modified or not) as part of a “service” must release the source code for the entirety of the service, including without limitation all “management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service…”
• This way Elastic and MongoDB’s are protecting their hosting business, by making it almost impossible for a cloud provider or a vendor to comply with the SSPL license while providing a hosted version of the open-source products
• Needless to say, there is a strong debate ongoing on adoption and use of such SSPL software

Important Transitions

While you may think that choosing a license is a once-and-for-all decision, history says otherwise. A number of companies have transitioned their licenses from weak to strong (mostly) and strong to weak (rarely). Some have done these changes multiple times in their lifecycle. If there is one learning I have from reading the below changes, it’s that we don’t yet have a gold standard to follow and your license choice depends on your product, your business model, and most importantly, your fears.

Here are some examples of license changes that happened recently:

Confluent: Moved from Apache to Confluent Community License

Elastic: Moved from Apache to SSPL (and Elastic License)

Grafana: Moved from Apache to AGPL

MongoDB: Moved from AGPL to SSPL

Redis: Moved from AGPL to Apache (with Commons Clause) and again moved to Redis Source Available License

Cockroach Labs: Moved from Apache to BSL (Business Source License)

Conclusion

Again, IANAL (see disclaimer above), and my conclusion below is my own personal inference of each license, as well as what would I do if I were launching a commercial open-source product in the market today. Please seek proper legal advice before following any of the content, tips or advice mentioned in this article.

• If you are building a commercial product, are not scared of cloud providers or third party copying your code and distributing it, already have a relevant commercial-licensed offering to distribute along with the open-source solution, I’d consider using the Apache license. It’s one of the most flexible and open source licenses, and community adoption is likely to be the highest.
• If you are worried about third parties, especially cloud vendors, commercializing your code and want to desperately prevent it from happening, but your product is unlikely to be directly integrated into your customers’ products and hence will not be “remotely interacted with” by their users in turn, and is instead a standalone product that will be used only by your customers themselves, consider using AGPL because it is an OSI-approved license. But remember, that your community adoption will likely be lower, especially in the enterprise segment.
• In all other cases consider using SSPL under a source-available license to truly protect yourself. But remember that you will not fall under the definition of open-source and hence cannot call yourself an “open-source company”. This way your community adoption will likely be the lowest among the three.

I hope this post helps you think through your open-source licensing choices. Do reach out to me on LinkedIn/Twitter with a short note in case you have any follow-up questions.