LinkedIn "wisdom"

by "Stavros"

How a vendor's monetization pivot can rewrite your architecture without a single decision on your part

BY STAVROS · OCTOBER 6, 2026
How a vendor's monetization pivot can rewrite your architecture without a single decision on your part infographic

The proof is indisputable.

THE INSIGHT

In August 2023, a group of people I have never met, at a company I do not work for, changed my architecture. HashiCorp moved Terraform from MPL 2.0 to the Business Source License, and overnight every plan touching it acquired a legal review step that had not existed the day before.

No one on my team made a decision. It was made for us by a copyright holder exercising a right it had held all along, and we had simply never thought about who held it.

Not a one off. MongoDB went SSPL in 2018, Elastic in 2021, Grafana AGPL that April, Akka BSL in 2022, Redis core off BSD in 2024. Same shape each time: raise or list, watch a hyperscaler resell your work, then pull the license lever because it is the only lever you own outright.

The mechanism is dull, which is why it gets missed. If one company holds the copyright, usually because contributors signed a CLA assigning it, that company can change the terms whenever it likes. If copyright is spread across thousands of people, it cannot. The Linux kernel will never go BUSL, because that would require every contributor to agree.

So adoption tells you nothing about control. Terraform was the most widely used IaC tool on earth when it was relicensed. Redis was in almost everyone's stack.

What protected people was fork viability, and that turns out to be predictable. OpenTofu was under the Linux Foundation within weeks. Valkey forked from Redis 7.2.4 within eight days, led by a former maintainer, backed by AWS, Google, Oracle and Snap, now past 100 million Docker pulls with production use at Intuit and Airbnb. Redict and Microsoft's Garnet got no multi vendor coalition and stayed marginal. Original maintainers, competing sponsors who need the thing neutral, drop in compatibility. If your dependency lacks that, no fork is coming to save you.

Exit cost is about coupling, not popularity. Swapping Redis for Valkey is a connection string, because the wire protocol is the same. Fidelity moved 50,000 state files and 4 million cloud resources to OpenTofu, hitting 70% in two quarters, and their VP of Automation Tooling said the code was never the hard part. But Sentinel policies, private module registries, Terraform Cloud workspaces and years of Elasticsearch query DSL drift do not port anywhere.

Meanwhile we count CVEs beautifully. Black Duck found the average application carries 911 open source components, 64% of them transitive. I cannot find a survey asking whether anyone inventories dependencies by who can change the terms. IEC 62304, FDA guidance and DTAC do not ask either.

So add the column. For every critical dependency, write down who holds the copyright, whether a CLA exists, and what leaving would cost. Then look at the ones you could not leave, and decide whether you are comfortable with that being someone else's business decision.

THE EVIDENCE

Open source license changes and vendor monetization pivots as an architectural and governance risk

Research notes for the Director of Technical Strategy, Numan. Objective, sourced findings only. No post drafted.

TL;DR

  • The evidence strongly supports the thesis: between 2018 and 2026 at least a dozen widely-adopted infrastructure tools were relicensed by their single corporate copyright-holder, and in the biggest cases (Terraform, Redis, Elasticsearch) the change rewrote users' options without any user decision. The enabling mechanism is copyright concentration plus Contributor License Agreements, which is a governance property, not a popularity property.
  • Forks succeeded where there was neutral foundation governance plus multiple competing commercial sponsors (OpenTofu, Valkey, OpenSearch) and stayed marginal where they did not (Redict, Garnet). Switching cost is near-zero for wire-protocol/state-format compatible tools and structurally hard where query DSLs, drivers, or proprietary control-plane features are coupled.
  • The empirical gap the user suspects is real: SBOM adoption is rising but licence-field quality is poor, and no mainstream survey measures how many organisations inventory dependencies by who controls the licence. Nearest proxies (OSSRA licence-conflict data, Census II maintainer concentration, CLA prevalence) all point at governance being under-tracked relative to CVE counts.

Key findings

  1. The relicensing wave is real, sustained, and single-vendor driven. Confirmed dated events: MongoDB AGPL to SSPL (16 Oct 2018); Confluent Community License (Dec 2018); Grafana Apache 2.0 to AGPLv3 (20 Apr 2021); Elastic Apache 2.0 to SSPL/Elastic License (Jan 2021); MinIO to AGPLv3 (2021); Akka/Lightbend Apache 2.0 to BSL (7 Sep 2022); Redis modules to dual RSALv2/SSPL (15 Nov 2022); HashiCorp MPL 2.0 to BUSL 1.1 (10 Aug 2023); Redis core BSD to RSALv2/SSPL (20 Mar 2024); CockroachDB retires free Core (18 Nov 2024); MinIO strips console from community edition (2025). Reversals: Elastic added AGPLv3 (29 Aug 2024); Redis added AGPLv3 in Redis 8 (1 May 2025).
  2. Forks with institutional backing reached escape velocity. OpenTofu and Valkey both moved to the Linux Foundation within days/weeks and gathered multiple hyperscaler sponsors. OpenSearch is the older proof case. Redict and Garnet did not achieve comparable adoption.
  3. Switching cost depends on coupling type, not popularity. Drop-in cases (Valkey wire protocol, OpenTofu state format) are cheap; deep-coupling cases (Elasticsearch query DSL post-7.10 drift, MongoDB drivers, Terraform Cloud/Sentinel/private registry) are expensive.
  4. The governance-tracking gap is genuine. SBOMs increasingly exist but often lack complete licence data, and I found no survey measuring governance-model inventories.

Details

1. The relicensing wave: timeline and specifics

HashiCorp (Terraform, Vault, Consul, Nomad, Packer, Boundary, Waypoint). On Thursday 10 August 2023 HashiCorp co-founder and CTO Armon Dadgar announced a move from Mozilla Public License 2.0 to the Business Source License (BSL/BUSL) 1.1 on all future releases. Terraform 1.5.x and earlier (through v1.5.7) remain MPL; everything from 1.6 is BUSL. The BUSL bars using the product to build a "competitive offering" to HashiCorp's commercial products, defined to include hosting or embedding Terraform in a competing service. Dadgar's stated reasoning: "there are other vendors who take advantage of pure OSS models, and the community work on OSS projects, for their own commercial goals, without providing material contributions back. We don't believe this is in the spirit of open source." The competitive-offering clause: "End users can continue to copy, modify, and redistribute the code for all non-commercial and commercial use, except where providing a competitive offering to HashiCorp." HashiCorp APIs, SDKs and most libraries stayed MPL 2.0. The BUSL 1.1 carries a four-year conversion clause: each BUSL release converts to MPL 2.0 (a GPL-compatible open licence) four years after release. IBM announced its acquisition of HashiCorp in April 2024 and closed it on 27 February 2025 at $35/share cash (an enterprise value of about $6.4 billion; IBM's SEC filing reports total equity value of roughly $7.2 billion and cash consideration of $7,390 million). HashiCorp revenue: roughly $476m (FY2023), $583m (FY2024), and about $655m for the twelve months to 31 October 2024 (Macrotrends). Analysts (RedMonk, Rachel Stephens, 26 Aug 2024) note HashiCorp's valuation fell after the licence change while revenue kept growing, so the licence change cannot be cleanly credited with financial improvement. [1]

Redis. Progression: Commons Clause applied to some Redis modules (2018); modules moved to RSAL (2019); Redis Stack modules dual-licensed RSALv2/SSPLv1 (15 Nov 2022); Redis core moved from BSD 3-clause to dual RSALv2/SSPLv1 on 20 March 2024 (from v7.4), announced by CEO Rowan Trollope; then Redis 8 (1 May 2025) added AGPLv3 as a third option. Trollope's stated reasoning (TechCrunch, 21 Mar 2024): "We switched for the same reasons, I think, that everything that has come before us has switched, which is protecting our investment that we make in open source." He also said the majority of Redis commercial sales run through the largest cloud providers "who commoditize Redis' investments and its open source community." Redis's own May 2025 statement: "Our license change was in response to the managed service providers who used Redis 7.2 and prior versions under the BSD3 license but provided limited contributions... Some chose to move on." Redis creator Salvatore Sanfilippo (antirez), who rejoined Redis, wrote on 1 May 2025: "I'm happy that Redis is open source software again, under the terms of the AGPLv3 license," and "My feeling was that the SSPL, in practical terms, failed to be accepted by the community. The OSI wouldn't accept it, nor would the software community regard the SSPL as an open license." [2]

Elastic. In January 2021 (7.11 release) Elastic moved Elasticsearch and Kibana from Apache 2.0 to dual SSPL/Elastic License. AWS forked Elasticsearch 7.10.2 to create OpenSearch under Apache 2.0. On 29 August 2024 founder Shay Banon announced adding AGPLv3 as an option, in a post titled "Elasticsearch is Open Source, Again." Banon: "The tl;dr is that we will be adding AGPL as another license option next to ELv2 and SSPL... being able to use the term Open Source, by using AGPL, an OSI approved license, removes any questions, or fud, people might have." On the original 2021 change and the fork: "We had issues with AWS and the market confusion their offering was causing. So after trying all the other options we could think of, we changed the license, knowing it would result in a fork of Elasticsearch with a different name and a different trajectory." [3]

MongoDB. Moved from AGPLv3 to SSPL on 16 October 2018, twelve months after its IPO. OSI never approved SSPL; MongoDB withdrew the submission in 2019. Debian, Fedora and Red Hat Enterprise Linux dropped MongoDB. Fedora's Tom Callaway: SSPL is "intentionally crafted to be aggressively discriminatory towards a specific class of users." AWS launched DocumentDB (a MongoDB-API-compatible service) in January 2019. Long-run: MongoDB grew strongly post-SSPL: FY2023 revenue $1.28bn (up 47%), FY2024 $1.68bn (up 31%), with quarterly revenue reaching $529.4m in Q3 FY2025 (up 22% YoY) and over 52,600 customers by 31 Oct 2024. RedMonk's analysis says MongoDB "experienced tremendous growth in company value post-license change," but cautions the growth rate did not visibly change at the licence-change inflection. [4]

Other cases. CockroachDB: Apache to BSL then to its own CockroachDB Software License; on 18 November 2024 (v24.3) it retired the free Core edition, making Enterprise free only for individuals and companies under $10m annual revenue, with mandatory telemetry on free tiers. Grafana, Loki, Tempo: Apache 2.0 to AGPLv3 on 20 April 2021 (CEO Raj Dutt cited Elastic, Redis, MongoDB, Timescale, Cockroach as precedents). MinIO: Apache to AGPLv3 (2021); in 2025 it stripped the admin console from the community edition (leaving a bare object browser), then put the repo into "maintenance mode" (3 Dec 2025) and archived it (12 Feb 2026); MinIO paid pricing was reported at a minimum $96,000/year rising to $244,032/year for 1PB. Akka/Lightbend: Apache 2.0 to BSL from Akka 2.7 (announced 7 Sep 2022), free only under $25m revenue, three-year conversion to Apache 2.0. Confluent: Confluent Community License (Dec 2018). Docker Desktop: licensing change in 2021 requiring paid subscriptions for larger companies. Bitwarden: in October 2024 a new sdk-internal dependency carried a non-OSS clause ("You may not use this SDK to develop applications for use with software other than Bitwarden..."); after backlash Bitwarden called it a "packaging bug" and in November 2024 relicensed the SDK to GPLv3. Sentry moved BSD to BSL to its own Functional Source License (FSL). Neo4j, Chef, Couchbase, Airbyte (MIT to Elastic License, 27 Sep 2021) also feature in trackers. [5]

Aggregate trackers. There is no authoritative annual count, but community trackers exist: the "rugpulls.dev" GitHub list (Chris Aniszczyk) catalogues relicensing events with dates and source/target licences. Most-cited pattern: a company IPOs or raises, then relicenses within roughly 1-3 years to counter hyperscaler competition. [6]

2. Fork viability: OpenTofu, Valkey, OpenSearch

OpenTofu. The OpenTF manifesto (August 2023) urged HashiCorp to revert and was signed by a large coalition; env0 reported "over 100 organizations, and hundreds of individual developers" and the manifesto repo passing 2,200 stars within days. The fork (initially OpenTF) was announced 25 August 2023, rebranded OpenTofu and joined the Linux Foundation in September 2023, reached GA 1.6 in January 2024, then shipped 1.7 (state encryption), 1.8 (early variable evaluation), 1.9 (for_each on providers, -exclude), 1.10 (OCI registry). It was accepted into the CNCF in April 2025; current stable is in the 1.11/1.12 line as of 2026. Adoption metrics: roughly 27,000-29,000 GitHub stars, about 9.8 million downloads with reported ~300% annual growth, 3,900+ providers and 23,600+ modules. Corporate adopters: Fidelity migrated 50,000+ state files across 2,000+ applications managing 4 million+ cloud resources, reaching 70% adoption in two quarters; GitLab deprecated its Terraform CI/CD templates in favour of OpenTofu on legal-risk grounds. Spacelift reports about 50% of its deployments now use OpenTofu (note: Spacelift is a founding OpenTofu TSC member, so treat as directional). A Spacelift survey (Q4 2024) reportedly found 38% of Terraform users evaluating or migrating. Independent 2026 estimates put OpenTofu around 12% of IaC practitioners with Terraform still the majority. HashiCorp sent OpenTofu a cease-and-desist on 3 April 2024 alleging BUSL code was copied (specifically "removed blocks"); OpenTofu responded on 11 April 2024: "The OpenTofu team vehemently disagrees with any suggestion that it misappropriated, mis-sourced, or otherwise misused HashiCorp's BSL code," attributing the similarity to shared pre-BSL MPL origins. [7]

Valkey. Forked from Redis 7.2.4 within eight days of the March 2024 relicensing; announced under the Linux Foundation on 28 March 2024, led by AWS principal engineer and former Redis maintainer Madelyn Olson. Founding backers: AWS, Google Cloud, Oracle, Ericsson, Snap; later sponsors include Alibaba, Huawei, Tencent, Intel, Salesforce, ByteDance. Releases: 8.0 (late 2024, I/O threading), 8.1 (31 Mar 2025), 9.0 (GA 21 Oct 2025). Performance: AWS cites up to 60% better price-performance; per AWS's Valkey 8.1 GA notes (via Upstash, 2026), Valkey 8.1 delivers around 8% more ops/sec, roughly 22% lower p99 latency, and roughly 20% less memory than Redis OSS, which is why ElastiCache for Valkey lists roughly 20% lower prices. Adoption (AWS "Valkey turns two," May 2026): Valkey has surpassed 100 million Docker pulls (up 17x year over year) and attracted more than 225 contributors who have submitted over 1,500 pull requests, with over 25,000 GitHub stars; named production adopters include Intuit, Airbnb, Nextdoor, Tinder, Peloton, Amazon Ads and Amazon Music. It is packaged in Fedora, Debian, Ubuntu, Alpine and Arch, and is default on AWS ElastiCache and Google Memorystore. Percona's 12 September 2024 report "Key-Value Stores: Adoption Trends Through a Valkey Lens" (survey of 151 database/IT managers) found 75% of Redis users are testing, considering, or have already adopted Valkey (67% still use Redis as their primary key-value store; 7% already on Valkey); Percona's headline was "83% of Enterprises Have Already Adopted, or are Actively Testing, Valkey." RedMonk's Stephen O'Grady (April 2026): "two years in, Valkey is not behaving like most forks and declining in interest, commits and project traction." Redis's May 2025 AGPL return is widely attributed to fork pressure, though Redis frames it as responding to community feedback. [8]

OpenSearch (older comparison). AWS forked Elasticsearch 7.10.2 in 2021. The AWS/Elastic trademark dispute was settled in 2022 (Elastic stopped selling its own Elasticsearch service on AWS; AWS rebranded to OpenSearch). On 16 September 2024 AWS transferred OpenSearch to the new OpenSearch Software Foundation under the Linux Foundation (premier members AWS, SAP, Uber). Downloads: about 700 million at transfer, reaching about 1.4 billion by 2026 per the OSSF; 400+ contributing organisations, 3,300+ contributors. OpenSearch 3.0 (May 2025) was the first major release under the foundation. [9]

Fork failure / partial success (for balance). Redict (an LGPL copyleft Redis fork associated with Drew DeVault/SourceHut) and Microsoft Garnet (a from-scratch RESP-compatible C# reimplementation from Microsoft Research) both remained marginal next to Valkey; neither attracted a multi-vendor backer coalition. The distinguishing factors match the academic literature: surviving forks had the original core maintainers, multiple competing commercial sponsors, neutral foundation governance from day one, and drop-in compatibility.

Research on fork success. Robles and González-Barahona (2012), "A Comprehensive Study of Software Forks," identified 220 significant forks; outcomes: successful branching (both survive) 43.6%, fork discontinued 29.8%, original discontinued 13.8%, both failed 8.7%, remerge 3.2%. Nyman and Mikkonen argue the credible threat of forking is the "invisible hand of sustainability" that disciplines project stewards. Mike Dolan of the Linux Foundation argues foundation governance itself is the protection: because copyright is distributed across many contributors, "the community of contributors would have to collectively all agree to change the license," which "creates a significant barrier to a license change."

3. Real switching cost of an embedded infrastructure tool

Documented migrations. Fidelity's Terraform-to-OpenTofu migration is the best-documented enterprise case: 50,000+ state files, 2,000+ applications, 4 million+ resources, 70% in two quarters. Fidelity's David Jackson, VP of Automation Tooling: "The code itself isn't the hard part. Changing the CLI in a pipeline is trivial. The complexity lives in the surrounding ecosystem: versioning, CI/CD, governance, artifact management." For Redis-to-Valkey and Elasticsearch-to-OpenSearch, migration is described as a connection-string or binary swap in the common case, with caveats around module/feature drift. [10]

Near-free vs structurally hard. Near-free: Valkey and Redis share the wire protocol so existing clients (node-redis, ioredis) work unchanged; OpenTofu preserves HCL syntax and state format so migration is often a find-and-replace of terraform to tofu plus one state marker change. Structurally hard: Elasticsearch and OpenSearch diverged after the 7.10.2 fork point, so client version drift and query-DSL differences accumulate; MongoDB aggregation pipeline and driver features can differ from DocumentDB/FerretDB; Terraform Cloud/Enterprise workspaces, Sentinel policy-as-code, and private module registries are proprietary control-plane features that do not port to OpenTofu. Observability wiring (metric names, exporters, dashboards) is a commonly underestimated cost in "drop-in" swaps.

Frameworks for quantifying exit cost. Gregor Hohpe frames vendor lock-in as an options/reversibility problem: "Every decision to use any given vendor ought to produce some 'lock-in,' but there ought to be a key to un-lock, and the difficulty of using it ought to be the measure of risk." The Amazon "one-way door / two-way door" framing (Type 1 vs Type 2 decisions) maps directly: choosing a deeply-embedded infrastructure tool is closer to a one-way door. Relevant literature: switching-cost economics, lock-in taxonomies, and reversibility/option-value writing. [11][12]

How deeply tools embed. Black Duck's 2025 OSSRA (10th annual, released 25 Feb 2025; 1,658 analyses of 965 commercial codebases across 16 industries) found the average application contains 911 open source components (64% of them transitive) and that open source files "tripled, from more than 5,300 in 2020 to more than 16,000 in 2024." This scale is the reason a single relicensing event can touch many services. [13]

Consequences of not switching. BSL creates compliance ambiguity requiring legal review; OSI's Stefano Maffulli argues source-available licences "require your legal team to review them carefully before they can say 'yes, you can use them, or no you cannot use them.' They force you to go through a gatekeeper." Procurement leverage shifts to the vendor at renewal. I did not find a clean published figure isolating a HashiCorp or Redis post-relicensing price increase; this is an area where hard numbers are thin and claims are largely anecdotal.

Healthcare/regulated angle. Regulated software supply chains (IEC 62304 for medical device software, FDA premarket cybersecurity guidance requiring SBOMs, EU Cyber Resilience Act, NHS DTAC) increasingly require SBOMs, but these frameworks centre on vulnerability and provenance, not licence-governance risk. Licence-change/vendor-control risk is not an explicit named element in NTIA minimum SBOM elements or NHS DTAC. This is a genuine gap the user could legitimately flag.

4. How many organisations inventory dependencies by governance model rather than CVE count

SBOM adoption. The Linux Foundation's 2022 research found 78% of organisations expected to produce or consume SBOMs in 2022 (survey of 412 organisations, Q3 2021). ENISA's "SBOM Adoption State of Play – 2026" (survey of 334 organisations, 65% EU-based, 80% CRA-affected, collected end-2025) found "78% of the respondents reported that their organisations have already initiated their SBOM adoption journey, with 44% currently being in the pilot or limited adoption phase" and "Only 9% have reached a mature level of implementation, supported fully by automation"; 43% say the CRA significantly accelerated investment. A recurring finding: organisations generate SBOMs but rarely consume supplier SBOMs (39% never receive them). [14][15]

What SBOMs capture and licence-field quality. Both SPDX and CycloneDX have licence fields, but completeness is poor in practice. Black Duck's 2025 OSSRA found 33% of codebases contained open source with no licence or a customised licence, and only 77% of dependencies were identifiable via package-manager scanning. This is a direct measure that licence metadata is frequently missing or ambiguous even before you get to governance-model questions.

OSSRA licence-conflict data. Black Duck 2025 OSSRA (965 commercial codebases, 16 industries, findings from 2024): 56% of audited codebases contained licence conflicts; transitive dependencies caused nearly 30% of those conflicts; 33% contained components with no or a custom licence; 97% contained open source; 86% contained vulnerable open source. The 2026 OSSRA states licence conflicts reached "their highest levels in OSSRA history." A 2019 Synopsys figure found 85% of audited codebases had licence compliance issues. [16]

Governance-model tracking. I found no mainstream survey that asks organisations whether they inventory dependencies by who controls the licence (single-vendor vs foundation), bus factor, or maintainer concentration. Nearest proxies:

  • Census II (Linux Foundation + Harvard LISH + OpenSSF, released 2 March 2022, authored by Frank Nagle et al.): "136 developers were responsible for more than 80% of the lines of code added to the top 50 packages," documenting extreme maintainer concentration. Census II recommends SBOM adoption but frames risk as security/atrophy, not licence governance. [17]
  • OpenSSF Criticality Score and Scorecard, and CHAOSS metrics (organisational diversity, "elephant factor"/"bus factor") measure maintainer and organisational concentration, but adoption of these for dependency inventory is not widely quantified.

Single-vendor control and the CLA mechanism. The relicensing lever is copyright concentration. Contributor License Agreements let a single steward relicense: when a CLA assigns copyright or grants broad relicensing rights, "contributed code can be relicensed at the discretion of the project." Dirk Riehle coined "single-vendor open source" and warns that accepting contributions "without a copyright transfer or at least a re-licensing rights agreement will dilute your ownership... Over time, you could lose your ability to change licenses." By contrast, distributed-copyright projects cannot easily be relicensed: the Linux Foundation's Mike Dolan writes that "no single person or entity owns all the copyrights for the Linux kernel," so relicensing to BUSL would be "impracticable (and perhaps, laughable)," and "you will never see the Linux kernel relicensed as BUSL." Linus Torvalds (2007) confirmed he personally cannot relicense the kernel. On concentration in foundations: RedMonk found single vendors dominate most CNCF projects' contributions (e.g. Google ~77% of Vitess commits in 2018); Kubernetes is the diversification counter-example (Google plus Red Hat fell from 83% of contributions pre-CNCF to 46%). A Gartner projection quoted by Riehle predicted that by 2012 more than 50% of open source software revenue would come from single-vendor projects (a forward-looking estimate, not a measured outcome). [18][19]

Governance-oriented frameworks and responses. The Fair Source movement (fair.io) launched in 2024, driven by Sentry's Chad Whitacre with David Cramer and Keygen's Zeke Gabrielse; it defines a category for source-available commercial software that eventually converts to open source, with early adopters including Sentry and GitButler. Whitacre: "Open source isn't a business model, open source is a distribution model." Gartner published "Impact and Risks of Open-Source to Source-Available Licensing Shifts" (paywalled) advising software engineering leaders to assess licensing changes. Thoughtworks' Technology Radar advisory board flagged the theme: "We find it problematic when core functionality of a widely used tool is suddenly put behind a paywall, especially when an ecosystem has developed around the tool." [20]

5. Counterarguments and nuance

The sustainability/free-rider argument. Every relicensing vendor made the same case: hyperscalers monetise the software as a managed service while contributing comparatively little back. HashiCorp, Elastic, MongoDB and Redis all cited this. Heather Meeker, who helped draft the BSL, the Elastic License and SSPL, frames source-available as fitting "platform software... in ubiquitous use... most valuable when standardized, and the cost to develop it is shared by the industry." The BSL's four-year conversion to an open licence is a genuine concession versus pure proprietary.

Relicensing is rarely fatal to ordinary users. In every BSL/source-available case, internal end-users who are not building a competing hosted service can keep using the software. Commentators (including Gruntwork and Fintan Ryan) noted that ordinary Terraform users' risk profile "is unlikely to change significantly." The real bite falls on vendors and on companies embedding the tool in a product they sell.

Reversals show the market self-corrects. Elastic (Aug 2024) and Redis (May 2025) both added AGPLv3 back. This is evidence that credible fork pressure (OpenSearch, Valkey) functions as a governance mechanism, forcing vendors back toward OSI-approved licensing. Banon explicitly said the earlier change removed "market confusion."

Permissive licences and foundations carry their own risks. Foundation projects can be archived or abandoned; corporate contributors can withdraw funding; and permissive licensing is precisely what enabled the hyperscaler capture that triggered relicensing. The Linux Foundation itself depends on member funding. Financially, RedMonk's analysis concludes there is no clear causal link between relicensing and improved valuation: MongoDB's value grew strongly, Elastic grew moderately, HashiCorp's valuation fell, and none of these firms were profitable at the time of analysis. [21]

6. Useful quotes and framing material
  • Armon Dadgar (HashiCorp, 10 Aug 2023): "there are other vendors who take advantage of pure OSS models... without providing material contributions back. We don't believe this is in the spirit of open source."
  • OpenTF manifesto (Aug 2023): urged HashiCorp to "switch Terraform back to an open source license, avoiding fragmentation of the community." [7]
  • OpenTofu maintainers (11 Apr 2024): "The OpenTofu team vehemently disagrees with any suggestion that it misappropriated, mis-sourced, or otherwise misused HashiCorp's BSL code." [22]
  • Shay Banon (Elastic, 29 Aug 2024): "being able to use the term Open Source, by using AGPL, an OSI approved license, removes any questions, or fud, people might have." [23]
  • Rowan Trollope (Redis, 21 Mar 2024): "We switched for the same reasons... which is protecting our investment that we make in open source." [24]
  • Salvatore Sanfilippo / antirez (1 May 2025): "I'm happy that Redis is open source software again, under the terms of the AGPLv3 license."
  • Dev Ittycheria / MongoDB: SSPL change positioned as protecting Atlas from cloud providers offering MongoDB as a service.
  • Stefano Maffulli (OSI): source-available licences "force you to go through a gatekeeper. And that's really against the spirit, the letter of open source."
  • Adam Jacob (System Initiative, ex-Chef): "There isn't an open source business model... open source is a channel."
  • Heather Meeker (BSL/Elastic License author): source-available fits "platform software... most valuable when standardized, and the cost to develop it is shared by the industry."
  • Chad Whitacre (Sentry, Fair Source): "Open source isn't a business model, open source is a distribution model."
  • Mike Dolan (Linux Foundation): "you will never see the Linux kernel relicensed as BUSL."
  • David Jackson (Fidelity): "The code itself isn't the hard part... The complexity lives in the surrounding ecosystem." [10]

Recommendations

  1. Inventory dependencies by control model, not just CVE count. For each critical infrastructure dependency record: who holds copyright, whether there is a CLA/copyright assignment, current licence, whether governance is single-vendor or neutral-foundation, and whether a viable foundation-backed fork exists. This is the concrete practice the thesis implies and that no standard tool provides out of the box. Threshold to escalate: any dependency that is single-vendor controlled, requires a CLA, and is embedded in a product you ship.
  2. Classify each dependency as a one-way or two-way door. Score exit cost by coupling type: wire-protocol/state-format compatible (cheap), query-DSL/driver coupled (moderate), proprietary control-plane features like Sentinel or private registries (expensive). Prioritise abstraction layers for one-way doors.
  3. For a regulated healthtech estate, add licence-governance risk to your SBOM/vendor-risk process explicitly, since IEC 62304, FDA guidance and NHS DTAC do not name it. Add a licence-change clause to vendor questionnaires.
  4. Track the leading indicators that would change the decision: a dependency vendor IPO or acquisition, a new CLA requirement, a shift from OSI-approved to source-available licensing, or a credible foundation fork appearing. Any of these should trigger a review.
  5. Prefer foundation-governed or distributed-copyright dependencies for anything embedded deeply, and keep a documented exit path for single-vendor ones.

Caveats

  • Vendor-sourced adoption figures (Spacelift, Percona, AWS on Valkey; Elastic/OpenSearch download counts) are marketing-adjacent; treat as directional, not audited. Where a source is a project sponsor I have flagged it.
  • Financial causation is weak: revenue rose at several firms post-relicensing but RedMonk finds no clean causal link to the licence change, and valuations diverged.
  • I found no authoritative annual count of relicensing events and no survey measuring governance-model dependency inventories; the strongest statement the evidence supports is that this tracking is rare, inferred from proxies (OSSRA licence gaps, Census II concentration, SBOM licence-field incompleteness).
  • Reported post-relicensing price increases for HashiCorp and Redis are anecdotal in my sources; do not present a specific percentage as fact.
  • The Gartner "50% of OSS revenue single-vendor by 2012" figure is a forward-looking projection quoted in Riehle's paper, not a measured outcome.
  • Some secondary blog sources (cloudmagazin, tech-insider, medium) corroborate primary facts but should not be the sole basis for any single hard claim.
  1. Gruntwork + 2 — https://www.gruntwork.io/blog/the-impact-of-the-hashicorp-license-change-on-gruntwork-customers
  2. Redis + 3 — https://redis.io/blog/redis-adopts-dual-source-available-licensing/
  3. infoq + 2 — https://www.infoq.com/news/2024/09/elastic-open-source-agpl
  4. SoftwareSeni + 3 — https://www.softwareseni.com/the-open-source-license-change-pattern-mongodb-to-redis-timeline-2018-to-2026-and-what-comes-next/
  5. SD Times + 9 — https://sdtimes.com/os/cockroachdb-retires-self-hosted-core-offering-makes-enterprise-version-free-for-companies-under-10m-in-annual-revenue/
  6. GitHub — https://github.com/caniszczyk/rugpulls.dev
  7. GitHub + 12 — https://github.com/opentofu/manifesto
  8. Medium + 4 — https://medium.com/@ShayanHussainSB/redis-went-sspl-then-agpl-heres-how-i-stopped-worrying-and-shipped-valkey-support-4eb681fdc112
  9. Techzine — https://www.techzine.eu/blogs/devops/141703/opensearch-doubles-downloads-as-open-source-alternative-to-elasticsearch/
  10. Jorijn — https://jorijn.com/en/blog/opentofu-vs-terraform-2026-the-fork-finally-diverged/
  11. LinkedIn — https://www.linkedin.com/posts/ghohpe_lock-in-is-one-of-every-vendors-unfavorite-activity-7122605860794613760-6xOf?trk=public_profile
  12. Chaoskyle — https://chaoskyle.com/one-way-vs-two-way-door-decisions
  13. CinchOps, LLC — https://cinchops.com/black-duck-2025-open-source/
  14. Help Net Security — https://www.helpnetsecurity.com/2022/02/09/sbom-readiness-adoption/
  15. Linux Foundation — https://www.linuxfoundation.org/press/press-release/the-linux-foundation-releases-the-state-of-software-bill-of-materials-sbom-and-cybersecurity-readiness-research
  16. Digital IT News + 2 — https://digitalitnews.com/new-black-duck-ossra-report-released/
  17. Linux Foundation — https://www.linuxfoundation.org/blog/blog/a-summary-of-census-ii-open-source-software-application-libraries-the-world-depends-on
  18. RedMonk — https://redmonk.com/fryan/2018/04/03/who-contributes-an-analysis-of-cncf-projects/
  19. Open Source For You — https://www.opensourceforu.com/2019/01/google-is-the-biggest-open-source-contributor-to-cncf-projects-stackalytics/
  20. TechCrunch — https://techcrunch.com/2024/09/22/some-startups-are-going-fair-source-to-avoid-the-pitfalls-of-open-source-licensing/
  21. RedMonk — https://redmonk.com/rstephens/2024/08/26/software-licensing-changes-and-their-impact-on-financial-outcomes/
  22. Forbes — https://www.forbes.com/sites/justinwarren/2024/04/11/opentofu-responds-to-hashicorp-copyright-infringement-claims/
  23. Unixism — https://unixism.net/2024/08/elasticsearch-is-open-source-again/
  24. TechCrunch — https://techcrunch.com/2024/03/21/redis-switches-licenses-acquires-speedb-to-go-beyond-its-core-in-memory-database/

EDITORIAL BRIEF

Commissioned from our research desk. Subject to final editorial discretion.

How a vendor's monetization pivot can rewrite your architecture without a single decision on your part. Use the wave of open source relicensing events—Terraform to BSL, Redis, Elastic, MongoDB's SSPL—to argue that dependency risk is a governance question, not a popularity question, and that 'widely adopted' says nothing about who controls the license. Research fork viability (OpenTofu, Valkey adoption curves), the real switching cost of an embedded infrastructure tool, and how many orgs have any inventory of dependencies by governance model rather than by CVE count. Takeaway: audit your critical dependencies by who can unilaterally change the terms, and know which ones you'd be structurally unable to leave.