Open Source License Types in the Cloud-First World

Open source is driving billions of dollars of annual savings for the technology community, and the cloud is accelerating digital like never before. However, with the cloud launch, the traditional dynamics of open source and derivative work have been skewed. Over the last couple of years, we saw MongoDB, Confluent, Redis, Elastic, and others develop licenses to prevent an As A Service (AAS) distribution on the cloud. As most of our development is cloud-first these days, developers need to be aware of the license type constraints and open source license types to use in the cloud. While the Open Source Initiative strictly defines what is “Open Source”¹, here we refer broadly to publicly available free licenses that are prevalent today.

The open source movement started with an intent to share code and know-how so the community could benefit from it. The origins of open source trace back to Richard M. Stallman and his personal experience of sharing code in the 70s. He announced the GNU project in 1983 and the first version of GNU GPL in 1989. If you didn’t know, GNU stands for “GNU’s Not Unix”! There were multiple pivotal moments in making what is open source today, but we will not delve into all of them.

The core aspect of open source hinged on sharing the source work with others, creating derivative work and distributing that in open source, and generating an exponential growth in the shared knowledge base. The term copyleft became prevalent, signifying that the open source should not have a specific copyright. A smart play of words like the naming of GNU, but communicates the focus precisely. Reciprocal licensing is another term used alternatively to copyleft.

With the cloud model, the hyper-scale cloud providers could generate tremendous value from their As A Service (AAS) offerings without creating much of a derivative work and adding value to the open source community. While the jury is still out on the ideology and who’s right, some of the commercial open source providers switched licenses so they could reap the value of the AAS offerings instead of the cloud providers.

Here is a comparison of the most popular open source license types that we come across in building applications today.

Restrictive Licenses

Not everyone seems to get this. NO LICENSE is not open source, but the opposite! When you come across code or components in public repositories with no license attribution, stay miles away. The absence of license indicates full copyright to the author, and you cannot use any part of it for know-how or create derivative work.

So creators need to understand the licenses and adopt them appropriately while sharing your work on public repositories. Failing to add a license makes your work unusable to others even though you have shared It in public with good intent.

Cloud Licenses

This is an evolving segment. Most licenses were created around 2018 as AAS offerings from hyper-scale cloud providers started eclipsing the products. The popular licenses are:

Server Side Public License: This was introduced by MongoDB in 2018 when it moved away from AGPL to prevent large cloud providers from offering AAS models. Instead of directly preventing cloud providers, MongoDB introduced Section 13 that requires all providers in an AAS model to release all their software used to provide the AAS service also under the SSPL license. This includes all of the hosting, storage, management, monitoring, and other software that typically are core to a cloud provider, thereby discouraging an AAS offering.

Commons Clause: This is available as a narrow, minimal-form commercial restriction on top of an existing open source license to transition the project to a source-availability licensing scheme. Commons Clause prevents the user from selling the base software’s core capabilities while allowing them to create other value-added AAS offerings.

Elastic License: Created by Elastic search in 2018, the license restricts an AAS offering where the capability of Elastic cannot be the primary capability of your offering.

Redis Source Available License: Created by Redis with a similar approach of other providers listed above, this license prevents an offering using Redis that is directly a database, or search engine, or caching engine, or stream processing engine, or an indexing engine or an ML/DL/AI serving engine.

Confluent Community License: Confluent introduced this in 2018 around its KSQL product. It blocks AAS models. While companies could use KSQL as a part of their SaaS or any other offering, they cannot create a KSQL as a Service offering.

While many software providers are creating such licenses to prevent AAS, they also provide modules under traditional open source licensing models listed below. So if you plan to create AAS business models using these software, do look for managed instances or modules under traditional open source licensing based on your need and ability to comply with their cloud license requirements.

Strong Copyleft Licenses

Unlike cloud licenses, they do not restrict AAS offerings. But they require all code required to create the extended product to be shared under the same license, i.e., full reciprocity. The most popular licenses in this category are the GNU General Public License (GPL) and the European Union Public License (EUPL). This is an outstanding category if you are working on community projects. But if you are looking to leverage open source for proprietary business work, this could be limiting. While Creative Commons is not used in software licensing, it shares the strong copyleft philosophy. You would come across ‘Creative Commons share-alike’ in situations like using code snippets or solutions from forums like Stack Exchange. Use them accordingly.

Weak Copyleft Licenses

This category allows developers and companies to use open source in their proprietary business applications while balancing reciprocity. Under this license, only when you modify the source of the component under the license needs to be shared. Any proprietary component developed separately, but only uses the licensed component without modification, does not need to be shared. Popular licenses in this category are the GNU Lesser General Public License (LGPL), the Eclipse Public License (EPL), and the Mozilla Public License (MPL).

Permissive Licenses

This category of licenses enforces the least reciprocity in sharing source code. They are also called non-copyleft. Well, if copyleft was the opposite of copyright, then the opposite of copyleft is non-copyleft? Derivative work in this category can be under any license, and the source code of derivative work is not required to be shared irrespective of modification status. In this category, popular licenses are the MIT License, the Apache License (ASL), and the BSD License (Berkeley Software Distribution).

So apply due care when you are picking up code or software packages from public libraries. If you are targeting community projects, then strong copyleft is a suitable license. Suppose you are looking for proprietary software, then choose between weak copyleft and permissive licenses. If you are working on proprietary solutions are unclear of licensing terms, then a cloud-managed service could take away the guesswork for you.

Happy Reuse!

Sources

While every effort has been made to provide accurate and updated information, we regret any omission or error.

[1] Open Source Initiative — https://opensource.org/osd