What is this open source licence change pattern we keep seeing? It’s a recurring sequence where successful open source infrastructure projects shift from permissive licences to restrictive “source-available” licences after cloud providers start offering them as managed services. This pattern started in 2018 with MongoDB‘s SSPL adoption and has repeated with Elastic (2021), HashiCorp (2023), and Redis (2024). Each time, the community mobilises and forks the project to preserve open source freedoms.
If you’re managing infrastructure that depends on open source projects, this pattern matters. Understanding it helps you predict which projects might change licences next so you can plan accordingly.
This guide is part of our comprehensive analysis of open source licensing wars, examining how cloud economics and vendor sustainability are reshaping infrastructure software. Over six years, a clear pattern has emerged. Once you see it, the warning signs become obvious.
Here’s what we’ll cover: the specific pattern that keeps repeating, how to spot warning signs in projects you depend on, which licence change hurt the community most, why this all started in 2018, what makes PostgreSQL immune, and what comes next.
The Pattern Emerges – MongoDB to Redis 2018-2024
Can you explain what happened with Redis and Valkey? It’s the same thing that happened to MongoDB, Elastic, and HashiCorp before it.
MongoDB changed from AGPL to SSPL in October 2018, twelve months after going public. AWS DocumentDB competing with MongoDB Atlas triggered the change. Debian, Red Hat, and Fedora dropped MongoDB. The OSI declared in January 2021 that SSPL doesn’t comply with the Open Source Definition.
January 2021 brought Elastic. They dual-licensed under SSPL and Elastic Licence. AWS OpenSearch competing with Elastic Cloud drove the change. AWS created the OpenSearch fork. Then in August 2024, Elasticsearch returned to AGPL—the first reversal.
August 2023 brought HashiCorp. They adopted the Business Source Licence, shifting Terraform from MPL 2.0 to BSL 1.1. The community forked Terraform to create OpenTofu. IBM acquired HashiCorp for $6.4 billion in February 2025. For a detailed analysis of the HashiCorp case and its implications, see our guide on HashiCorp Terraform, OpenTofu, and the IBM acquisition.
Redis moved from BSD on March 20, 2024. AWS ElastiCache and Azure Cache drove the change. Redis is no longer “open source”. The Linux Foundation launched Valkey within 30 days. Valkey expanded to nearly 50 contributing companies within the first year. The complete story of how 83% of enterprises migrated to Valkey demonstrates the community’s rapid response.
Two things show up every time: cloud provider competition and single-company control. We’ll dig into the common elements next.
Common Elements – What Every License Change Shares
These four major licence changes over six years reveal a consistent underlying pattern. Why are open source companies changing their licences? The pattern shows clear common elements across every case.
AWS, Azure, and GCP offer managed services without contributing code. AWS ElastiCache offers Redis without contributing code. Azure DocumentDB competes with MongoDB Atlas. Google Cloud Memorystore uses the Redis protocol. Cloud-hosted open source services rank among the highest-margin products for cloud providers. This cloud provider economics debate examines both sides of the sustainability argument.
There’s a conversion problem. Only about 1% of users convert to paid services according to vendor investor presentations. The maths doesn’t work. Ten million users at 1% conversion gives you 100,000 customers. But cloud providers with ten million users and 80% cloud deployment creates eight million potential customers. The vendor captures less than 10% of the total market value their software creates.
Governance vulnerabilities make licence changes possible. Single-company control enables unilateral licence changes. Centralised decision-making with no community veto power. Projects under corporate rather than neutral control are vulnerable.
The community response follows a pattern too. Rapid fork mobilisation within days or weeks of licence changes. The Linux Foundation provides neutral governance for forks. Cloud providers fund fork development. Forks preserve API and protocol compatibility. Valkey’s 1,000+ commits with 150 contributors in the first year shows how quickly the community mobilises.
Here’s how it plays out economically. Cloud provider managed services create revenue arbitrage where AWS, Azure, and Google Cloud offer open source infrastructure as paid services without reciprocating code contributions. When only 1% of users convert to vendor-paid plans, venture capital pressure forces licence restrictions preventing competitive services. This shifts projects from open source to “source-available” proprietary models.
Warning Signs – Predicting the Next License Change
How do you evaluate if your projects use at-risk open source software? There’s a checklist.
Governance red flags carry highest risk. Single company owns 80%+ of commits. No independent foundation governance. Contributor Licence Agreement grants licence flexibility. Board dominated by vendor employees. No community veto power.
Economic pressure indicators signal trouble. Recent VC funding requiring growth. AWS, Azure, or GCP offers competing managed service. Vendor complains about “cloud provider freeloading”. Company discusses “sustainability” or “fair use”.
Technical maturity signals matter. Project reached feature completeness. Critical infrastructure status. High adoption but low paid conversion. Commodity status. API stability.
Community health warnings appear. Declining external contributors. Maintainer burnout. “Maintenance mode” announcements. Key contributors leaving. Governance reform proposals rejected.
Let me show you how the risk scoring works. Take MinIO as an example. Single company owns 80%+ of commits—that’s 3 points. No independent foundation governance—2 points. Cloud competition from AWS S3 and Google Cloud Storage—2 points. They announced maintenance mode in 2024—2 points. Public sustainability complaints—1 point. Total: 9 out of 10. High risk, likely within 12 to 18 months. Alternatives include Ceph and SeaweedFS.
Projects most likely to change licences show: single-company ownership controlling more than 80% of commits, no independent foundation governance, cloud providers offering competing managed services, recent venture capital funding requiring aggressive growth, public complaints about sustainability, and declining external contributor percentages. Projects with Linux Foundation governance and distributed ownership rarely change licences.
Comparative Impact – Which Change Hurt Community Most?
MongoDB versus Redis versus HashiCorp: which licence change had the worst community impact?
For community trust damage, HashiCorp hit hardest. Infrastructure-as-code tooling was perceived as part of open source identity, so the BSL change felt like betrayal. 40-plus companies immediately joined the OpenTofu consortium. Redis came second with fifteen years of open source history making the licence shocking.
Terraform and OpenTofu split the ecosystem—providers, modules, tutorials all fragmented. Redis and Valkey created client library fragmentation. MongoDB saw limited fragmentation with no major fork.
Valkey achieved fastest adoption. Valkey hit 19.8K GitHub stars in year one. MaiCoin migrated achieving 20-33% lower cost.
Did licence changes improve revenue? MongoDB’s growth was already strong. Elastic saw declining growth that worsened, then reversed to AGPL in August 2024. HashiCorp was acquired by IBM. No evidence shows licence changes improved revenue.
HashiCorp’s Terraform BSL caused deepest community damage. Redis/Valkey shows fastest recovery due to wire protocol compatibility.
SSPL from MongoDB prevents cloud providers from offering MongoDB-as-a-service without open sourcing all infrastructure code. BSL from HashiCorp restricts production use for three to four years before converting to open source, blocking competitive Terraform services. RSALv2 from Redis prohibits managed Redis service offerings. All three fail the Open Source Definition, but SSPL is strictest requiring service infrastructure disclosure, BSL adds time delay, and RSALv2 targets only managed services. For a comprehensive explanation of open source license types, including the differences between permissive, copyleft, and source-available licenses, see our foundational guide.
Economic Drivers – Why This Pattern Emerged After 2018
To understand why this pattern emerged specifically after 2018, we need to examine the economic forces that converged during that period. What economic forces drive licence changes? The timeline tells the story.
Before 2018, traditional monetisation worked. Support contracts, consulting, training. Red Hat, MySQL, and Canonical succeeded with these models.
2018 was the inflection point. Cloud adoption crossed 50%. MongoDB’s licence change followed its IPO. AWS, Azure, and GCP offered one-click deployment. The support model collapsed because cloud providers handle operations.
Cloud providers generate billions without reciprocal contribution. Companies invest $100 million-plus while cloud providers generate billions. Commoditisation threatened vendor SaaS business. The economics of cloud providers and open source sustainability reveals why traditional funding models broke down.
Post-IPO companies need sustained revenue growth. Quarterly pressure prioritises shareholder value over open source principles.
The licence change pattern emerged in 2018 when cloud adoption crossed 50% and AWS, Azure, and GCP began offering open source infrastructure as managed services, capturing 90% of operational value while contributing zero code. MongoDB’s October 2018 SSPL adoption followed its October 2017 IPO, revealing venture capital growth expectations incompatible with 1% user-to-customer conversion rates. Cloud provider arbitrage eliminated traditional support revenue models, forcing vendors to restrict licences preventing competitive services.
Pattern Breakers – Why PostgreSQL Doesn’t Follow the Trend
Understanding why some projects resist this pattern helps identify which projects remain vulnerable. What’s the difference between PostgreSQL governance and MongoDB or Redis governance? Everything.
PostgreSQL has volunteer-driven development since 1996. No single company controls more than 10% of commits. Distributed trademark ownership makes unilateral change impossible. The PostgreSQL Global Development Group coordinates via mailing lists. Microsoft, Amazon, Google, Crunchy Data, and EnterpriseDB all contribute. No vendor can dictate strategic direction.
The PostgreSQL Licence is similar to MIT or BSD. It cannot be retroactively changed for existing versions. A new restrictive licence would require all contributors’ consent over 30-plus years of distributed contributions. That’s impossible.
Cloud providers fund development directly—the AWS RDS team contributes to the core. Enterprise support companies like Crunchy Data, EDB, and Percona are profitable without restricting the licence.
Contrast with MongoDB. MongoDB now resembles Oracle more than open source. Investor demands led to customer lock-in strategies. Discussions about MongoDB mostly focus on migration away.
Other pattern-resistant projects: Linux Kernel with thousands of contributors and GPL. Kubernetes with CNCF governance. Apache HTTP Server with ASF governance.
PostgreSQL maintains its permissive open source licence because no single company controls development—ownership is distributed across thousands of contributors over 30 years, making licence changes impossible without unanimous consent. The PostgreSQL Global Development Group coordinates via community governance, with Microsoft, Amazon, Google, and independent developers all contributing equally. Cloud providers fund PostgreSQL development directly rather than restricting the licence, proving sustainable open source at enterprise scale.
What Comes Next – Predicting Future License Changes
Which projects are at risk of changing licences next? You can assess the risk using this framework.
The risk scoring system uses: single-vendor ownership for zero to three points, no foundation governance for zero to two points, cloud competition present for zero to two points, venture capital or public market pressure for zero to two points, and sustainability complaints for zero to one points. Eight to ten points means high risk and likely within 12 to 18 months.
MinIO scores nine out of ten. Single-company control adds three points. No independent foundation adds two points. AWS S3 and Google Cloud Storage competition adds two points. The maintenance mode announcement adds two points. Public sustainability complaints add one point. Predicted timeline is 12 to 18 months. Alternatives include Ceph and SeaweedFS.
ScyllaDB scores eight out of ten. ScyllaDB Inc. dominates development for three points. Corporate control adds two points. AWS Keyspaces and Azure Cosmos DB competition adds two points. Publicly discussed licence changes add one point. Predicted timeline is 18 to 24 months.
ClickHouse scores six out of ten. ClickHouse Inc. is the majority contributor for two points. Recent company formation adds two points. Snowflake and BigQuery gaining OLAP share adds two points. Predicted timeline is two to four years if pressure increases.
Three scenarios map the future. Pattern acceleration has 40% probability. Outcomes are three to five additional major projects changing licences by 2027. Pattern stabilisation has 35% probability. Outcomes are licence changes plateauing at current rate of one to two per year. Pattern reversal has 25% probability. Elasticsearch’s 2024 AGPL return proves reversals possible. Licence restrictions failing to improve revenue drives this. Candidates: HashiCorp if IBM prioritises community, Redis if RSALv2 fails.
Breaking the Pattern – Sustainable Alternatives
How can small companies sustain open source projects without going closed source? Multiple proven models exist.
Foundation governance plus support and services works. Examples are Red Hat with Fedora and RHEL, Canonical with Ubuntu. Core project sits under Apache or Linux Foundation governance. The company provides enterprise support, certifications, and long-term maintenance. Revenue comes from expertise, not artificial scarcity.
Open core with governance boundaries works. Examples are GitLab, Sentry, and Mattermost. Core platform is 100% open source under MIT or Apache licence. Enterprise features are proprietary extensions. Core remains fully functional for self-hosters.
Hybrid company stewardship with foundation safety net works. Valkey with Linux Foundation support. The company funds majority of development. The foundation holds trademarks and governance authority. Community veto power prevents licence changes.
The Business Source Licence sits between open source and proprietary. BSL allows non-production use. BSL automatically converts to open source within four years.
For infrastructure planning, use a governance audit requiring Apache, Linux Foundation, or CNCF hosting. Check ownership diversity to avoid single-vendor more than 50% commit dominance. Prefer permissive licences like MIT, Apache, or BSD. Ensure fork viability.
Use contractual protections. Add licence guarantee clauses in procurement contracts. Include fork migration clauses where the vendor pays migration costs if the licence changes. Set community governance requirements for dependencies.
Where This Leaves You
Six years of evidence shows this pattern repeating with remarkable consistency. MongoDB in 2018, Elastic in 2021, HashiCorp in 2023, Redis in 2024. Common elements are single-vendor control plus cloud competition plus venture capital pressure. Financial outcomes show no evidence restrictions improve revenue according to industry analysis.
Warning signs enable prediction. MinIO and ScyllaDB show highest risk for 2025 to 2026 changes. Projects with foundation governance like PostgreSQL, Kubernetes, and Linux are immune. You can proactively assess dependency risk using governance audits.
Sustainable business models exist without restrictions. Foundation governance prevents unilateral licence changes. Open core, support and services, and consortium funding are proven alternatives.
Five actions for your infrastructure. First, audit your infrastructure using the risk framework based on governance, ownership, and competition. Second, prioritise foundation-governed projects where Apache, Linux Foundation, or CNCF hosting signals stability. Third, plan migration contingencies by identifying open source alternatives for high-risk dependencies now. Fourth, add contractual protections including licence guarantee and fork migration clauses to vendor contracts. Fifth, monitor pattern evolution by tracking MinIO, ScyllaDB, and ClickHouse for early signals.
This pattern analysis provides essential context for navigating the open source licensing wars, where understanding historical cycles helps predict future risks and plan infrastructure strategies that prioritise governance stability over vendor convenience. For comprehensive coverage of licensing concepts, case studies, economic forces, and practical migration guidance, explore our complete resource hub.
The next phase of this industry transformation will determine whether open source infrastructure returns to community governance or fragments further into vendor-controlled silos. Your procurement decisions today shape which future emerges.
Frequently Asked Questions
What is the open source licence change pattern?
The open source licence change pattern is a repeating sequence where successful infrastructure projects shift from permissive licences to restrictive “source-available” licences after cloud providers offer them as managed services. The pattern started with MongoDB’s SSPL in 2018 and repeated with Elastic (2021), HashiCorp (2023), and Redis (2024).
Why did MongoDB change its licence in 2018?
MongoDB changed from AGPL to SSPL in October 2018 (12 months after its October 2017 IPO) to prevent AWS DocumentDB from offering MongoDB as a managed service without contributing code or revenue. Public market growth expectations combined with cloud provider competition drove the licence restriction.
Which licence change hurt the community most?
HashiCorp’s Terraform BSL change caused the deepest community damage because infrastructure-as-code tooling was perceived as part of open source, developer identity was tied to Terraform expertise, and the ecosystem immediately fragmented. Redis/Valkey showed fastest community recovery due to wire protocol compatibility.
What warning signs predict the next licence change?
Projects most at risk show: single-company ownership (>80% commits), no independent foundation governance, cloud provider managed services competition, recent VC funding, public sustainability complaints, and declining external contributors. MinIO (maintenance mode) and ScyllaDB (discussed changes) show highest 2025-2026 risk.
Why hasn’t PostgreSQL changed its licence?
PostgreSQL maintains open source licensing because ownership is distributed across thousands of contributors over 30 years – no single company can unilaterally change licences. Community governance via PostgreSQL Global Development Group prevents vendor capture, and cloud providers fund development directly without restricting licences.
How can companies sustain open source without restrictive licences?
Sustainable alternatives include: foundation governance with support/services revenue (Red Hat model), open core with enterprise features while keeping core open (GitLab model), company stewardship under Linux Foundation safety net (Kubernetes model), and consortium funding from corporate sponsors (OpenSSL model).
What’s the difference between SSPL, BSL, and RSALv2 licences?
SSPL (MongoDB) prevents cloud services unless all infrastructure code is open sourced. BSL (HashiCorp) restricts production use for 3-4 years before converting to open source. RSALv2 (Redis) prohibits managed service offerings. All three fail the Open Source Definition but differ in scope and duration of restrictions.
Did licence changes improve vendor revenue?
No evidence shows licence changes improved revenue trajectories. Industry analysis found MongoDB’s growth predated SSPL, Elastic’s growth declined post-change (reversed to AGPL in 2024), and HashiCorp was acquired by IBM rather than achieving independent growth. Licence restrictions failed to solve fundamental business model challenges.
