Open Source Security

Commercial OSS License Shifts: An Analysis

From MongoDB to HashiCorp, commercial open source vendors have repeatedly relicensed away from OSI-approved licenses. The pattern reveals a fundamental tension between sustainability and freedom.

Nayan Dey
Senior Security Engineer
6 min read

On August 10, 2023, HashiCorp announced that Terraform, Vault, Consul, Nomad, Boundary, Waypoint, and Packer would move from the Mozilla Public License 2.0 to the Business Source License 1.1. The reaction was immediate and familiar: a fork emerged within weeks (OpenTofu, incubated by the Linux Foundation), competitors issued press releases, and enterprise procurement teams scrambled to understand what they had just been locked into. If this sounds familiar, it is because the same story had already played out at MongoDB, Elastic, Confluent, Cockroach Labs, MariaDB, and Redis.

The commercial open source license shift is no longer a one-off event. It is a repeating pattern, and understanding that pattern is essential for anyone building on venture-backed infrastructure.

The Business Model That Broke

The "open core" model emerged in the 2010s as a way to reconcile the economics of software development with the reality that cloud providers could capture enormous margin by running other people's open source code as managed services. For a decade, companies like MongoDB, Elastic, and Confluent built global businesses around permissively licensed core products plus proprietary management tooling.

Then AWS started running managed versions of those same cores: Amazon DocumentDB (compatible with MongoDB), Amazon Elasticsearch Service, Amazon MSK (Kafka). The hyperscaler did not need to fork. They could take the Apache 2.0 code, rebrand it, and run it at scale with their existing infrastructure, sales, and support operations. From the vendor's perspective, the permissive license was subsidizing their largest competitor.

MongoDB moved first, in October 2018, creating the Server Side Public License. The SSPL is a strong copyleft license that the Open Source Initiative declined to approve. The OSI's position, articulated in a January 2019 statement, was that the SSPL's requirement to release the source of the entire service stack was designed to be commercially unusable, which violated the spirit of the Open Source Definition.

Elastic followed in January 2021, dual-licensing Elasticsearch and Kibana under SSPL and the Elastic License 2.0. Amazon's response was to fork Elasticsearch 7.10.2, the last Apache 2.0 release, into OpenSearch, with code donated to the Linux Foundation in September 2024.

The Business Source License Era

HashiCorp's August 2023 move to BSL 1.1 was different in character. BSL is a "source-available" license that prohibits competitive commercial use for a period (typically four years), after which the code converts to Apache 2.0. MariaDB created the BSL in 2013 for MaxScale, and it has since been adopted by CockroachDB (June 2021), Sentry (November 2019), Couchbase (for some products), and others.

BSL 1.1 is less restrictive than SSPL in one important sense: it has a sunset. The commercial restriction expires. But for enterprises building on Terraform today, the practical effect is that any version they deploy is under a non-OSI license for four years. For security teams, that means CVE remediation on a version that is not free software.

The OpenTofu fork, launched by a consortium led by Harness, Spacelift, env0, and others, and accepted into the Linux Foundation as a project in September 2023, was the first coordinated community response to a BSL shift. OpenTofu maintains MPL 2.0 licensing and has already diverged from Terraform in meaningful ways, including a different state file format in version 1.8.

The Redis Capitulation

On March 20, 2024, Redis Ltd. announced that Redis 7.4 and later would move from the three-clause BSD license to a dual SSPL / Redis Source Available License model. Redis had been BSD since its creation by Salvatore Sanfilippo in 2009. The license change provoked an immediate fork: Valkey, launched by the Linux Foundation with commitments from AWS, Google Cloud, Oracle, Ericsson, and Snap, with a 7.2.5 release in early April 2024.

What made Redis distinctive was speed. Within weeks, major cloud providers had aligned behind a fork, Linux distributions had begun shipping Valkey packages, and the "Redis" brand had been bifurcated from the Redis codebase. By the end of 2024, most major managed Redis offerings outside Redis Ltd. itself had committed to Valkey migration paths.

What Changes for Security Teams

License shifts do not create vulnerabilities by themselves. They create second-order risks that often show up in security programs.

Patch divergence. Once a fork exists, upstream security fixes may or may not land downstream in a timely way. Amazon backported several security fixes to OpenSearch from Elasticsearch, but there were gaps. Valkey and Redis will increasingly ship fixes independently. Security teams need to know which fork their deployment is actually running.

Supply chain inventory drift. SBOMs generated against "redis 7.2" may be ambiguous once the same name refers to two different codebases under different licenses. CycloneDX and SPDX both support PURLs that can disambiguate, but only if the SBOM generator is updated to do so.

Compliance posture. Enterprises with internal OSS usage policies keyed to OSI-approved licenses find that products they adopted years ago no longer qualify. The software has not changed, but the license has. Legal teams then face the choice of exception, migration, or grandfathering.

Contributor license assumptions. Community contributors who signed CLAs assuming Apache 2.0 distribution may feel, and in some cases have publicly argued, that the relicensing violated the spirit of their contributions. Elastic faced this critique from Shay Banon's original contributors. HashiCorp faced it from the Terraform provider community.

A Decision Framework

When a dependency relicenses, the practical questions for an engineering organization are: does my current usage remain compliant under the new terms? (Often yes, for internal use; often no, for embedded-in-SaaS use.) Is there a viable fork with backing I trust? (OpenTofu, Valkey, and OpenSearch all clear this bar today; smaller relicensings sometimes do not.) What is the blast radius of a migration, and what is the blast radius of staying? The blast-radius calculation almost always favors migration when the fork has hyperscaler support and community momentum.

How Safeguard Helps

Safeguard tracks license metadata and license-change events across every component in your SBOM, flagging the moment a dependency transitions from OSI-approved to source-available or proprietary terms. Our policy engine lets security and legal teams encode their stance, whether that is block on relicense, require review, or permit with an exception, and evaluates every new build against those rules. When a relicensing event like Redis to Valkey or Terraform to OpenTofu occurs, Safeguard surfaces which of your projects are affected and which fork pathway aligns with your compliance posture. That turns a legal surprise into an engineering ticket.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.