Picking an Open Source License — a Decision Framework

In this post, I’m describing our decision making process to determine which license to pick for Resoto, our open source cloud asset inventory.

The question came up during Week 1 for “Some Engineering Inc”, the company behind Resoto. My co-founder Lukas had developed Resoto (please consider giving us a star!) inside of D2iQ, which had open-sourced the repo under the Apache 2.0 license.

We discussed if Apache was still the right license going forward, or if a more restrictive, “copyleft” license might be a better option. Open source vendors like Elastic and MongoDB had also published their own licenses, to restrict cloud providers like AWS to offer managed services.

The difference in these licenses comes down to the freedom, obligations and restrictions a developer faces in using the code base. That in turn has implications for your company’s distribution strategy.

The outcome for us — Apache 2.0 — may not be surprising. But I thought describing how we got to our decision will be useful for other start-ups. I’m including an overview of the evolution of open source licenses, and new types of partnerships between open source and the cloud providers.

A History of Open Source — Licenses, Lawsuits & Litigation

The term “open source” goes back to a strategy meeting in Palo Alto, California on February 3rd, 1998.

A month before in January 1998, Netscape had released their browser source code under the Mozilla Foundation. An unusual move at the time that generated quite some publicity. The meeting recognized the opportunity to educate the market about the benefits of an open development approach.

Open Source Organizations

The meeting resulted in the creation of the “Open Source Initiative” (OSI). The OSI publishes a definition of what they consider “open source”. The intent of the term “open source” was also to delineate from the term “free software”, popularized by the Free Software Foundation (FSF).

The term “free” has often been confused with “free as in price”, when the actual intent was “freedom to run, copy, distribute, study, change and improve the software”. The FSF incorporated in 1985. You may have heard of its founder, Richard Stallman. Stallman is, let’s say, a rather controversial person.

You’ve probably also heard of the “Apache Software Foundation” (ASF), which goes back to the Apache Web Server. Engineers started sharing code patches for the server via email around February 1995. The ASF incorporated in June 1999 and manages over 300 well-known open source projects.

Categories of (open source) software licenses.

Fast forward to today, and there are three broad categories of (open source) software licenses.

1. Restrictive licenses
2. Permissive licenses
3. Vendor licenses

You could argue there are more, different categories (public domain, proprietary, by industry, etc.). But for simplicity and the purpose for this post, let’s roll with these three.

Restrictive licenses, also known as “ copyleft licenses”, require release of all source code based on prior copyleft work to the public. The term “ copyleft” first appeared in the freeware program Tiny BASIC in 1976, as an obvious opposition to “copyright”. Stallman picked up on the idea and included the term “copyleft” to formulate the first GNU General Public License (GPL) in 1988. Any project built with GPL code must itself have a GPL license. Other restrictive licenses include the “Affero General Public License” (AGPL) and additions to the GPL like the “Lesser General Public License” (LGPL).

Permissive licenses, also known as “ attribution style licenses”, impose minimal restrictions on modifying or redistributing software. The only requirement is usually to retain a copyright notice, i.e. attribution. A third party can take the code, modify and distribute it as a proprietary product. As long as they reference the original project, they’re ok. The most popular permissive licenses in software are the Apache license, the MIT license, and the BSD license.

Vendor licenses combine aspects of permissive and restrictive licenses. They aim to keep a balance between publishing open source software and securing economic income for the maintainers of a project. Restrictions apply to commercialization or usage by 3rd parties without contributing back. They also protect the right of offering a managed service in the cloud for the main creator and maintainer of the project.

The OSI tends to not consider vendor licenses as “open source”, as the restrictive elements don’t fit their definition of “open source”.

The rationale for vendor licenses

Thought leadership around vendor licenses started around 2010. Back then, there was a (justified) fear that enterprises and web-scale companies would use open source software, but not contribute back, either in code or cash.

For example, in June 2013, Michael Widenius and Linus Nyman published “ Introducing “Business Source”: The Future of Corporate Open Source Licensing?”. BSL issues an initial non-open source license with usage restrictions. The license transforms to an open source license on a future date within a four years or less.

Then, in October 2015, Amazon Web Services launched its “Amazon Elasticsearch Service”. AWS had taken “Elasticsearch”, software published by Dutch company Elastic under the permissive Apache 2.0 license, and offered it as a managed service. According to the New York Times, “ within a year, Amazon was generating more money from what Elastic had built than [Elastic]”.

The world had changed.

• In the “old” world, the business model for open source consisted of enterprises paying for support or (proprietary) enterprise features on top of the open source code. In this context, most people probably think of Red Hat.
• In the “new” world, customers would rather pay somebody to run the software and take care of all the heavy lifting to manage enterprise features like performance, scalability, and availability.

And that’s exactly what AWS is good at. Plus, the integration with all other AWS products makes using a managed service even more compelling.

As you can imagine, Elastic wasn’t happy. “ NOT OK “, as Elastic CEO Shay Banon writes. In fact, Elastic claims that they never partnered with AWS, despite AWS claiming otherwise.

And who’s to blame Elastic for looking out for themselves? Elastic took AWS to court, the case is pending at the time of this post.

The argument of taking Apache 2.0-licensed software is obviously impossible given the license’s permissive nature. Rather, Elastic argues that AWS is infringing on Elastic’s trademark for Elasticsearch, and also using proprietary Elastic code that’s not part of the open source. Neither one was part of the original Apache license.

That’s of course where the narratives diverge. Elastic stands its ground with the lawsuit. AWS argues that they merely built a service for a popular open source tool, something customers asked for.

But for open source, it was a signal to react.

Ecosystem Reaction

Michael Widenius, author of the Business Source License, is also the CTO of MariaDB. In fact, in August 2016 MariaDB published and licensed select enterprise parts of their software under the MariaDB Business Source License (BSL). Everything else stayed licensed under GPLv2.

Other vendors followed suite, here are a few examples:

• In October 2018, MongoDB introduced the “Server-Side Public License” (SSPL). The SSPL is based on the restrictive GPLv3 license.
• In April 2018, Elastic introduced the Elastic License. In January 2021, Elastic publishes the Elastic License 2.0 (ELv2) and also adopts MongoDB’s SSPL.
• In December 2018, Confluent introduced the Confluent Community License.
• In December 2018, Timescale introduced the Timescale License, with a 2.0 update in September 2020. A long thread on HackerNews debates the license change.
• In June 2019, Cockroach DB introduced the CockroachDB Community License. CoackrochDB also uses MariaDB’s BSL.
• In September 2021, Airbyte changed from the MIT License to the ELv2. The interesting aspect here is that Airbyte is a investment, and Benchmark partner Chetan Puttagunta was previously an investor and board member at MongoDB — so he’s very much familiar with the licensing topic.

In these cases, the companies changed their licensing from the permissive Apache 2.0 License. The one thing the new vendor licenses have in common is that they restrict third parties from offering hosted or managed services.

It’s a direct shot at cloud providers like AWS, in response to the lessons learned from Elastic. In fact, you’ll sometimes hear the term “Cloud Protection Licenses” instead of “Vendor Licenses”.

Permissive Open Source Licenses Continue to Trend

For new open source projects, what’s the preferred licensing option? Based on what we’ve learned so far, we should expect a shift to more restrictive, GPL-style licensing.

Turns out, the opposite is true. Permissive licenses have grown in popularity.

In 2021, according to data by WhiteSource, 76% of open source components have a permissive license, a 9% rise from 67% in the previous year. Only 24% of open source licenses are copyleft, compared to 33% in 2020.

Source: Whitesource, “ Open Source Licenses in 2021: Trends and Predictions “

What Matters is Developer Adoption

So how come the continued shift to permissive licenses?

There’s only one answer:

Developer adoption.

When you’re starting out as an open source project, you’re long on aspirations but short on ecosystem traction.

GPL-style licenses carry too many uncertainties that make it risky for developers to adopt your software. Attribution-style licenses make it a no-brainer for a developer to use and contribute to your project’s code. Licenses like Apache 2.0 and MIT are established, transparent and carry no risks.

Time has also shown that if it comes to that point, creating and switching to a vendor license is not that much of a big deal. Yes, there may be fallout and you may get a lot of flak at the start — all you need to do is look at the various threads on Hacker News.

But people understand that you have to make a living.

And making a living they do. Elastic, Confluent and MongoDB are all public companies and thriving. At the time of publication of this post, their stock prices are at all time highs. Cockroach Labs received a mega-round of $160M in funding in January 2021.

What’s the common thread? They all now offer hosted versions of their products. There’s still a lot of open source within their products, even if their definition of “open” may not fit the OSI’s definition. But they still leave enough room for bottom-up adoption — the restrictions of these licenses hardly affect anyone but the largest cloud providers.

Cloud Partnerships as a Business Model

Finally, everyone has gotten smarter and figured out that it’s better to work together and focus on the opportunity ahead.

Open source companies bring great software and a developer ecosystem to the table. The cloud providers offer distribution with their large enterprise footprint and billing relationships.

A few examples.

In 2019, Google Cloud announced a partnership with Confluent, DataStax, Elastic, InfluxData, MongoDB, Neo4j and Redis Labs. GCP integrates the partners’ products into the GCP Console, to offer them as managed services operated by the partners.

In fact, offering managed versions of popular open source product is part of GCP’s strategy to attract new workloads — something I wrote about in “ The Shift to Multi-cloud Is in Full Swing “

Even AWS has come around. In 2020, AWS teamed up with Grafana Labs, creator of the popular open source observability product Grafana, to offer “Amazon Managed Service for Grafana (AMG)”.

These partnerships make sense for all parties involved:

• Customers get a managed service.
• Vendors get distribution.
• The cloud providers make money on compute, network and storage.

Everyone wins.

How to pick a license for your company

This brings us back to the beginning of this blog post. What license to pick when you start?

It all depends a bit on what you’re afraid of.

If you’re afraid…

• … that somebody will take your work and offer it as a managed service, then using a restrictive GPL-style license is the way to go. Or you adopt one of the vendor licenses, like the SSPL. For open source companies whose strategy is to go-to-market with a SaaS or a self-hosted version, this approach may make sense.
• … that nobody will adopt your project, and you’re solving for traction. then a permissive license is the best option. You don’t want to create any hurdles for users to adopt your project.

You may also choose a hybrid strategy, where different parts of your product carry different licenses.

How we picked Apache 2.0 for Resoto

Asking ourselves what we’re afraid of was the approach we chose for Resoto. With Resoto, we’re building an open source cloud asset inventory, and make the problem of figuring out what’s running in your cloud easy for developers and SREs.

Making adoption easy and building a big community are our primary goals. We don’t want users to fear any copyleft restrictions. The MIT license didn’t feel right for us, as we still want to maintain certain trademarks and rights to our logo and brand.

That’s why we decided Apache 2.0 is the best license for Resoto. I’ll publish more thoughts on licensing strategy soon in our GitHub repo, and what it means for contributions to our code base.

You can check it out at https://github.com/someengineering/resoto — and if you like what we do, please give us a star!

Originally published at https://www.linkedin.com.