The Impact of Licensing Change on Open Source

In today’s digital era, open source is more than just a method of developing and distributing software. It’s a philosophy and a movement. From powering the world’s largest servers to being the backbone of the internet and enabling the rise of countless startups, the influence of open source is pervasive and transformative.

In the past few years, many well-known companies have decided to transition from the open source model that initially launched its products to a source-available Business Source License (BSL) or a non-OSI-approved source-available license.

In this article we will dive into the topic and discuss why companies that have made the decision to drop their open source approach, which licenses they have transitioned to and what the implications of these decisions are. But first, let’s cover the basics of Open Source Licensing.

Open Source and Open Source Licensing

What is Open Source?

Open source refers to a type of software whose source code is made publicly accessible on platforms such as GitHub. Unlike proprietary software, where the source code is kept secret and rights to modify and distribute are reserved by the copyright holder, open source software encourages collaboration and freedom. This means that anyone can view, modify, and distribute the software for almost any purpose. The idea behind open source isn’t just about making the code accessible but also embodies the principle of collaboration, where multiple contributors come together to improve and refine the software.
  

Open Source Licensing

While open source software grants certain freedoms, it’s not a free-for-all. There are rules and conditions set by the software’s creators, and these are expressed through open source licenses. These licenses define how the software can be used, modified, and redistributed.

The primary purpose of open source licenses is to:

  • Ensure Freedom: Guarantee that the software remains open and that users have the freedom to view, modify, and distribute the source code.
  • Set Conditions: While maintaining the software’s openness, outline conditions under which it can be used, modified, or distributed.
  • Protect Developers: Safeguard the original developers from liabilities arising from the software’s use.

Common Open Source Licenses


The Open Source Initiative (OSI) is a standardizing body that reviews software licenses and certifies them as “open source” if they meet the criteria laid out in the Open Source Definition (OSD). These criteria ensure that the software can be freely used, modified, and shared.

Several open source licenses have emerged over the years, each with its terms and conditions. These predominantly align with one of two main classifications: copyleft and permissive.

A copyleft license mandates that any code evolved from the original open source code must retain its licensing conditions. A permissive license offers greater flexibility in terms of reusing, altering, and distributing the code.

Some of the most popular licenses include:


Copyleft


GNU General Public License (GPL): One of the most well-known licenses, GPL ensures that any modified version of the software must also be open source under the GPL. It’s often described as a ‘copyleft’ license because of this clause.


Affero General Public License (AGPL) v3:  The Affero General Public License (AGPL) v3 is a version of the General Public License (GPL) that has an additional clause to address the use of software over a network. The AGPLv3 is designed to ensure that the copyleft provisions are triggered even when users interact with the software over a network.


The Lesser General Public License (LGPL): Originally named the Library General Public License, the LGPL is a derivative of the GNU General Public License (GPL). It was primarily intended for software libraries, though it’s used for other software as well. Unlike the GPL, which requires derivatives or software linked to it to also be GPL-licensed, the LGPL permits proprietary and open-source software to link to LGPL-licensed libraries without inheriting the GPL’s strong copyleft clause. If you modify the library itself, however, you must release those changes under LGPL.


The Mozilla Public License (MPL): The MPL is an open-source license developed by Mozilla for its products, like Firefox. Unlike the strong copyleft of the GPL, which requires the whole derivative work to be GPL-licensed, the MPL’s copyleft provisions apply only at the file level. This means that MPL-licensed files that are modified must have their modifications released under the MPL, but new files can be covered under a different license.


Permissive


MIT License: A permissive license that allows users to do almost anything with the software (including making it proprietary) as long as they include the original copyright notice.

Apache License 2.0: Allows users to use, modify, and distribute the software. However, if a user modifies and then redistributes the software, they must state the changes made.


BSD Licenses: Similar to the MIT License, but there are variations like the “3-clause” and “2-clause” BSD licenses, which have some differences in terms.

 

Each of these licenses serves particular use cases and has its own set of permissions and limitations. Before choosing or using a license, it’s important to understand its terms and implications.


Non-OSI-approved Licenses:


Non-OSI-approved licenses refer to software licenses that haven’t been endorsed or recognized by the Open Source Initiative (OSI).

When a license is not OSI-approved, it typically means one of the following:


The license hasn’t been submitted for review: Not every license creator chooses to submit their license to the OSI for review.


The license doesn’t meet the Open Source Definition criteria: If the OSI determines that a license doesn’t meet its criteria, the license won’t receive OSI approval. This could be due to restrictions on use, modification, distribution, or other non-compliance with the OSD.


The license may be “source available” but not truly “open source”: Some licenses allow for the source code to be viewed, but they impose restrictions that are incompatible with the OSI’s definition of open source. These are sometimes called “source-available licenses.”


Some examples of non-OSI-approved licenses include:


Server Side Public License (SSPL): Introduced by MongoDB, it has certain restrictions on service offerings that aren’t present in traditional open source licenses.


Commons Clause: An addendum that can be attached to existing open-source licenses, adding a restriction, for example against selling the software.


JSON License: While largely permissive, it includes the clause “The Software shall be used for Good, not Evil,” which is subjective and thus not OSI-compliant.

Licensing Changes

Among the companies that have decided to drop their OSI-approved licenses to increase profitability, we can highlight HashiCorp and RedHat. Let’s dive into each one of them and see how their decisions are affecting millions of users and contributors.

Let’s start with Hashicorp. HashiCorp’s Terraform is a leading tool in the Infrastructure as Code (IaC) domain. It is one of Hashicorp’s flagship products and it was previously licensed under the Mozilla Public License (MPL) v2.0.

Not so long ago, HashiCorp has decided to transition from the open-source model that initially propelled its products to the source-available Business Source License (BSL) v1.1.


So what is the difference between the Mozilla Public License (MPL) and the Business Source License (BSL)?
They are both software licenses, but they serve different purposes and have different implications for both users and developers. As we learned above,the MPL is a free and open-source license created by the Mozilla Foundation.
 

The BSL is not an open-source license but is instead a source-available license. It allows developers to see and modify the source code but places restrictions on how it can be used, especially in a commercial context. The idea of BSL is to prevent cloud providers or other businesses from offering the software as a commercial service without contributing back or paying the original developers. Often the transition is the opposite, when BSL-licensed software becomes open-sourced after a period of time.


In other words, with the BSL, users can largely interact with the codebase in familiar ways, but they are restricted from offering services that compete directly with HashiCorp. This transition represents a pivotal moment not just for HashiCorp, but for the wider open-source community as well.


Next, let’s talk about RedHat (now fully owned by IBM) and particularly about CentOS and Red Hat Enterprise Linux (RHEL). Where CentOS is a free rebuild of the paid RHEL product that includes enterprise support.

Two years ago, CentOS announced a dramatic change for the project, changing it from being a stable RHEL clone to being a rolling Linux release distro, namely CentOS Stream. This suggests that Red Hat might have concluded that CentOS’s availability negatively impacts its commercial operations and sales of RHEL.

But it didn’t end there. Earlier in 2023, RedHat announced that they would change the licensing for RHEL source code, limiting it to only paying customers. In addition to that, under the terms of their contracts, the users that have access to that code, won’t be able to publish it somewhere else.

This shift sparked many discussions in the Linux community, as a few downstream distributions directly depend on the public RHEL source code to ensure exact compatibility. Moreover, the license agreement even restricts paying customers from using the source code for rebuilds and there is a debate ongoing of whether or not this constitutes a GPL violation.


These measures may in the end cause certain distributions to shut down completely leaving users with unmaintained software that gets no security patches. Many prominent figures stated that Red Hat has gone against the original open-source spirit of Linux, where in fact RHEL is itself using Linux Kernel and hundreds of packages developed and maintained in the open source community.


No need to go far, there are more recent examples of open-source projects that are managed by commercial entities and have shifted their licensing terms to more restrictive licenses in the latest software versions.

Some examples include Elastic (a real-time search server built on Apache Lucene), Redis (an in-memory database), MongoDB (a database), and Grafana (a tool for visual data representation). Each of these has transitioned their licensing models to more constrained terms aiming to balance the principles of open source with their revenue-generating approach while remaining Open Source. In other words, as an attempt to compel existing users, particularly businesses that don’t pay, to buy commercial licenses to keep using these products.


At no surprise, such changes have stirred significant tensions between the existing software user base, businesses looking to make more money and the open-source project contributors that also include enthusiasts working on a volunteer basis.

What can be done about these changes?

In the case of RedHat, a new generation of RHEL clones such as AlmaLinux, Rocky Linux, and Oracle Unbreakable Linux, were born in response to the CentOS license change. They stopped a widespread departure from the Red Hat environment, offering developers a consistent platform for their open-source projects. The issue with these clones is that they depended on Red Hat releasing their source code and can no longer easily create RHEL-compatible operating systems because CentOS Stream is not 100% compatible  RHEL replacement.


In response to HashiCorp’s transition from an open-source license to the BSL, OpenTF (now OpenTofu) was created by and already supported by 100+ organizations, and hundreds of individual developers. OpenTofu is a fork of Terraform that was initiated by Gruntwork, Spacelift, Harness, Env0, Scalr and others. Currently there are no differences between Terraform (versions prior to 1.5.x) and OpenTofu. The question remains if this will change as new versions are released and if both OpenTofu and Terraform will remain compatible.


Less than a month ago, on the 20th of September of 2023, the Linux Foundation announced the formation of OpenTofu. And this is good news, since it is bringing hope to all affected by license changes and will further foster open collaboration. We are looking forward to seeing how OpenTF evolves when backed by the open source community.

What are the implications of these changes?

The implications of these sudden changes are of course the uncertainty of having a successful product today and not knowing if by tomorrow you will have to rebuild everything because of a sudden change in the licensing of OSS you’re using.

When an Open Source project is primarily reliant on a single or a handful of developers, or predominantly spearheaded by one company (commercial open-source software), there’s a heightened risk of unforeseen licensing shifts that could impact your commercial interests compared to a project that is backed by a widespread community (e.g. a real community open source project).

This opens up the discussion of who open source should be run by. Is it best for open source projects to be under foundations or a single vendor maintenance?

An OSS project can serve as a small yet essential library for some larger software. And for some companies, it might stand at the heart of their products, with exclusive features and support reserved for paying users. 

We find it truly unfortunate that some companies that have based their business model on an open-source solution now face the challenge of reevaluating their entire offering structures.


Is there any way of avoiding this?

Commercial open source today seems to be following a tendency of transitioning from being openly accessible to a source-available license or another kind of restricted license.

There are many ways in which a vendor can push to convert open-source users into paying customers. This can look like the delayed release of open-source code, the absence of certain features, or the outright discontinuation of an open-source license.

If you want to avoid having to become a paying customer, having to migrate to an alternative solution, or having to start maintaining the software yourself, you should proceed with caution and carefully evaluate the pros and cons of integrating open source into your projects and products.

Are you faced with the challenge of deciding which OSS to adopt for your next project? Contact us today! Cloudification team has wide exposure to the OSS and are always happy to assist you.