Traditional AI tools treat code as text. That’s the problem. They miss structural relationships and dependencies that separate successful modernisation from production failure.
This technical exploration is part of our comprehensive guide on AI for legacy modernisation, where understanding old code has emerged as the killer app for enterprise AI adoption.
LLMs forget variable definitions and function dependencies separated by thousands of lines. The “Lost in the Middle” problem means AI loses attention on information buried in long contexts.
Knowledge graph architecture transforms code from linear text into a queryable network of entities—functions, variables, classes—and relationships like calls, imports, and dependencies. Abstract Syntax Trees parse code structure, Neo4j stores relationships, and GraphRAG retrieves logically connected context beyond vector similarity.
The result? AI that follows transitive dependencies and accelerates reverse engineering from 6 weeks to 2 weeks. Thoughtworks proved this with CodeConcise in production.
Code is fundamentally relational. Functions call functions, variables flow through execution paths, modules depend on modules. Text documents can’t represent these networks properly.
Graph structure enables deterministic traversal. If A calls B and B calls C, the graph stores that A depends on C. No guessing—just verifiable relationships.
This solves “Lost in the Middle” where LLMs lose focus in long contexts. Instead of stuffing random chunks into context, you retrieve the logically connected subgraph: the function plus dependencies plus data flow sources.
COBOL migrations illustrate this. A COPYBOOK variable defined 5,000 lines from usage gets missed by text search. Graph traversal finds it by following edges that show control flow.
The business impact? Missed variable dependencies crash ATM networks. Understanding existing code provides as much value as generating new code—a core thesis of AI-assisted legacy modernisation that challenges the current focus on code generation tools.
Graph queries guarantee finding all callers of a function. Text search misses synonyms and aliases across decades-old modules.
Thoughtworks cut reverse engineering from 6 weeks to 2 weeks for a 10,000-line module. For entire mainframe programmes, that’s 240 FTE years saved—proof points detailed in our analysis of cutting legacy reverse engineering time by 66% with AI code comprehension.
An Abstract Syntax Tree is a hierarchical representation of code’s grammatical structure. Created during compilation, it’s the intermediary between raw text and executable instructions.
AST captures nesting—functions contain statements, statements contain expressions—plus types and structural relationships. This enables deterministic analysis without executing the programme.
It treats code as data. Language-specific parsers extract intrinsic structure. Where plain text sees characters in parentheses, AST knows “this is a function call with three arguments of specific types”.
The process: source code goes to a lexer for tokenisation, then to a parser building the AST. The tree shows logical structure, stripping concrete syntax details like semicolons and whitespace.
This distinction lets you split code at logical boundaries. AST-based semantic chunking breaks at function boundaries, not arbitrary token limits that cut mid-statement.
CodeConcise parses code into AST forests stored in graph databases. Tree-sitter parsers support COBOL, PL/I, Java, Python, and JavaScript.
One project analysed 650 tables, 1,200 stored procedures across 24 business domains and 350 screens through AST parsing. Another tackled thousands of assembly functions in compiled DLLs with missing source code.
AST provides the nodes—functions, classes, variables. Graph databases add edges—semantic relationships showing how entities connect. These architecture patterns underpin the tools implementing knowledge graph principles differently across the vendor landscape.
Graph databases store nodes—functions, classes, variables, files—and edges representing relationships like CALLS, IMPORTS, DEFINES, and USES.
Neo4j provides query languages like Cypher for traversing relationships. Finding all functions depending on a variable? Follow edges from the variable node to every function connected by USES edges.
Symbol resolution merges duplicate references into canonical nodes. Same function referenced in 10 files becomes one node with 10 edges. No duplication.
Transitive closure calculations expand relationships beyond direct connections. The graph computes and stores the implicit A→C dependency when A calls B and B calls C.
This enables multi-hop queries like “show all code paths from this API endpoint to database queries”, traversing the graph through service calls, business logic, and data access.
Different codebases need different emphasis. Heavy inheritance requires more INHERITS_FROM edges versus COMPOSED_OF edges in composition-favouring codebases.
Edge types capture structural and behavioural relationships. CALLS for function invocations. IMPORTS for module dependencies. DEFINES for variable declarations. ACCESSES for state modification.
Graph traversal at granular level reduces noise from LLM context, showing which conditional branch in one file transfers control to code in another.
Persistent storage allows incremental updates. Parse only changed files, recompute affected subgraphs. Graph stays fresh without prohibitive costs.
RAG provides LLMs with relevant external context before generating responses. Retrieval finds relevant code, then generation has the LLM explain it.
This reduces hallucination by grounding answers in actual codebase. RAG overcomes context window limits by sending 20 relevant functions instead of 500,000 lines.
Vector embeddings enable similarity search finding semantically similar code despite different variable names. Encoder models learn that “authentication”, “login”, and “verify credentials” are conceptually related.
Semantic chunking via AST ensures retrieved chunks are logically complete. You get entire functions, not mid-statement truncation. This approach maintains lightweight identifiers and dynamically loads data at runtime.
The maths: GPT-4’s 128,000 tokens equals roughly 30,000 lines. Enterprise codebases run 500,000 to 5 million lines. Retrieval becomes necessary.
Just-in-time strategies mirror human cognition. We create indexing systems like file systems and bookmarks, retrieving what we need when we need it.
RAG responses cite source file and line number for verification. You can check whether AI explanations match actual code behaviour.
Why external retrieval matters: LLMs train on public code, not your proprietary codebase. Without retrieval, the model doesn’t know your implementation details, naming conventions, or architectural decisions.
Progressive disclosure lets agents incrementally discover context. File sizes suggest complexity, naming conventions hint at purpose, timestamps proxy for relevance.
GraphRAG uses graph traversal—following relationships—not just vector similarity. Vector RAG finds textually similar code. GraphRAG finds logically connected code through dependencies, callers, and implementations.
GraphRAG follows chains where function A calls B and B uses variable C—connections vector search misses because similarity between A and C might be low despite real dependencies.
Query “how does authorisation work when viewing card details?” Vector search returns scattered functions with “auth”. GraphRAG starts with the entry point and follows CALLS edges retrieving the complete flow: endpoint function, called services, database queries, data validation.
This solves “Lost in the Middle”. Instead of scattered chunks creating incoherent jumble, graph retrieval assembles complete dependency subgraphs.
With behavioural and structural edges, you include information in called methods, surrounding packages, and data structures passed into code.
Transitive closure finds all code affected by changing a variable definition. Forward traversal from DEFINES edges shows every usage. Reverse traversal of CALLS edges answers “if I change this function signature, what breaks?”
Hybrid approaches combine both: vector search for initial relevance, graph expansion for structural completeness.
Vector search suffices for documentation search and finding examples. GraphRAG becomes necessary for dependency analysis, impact assessment, and understanding complete flows in legacy modernisation.
GraphRAG provides explainable retrieval paths. “I included function X because it’s called by Y” versus “I included X because it had high vector similarity”.
CodeConcise is Thoughtworks’ internal modernisation accelerator. Three generations developed over 18 months tackle legacy system challenges.
The tool combines an LLM with a knowledge graph derived from codebase ASTs. It extracts structure and dependencies, builds the graph in vector and graph databases, and integrates with MCP servers like JIRA and Confluence.
Multi-pass enrichment breaks analysis into layers. In each pass, navigation enriches function context using parent or child context. Pass 1 extracts function signatures. Pass 2 analyses logic and business rules. Pass 3 resolves data flows and dependencies.
Break artifacts into manageable chunks, extract partial insights, progressively build context. This reduces hallucination risk.
Human-in-the-loop validation prevents unchecked assumptions. Engineers review AI-generated specifications against source code. Corrections feed back for iterative refinement.
Output is functional specifications describing what the system does—business logic as requirements—not implementation details. This matters for preserving business rules while changing technical implementation.
A proof of concept cut reverse engineering from 6 weeks to 2 weeks for a 10,000-line module. The accelerator was extended for COBOL/IDMS tech stacks.
One project narrowed from 4,000+ functions to 40+ through multi-pass approach.
The principle: “Don’t try to recover the code—reconstruct the functional intent”. This matters when requirements are lost and comprehension takes months.
Preserving lineage creates audit trails. Track where inferred knowledge comes from—UI screen, schema field, binary function—preventing false assumptions.
Triangulation confirms every hypothesis across two independent sources. Call stack analysis, validating signatures, cross-checking with UI layer—all build confidence.
The multi-lens approach starts from visible artifacts like UI, databases, and logs. AI accelerates archaeology layer by layer but cannot replace domain understanding.
Vector embeddings convert code chunks into numerical representations capturing semantic meaning. Encoder models like CodeBERT train on millions of code examples to learn patterns.
Models learn that “authentication”, “login”, and “verify credentials” are semantically similar. This enables semantic search finding conceptually related code despite different names across files.
The process: function code goes through tokenisation, then through CodeBERT to produce a 768-dimensional vector. Vectors go into databases like Pinecone, Weaviate, or Qdrant for similarity search.
Cosine similarity measures the angle between vectors. Closer angle means more related content. Query “user authentication” retrieves “verify_credentials”, “check_login”, and “authenticate_user” without exact matches.
This handles synonyms, abbreviations, and different naming conventions. Systems built over decades have multiple names for similar operations. Semantic search cuts through variation.
Vector search in the graph leverages graph structure. After finding matches through vector similarity, the system traverses neighbouring nodes accessing LLM-generated explanations.
Vector database indexing uses approximate nearest neighbour algorithms enabling fast search across millions of embeddings. ANN algorithms trade slight accuracy for speed.
AST-based splits ensure functions are embedded as complete units. Embedding complete functions produces more meaningful vectors than arbitrary token windows.
Each interaction yields context informing the next decision. File sizes suggest complexity. Naming conventions hint at purpose. Timestamps proxy for relevance.
LLM context windows of 32,000 to 128,000 tokens can’t fit enterprise codebases. 128,000 tokens equals roughly 30,000 lines. Enterprise applications run 500,000 to 5 million lines.
The “Lost in the Middle” phenomenon shows LLMs lose attention on information mid-context. They remember start and end better, missing dependencies buried in thousands of intervening lines.
Knowledge graphs solve this through targeted retrieval. Send only relevant subgraphs, not entire codebases. Breadth-first search retrieves immediate dependencies. Depth-first search follows complete call chains.
Prioritise direct dependencies over distant ones, variable definitions over comments, called functions over siblings.
Context is a finite resource with diminishing returns. LLMs have an “attention budget”. Every token depletes this budget.
Attention scarcity stems from transformer architecture. Every token attends to every other token—n² pairwise relationships. As context grows, the model’s ability to capture relationships thins.
Good context engineering means finding the smallest set of high-signal tokens maximising desired outcomes.
Graph traversal reduces noise from context, letting LLMs stay focused and use limited space efficiently.
The deterministic process lets you analyse code independent of how it’s organised. Files might be structured for historical reasons not matching logical dependencies. Graph traversal follows actual relationships.
For API endpoint analysis, you need the endpoint function plus called services plus database queries plus validation logic. Assemble the logically connected subgraph, not random chunks.
Iterative dialogue enables refinement. LLM asks “what does function X do?” Graph retrieves X plus callees. Progressive disclosure keeps context focused on current needs.
Multi-pass enrichment builds knowledge graphs in layers, progressively adding detail from structure to semantics. Each pass validates the previous layer, preventing error propagation.
Pass 1: Extract function signatures, class definitions, module boundaries from AST. No semantic interpretation—just grammatical structure. Fast because it’s pure parsing.
Pass 2: Resolve symbols across files, build call graph, identify data flow paths. Uses static analysis, not LLM inference. Map who calls whom, who imports what, which variables flow where.
Pass 3: Apply the LLM to analyse business logic within identified functions. Computationally expensive but runs only on targeted code after structural filtering.
Why multi-pass matters: analysing everything at once overwhelms compute budget and produces inaccurate results.
Incremental validation happens after each pass. Pass 1: verify AST completeness. Pass 2: validate call graph has no dangling references. Pass 3: check LLM explanations align with code behaviour.
The comprehension pipeline traverses the graph using algorithms like depth-first search with backtracking, enriching with LLM-generated explanations at various depths.
One project narrowed down from 4,000+ functions to 40+ through staged filtering.
Automatically generated documentation is valuable for ongoing maintenance and knowledge transfer, not just modernisation.
Yes, through gradual typing and runtime behaviour analysis. The graph stores observed types from test executions, type hints, and LLM inference. Less precise than statically typed languages, but it captures actual usage patterns.
Hybrid approaches combine static AST parsing with dynamic profiling. The static pass extracts structure and relationships it can verify. The dynamic pass runs test suites and observes actual type behaviour at runtime. Type hints in Python and TypeScript definitions get incorporated where available. For completely untyped code, the LLM infers types based on usage context—if a variable is passed to a function expecting a string, it’s probably a string.
Incremental update strategies parse only changed files and recompute affected subgraphs. MCP (Model Context Protocol) enables real-time graph serving for continuous synchronisation.
Most teams update nightly or per-commit in CI/CD pipelines. The trade-off between freshness and computational cost determines frequency. Per-commit updates provide real-time accuracy but consume significant compute resources. Nightly updates batch the work when systems are idle. For active development, per-commit makes sense. For stable maintenance-mode systems, nightly suffices.
Git hooks trigger the update process. Changed files get parsed, new AST nodes created or updated, affected edges recomputed. If function X changes signature, the graph recomputes all CALLS edges pointing to X. Symbol resolution runs again on modified modules. The entire process completes in minutes for typical commits touching a handful of files.
Call graphs map function invocation relationships—who calls whom. Control flow graphs map execution paths within a function—branches, loops, jumps. Both stored in knowledge graph as different edge types. Call graphs for dependency analysis. Control flow graphs for understanding spaghetti code with GOTOs in legacy systems.
Typically 2-10x source code size depending on relationship density. Example: 1GB source code might require 5-8GB graph database including AST nodes, relationships, embeddings, and metadata.
Neo4j compression helps reduce overhead. The multiplier depends on code characteristics. Object-oriented codebases with deep inheritance hierarchies generate more edges than procedural code. Microservices with many inter-service calls create dense graphs. Legacy monoliths with minimal modularisation have sparser graphs.
The trade-off is worthwhile: storage is cheap, engineer time understanding code is expensive. The graph enables queries impossible with grep. “Find all code paths that modify this database table” takes seconds with graphs, days with manual investigation.
Yes, with limitations. The graph marks unresolved symbols as “external” or “unknown” nodes. Partial graphs are still valuable for analysing available code. Heuristics infer missing types from usage context. Better than nothing, but completeness suffers. Ideal case includes full source with third-party dependencies for complete graph.
The graph stores inheritance edges like EXTENDS and IMPLEMENTS, enabling traversal of type hierarchies. When retrieving callers of a virtual method, the graph follows the inheritance tree to find all overrides.
This gets complex fast. A call to vehicle.move() might invoke Car.move(), Truck.move(), or Motorcycle.move() depending on the runtime type. The graph stores all possibilities. When assembling context for the LLM, it includes all implementations the type system allows.
More complex than static calls because it requires type resolution pass determining possible types at each call site. GraphCodeBERT encoders understand OOP patterns, improving semantic search across hierarchies. The embeddings capture that Car.move() and Truck.move() are semantically related despite different implementations.
The comprehension pipeline keeps extensibility to extract knowledge most valuable to users considering their specific domain context. Continuous integration triggers graph updates on commits. Timestamp metadata tracks last modification dates. Staleness detection lets queries filter by recency. Human-in-the-loop validation flags outdated specifications. Perfect freshness is impossible, but acceptably recent suffices for most use cases.
Grounding means every explanation cites source file and line number for verification. You can read the actual code the AI referenced and confirm the explanation matches reality.
Triangulate everything: never rely on single artifacts, confirm every hypothesis across at least two independent sources. If the AI says function X handles authentication based on its name, verify by checking what it actually calls, what data it accesses, and what the UI layer expects.
Preserve lineage by tracking where every piece of inferred knowledge comes from. The AI might infer business rules from database constraints, UI validation logic, and function implementations. Knowing which sources contributed to each conclusion helps you assess confidence.
Human review validates sections where errors would be costly. Test generation verifies specs match implementation—generate unit tests from the AI’s understanding and see if they pass. Multi-model consensus compares outputs from different LLMs for critical decisions.
Emerging capability with tools demonstrating commit-level analysis. Requires highly optimised incremental updates and caching. MCP servers expose graphs to IDE extensions for live queries. Real-time is less relevant for legacy modernisation than batch analysis. More relevant for code review and documentation use cases. Performance improving as graph databases optimise.
Tools abstract complexity: engineers query graphs through natural language, not Cypher. Graph concepts—nodes, edges, traversal—are intuitive to developers who already think in terms of function calls and dependencies.
The steeper curve is graph database administration: indexing strategies, query optimisation, managing graph size as codebases grow. But most teams consume graphs, they don’t build infrastructure. CodeConcise and similar tools provide the interface. You ask questions in English, get answers with citations.
Most teams productive within weeks for consumption, months for graph construction if you’re building your own infrastructure. Vendors provide managed services eliminating infrastructure burden. You point the tool at your codebase, it handles AST parsing, graph construction, embedding generation, and query optimisation.
Comments are stored as properties on function and class nodes, indexed for semantic search. Documentation embeddings link to code entities they describe. Graphs can map outdated comments by comparing documentation content to implementation when function signatures change but comments don’t. When codebase includes documentation it provides additional contextual knowledge enabling LLMs to generate higher-quality answers.
Yes. Memgraph for graph databases, Apache AGE as PostgreSQL graph extension, JanusGraph for distributed graphs. Vector databases include Qdrant, Weaviate, and Chroma for embeddings. Graph construction tools include Tree-sitter for parsing. MCP has a growing ecosystem of servers for various systems including AWS services and Atlassian products. Full stack requires assembly whereas commercial tools provide integrated experience.
The knowledge graph architecture principles explored here form the technical foundation for AI-assisted legacy modernisation. They enable AI to understand code structure and relationships rather than treating codebases as unstructured text, delivering the precision that separates successful modernisation programmes from failed experiments.
For teams evaluating which tools best implement these principles, our comparison of code comprehension vs code generation tools provides vendor landscape analysis and build-versus-buy frameworks. The technical capabilities outlined in this article translate directly to the 66% reduction in reverse engineering timelines achieved through GraphRAG approaches that maintain context while respecting LLM attention budgets.
The Open Source License Change Pattern – MongoDB to Redis Timeline 2018 to 2026 and What Comes NextWhat 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Migration and Risk Assessment Playbook for CTOs – Evaluating Redis to Valkey and Terraform to OpenTofu SwitchesIs your company at risk right now? That’s the question keeping you up at night after Redis and HashiCorp changed their licences. The good news? Licensing anxiety becomes structured action when you have a systematic methodology. This playbook gives you decision trees, compliance audit checklists, and step-by-step migration guides for evaluating Redis to Valkey and Terraform to OpenTofu switches.
This guide is part of our comprehensive resource on Open Source Licensing Wars – How HashiCorp, Redis and Cloud Economics Are Reshaping Infrastructure Software, where we explore the economic forces and vendor dynamics driving these changes. If you’re running Redis or Terraform in production at a company with 50-500 employees, you need clear decision criteria and actionable steps. The framework is straightforward: immediate risk assessment → compliance audit → migration vs stay decision → execution (if migrating) → vendor evaluation (for future).
Before you dive into detailed analysis, work out your urgency level. Redis changed to three licence options: AGPLv3, RSALv2 (Redis Source Available Licence), and SSPLv1. The RSALv2 prohibits offering Redis as a managed service. HashiCorp’s Business Source Licence includes an Additional Use Grant that allows production use except in products competitive with HashiCorp’s offerings.
Here’s how to classify your situation:
HIGH URGENCY scenarios require action within 30-90 days:
MODERATE URGENCY scenarios need assessment within 3-6 months:
LOW URGENCY scenarios mean monitor but no immediate action:
Most companies fall into moderate urgency. The licence doesn’t prohibit your current use but it creates strategic vendor lock-in risk worth evaluating.
You need to systematically verify whether current usage violates the new licensing terms. Get your documentation sorted before you can make informed decisions.
For Redis, work through this checklist:
For Terraform, audit these elements:
Create an inventory spreadsheet with columns for instance/deployment, usage type, version, licence status, and risk level. Identify dependencies—applications and services that rely on Redis or Terraform. Quantify scale through data volumes, request rates, and infrastructure resource counts.
How do you identify the “offering as a service” threshold? If you’re offering Redis access to customers as part of your product, that trips the restriction. Internal caching for your own application doesn’t.
The core question is whether migration cost is justified by risk reduction and long-term benefits.
STAY scenarios where migration isn’t recommended:
MIGRATE scenarios where migration is recommended:
Work out your costs. Migration costs include engineering time, infrastructure duplication during parallel running, training and knowledge transfer, and opportunity cost of delayed features. Staying costs include potential licence fees if usage changes, vendor lock-in switching costs increasing over time, and governance risk if the vendor makes unfavourable changes.
For most, Valkey represents a safe evolutionary step as a compatible successor with solid improvements. The question isn’t about feature parity—both tools provision infrastructure. The real question is how each aligns with your platform engineering strategy, governance requirements, and long-term risk tolerance.
For companies with 50-500 employees, the typical project is 4-6 weeks with 2-3 engineers part-time.
Valkey is compatible with Redis OSS 7.2 and all earlier open source Redis versions. You’re aiming for protocol-compatible replacement with zero customer-facing downtime.
Here’s your step-by-step execution plan:
Week 1: Compatibility verification testing
Week 2: Parallel deployment setup
Weeks 3-4: Phased migration approach
Week 5: Validation and cleanup
Valkey 8.0 achieved 999.8K RPS on SETs with 0.8ms p99 latency versus Redis 8.0 at 729.4K RPS with 0.99ms p99. Valkey achieved 37% higher throughput on SET and 16% higher on GET compared to Redis.
Redis Stack compatibility concerns: Valkey does not yet support RedisJSON, RedisGraph, RedisSearch, RedisBloom modules. If you’re using Redis Stack, migration is blocked until Valkey module equivalents become available.
Aiven successfully migrated approximately 15,000 Redis servers to Valkey. MaiCoin used blue/green deployment strategy for migration from ElastiCache Redis to Valkey. Both show that zero-downtime migration is doable for standard Redis workloads, but it requires 4-6 weeks of careful testing, parallel running, and monitoring.
OpenTofu maintains 100% backward compatibility with existing Terraform code, modules, providers, and state files. Command syntax mirrors Terraform—simply replace terraform with tofu.
Here’s your step-by-step execution plan:
Day 1-2: State file backup and preparation
Days 3-4: State migration execution
Weeks 2-3: Phased migration approach
Week 4: CI/CD pipeline updates
OpenTofu ships with native state file encryption. State encryption is a feature the Terraform community has requested for the last five years but has never received.
Technical migration takes 1-2 weeks for most organisations. Full team adoption and workflow adjustment takes 2-4 weeks total.
You want to prevent future licensing crises by assessing vendor governance and licensing stability upfront. As detailed in our comprehensive analysis of the open source licensing wars, HashiCorp and Redis licence changes were predictable from governance structure and VC funding.
Licensing and governance questions:
Long-term sustainability questions:
Vendor lock-in assessment questions:
Red flags include evasive answers about licensing or governance structure, recent venture capital funding rounds (creates pressure for revenue extraction), conflicts with cloud providers (risks future licence restrictions), lack of contributor diversity (single vendor control), and proprietary features required for production use.
HashiCorp controls Terraform’s roadmap, prioritisation, and contribution acceptance. Within weeks of the HashiCorp licence change, major cloud providers formed the OpenTofu initiative. Decisions in OpenTofu happen in public, and contributions follow standard open source processes.
Ask these questions during vendor selection, not after you’re already deeply invested in the tool.
Here’s the recap: immediate risk assessment leads to compliance audit, then migration versus stay decision, followed by execution and vendor evaluation for future tool adoption. Licensing anxiety becomes structured action when you have systematic assessment methodology.
Choosing to stay and accepting lock-in is valid if you make the decision deliberately after assessment, not from avoidance. Migration is risk management investment—upfront cost buys long-term independence and stability.
Redis and Terraform represent a recurring pattern across the infrastructure industry—vendors changing terms as they seek exits or revenue growth. For a deeper understanding of the economic forces and governance models driving these changes, explore our complete overview of open source licensing wars. The vendor evaluation questions prevent repeat scenarios.
Start your assessment this week: run the compliance audit checklist, classify your urgency level, and schedule a decision review with your leadership team. Whether you migrate or stay, make it a deliberate strategic choice backed by systematic analysis.
BSL permits internal use without restriction—you can continue using Redis or Terraform for your own infrastructure. BSL prohibits offering as a managed service or competitive product. If you provide Redis or Terraform access to customers as a service, you violate the licence.
Most companies face strategic vendor lock-in risk, not immediate legal violation. The vendor controls pricing, features, and future changes. BSL enables monetisation pressure. Assess your specific usage pattern against BSL restrictions, then decide if strategic risk justifies migration.
For companies with 50-500 employees, typical migration timeline is 4-6 weeks with 2-3 engineers part-time. Week 1-2 covers compatibility testing and parallel environment setup. Week 3-4 handles phased migration (dev to staging to production) with monitoring. Week 5-6 includes validation, documentation, and decommissioning old infrastructure.
Things that extend the timeline? Large data volumes, complex custom integrations, Redis Stack module dependencies, and extensive Terraform module ecosystem. Rushing migration increases production incident risk. Careful execution is worth the time investment.
Yes, zero-downtime migration is achievable using PSYNC replication and blue/green deployment. PSYNC replication continuously synchronises Redis to Valkey in real-time. Blue/green deployment runs both systems in parallel, allowing instant traffic cutover and rollback.
You need Redis 7.2.4+ (Valkey protocol baseline), standard data types (not Redis Stack), and sufficient infrastructure capacity for parallel running. “Zero downtime” means no customer-facing outages, but migration still requires engineering time and careful monitoring.
Primary risks include fork abandonment (community loses interest), feature divergence (compatibility breaks over time), and security vulnerabilities (smaller security team than original). Look for these mitigation signals: foundation hosting (Linux Foundation for Valkey/OpenTofu), contributor diversity (multiple companies), enterprise adoption (AWS, others), and community momentum.
Valkey and OpenTofu show strong viability signals: Linux Foundation governance, AWS/cloud provider backing, growing community, and production deployments. Compare fork risk versus vendor lock-in risk—staying with BSL vendor creates strategic dependency risk while migrating to fork creates technical sustainability risk. Both Valkey and OpenTofu are mature enough for production adoption now.
Frame it as risk management investment: upfront cost buys long-term stability and vendor independence. Work out how switching costs compound as infrastructure scales 10x. Use the decision framework for systematic cost-benefit analysis removing emotional arguments.
Address team concerns: migration is a controlled project with testing and rollback, not reckless change. Highlight strategic benefits including avoiding future licence fees, reducing vendor negotiating power, and controlling infrastructure roadmap. Be realistic about timeline: 4-6 weeks is a meaningful investment but not a year-long distraction. Consider timing: migrating before scaling 10x is far easier than migrating after.
Standard Redis features show full compatibility with Redis 7.2.4 baseline—strings, lists, sets, sorted sets, hashes, streams, pub/sub all work identically. Redis Stack modules are currently not available in Valkey—RedisJSON, RedisGraph, RedisSearch, RedisBloom require staying on Redis or finding alternatives.
If using Redis Cloud proprietary features, Valkey on AWS ElastiCache may lack equivalents. Performance characteristics: Valkey matches or exceeds Redis performance in most benchmarks. For Redis Stack dependencies, DragonflyDB offers Redis Stack compatibility while staying open source. If Redis Stack is critical to your application, migration is blocked until Valkey adds equivalents or you architect around them.
Redis migration involves data migration requiring replication, compatibility testing, performance validation, and production cutover with rollback capability. Terraform migration primarily involves state file management and CLI command updates with no data migration required.
Timeline comparison: Redis migration typically takes 4-6 weeks, Terraform migration typically takes 1-2 weeks. Risk profile: Redis migration affects production data systems (higher downtime risk), Terraform migration affects deployment tooling (lower customer impact). Team skill requirements: Redis migration requires database operations expertise, Terraform migration requires IaC and CI/CD pipeline knowledge. Terraform to OpenTofu migration is “easier” but still requires careful execution—don’t underestimate CI/CD pipeline coordination complexity.
Current maturity level (early 2026): both Valkey and OpenTofu are production-ready for most use cases. Valkey maturity includes Linux Foundation hosting, AWS ElastiCache support, protocol compatibility proven, and enterprise deployments (Aiven 15k servers). OpenTofu maturity includes Linux Foundation hosting, Terraform 1.5.x feature parity, state encryption advantage, and growing community adoption.
Waiting strategy risks: vendor lock-in costs compound as infrastructure scales, and migration difficulty increases non-linearly with scale. Decision criteria: if your risk assessment shows HIGH urgency (legal compliance) or MODERATE urgency with capacity (strategic planning), migrate now rather than waiting. Thorough testing and phased migration reduce “early adopter risk”. Both forks already crossed the production-readiness threshold for most use cases.
For Redis to Valkey, you need database operations experience, replication understanding, performance testing capability, and production cutover experience. For Terraform to OpenTofu, you need IaC fluency, state file management knowledge, CI/CD pipeline experience, and module ecosystem familiarity.
Skill gap options: train internally by allocating learning time and test environment practice (adds 1-2 weeks to timeline). Hire a contractor to bring in migration specialist for 2-4 week engagement. Use managed migration through cloud provider migration services (AWS Database Migration Service, etc.) if available. Team capacity assessment: migration requires dedicated focus from 2-3 engineers part-time (50% capacity) for 4-6 weeks—can you allocate this without sacrificing projects? Skill gaps are solvable with training or contractor support—don’t let “we’ve never done this” block strategically justified migration.
Immediate actions (within 7 days): stop expanding restricted usage by not onboarding new customers to service using Redis/Terraform under BSL. Document violation scope to quantify affected deployments and customer impact. Get legal consultation to verify interpretation of BSL restrictions applies to your usage pattern. Inform leadership by escalating legal compliance risk to the executive team.
Short-term actions (30-90 days): prioritise migration as P0 project by allocating dedicated team. Consider workarounds by restructuring offering to avoid “providing as service” definition. Try licensing negotiation by contacting Redis Ltd or HashiCorp to discuss commercial licensing if migration is infeasible. BSL violations are less common than feared (most internal use is permitted) but require urgent action if identified—migration or licensing deal needed within 90 days to avoid legal risk.
Direct costs include engineering time (2-3 engineers at 50% capacity for 4-6 weeks equals 4-9 engineer-weeks of effort), infrastructure duplication for parallel running during migration (1-2 weeks of double hosting costs, typically less than $5k for SMB), testing environments for validation (approximately 20% of production cost), and external help if needed (contractor rates $150-300/hour for 40-80 hours if skill gaps exist).
Indirect costs include opportunity cost (features/projects delayed while team focuses on migration), training and documentation (updating runbooks, training team on new tools), and monitoring and tooling updates (dashboards, alerts, automation).
Cost avoidance through long-term benefits includes vendor lock-in reduction (avoiding future licence fee increases or forced upgrades), strategic independence (controlling infrastructure roadmap and upgrade timing), and governance stability (foundation-backed projects less likely to change terms unfavourably). Break-even analysis shows migration typically pays back within 12-24 months through avoided vendor leverage and price increases. Rough estimate for companies with 50-500 employees: $20-50k total migration cost, offset by reduced lock-in risk and long-term economic benefits.
Open Source Governance Models: How Linux Foundation and PostgreSQL Prevent Vendor ControlHashiCorp changed Terraform’s license from MPL 2.0 to BSL. Redis Inc tried to push SSPL restrictions on Redis. Elastic did the same thing. When you’re relying on infrastructure software for your business, watching a vendor unilaterally change the rules is a problem. These changes aren’t isolated incidents—they’re part of the broader open source licensing crisis that’s reshaping how infrastructure software gets built and governed.
The common thread in all these cases? Single company control over project governance. When one company controls all major decisions, they can change licensing terms whenever their business model demands it.
Three governance models exist on a spectrum. On one end, you have vendor-controlled projects like HashiCorp’s Terraform. In the middle, Linux Foundation-governed projects like OpenTofu and Valkey. On the other end, pure community-governed projects like PostgreSQL.
Governance structure determines whether projects survive 30+ years like PostgreSQL or trigger community forks like Redis and Terraform. For you and your team selecting infrastructure tools, governance assessment is now as important as technical evaluation.
This guide explains governance mechanics, walks through fork creation step-by-step, evaluates fork viability, and shows you how to set up governance that prevents vendor lock-in.
Governance defines who makes decisions about licensing, roadmap, contribution acceptance, and project direction. Simple as that.
When vendors control governance, they can change licenses unilaterally. HashiCorp moved Terraform from MPL 2.0 to BSL because they controlled all major decisions. Redis Inc attempted the same with SSPL restrictions. Both decisions were made behind closed doors.
Community-governed projects can’t do this. PostgreSQL has maintained permissive licensing for 30+ years because no single vendor controls the decision-making. Distributed authority means distributed veto power. If you want to change PostgreSQL’s license, you need consensus from dozens of independent committers across multiple organisations. Good luck with that.
The governance question matters for infrastructure stability. If a vendor gets acquired or pivots their business model, projects under their control face abandonment risk. Your database, IaC tools, and caching systems need to remain stable as your organisation scales over decades, not just quarters.
The fork pattern proves this. Valkey emerged in March 2024 following Redis Inc’s licensing changes. OpenTofu forked from Terraform after HashiCorp’s BSL announcement. OpenSearch split from Elasticsearch. Communities don’t just assess technical features anymore. They assess governance structures.
Technical Steering Committees and distributed committer models distribute authority. This prevents single points of control. When OpenTofu talks about being vendor-neutral, they mean multiple organisations sit on the Technical Steering Committee. No single company can push through a license change.
PostgreSQL’s public mailing list review process creates transparency. Vendor-controlled projects make roadmap decisions in private. You can read every technical debate in PostgreSQL’s archives. Try doing that with a vendor-controlled project.
Understanding the governance spectrum helps you evaluate projects for long-term viability.
Vendor-controlled governance means a single company owns the project and makes all major decisions. HashiCorp controlled Terraform this way. Redis Inc controlled Redis. These companies controlled contribution acceptance, roadmap priorities, and licensing terms. When business pressures mounted, they changed the rules.
The tradeoff: vendor control enables rapid decision-making. Roadmap items get prioritised quickly. Features ship faster. But you’re trusting one company’s ongoing goodwill and financial stability. If their revenue model changes, your infrastructure stack is at risk.
Linux Foundation governance provides the middle ground. A neutral non-profit hosts the project. A Technical Steering Committee represents multiple organisations, enforcing vendor neutrality. OpenTofu operates this way. So does Valkey.
The React Foundation is a recent example. Meta transferred React governance in October 2025 to ensure long-term neutrality. The governing board includes Amazon, Microsoft, Vercel, and others. Meta committed $3 million in funding and engineering support over five years. This structure ensures no single company controls React’s destiny.
Valkey established Linux Foundation backing with nearly 50 contributing companies including AWS, Ericsson, Oracle, and Google. Legal frameworks protect the community. License agreements prevent unilateral changes. Contributors retain their rights.
Pure community governance operates without corporate ownership. PostgreSQL runs this way through the PostgreSQL Global Development Group. Distributed committers hold merge authority. Mailing list consensus drives decisions. Working groups handle specialised areas like infrastructure and security.
This model takes decades to establish. PostgreSQL earned its trust over 30+ years. But once established, it’s remarkably resilient. No corporate acquisition can change PostgreSQL’s direction. No investor pressure can force a license change. The community owns the project in practice, not just in theory.
Each model trades control for resilience. You choose based on your risk tolerance and timeline.
Linux Foundation governance provides formalized vendor neutrality. The legal structure protects you from the governance failures that triggered recent forks.
The Technical Steering Committee distributes authority across multiple organisations. OpenTofu’s TSC includes multiple infrastructure companies. React Foundation’s governing board includes Amazon, Callstack, Expo, Meta, Microsoft, Software Mansion, and Vercel with plans to expand further. No single vendor controls the roadmap.
License agreements prevent unilateral changes. When OpenTofu forked from Terraform, they restored MPL 2.0 permissive licensing. The Linux Foundation structure protects this restoration. Contributors retain their rights. Fork protection mechanisms prevent what happened with HashiCorp from happening again.
Infrastructure support enables independence. Linux Foundation members fund build systems, CI/CD, security auditing, and community infrastructure. This removes single-vendor dependency for basic project operations. Multiple sponsors means the lights stay on even if one company exits.
Governance bylaws formalise decision-making. Voting procedures, membership criteria, and roadmap approval processes are documented publicly. You can read exactly how decisions get made. Compare this to vendor-controlled roadmap decisions made in executive meetings you’ll never see minutes from.
Valkey’s first year demonstrates this model working. The project grew to 1,000+ commits with 150 contributors, 19.8K GitHub stars, 761 forks, and 5 million+ Docker pulls. Nearly 50 companies contribute. This level of distributed contribution doesn’t happen under vendor control.
The Linux Foundation enables enterprise confidence. When you evaluate infrastructure software, governance stability signals long-term project viability. A diverse Technical Steering Committee backed by multiple cloud providers tells you this project won’t disappear if one company changes strategy.
PostgreSQL proves pure community governance scales. After 30+ years, the project maintains permissive licensing, active development, and massive enterprise adoption without corporate ownership.
The PostgreSQL Global Development Group consists of distributed committers with merge authority. No corporate owner. Decisions happen through mailing list-based review processes. This might sound chaotic, but it works because the processes evolved over decades.
The Commitfest cycle provides structure. Recurring community review periods handle outstanding patches collaboratively. Monthly commits. Annual major releases. Everyone knows the schedule. Contributors know when their work gets reviewed.
Working groups provide specialisation without centralisation. The infrastructure team manages servers and builds. The security working group handles vulnerabilities. Non-profits support specific areas. This distributed structure prevents bottlenecks while maintaining coordination.
Contributor diversity prevents vendor control. No single organisation contributes the majority of code. This matters because it prevents corporate takeover scenarios. If one company employs half the committers, they effectively control the project. PostgreSQL avoids this through genuine distribution.
Decentralised decision-making scales. Committers make final technical decisions after public mailing list discussion. Roadmap emerges from consensus. Thousands of contributors coordinate without corporate structure. This proves community governance can handle complexity.
The 30-year permissive license track record tells you everything. Distributed authority means no entity can unilaterally restrict licensing. Multiple attempts to create “enterprise PostgreSQL” with restricted features have failed. The community maintains permissive licensing because no single vendor can override this.
Enterprise adoption proves commercial viability. PostgreSQL powers millions of applications. AWS, Azure, and Google Cloud all provide managed PostgreSQL services. You get commercial support without corporate ownership. This demonstrates you don’t need a single vendor controlling a project for it to succeed at scale.
Successful forks follow a pattern. Understanding this pattern helps you evaluate whether a fork is legitimate or likely to fail. These mechanics emerged directly from the crisis affecting infrastructure software that we explore throughout this wave of license changes and forks.
Step 1: License change triggers community response. The vendor announces restrictive licensing like BSL or SSPL. The community recognises the governance threat. Major stakeholders assess migration costs. HashiCorp’s BSL announcement triggered this for Terraform. Redis Inc’s SSPL attempt triggered it for Redis.
Step 2: Rapid community mobilisation. Key contributors coordinate a response. Major users signal support. Cloud providers evaluate commercial impact. This happens fast because everyone realises the window for action is narrow.
Step 3: Code fork creation. The repository gets copied. Branding changes. Initial maintainers get identified. Infrastructure setup begins. This is the easy part.
Step 4: Governance establishment. Linux Foundation adoption gets negotiated. The Technical Steering Committee forms. Bylaws get documented. This is the hard part because it requires coordination across organisations with competing interests.
Step 5: License restoration. Return to permissive licensing like MPL 2.0 or Apache 2.0. Legal review completes. Contributor agreements get established. This signals the fork’s intent to remain truly open.
Step 6: Cloud provider backing. Hyperscalers signal support. AWS contributed actively to Valkey and now provides ElastiCache for Valkey at 20-33% lower cost. Managed service commitments provide commercial validation. This tells enterprise users the fork is viable for production.
Step 7: Community coalition building. Tool ecosystems commit compatibility. ArgoCD and Flux added OpenTofu support. Documentation gets migrated. Adoption guidance gets published. This reduces switching costs for users.
Step 8: Technical improvements. Community contributions prove the fork’s viability. Valkey achieved 37% higher SET throughput and 16% higher GET throughput compared to Redis 8.0, plus 30-60% faster p99 latencies. Performance benchmarking demonstrates technical superiority. Feature differentiation emerges.
Timeline expectations matter. OpenTofu and Valkey both achieved Linux Foundation adoption and cloud backing within 12-18 months of fork creation. This window tells you whether a fork has momentum.
Not all forks succeed. Understanding success factors helps you evaluate whether to trust a fork for production infrastructure.
Governance legitimacy matters most. Linux Foundation backing signals neutrality. A Technical Steering Committee with multiple organisations prevents single vendor capture. Forks without this structure struggle because they replicate the vendor control problem they claim to solve.
Cloud provider support provides commercial validation. Hyperscaler commitment from AWS, Azure, or Google Cloud tells enterprise users the fork has staying power. Managed service offerings ensure an adoption path. Valkey got backing from nearly 50 companies including AWS, Ericsson, Oracle, Google, Percona, Canonical, and Aiven.
Tool ecosystem compatibility reduces switching costs. OpenTofu maintained compatibility with Terraform providers. ArgoCD, Flux, and Atlantis added support. Migration tooling helps users switch. Without ecosystem support, forks die from network effects.
Community contribution velocity indicates health. Valkey demonstrated 1,000+ commits with 150 contributors in the first year. Active development post-fork proves the community is real, not just a handful of disgruntled former employees. Contributor diversity matters. Sustained commit activity matters.
Technical differentiation proves value beyond license restoration. Valkey’s 37% throughput gains demonstrate performance superiority. OpenTofu’s state file encryption addresses a security gap Terraform left unresolved. Feature parity isn’t enough. You need actual improvements.
Enterprise confidence signals drive adoption. Major user adoption announcements. Case studies. Commercial support availability. Security audit completion. These signals tell you other organisations trust the fork enough to bet their infrastructure on it.
Time horizon determines viability assessment. The first 12-18 months are critical for establishing legitimacy. Years 2-3 prove long-term viability. Historical fork patterns show this timeline consistently.
Failure patterns exist too. Forks without governance structure fade. Single-vendor-backed forks get perceived as vendor swaps rather than governance improvements. Forks lacking cloud provider support struggle to reach enterprise users. The community sees through fake governance.
This is the question you need answered before committing infrastructure to a fork. Let’s look at the evidence.
Valkey survival indicators look strong. The performance numbers tell a compelling story. 37% higher SET throughput, 16% higher GET throughput, 30-60% faster p99 latencies. These aren’t marginal improvements. Valkey with 6 I/O threads achieved 832K RPS throughput with lower latency compared to Redis 8.0.
AWS Async I/O Threading contributions demonstrate sustained engineering investment from a hyperscaler. AWS isn’t treating this as a side project. They’re building ElastiCache for Valkey as a first-class managed service. The economic incentives align for long-term support.
The fork achieved differentiation beyond license restoration. Community-driven performance improvements exceeded the original Redis. Hyperscaler commitment provides commercial stability. Enterprise users can trust this for production.
OpenTofu survival indicators also look solid. State file encryption at rest addresses a security gap that Terraform left unresolved. This is the kind of technical differentiation that matters. Linux Foundation governance provides legitimacy. Tool ecosystem compatibility maintained through ArgoCD, Flux, and Atlantis support.
The Technical Steering Committee includes multiple organisations ensuring vendor neutrality. Provider ecosystem compatibility reduces migration friction. Enterprise adoption is growing because the governance question is settled.
Historical fork patterns provide context. Forks succeed when they achieve technical superiority plus governance legitimacy plus cloud provider backing. OpenSearch succeeded this way. MariaDB succeeded this way. Forks without all three factors tend to consolidate back or fade away.
Risk factors exist. If HashiCorp reversed course and open-sourced Terraform again, competitive dynamics would shift. If Redis restored original governance, some users might return. But governance trust is broken. Once a vendor demonstrates they’ll change licenses when business pressures mount, that trust doesn’t fully return.
The 5-year outlook favours both forks thriving as governance-first alternatives. Community-driven development models prove resilient. Your preference should be shifting toward governed alternatives because they remove business risk from technical decisions.
Monitor these indicators over time. Contributor diversity growth. Cloud provider managed service expansion. Enterprise case study publication. Performance benchmark improvements. These metrics tell you fork health.
If you’re building open source projects, setting up governance correctly from the start prevents the problems we’ve been discussing. This approach directly addresses the shift affecting infrastructure tools that characterises the current open source licensing crisis.
Choose your governance model early. Decide between Linux Foundation hosting, pure community model like PostgreSQL, or vendor-controlled with full awareness of the risks. Don’t drift into vendor control accidentally because you didn’t think through governance structure upfront.
Establish a Technical Steering Committee. Multiple organisations represented. Voting procedures documented. Decision-making transparent. This prevents single vendor dominance even if your company starts the project. Invite major contributors and users to join the TSC early.
Document governance bylaws. Membership criteria. TSC election process. Roadmap approval procedures. License change requirements should need supermajority votes, not simple majority. Write this down before conflicts emerge. Bylaws created during conflicts never satisfy everyone.
Select permissive licensing. MPL 2.0, Apache 2.0, or similar licenses enable commercial use without restriction. Avoid dual licensing structures that create vendor control backdoors. If you want an open source project to remain open, choose a license that prevents you from changing your mind later.
Set up contributor agreements. Clarify rights retention. Prevent unilateral license changes. Protect community investment in the codebase. Contributor License Agreements need legal review, but they’re worth doing properly.
Implement transparent decision-making. Public mailing lists. Documented RFC processes. Roadmap discussions visible to the community. This mimics the PostgreSQL model. Transparency creates trust. Secret roadmap meetings create suspicion.
Build contributor diversity. Encourage multi-organisation contributions. Prevent single vendor code majority. This creates resilience against corporate strategy shifts. If your company contributes 80% of the code, you don’t have community governance no matter what your bylaws say.
Establish legal entity or foundation relationship. Non-profit hosting through Linux Foundation or a legal entity like PostgreSQL’s infrastructure non-profits provides stability. This separates project governance from company governance.
The React Foundation provides a recent case study. Meta transferred React governance to ensure long-term neutrality. The governing board includes Amazon, Microsoft, and Vercel. This demonstrates how large projects can formalise governance when they recognise vendor control creates community concerns.
Linux Foundation governance provides formalised legal structure, Technical Steering Committee with documented procedures, and infrastructure support while maintaining vendor neutrality. Pure community governance like PostgreSQL operates through distributed committers, mailing list consensus, and working groups without legal entity hosting. Linux Foundation suits projects needing rapid legitimacy and multi-organisation coordination. PostgreSQL’s model requires decades to establish trust and processes.
Initial fork creation including code copy, governance setup, and Linux Foundation adoption typically takes 6-12 months, as OpenTofu and Valkey demonstrated. Proving long-term viability requires 2-3 years for achieving technical differentiation, securing cloud provider backing, and building enterprise confidence through case studies and commercial support. The first 12-18 months are critical for establishing governance legitimacy and community momentum.
Single-company forks rarely succeed long-term because they replicate the vendor control problem they claim to solve. Successful forks like Valkey, OpenTofu, and OpenSearch require multi-organisation Technical Steering Committees, Linux Foundation hosting for neutrality, and cloud provider coalitions. Single-vendor forks get perceived as vendor swaps rather than governance improvements.
PostgreSQL’s distributed committer authority prevents any single organisation from changing licensing or roadmap unilaterally. Monthly Commitfest review cycles, public mailing list discussion, and working group specialisation enable thousands of contributors to coordinate without corporate structure. No single organisation contributes the majority of code, creating resilience against corporate strategy shifts or acquisitions.
Technical Steering Committees distribute decision-making authority across multiple organisations, preventing single-vendor unilateral actions. TSC voting procedures, documented bylaws, and membership diversity ensure licensing changes require supermajority consensus. OpenTofu’s TSC includes multiple infrastructure companies. React Foundation’s governing board includes Amazon, Microsoft, Meta, and Vercel. No single vendor controls project destiny.
Evaluate six factors: Linux Foundation or equivalent neutral governance, cloud provider managed service commitments, tool ecosystem compatibility, contributor diversity and velocity, technical differentiation beyond feature parity, and enterprise adoption signals like case studies and commercial support. Monitor these indicators over 12-18 month periods to assess fork sustainability.
Meta formalised React governance to ensure long-term vendor neutrality and prevent community concerns about corporate control. By establishing React Foundation with a governing board including Amazon, Microsoft, Vercel, and others, Meta signaled React’s independence from Meta’s business priorities. Governance formalisation enables enterprise confidence and community trust for infrastructure frameworks. Meta committed five years of funding and engineering support to ensure smooth transition.
Community-driven forks benefit from diverse contributor expertise and reduced corporate constraint. Valkey achieved 37% higher throughput and 30-60% faster p99 latencies through AWS Async I/O Threading contributions and community optimisations. OpenTofu added state file encryption at rest, addressing a security gap in vendor-controlled Terraform. Distributed contribution models enable rapid innovation without corporate roadmap gatekeeping.
Warning signs include single company controlling all major decisions, commercial pressure from cloud provider revenue capture, new investor demands for monetisation, acquisition by a company with proprietary software business model, introduction of commercial features in parallel proprietary versions, reduced community contribution acceptance, and roadmap secrecy. Projects under vendor control face higher license change risk than community-governed alternatives.
Yes, if the community holds copyright or contributors agree. OpenTofu reverted Terraform from BSL back to MPL 2.0 after forking. Valkey restored permissive licensing after Redis Inc’s SSPL attempt. Fork copyright independence from the original vendor enables license restoration. Linux Foundation hosting and contributor agreements protect the community’s ability to maintain permissive licensing.
Frame governance as infrastructure risk management. Vendor-controlled projects face license change risk like HashiCorp’s BSL switch, abandonment risk from acquisitions, and roadmap uncertainty. Community-governed alternatives provide license stability through distributed authority, cloud provider backing ensuring commercial viability, tool ecosystem compatibility reducing migration risk, and technical improvements from diverse contributors. Use PostgreSQL’s 30-year stability as precedent for community governance success.
Feature forks address technical gaps but often struggle long-term without governance legitimacy. Governance forks like Valkey and OpenTofu address vendor control and license restrictions. They achieve legitimacy through Linux Foundation adoption, Technical Steering Committee formation, and permissive license restoration. Governance forks attract cloud provider backing and enterprise adoption because they solve business risk, not just technical limitations. Most successful modern forks are governance-driven.
Cloud Provider Economics and the Open Source Freeloading Debate – AWS, Managed Services and SustainabilityCloud providers are making billions from open source software. The maintainers who built that software are struggling to keep the lights on. This is the “freeloading” accusation at the heart of one of tech’s biggest fights.
This guide is part of our comprehensive Open Source Licensing Wars – How HashiCorp, Redis and Cloud Economics Are Reshaping Infrastructure Software resource, where we examine the economic tensions driving the most significant shift in open source history.
[AWS ElastiCache, Azure Cache for Redis, and Google Memorystore are high-margin managed services](https://thenewstack.io/forks-clouds-and-the-new-economics-of-open-source-licensing/) that are generating way more revenue than the companies that built the underlying databases ever did. But cloud providers aren’t paying those maintainers a cent.
Cloud providers say they’re following the licence terms and contributing code back to projects. Maintainers fire back that the biggest users—the cloud providers—are killing off the enterprise support contracts that fund development.
Why does this matter to you? Because it affects how you evaluate managed services versus self-hosting, how you assess vendor lock-in risks, and which projects you bet your business on. The 1% conversion problem is why maintainers are switching to restrictive licensing. PostgreSQL is proof that sustainable open source is possible, but only under specific conditions.
Cloud providers take permissively-licensed projects like Redis or PostgreSQL, package them up as managed services, and capture the majority of commercial value. The maintainers get zero revenue from these deployments.
AWS offers RDS for PostgreSQL, ElastiCache for Redis, and DocumentDB as MongoDB-compatible. These are some of the highest-margin products cloud providers sell.
Sure, cloud providers contribute code and patches. But critics say it’s disproportionate to revenue captured—often 0.1% contribution for 80% of the revenue.
Why “freeloading” is contested comes down to how you read the licence. Apache 2.0, MIT, and BSD licences explicitly allow commercial use without payment. Cloud providers argue they’re just exercising rights the maintainers granted them.
But here’s where it gets controversial. 96% of organisations maintained or increased open source use in 2025. When millions of deployments happen via managed services, cloud provider revenue completely dwarfs what maintainers can generate through support contracts.
The managed service model eliminates operational burden. You don’t hire database administrators who specialise in PostgreSQL tuning. Integration with the cloud ecosystem means monitoring, backups, and networking just work.
Industry estimates suggest 60-80%+ gross margins on managed services. Maintainers selling direct support see 20-40%. That gap is the whole story.
Lock-in effects increase customer lifetime value. Proprietary APIs, monitoring tools, and networking create switching costs that make leaving expensive. Once you’ve built around AWS RDS PostgreSQL’s extensions, moving becomes a serious headache.
Cloud providers sell open source alongside compute, storage, and networking, capturing more of your infrastructure spend. This is why managed services are so profitable—they’re selling convenience, integration, and scale that individual maintainers simply can’t match.
Permissive licences explicitly allow commercial use without payment. Apache 2.0, MIT, and BSD were chosen by the maintainers themselves. Cloud providers are just exercising rights the maintainers granted.
The Open Source Definition makes this pretty clear. Open source must grant all rights without restrictions on use. When maintainers release under Apache 2.0, they’re making a choice.
Cloud providers point to their contributions. AWS employs PostgreSQL committers, contributes security patches, funds Linux Foundation projects, and maintains OpenSearch. Google funds Kubernetes. Microsoft contributes to .NET and VS Code.
And they argue that managed services make open source accessible to companies that couldn’t otherwise adopt it. That expands the ecosystem and benefits maintainers who see broader adoption.
There’s also the open source preservation angle. When maintainers switch licences, providers fork to keep code open. Valkey emerged as a BSD fork backed by AWS after Redis changed licences. OpenSearch was AWS’s Elasticsearch fork. OpenTofu forked Terraform when HashiCorp moved to BSL. These forks represent a pattern explored throughout our open source licensing wars analysis.
Here’s the economic reality: 99% of users never convert to paying customers, yet they all demand features, patches, and support.
Maintainer revenue comes from enterprise support. But cloud providers eliminate this need by offering managed alternatives. When AWS runs your PostgreSQL database, you don’t pay EDB or Crunchy Data.
Without revenue from largest users, maintainers can’t hire engineers for maintenance and innovation. Security patching and new features require full-time engineers, not weekend warriors.
Cloud providers capture billions while paying nothing. When they do fork projects, commercial forks create divergence and split developer activity.
Maintainers are stuck with lousy options: Restrictive licensing alienates community, venture funding means unsustainable burn, or acquisition means loss of independence.
Industry estimates suggest only 1-2% of users convert to paying customers through support contracts or managed services.
Permissive licences provide full functionality for free. There’s no incentive for customers to pay. Why pay for PostgreSQL support when you can just use it for free?
PostgreSQL has millions of users but only a fraction pay for commercial support. The gap between users and paying customers is absolutely massive.
Projects typically start as side projects, get popular, then face an unsustainable support burden. As one maintainer put it: “Despite adoption and success, I couldn’t make it sustainable. Good intentions don’t pay bills”.
Venture capital distorts the model. VC-funded companies burn cash building free software, hoping to capture users later. Most fail before finding sustainable revenue.
Corporate sponsorship funding is unpredictable and subject to shifting priorities. What happens when those priorities change?
Economic models that work do exist. Red Hat built a business on support. Confluent offers managed Kafka. GitLab uses open-core. But these require conditions most projects can’t replicate.
Open-core provides free core with proprietary premium features. GitLab, Grafana, and Mattermost use this approach. The challenge is drawing the line—what goes in core versus premium?
Managed service with value-add means maintainer-operated offerings with features cloud providers don’t match. Confluent Cloud offers Kafka governance AWS doesn’t provide. Databricks adds lakehouse features beyond managed Spark.
Dual licensing gives you a choice. Use AGPLv3 for free if you’re happy sharing modifications, or pay for a commercial licence. AGPLv3 is OSI-approved copyleft requiring network service providers to share modified code. Many developers misunderstand it—they believe it requires open sourcing their entire application, but it doesn’t.
Support contracts provide enterprise agreements with SLAs. Red Hat, SUSE, and Canonical built entire businesses on this.
Foundation funding through multi-company sponsorship works for projects like PostgreSQL and Kubernetes. But this requires broad appeal and established adoption.
Now here are the nuclear options. SSPL requires anyone offering software as a service to open-source all infrastructure code—management software, APIs, automation, monitoring, backup, storage, hosting, the lot. It’s based on AGPLv3 but replaces Section 13 with requirements so broad that cloud providers simply can’t comply.
BSL is source-available with commercial restrictions for 3-4 years, then converts to Apache 2.0. HashiCorp’s BSL allows production use except in products competitive with HashiCorp.
Vendor lock-in means switching costs that make changing vendors prohibitively expensive.
Managed service lock-in comes through proprietary APIs, backup formats, and monitoring integrations. AWS-specific optimisations like Aurora PostgreSQL don’t exist in vanilla open source. If you build on those features, migration becomes really hard.
Self-hosted lock-in includes custom configurations, operational knowledge, and team expertise. Your team’s PostgreSQL knowledge doesn’t transfer to MySQL. Your backup scripts don’t work with managed services.
Cost comparison gets complicated fast. Managed pricing can escalate as usage grows. Self-hosted has engineering costs—salaries for specialists, infrastructure, monitoring—that aren’t immediately obvious.
Managed services reduce need for specialised database administrators; self-hosted requires deep expertise. Do you have that expertise in-house? Can you hire it?
Aurora PostgreSQL delivers better performance than standard PostgreSQL. If your application relies on that performance, self-hosting might not even be viable.
No deployment is perfectly portable. Lock-in mitigation includes infrastructure-as-code, containerisation, and abstraction layers.
Both approaches create lock-in through different mechanisms. The question is which trade-offs make sense for your operational maturity and risk tolerance.
PostgreSQL thrives with permissive licensing similar to MIT/BSD. It’s proof that sustainable open source is actually possible.
The governance model centres on the PostgreSQL Global Development Group with distributed maintainership. No single vendor controls the project.
The commercial ecosystem includes multiple vendors—EDB, Crunchy Data, Timescale, Supabase—that coexist. AWS, Azure, and Google offer managed PostgreSQL while maintainer companies also offer competing services.
Development funding is sustained by companies employing PostgreSQL committers—Microsoft, Amazon, EDB, Fujitsu, Google all pay core developers.
Extensions like PostGIS, TimescaleDB, and pgvector create differentiation without fragmenting the core. Commercial vendors compete on extensions and support quality, not by controlling the core database.
Why does it work? It comes down to specific conditions. Strong governance established early. A mature codebase with 30+ years of development. A diverse commercial ecosystem. Strategic importance to multiple large companies.
Neutral governance, multi-vendor ecosystem, and strategic corporate alignment enable sustainability. But newer projects don’t have these preconditions.
The model is replicable for strategically important infrastructure projects that can attract multi-vendor investment. For projects without that broad importance, PostgreSQL’s path simply isn’t available.
Cloud providers and maintainers both have economically rational perspectives. Providers follow licence terms and contribute to projects. Maintainers can’t sustain development when 99% never pay and cloud providers eliminate support revenue.
All technology choices involve trade-offs between cost, control, convenience, and risk. Managed services provide convenience but create lock-in. Self-hosting provides control but requires expertise. Permissive licences ensure freedom but create sustainability challenges. Restrictive licences fund development but fragment communities.
PostgreSQL proves that sustainable open source is possible under specific conditions—neutral governance, multi-vendor ecosystem, strategic importance to multiple companies. But most projects can’t replicate those conditions.
Restrictive licensing solves immediate funding problems but creates new issues. MongoDB reported revenue growth after SSPL adoption. But HashiCorp’s BSL triggered immediate backlash and the OpenTofu fork. Redis’s licence change prompted Valkey, a well-funded competitor backed by AWS and Google.
The future looks like continued fragmentation. More maintainers will adopt BSL or SSPL to protect their commercial interests, triggering community forks. Cloud providers will maintain open alternatives. Enterprises will face confusion choosing between original projects and forks. To understand how this pattern has evolved from MongoDB to Redis, examine the historical timeline that reveals predictable warning signs.
The 1% conversion problem remains unsolved. Until open source economics fundamentally change, expect more licensing wars, more forks, and more uncertainty.
So what do you do? Evaluate managed versus self-hosted based on your operational maturity and risk tolerance. Understand that sustainability concerns affect project viability long-term. Choose vendors and projects with governance models that reduce licence change risk.
Understanding these economic forces helps you navigate the open source sustainability crisis that’s reshaping enterprise technology decisions. For a complete overview of how licensing changes are affecting infrastructure software decisions, see our comprehensive Open Source Licensing Wars resource.
“Freeloading” is contested. Cloud providers follow permissive licence terms (Apache 2.0, MIT, BSD) that explicitly allow commercial use without payment. They contribute code, employ maintainers, and expand the market. Maintainers counter that contributions are disproportionate to revenue captured (often 0.1% contribution for 80%+ revenue). Both perspectives are economically rational but conflicting.
Industry estimates suggest 1-2% of open source users convert to paying customers through support contracts, commercial licences, or managed services. PostgreSQL has millions of users but only thousands of paying enterprise customers. This low conversion creates the sustainability crisis: maintainers can’t fund development when 99% never pay, especially when cloud providers offer competing managed services.
Both create lock-in through different mechanisms. Managed services lock you into proprietary APIs, backup formats, and cloud-specific optimisations (AWS Aurora). Self-hosted creates lock-in through operational knowledge, custom configurations, and team expertise. Your team’s PostgreSQL knowledge doesn’t transfer to MySQL. Your backup scripts don’t work with managed services. Neither is perfectly portable. Evaluate switching costs realistically: data migration effort, application changes, re-training. Use infrastructure-as-code and abstraction layers to mitigate lock-in.
Yes, but under specific conditions. PostgreSQL thrives with permissive licensing through neutral governance, diverse commercial ecosystem (EDB, Crunchy Data, AWS, Azure), and strategic importance to multiple large companies. Alternative models include open-core (GitLab), managed services with value-add (Confluent Cloud), support contracts (Red Hat), foundation funding (CNCF), and dual licensing with AGPLv3. Success requires strong governance, commercial differentiation, and a multi-vendor ecosystem.
AGPLv3 is OSI-approved copyleft requiring network service providers to share modified code with users. SSPL (Server Side Public Licence) is non-OSI, requiring anyone offering the software as a service to open-source all infrastructure code—it’s designed to prevent cloud re-hosting. BSL (Business Source Licence) is source-available with commercial restrictions for 3-4 years, then converts to Apache 2.0. AGPLv3 is legitimate open source; SSPL and BSL are “source-available” and often trigger enterprise licence policy rejections.
Economic pressure from cloud providers offering managed services without contributing revenue. AWS ElastiCache competed with Redis Inc. AWS managed Elasticsearch competed with Elastic. Cloud providers planned managed Terraform threatening HashiCorp’s business. These companies switched to SSPL or BSL to prevent commercial re-hosting. The changes triggered backlash and forks (Valkey from Redis, OpenTofu from Terraform, OpenSearch from Elasticsearch), fragmenting ecosystems but protecting maintainer revenue.
It varies significantly. AWS employs PostgreSQL committers, contributes security patches, funds Linux Foundation projects, and maintains OpenSearch. Google funds Kubernetes development. Microsoft contributes to .NET, TypeScript, and VS Code. Critics argue contributions are disproportionate to revenue (0.1% contribution for 80% revenue capture). Supporters note code commits don’t reflect total value: infrastructure, security research, compliance certifications, and market expansion. There’s no industry-standard metric for “fair contribution.”
Both. PostgreSQL proves sustainable open source is possible under permissive licensing, but it requires specific conditions: neutral governance, strategic importance to multiple large companies, a mature codebase with 30+ years of development, and a diverse commercial ecosystem where vendors differentiate through extensions and services. Newer projects lack these preconditions. PostgreSQL’s model is replicable for strategically important infrastructure projects that can attract multi-vendor investment, but it’s not universally applicable.
Evaluate: (1) Total cost over 5 years including engineering time and infrastructure; (2) Operational maturity—do you have DBAs and infrastructure engineers?; (3) Lock-in risks—can you migrate if needed?; (4) Compliance requirements—do you need SOC2, ISO27001, HIPAA certifications?; (5) Performance needs—do cloud-specific optimisations provide advantages?; (6) Team expertise—will managed services enable focus on your core business?; (7) Sustainability concerns—does the licence restrict your use case?
Avoid restrictive licences if possible. Consider: (1) Open-core with clear premium features (GitLab, Grafana); (2) Managed service with value-add cloud providers don’t match (Confluent Cloud’s Kafka governance); (3) Dual licensing with AGPLv3 + commercial option; (4) Enterprise support contracts with SLAs; (5) Foundation governance preventing single-vendor control (PostgreSQL model); (6) Corporate sponsorship from multiple companies; (7) Development services (consulting, custom features). Success requires commercial differentiation beyond the core project.
Expect continued fragmentation: More maintainers adopting BSL/SSPL to protect commercial interests, triggering community-led forks (the OpenTofu, Valkey, OpenSearch pattern). Cloud providers will maintain open source alternatives to avoid restrictive licences. Enterprises face confusion choosing between original projects and forks. PostgreSQL-style neutral governance may become more attractive. The OSI definition of “open source” is under pressure. The 1% conversion problem remains unsolved, so the economic tension will persist.
Mixed results. MongoDB reported revenue growth after SSPL adoption. HashiCorp’s BSL adoption triggered immediate community backlash and the OpenTofu fork, fragmenting the Terraform ecosystem. Elastic’s SSPL adoption protected against AWS competition but alienated some enterprise users. Redis’s licence change prompted the Valkey fork backed by major tech companies, creating a well-funded competitor. Restrictive licences solve immediate revenue problems but risk community fragmentation, fork competition, and enterprise adoption barriers.
HashiCorp Terraform OpenTofu and the IBM Acquisition Wild Card for Infrastructure as CodeIBM just dropped $6.4 billion to acquire HashiCorp. And the infrastructure automation world is asking: will Big Blue restore Terraform‘s open-source licence, or are we doubling down on commercial restrictions?
The acquisition closed on 27 February 2025, throwing a wild card into an already tense situation. HashiCorp’s Business Source Licence change back in August 2023 already triggered a community fork. OpenTofu emerged under Linux Foundation governance, keeping the original MPL 2.0 licence alive. Now IBM calls the shots on HashiCorp’s licencing decisions, and the community’s waiting to see which way they’ll jump.
You’ve got a choice to make: stick with Terraform, migrate to OpenTofu, or wait it out. We’re going to walk through HashiCorp’s rationale for the licence change, how the community responded with OpenTofu, where feature parity sits in 2026, what the IBM acquisition means, governance models, and how to actually migrate if you decide to.
This case study is part of our comprehensive open source licensing wars resource, where we explore how vendor-controlled open source projects are turning to restrictive licences when cloud economics squeeze their business models. The HashiCorp-OpenTofu split mirrors the broader pattern reshaping infrastructure tooling.
On 10 August 2023, HashiCorp announced adoption of Business Source Licence 1.1 for all products. Terraform, Vault, Consul, Nomad—everything switched immediately. Existing versions stayed MPL 2.0 under perpetual licence, but going forward? BSL.
HashiCorp’s stated reason came down to revenue pressure from the cloud providers. AWS, Azure, and GCP were allegedly repackaging HashiCorp tools into managed services without contributing back. HashiCorp poured resources into developing Terraform yet struggled to monetise it profitably. As a publicly traded company with shareholder obligations, HashiCorp needed to address market dynamics.
BSL 1.1 sits in the middle ground between open source and proprietary. You can view, use, modify, and copy the code for non-production purposes, but commercial production use is restricted. You can’t offer Terraform as a competitive service, use it in products that compete with HashiCorp, or repackage and redistribute it commercially. The code’s visible but usage is restricted—that’s source-available, not open-source.
The licence includes a time-delayed conversion mechanism. BSL automatically converts to GPL-compatible open source within four years after release. Software licenced under BSL on 1 January 2025 must convert to GPL-compatible by 1 January 2029.
HashiCorp wasn’t alone in this. Redis, MongoDB, Elasticsearch, CockroachDB—they all went source-available. AWS alone controls 32% of the cloud market and can outspend infrastructure startups on managed services all day long. The challenge facing open-source infrastructure companies is explored in depth in our analysis of cloud provider economics and open source sustainability: how do you capture value when hyperscale cloud providers can commoditise your work overnight?
For most Terraform users, the immediate impact was minimal. If you’re just deploying infrastructure—not building a competitive product—BSL doesn’t restrict you. But long-term concerns started bubbling up. Vendor lock-in risk, potential future restrictions, loss of community control. Trust eroded. Single-vendor control means future licence changes are always on the table.
Within weeks of the BSL announcement, the community organised a response. A coalition of 140+ companies and contributors formed around returning to MPL 2.0 and ensuring permanent open-source status. The fork decision came together in September 2023.
They called it OpenTofu. Five principles drove it: truly open-source under MPL 2.0, community-driven development with no single vendor calling the shots, Linux Foundation neutral stewardship, backwards compatibility as a drop-in replacement, and a fair contribution model.
OpenTofu operates under MPL 2.0 open-source licence, enabling community-driven development. The Linux Foundation adopted the project in September 2023. Under Cloud Native Computing Foundation stewardship, OpenTofu became a CNCF project with formal governance protections.
The Technical Steering Committee structure matters here. The TSC requires multi-company representation with no single vendor controlling more than 50% of seats. Contributors elect members annually. The TSC controls the technical roadmap, feature priorities, and architecture. All meetings are public. Consensus-based governance prevents unilateral changes.
This governance structure means OpenTofu cannot unilaterally change licence like HashiCorp did. The Linux Foundation owns the copyright—not a single vendor. The OpenTofu trademark prevents hostile takeover.
Major infrastructure platforms backed the fork. Gruntwork, Spacelift, env0, Scalr, and Harness all pledged support. Oracle Cloud Infrastructure joined. These major IaC tooling vendors betting on OpenTofu’s viability sent a market signal.
OpenTofu began mirroring Terraform closely as a drop-in replacement. First stable release came in January 2024—OpenTofu 1.6.0. Monthly releases followed with 100+ contributors joining in six months.
Official documentation covers all use cases. Provider registry compatibility means 3,000+ providers work with both tools. Migration guides provide step-by-step walkthroughs. The governance structure demonstrates the Linux Foundation model that prevents vendor control—a contrast to the single-vendor control that triggered the HashiCorp licence crisis.
With both tools under active development in 2026, teams evaluating the fork need to understand what each brings to the table. OpenTofu maintains 100% command compatibility with Terraform. Commands like terraform init, terraform plan, and terraform apply work identically when you swap in the opentofu binary. HCL configuration language syntax is identical—no rewrites needed. Provider interface is shared, so 3,000+ providers work with both.
Where they differ matters for specific use cases.
Licencing: Terraform uses BSL 1.1 source-available. OpenTofu uses MPL 2.0 open-source. OpenTofu wins on licence freedom.
Governance: Terraform is HashiCorp/IBM-controlled. OpenTofu is Linux Foundation/CNCF governed. OpenTofu wins on neutral governance.
State Encryption: Terraform requires Vault or encrypted S3. OpenTofu provides native end-to-end encryption. This was a feature the Terraform community requested for the last five years but never received. OpenTofu wins here.
State files contain sensitive data—API keys, database passwords, infrastructure topology. Platform teams managing multi-tenant environments or operating under strict compliance regimes like HIPAA, SOC 2, or PCI-DSS need encryption by default. OpenTofu’s built-in encryption reduces the security surface area and simplifies compliance. No Vault dependency required.
Provider Ecosystem: Both share 3,000+ official providers. Tie.
Commercial Support: Terraform offers HashiCorp enterprise support. OpenTofu offers multiple vendor options through Spacelift, env0, and Gruntwork. Tie.
Early Variable Evaluation: Terraform doesn’t have it. OpenTofu 1.8 enables variables and locals within terraform blocks and module sources. OpenTofu wins.
Documentation: Terraform has 10+ years of maturity. OpenTofu is growing rapidly after 2+ years. Terraform wins on depth.
Enterprise Features: Terraform Cloud provides SaaS including Sentinel policy-as-code, remote operations, state management, team collaboration, and cost estimation. OpenTofu relies on self-hosted plus third-party platforms. Context-dependent.
Community Size: Terraform is larger with a 10-year head start. OpenTofu is growing with broad industry backing. Terraform wins for now.
OpenTofu’s faster release cycle shows in monthly feature releases versus Terraform’s quarterly major releases. Under IBM, Terraform’s cadence may slow further.
The long-term compatibility question looms. Today in 2026, feature parity sits at 95%+ with shared providers. But looking at 2027-2028, you can see inevitable divergence as the tools pursue different priorities. OpenTofu can read Terraform state files directly but the reverse isn’t guaranteed. Once you migrate to OpenTofu and use OpenTofu-specific features like native encryption, rolling back becomes complex.
IBM completed the acquisition of HashiCorp on 27 February 2025 for $35 per share in cash, representing $6.4 billion enterprise value. The acquisition rationale centres on strengthening IBM’s hybrid cloud portfolio and integrating with Red Hat Ansible. Nearly 75% of enterprises operate hybrid cloud environments—IBM’s target market.
HashiCorp’s infrastructure automation tools—particularly Terraform and Vault—will integrate with IBM’s existing portfolio. These products complement Red Hat’s Ansible Automation Platform. By 2028, generative AI is projected to drive creation of one billion cloud-native applications, intensifying demand for infrastructure automation at scale.
The acquisition announcement generated a sceptical reception in developer communities.
Three possible strategies emerge.
Strategy 1: Restore MPL 2.0. Red Hat maintained its open-source ethos after IBM’s 2019 acquisition. Likelihood: 30%. This would require admitting BSL was a mistake. Impact: OpenTofu becomes redundant as the community reunites.
Strategy 2: Maintain BSL. IBM’s software business still uses commercial licencing. Likelihood: 50%. This is conservative and low-risk. Impact: OpenTofu continues growing as the open-source alternative.
Strategy 3: Hybrid Model. Dual licencing following MySQL‘s pre-Oracle GPL/commercial model. Likelihood: 20%. This is complex to execute. Impact: market fragments further.
Those probability estimates reflect current market signals, IBM’s historical acquisition patterns, and OpenTofu’s competitive momentum as of February 2026.
IBM’s acquisition of Red Hat in 2019 shows what IBM got right and where they stumbled.
What IBM got right: Red Hat maintains independent branding and culture. RHEL is still based on CentOS Stream. Fedora and Ansible communities remain healthy. IBM allowed Red Hat’s independent culture to flourish.
Where IBM stumbled: the 2020 CentOS Linux discontinuation angered the community, leading to AlmaLinux and Rocky Linux forks. Mixed signals emerged about whether IBM prioritises commercial interests despite open-source rhetoric.
Applying Red Hat lessons to HashiCorp gives us three scenarios. Best case: IBM treats HashiCorp like Red Hat with independent operation and eventual licence restoration. Worst case: IBM treats it like Watson acquisitions with tight integration and commercial focus. Realistic case: hybrid approach maintaining BSL short-term while evaluating based on OpenTofu threat.
IBM has 16 open engineering requisitions for Vault and Terraform teams, indicating they’re planning to increase development velocity.
Watch for these signals. Signs IBM might restore MPL 2.0: public statements emphasising open-source values, Jim Whitehurst involvement in HashiCorp integration, community outreach and governance discussions. Signs IBM will maintain BSL: silence on licencing questions, focus on Terraform Enterprise commercial features, integration with IBM’s commercial stack.
Don’t wait for IBM’s entire evaluation process. They may take 12-18 months to clarify strategy. Test OpenTofu in parallel to minimise risk while gaining optionality. Do scenario planning that prepares for multiple outcomes.
Beyond technical features, the governance model determines who controls your infrastructure’s future. OpenTofu operates under Linux Foundation governance with a Technical Steering Committee drawn from multiple organisations. Decisions happen in public. HashiCorp controls Terraform’s roadmap, prioritisation, and contribution acceptance.
The Technical Steering Committee has 9-11 elected members from contributing organisations. No single company controls more than 50% of seats. Contributors vote annually. The TSC controls technical roadmap and architecture. All meetings and GitHub discussions are public.
The Linux Foundation provides neutral hosting, infrastructure, legal framework, and brand protection. Copyright is owned by the foundation, not a vendor. Trademark protection prevents hostile takeover.
For you as a user, this means licence stability. OpenTofu’s governance provides the structural protections outlined in our comprehensive guide to open source governance models. The community has veto power where major changes require consensus, not top-down decree. Contributor equality means all contributions are judged on merit, not company affiliation.
HashiCorp’s corporate control model works differently. The CEO and Board set strategic direction. Shareholder primacy means decisions optimise for IBM investor returns. Top-down roadmap prioritises commercial features. Community feedback is advisory only, not binding.
Historical precedent speaks volumes. The BSL change was announced without community consultation. Terraform Cloud focus prioritises commercial features over open-source core.
For you, this creates licence uncertainty. IBM can change terms at will. Commercial prioritisation means features that drive Terraform Cloud revenue come first.
OpenTofu guarantees licence stability by charter. Terraform’s licence serves business needs. OpenTofu provides binding community voting. Terraform offers advisory feedback only. OpenTofu decisions require consensus. Terraform uses executive decree. OpenTofu guarantees vendor neutrality. Terraform depends on IBM philosophy. OpenTofu offers multi-vendor support. Terraform provides single-vendor accountability.
Why does governance matter? IaC codebases live 5-10+ years. Migration costs are expensive. Licence changes can block operations.
Open-source provides insurance. MPL 2.0 allows community fork if OpenTofu pivots. Multiple support vendors prevent single vendor lock-in. Ecosystem diversity ensures sustainability.
For platform teams burned by the licence change, structural guarantee matters more than any technical feature.
If you’re choosing OpenTofu based on governance or licencing concerns, understanding the migration path reduces perceived risk. Command-line compatibility means commands work identically between tools. For most codebases, migration centres on replacing the Terraform binary with OpenTofu, updating CI/CD pipelines, migrating state files, and verifying provider compatibility.
Organisational Planning
Team preparation matters more than technical complexity. Update documentation before migration—rewrite runbooks and guides before cutover. Run overview sessions covering OpenTofu’s compatibility and governance. Plan two weeks for technical migration plus two weeks for adoption.
Risk management requires rollback procedures. Maintain Terraform binaries and state backups for 30 days post-migration so you can roll back cleanly if needed.
Technical Complexity Assessment
Project size determines timeline expectations. Small projects under 10 resources take 1-2 days. Medium projects with 10-100 resources take 1 week. Large projects with 100+ resources and multiple environments take 2-4 weeks. Enterprise with 1,000+ resources takes 4-8 weeks.
State backend considerations vary by platform. S3, Azure Blob Storage, and GCS are fully compatible. Terraform Cloud is not compatible because it’s proprietary—you’ll need to migrate to an alternative backend. Migrating from Terraform Cloud requires exporting state and configuring a new backend like S3.
Provider compatibility checking happens in staging environments first. Most providers work identically since both tools use the same provider protocol. The OpenTofu registry is compatible with Terraform’s provider ecosystem.
Migration Timing
Pilot on non-critical infrastructure—test OpenTofu on development environments before production. Run OpenTofu plan on staging and verify no unexpected changes. Once you use OpenTofu-specific features like native encryption, rolling back becomes complex. Treat migration as a one-way door.
For comprehensive migration decision frameworks and risk assessment methodologies, see our detailed migration and risk assessment playbook for CTOs. Official OpenTofu migration documentation provides detailed technical guidance.
Having evaluated the technical and governance landscape, the remaining question is IBM’s next move. The 12-18 month outlook breaks into four scenarios.
Best Case: IBM Restores Open Source (20% probability). Trigger: IBM leadership recognises BSL damaged community trust. Action: announce MPL 2.0 restoration for Terraform. Impact on OpenTofu: reduced urgency but continued existence as insurance policy. Your response: you can safely return to Terraform but maintain OpenTofu testing cadence.
Base Case: Status Quo Continues (50% probability). Trigger: IBM takes “wait and see” approach. Action: maintain BSL and focus on Terraform Enterprise revenue. Impact on OpenTofu: continued growth as open-source alternative. Your response: migration to OpenTofu becomes increasingly attractive.
Worst Case: Increased Restrictions (20% probability). Trigger: IBM tightens BSL interpretation. Action: clarify “competitive use” definition and restrict more use cases. Impact on OpenTofu: accelerated migration. Your response: immediate migration planning becomes necessary.
Wild Card: IBM Discontinues Terraform (10% probability). Trigger: IBM decides to sunset Terraform in favour of Ansible-based IaC. Action: announce deprecation timeline. Impact on OpenTofu: becomes de facto standard. Your response: OpenTofu migration becomes mandatory.
Migrate to OpenTofu now if you value open-source licence stability over vendor relationship, your organisation has OSPO requirements, native state encryption solves compliance challenges, you’re concerned about IBM’s long-term Terraform commitment, you have 2-4 weeks for a migration project, or multi-vendor support options matter to you.
Stay with Terraform if you have an existing HashiCorp Enterprise Agreement with favourable terms, deep integration with Vault, Consul, and Nomad is required, Terraform Cloud features like Sentinel and remote operations are needed, risk tolerance for vendor lock-in is high, your team prefers mature documentation and larger community, or waiting for IBM strategic clarity is acceptable.
The hybrid approach is recommended. Run OpenTofu in development and staging. Maintain Terraform in production short-term. Test feature parity quarterly. Build capability with both tools. Retain flexibility to switch based on IBM’s actions.
Q2-Q3 2026 represents a key period. Watch IBM Developer Conference keynotes on HashiCorp integration. Monitor Red Hat Summit discussions on Ansible plus Terraform or OpenTofu. Pay attention to HashiConf 2026 licencing announcements.
Market signals matter. OpenTofu adoption metrics show growth through GitHub stars, downloads, and corporate backing. Terraform Cloud revenue indicates whether BSL works. IBM executive statements signal direction.
The long-term outlook for 2027-2030 suggests Terraform and OpenTofu will coexist as stable alternatives. Provider ecosystem remains compatible. Enterprise market splits: IBM and HashiCorp customers stay with Terraform, open-source advocates choose OpenTofu. Both tools remain viable with choice driven by governance philosophy versus vendor relationship.
Don’t treat this as a binary choice. Build organisational capability with both tools. The cost of migration proficiency is lower than the risk of backing the wrong horse. In infrastructure automation, optionality is worth the investment.
The IBM acquisition creates uncertainty in IaC tooling. Treat 2026-2027 as an evaluation period. Test OpenTofu seriously while monitoring IBM’s strategic signals. The “wait and see” approach only makes sense if you’re actively preparing migration capability in parallel.
The IBM wild card means you should build optionality. Test OpenTofu in non-production while monitoring IBM’s 2026 strategic announcements. Infrastructure decisions require 5-10 year timelines.
Start OpenTofu testing in your development environment this quarter. Document the migration process. Attend HashiConf 2026 to hear IBM’s vision. Make an informed decision based on governance philosophy, technical requirements, and risk tolerance—not fear or inertia.
For a comprehensive overview of how the HashiCorp case fits into the broader licensing transformation, explore our complete guide to open source licensing wars, where we examine all the major cases and provide strategic frameworks for navigating this new reality.
The Redis Valkey Fork – How Enterprises Rapidly Migrated After the SSPL License ChangeIn March 2024, Redis dropped the BSD licence and switched to SSPL and RSALv2. Within months, enterprises were moving in serious numbers. Aiven shifted thousands of Redis servers to Valkey. MaiCoin completed a blue/green migration of their cryptocurrency exchange in weeks.
Legal departments started flagging compliance risks. Finance teams saw vendor lock-in issues—but also potential cost savings of 20-33% by switching to managed Valkey services.
The Linux Foundation launched Valkey in April 2024, with backing from AWS, Google Cloud, and Oracle. Within weeks, the fork had established itself as a real alternative—150+ contributors, 1000+ commits, and production-ready releases that maintained full Redis protocol compatibility.
This article is part of our comprehensive guide on open source licensing wars, where we examine how companies like Redis and HashiCorp are responding to cloud provider competition through restrictive licensing—and how the open source community is fighting back through governance and forks.
This article digs into why Redis Inc changed its licensing, how the community responded, what the performance benchmarks show, and what migration decisions you need to make.
Jump to: License Change Motivations | Performance Comparison | Migration Checklist
Redis Inc changed from BSD to SSPL and RSALv2 in March 2024 because cloud providers like AWS ElastiCache were making money from Redis without contributing anything back. The company had a “1% conversion problem”—only 1% of Redis users ever became paying Redis Enterprise customers, while AWS captured all the infrastructure revenue. The licensing change was designed to stop cloud providers from offering Redis as a managed service without paying up.
Understanding the full context of open source license types helps clarify why Redis Inc viewed SSPL as their best option—and why the community saw it as a betrayal of open source principles.
AWS ElastiCache was generating hundreds of millions in revenue while Redis Inc struggled to make money. Out of millions of Redis users, only 1% converted to Redis Enterprise customers.
The economics weren’t working. Cloud providers built thriving businesses on BSD-licensed Redis without needing to licence anything from Redis Inc. The company needed a different approach.
This dynamic represents the core of the cloud provider freeloading debate, where maintainers argue cloud providers exploit open source projects while cloud providers counter that they provide infrastructure value and customer access.
On March 20, 2024, Redis Inc announced an immediate licence change. Redis would now use dual licensing: SSPL for core Redis and RSALv2 for modules like Redis Stack, RedisJSON, RediSearch, and RedisBloom.
The target was explicit—stop cloud providers from offering “Redis as a Service” without licensing fees. Redis Inc said self-hosted Redis users weren’t affected, only “service providers” were in the firing line.
But a 15-year BSD licence doesn’t just disappear without breaking trust.
SSPL isn’t OSI-approved, which meant Redis wasn’t truly open source anymore by the standard definition. You don’t revoke a 15-year BSD licence without consequences.
AWS, Google Cloud, and other providers started evaluating fork possibilities within days. Community discussions showed opposition to what many saw as a licensing “bait and switch.”
Enterprise legal departments flagged compliance risk. Procurement froze Redis upgrades while lawyers reviewed the new terms.
The Server Side Public Licence (SSPL) requires anyone offering software as a service to open source their entire infrastructure stack—including proprietary tools, monitoring systems, and orchestration code. The Open Source Initiative rejected it as not meeting the Open Source Definition, making SSPL-licensed software “source available” rather than truly open source. Cloud providers see SSPL as specifically designed to make managed services commercially impossible unless they pay licensing fees.
For a deeper exploration of how SSPL differs from traditional open source licenses like BSD, Apache, and GPL, see our complete guide to open source licenses.
MongoDB created SSPL in October 2018. Section 13 requires service providers to release “all programs that you use to make the Program available as a service.” That includes load balancers, monitoring tools, orchestration systems, backup utilities, and networking configurations.
The practical impact? It would require AWS to open source ElastiCache infrastructure. That’s commercially impossible for cloud providers.
The compliance complexity is serious. The ambiguous language about what constitutes “making available as a service” creates legal uncertainty. Does providing Redis to internal teams count?
In 2018, MongoDB submitted SSPL to the Open Source Initiative for approval. The OSI rejected it. Bruce Perens explained: “Section 13 is very obviously intended to be a restriction against the field of endeavour of offering the software as a service”, violating OSD Principle #6.
SSPL adds restrictions beyond source code availability. That makes it “source available” not open source by the OSI definition. This distinction matters—open source means freedom to use software for any purpose. SSPL restricts that freedom specifically to extract revenue from cloud providers.
Enterprises now need legal review before upgrading Redis. Self-hosted Redis is theoretically unaffected, but the uncertainty about what “service” means creates risk.
Many enterprises chose migration to BSD-licensed Valkey rather than ongoing legal review. The risk mitigation strategy was simple—avoid SSPL entirely.
The Linux Foundation announced Valkey on April 1, 2024, as a BSD-licensed fork of Redis 7.2, with backing from AWS, Google Cloud, and Oracle. The project established neutral governance through a Technical Steering Committee, preventing single-vendor control while maintaining full Redis protocol compatibility. Within weeks, Valkey achieved 50+ contributing companies, 150+ individual contributors, and 1000+ commits—rapid community mobilisation.
Valkey’s governance structure exemplifies the community-governed open source model that prevents single-vendor control and ensures long-term project sustainability—a critical factor in fork viability.
March 20, 2024: Redis announced the licensing change. Within days, AWS, Google Cloud, and Oracle coordinated fork strategy. By April 1, 2024, the Linux Foundation announced Valkey.
The first Valkey release (7.2.5) arrived mid-April, achieving protocol parity with Redis. By May 2024, cloud providers announced managed Valkey support roadmaps. In June 2024, Valkey 7.2.6 shipped with AWS’s Async I/O Threading contribution, enabling 3x throughput improvement.
No single company controls Valkey direction. The Technical Steering Committee ensures balanced decision-making with multi-company representation.
Madelyn Olson, Valkey project lead, emphasised: “All the meetings are public. If we ever see people trying to host private meetings, we will force them to cancel them and make them public.” This transparency was a direct response to Redis Inc’s opaque governance.
The Linux Foundation owns the “Valkey” trademark, preventing hijacking.
It’s a drop-in replacement for Redis 7.2—no code changes required. Performance benchmarks show equivalent or better performance versus Redis. Managed services from AWS, Google, Azure, and Oracle remove operational burden.
The BSD licence provides legal clarity versus SSPL ambiguity. And cloud provider support matters—if AWS, Google, and Oracle are backing Valkey, enterprises can trust it’s not disappearing.
AWS ElastiCache, Google Cloud Memorystore, Microsoft Azure Cache, and Oracle Cloud Infrastructure all provide managed Valkey support. AWS contributed major performance improvements including Async I/O Threading (3x throughput gain) and offers Valkey in ElastiCache with 20% cost savings versus Redis.
Valkey became available in ElastiCache in June 2024 across all major AWS regions. AWS contributed the Async I/O Threading model that delivered 3x throughput improvement. ElastiCache Valkey pricing runs 20% lower than equivalent Redis instances.
Google Cloud announced Valkey support in Memorystore in May 2024, with general availability in Q3 2024. Google positioned Valkey as the standard Redis-compatible option across their multi-cloud strategy.
AWS ElastiCache cache.m6g.large instances: $0.034/hr for Redis, $0.027/hr for Valkey—20% savings. Google Memorystore: $0.054/GB-hour for Redis, $0.043/GB-hour for Valkey—20% reduction.
For enterprises running large Redis deployments, 20% savings represents serious budget impact.
Independent benchmarks by Momento show Valkey 7.2.6 delivers 37% higher SET throughput and 16% higher GET throughput compared to Redis 8.0, with 30% better tail latency (p99). AWS’s Async I/O Threading contribution to Valkey enables nearly 1 million requests per second on 8-vCPU instances—3x improvement over the single-threaded model.
Momento’s engineering team ran benchmarks in July 2024 using isolated AWS c7gn.2xlarge instances (8 vCPU, 16 GB RAM) with memtier_benchmark tool.
Results showed Valkey at 673k ops/sec for SET versus Redis at 491k ops/sec. GET operations: Valkey achieved 982k ops/sec versus Redis at 847k ops/sec—16% improvement.
Tail latency matters for user experience. Valkey’s p99 latency was 0.7ms versus Redis’s 1.0ms—30% better.
The Async I/O Threading architecture separates network I/O from command processing. Network I/O gets handled by dedicated threads while command execution runs on separate cores.
Without I/O threads, Valkey showed 239K RPS on SETs. With 6 threads: 678K RPS. P99 latencies dropped from 1.68ms to 0.93ms despite handling nearly 3x the throughput.
This feature is available in Valkey 7.2.6 and later, but not in Redis 8.0. That’s a competitive advantage for Valkey.
MaiCoin validated that Valkey met their latency requirements for their cryptocurrency exchange. Aiven ran thousands of servers in production without performance degradation. AWS and Google Cloud offer the same performance guarantees for Valkey as Redis in their managed services.
Aiven migrated 15,000 Redis servers to Valkey (11,000 automated, 4,000 user-initiated), while MaiCoin completed blue/green migration of its cryptocurrency exchange in weeks. The rapid adoption was enabled by drop-in Redis protocol compatibility, managed cloud services, and migration tools minimising downtime.
Aiven completed the largest documented Redis to Valkey migration—15,000 servers over three months from May to August 2024. The approach split between 11,000 servers using automated migration tooling and 4,000 through user-initiated opt-in.
The migration achieved zero-downtime using replication-based migration with REPLICAOF. No performance degradation occurred. Aiven passed 20% cost savings to customers on Valkey instances.
MaiCoin runs a cryptocurrency exchange requiring 24/7 uptime. Their migration strategy used parallel Redis and Valkey environments with gradual traffic cutover. Testing took 2 weeks with synthetic production traffic. Cutover was percentage-based over 48 hours.
Results: zero customer-facing downtime, latency requirements maintained.
If you’re evaluating a migration, our migration and risk assessment playbook provides a systematic framework for assessing immediate risk, deciding whether to migrate or stay, and executing migrations without breaking production systems.
Drop-in compatibility meant no code changes required. Cloud provider support through ElastiCache and Memorystore provided managed migration paths. Legal urgency from SSPL compliance risk motivated quick migration.
Migration tools like RedisShake reduced technical barriers. Performance benchmarks confirmed no performance penalty. And 20% cloud cost savings provided CFO-level motivation.
Your Redis deployment is affected by the SSPL licence change if you run Redis 7.4 or later and offer it as a service to external customers, whether free or paid. Self-hosted Redis for internal company use theoretically remains unaffected, but the legal ambiguity about “offering as a service” creates compliance risk.
For a comprehensive decision framework beyond just Redis, see our migration and risk assessment playbook covering both Redis to Valkey and Terraform to OpenTofu evaluations.
Step 1: Check Your Redis Version
Redis 7.2.x and earlier remain BSD-licensed—no SSPL restrictions apply. Redis 7.4.x and later use SSPL/RSALv2 licensing.
Staying on Redis 7.2.x avoids SSPL but misses security updates post-March 2024. You’ll need to self-patch vulnerabilities.
Step 2: Identify Your Deployment Model
Self-hosted (internal): Running Redis on your own infrastructure for internal applications. Managed service (customer-facing): Offering Redis as a service to external customers. SaaS component: Redis powers your SaaS product used by external customers.
Step 3: Assess “Offering as a Service” Risk
Clear SSPL violation: Offering managed Redis to external customers makes you a competitor to Redis Inc. Grey areas include internal developer platforms providing Redis to internal teams, SaaS products using Redis as a backend component, and multi-tenant applications with Redis shared across customer workloads.
Step 4: Evaluate Your Options
Migrate to Valkey if your legal department flags SSPL compliance risk, you value open source guarantees, you want 20% cloud cost savings, you prefer community-governed projects, or you anticipate future Redis licensing changes.
Consider staying on Redis if you have a Redis Enterprise relationship with Redis Inc, your deployment clearly qualifies as internal use only, you need specific Redis Enterprise features not in Valkey, or migration effort exceeds compliance risk.
AWS ElastiCache Redis: AWS handles compliance; you’re not “offering service,” you’re consuming it. Google Memorystore Redis: Same logic—Google’s licence relationship covers your usage.
Managed service users generally aren’t affected. Providers handle licensing relationships.
Valkey’s roadmap includes continuing Redis 7.x feature parity, implementing community-driven enhancements like improved Async I/O, and maintaining protocol compatibility while diverging on proprietary Redis Enterprise features. The project has demonstrated long-term viability with 150+ contributors, 1000+ commits in first six months, 5M+ Docker pulls, and sustained backing from AWS, Google Cloud, and Oracle.
The project’s governance structure and multi-company backing exemplify the principles we explore in our guide to open source governance models—showing how proper governance prevents vendor control and ensures long-term sustainability.
150+ individual contributors from diverse organisations contributed in the first six months. 1000+ commits since April 2024 show active development. 5M+ Valkey Docker image downloads indicate adoption. 19.8K GitHub stars show community interest.
Maintain Redis 7.x protocol compatibility. Continue Async I/O Threading optimisation, explore DPDK integration for performance improvements. Implement frequently requested features Redis Inc deprioritised.
The divergence strategy maintains protocol compatibility but doesn’t force feature parity with proprietary Redis Enterprise.
The Linux Foundation model provides proven governance structure. Technical Steering Committee ensures multi-company decision-making prevents single-vendor capture. Linux Foundation owns the Valkey trademark.
No single company dominates contributions. AWS contributes approximately 30%, other organisations 70%. That distribution prevents single-vendor control.
AWS shows long-term commitment to Valkey in ElastiCache. Google Cloud positions Memorystore Valkey as standard Redis-compatible offering. Microsoft Azure added Valkey support in 2024.
No cloud provider maintains dual Redis/Valkey support, suggesting Valkey as the primary path forward.
Fragmentation risk if the community splits on direction is mitigated by governance structure. If Redis Inc reverted to BSD, some enterprises might return—unlikely given AGPLv3 Redis 8.0.
Risk assessment: Low. Linux Foundation governance and multi-company backing provide stability.
For a complete understanding of the broader open source licensing crisis, including how this pattern emerged from MongoDB to Redis and what might come next, explore our comprehensive content hub on infrastructure licensing wars.
Can I use Redis 7.2 indefinitely without migrating?
Yes, Redis 7.2.x remains BSD-licensed and can be used indefinitely. However, Redis Inc stopped providing security updates for Redis 7.2 after March 2024, so you’ll need to self-patch vulnerabilities or migrate to Valkey (which continues Redis 7.2.x security support).
Will Valkey support Redis Cluster?
Yes, Valkey fully supports Redis Cluster mode for horizontal scaling across multiple nodes. Cluster functionality is part of Redis 7.2 protocol compatibility that Valkey maintains.
What Redis Enterprise features are missing from Valkey?
Valkey doesn’t include proprietary Redis Enterprise features like Active-Active Geo-Distribution, Redis on Flash (RoF), or Auto-Tiering. However, cloud providers offer equivalent features through their managed services (for example, AWS Global Datastore for ElastiCache).
How do I join the Valkey community?
Join Valkey development through GitHub (github.com/valkey-io/valkey), participate in monthly community calls, join the #valkey channel on CNCF Slack, or subscribe to the valkey-dev mailing list.
Does Valkey work with existing Redis client libraries?
Yes, all Redis client libraries (redis-py, node-redis, Jedis, StackExchange.Redis, etc.) work with Valkey without modification due to full Redis protocol compatibility. Simply change the connection string to point to Valkey endpoint.
Is Valkey slower than Redis because it’s a fork?
No, independent benchmarks show Valkey performs 16-37% faster than Redis 8.0 on key operations. Forks can outperform originals when the community contributes optimisations like AWS’s Async I/O Threading (3x throughput improvement).
What’s the difference between Valkey and KeyDB?
KeyDB is a separate Redis fork (created 2019) focused on multithreading. Valkey is newer (2024), has broader ecosystem backing (Linux Foundation, AWS, Google), and aims for protocol compatibility while adding community-driven features. Both are BSD-licensed Redis alternatives.
Does Valkey support Redis modules like RedisJSON?
Valkey supports Redis modules that are open source. RedisJSON, RediSearch, and other modules changed to RSALv2 (proprietary) and aren’t compatible with Valkey. The community is developing open source alternatives for popular module functionality.
How much does it cost to migrate to Valkey?
Migration cost depends on approach. Replication-based migration costs minimal downtime (seconds to minutes). Managed service migrations (ElastiCache, Memorystore) often have zero migration cost and offer 20% ongoing savings. Self-managed migrations require engineering time for testing and execution.
Understanding Open Source Licenses – From Permissive BSD to Restrictive Business Source License and SSPLYou’ve probably seen “open source” stamped on a GitHub repository and assumed you could use the code however you wanted. That’s not always true anymore.
Major infrastructure vendors like HashiCorp, MongoDB, Redis, and Elasticsearch have shifted to “source-available” licensing. The code is still visible, but new restrictions determine how you can use it in production. Terms like “competitive offering” and “production use” create legal grey areas.
Get it wrong and you might face expensive license negotiations or have to migrate off a dependency you’ve built your product around.
This article is part of our comprehensive guide on Open Source Licensing Wars – How HashiCorp, Redis and Cloud Economics Are Reshaping Infrastructure Software, where we explore the licensing crisis affecting infrastructure projects and what it means for CTOs making technology decisions.
This article walks you through the licensing spectrum—from permissive options like BSD and Apache 2.0, through copyleft licenses like GPL, to the newer source-available licenses like BSL and SSPL.
Open source doesn’t just mean you can see the code. The Open Source Initiative maintains the actual definition through ten specific criteria that any license must meet.
The OSI created the Open Source Definition by adapting the Debian Free Software Guidelines back in 1997. If a license doesn’t meet all ten criteria and get OSI approval, it’s not officially open source—no matter what the marketing materials claim.
Two criteria matter most when distinguishing between open source and source-available licenses. Criterion #6 says licenses can’t discriminate against fields of endeavour. You can’t prohibit someone from using the software for genetic research, running a business, or competing with you. Criterion #9 prevents licenses from imposing restrictions on other software that you use alongside the licensed program.
These two criteria are where Business Source License and SSPL fall short.
OSI approval has commercial consequences beyond branding rights. When MongoDB switched to SSPL, major Linux distributions dropped it from their repositories because it violated their open source policies. You can’t get into Debian or Red Hat Enterprise Linux repositories without an OSI-approved license. That distribution exclusion reduces adoption and creates installation friction for potential users.
The term “source-available” emerged to describe licenses where you can view the code but restrictions violate the Open Source Definition. If a license prohibits specific use cases—running competitors, cloud hosting, commercial production—it’s source-available, not open source. The code might be on GitHub with full visibility, but it doesn’t grant the freedoms that open source promises.
Permissive licenses give you considerable freedom. Use the code, modify it, distribute it commercially, combine it with proprietary software—all without copyleft obligations or source disclosure requirements.
BSD 3-clause sits near the permissive end of the spectrum. It requires you to keep the license notice in the code and not use the project’s name for endorsement without permission. That’s it. Mac OSX used BSD-licensed code because the license didn’t force Apple to open source their operating system.
Apache 2.0 adds specificity that lawyers appreciate. It includes an explicit patent grant protecting you from patent litigation by contributors. If someone contributes code to an Apache 2.0 project, they automatically grant you rights to any patents covering that code. The license also includes trademark protection. These additions make Apache 2.0 safer for commercial adoption than BSD or MIT, even though the core permission structure is similar.
Mozilla Public License implements what’s called weak copyleft or file-level copyleft. Modifications to MPL-licensed files must be shared, but you can combine MPL code with proprietary code as long as you keep them in separate files. This makes MPL easy to use in closed-source products while ensuring improvements to the MPL-licensed components get shared back.
All these permissive licenses are GPL-compatible and can be mixed in most projects. They maximise adoption velocity because they don’t place burdens on users.
So why did companies abandon them? Cloud providers monetised permissively-licensed infrastructure projects without contributing financially. AWS, Google Cloud, and Azure built managed services from projects like Redis, PostgreSQL, and MySQL. Azure Cache for Redis and Google Memorystore generate high-margin revenue that never flows back to the companies that built the databases. For maintainers trying to sustain commercial businesses around infrastructure projects, permissive licenses meant watching competitors profit from their work. This tension between cloud providers and open source companies is explored in depth in our open source licensing wars overview.
While permissive licenses proved vulnerable to cloud provider exploitation, source-available alternatives like the Business Source License took a different approach.
The Business Source License was created by MariaDB in 2016 and updated to BSL 1.1 in 2017. It’s a source-available license that sits between open source and proprietary software. You can view the code and use it for non-production purposes, but commercial production deployment is restricted.
The interesting bit is the “springing license” mechanism. BSL automatically converts to open source after a specified Change Date. That Change Date is set to a maximum of four years from each version’s release. Once that date arrives, the conversion is permanent—that version becomes truly open source with no production restrictions.
Each software version has its own Change Date. This creates a rolling window where recent versions remain BSL while older versions convert to open source. If you release Terraform 1.5 in January 2023 with a four-year Change Date and Apache 2.0 as the target license, it automatically becomes Apache 2.0 in January 2027. HashiCorp’s adoption of BSL for Terraform sparked the OpenTofu fork and raises questions about IBM’s future licensing direction.
The Change License must be GPL v2 or later, or a GPL-compatible license. This ensures the eventual open source version maintains genuine open source freedoms.
BSL includes an Additional Use Grant—a customisable clause where licensors specify exceptions to production restrictions. HashiCorp permits production use except for competitive offerings, though terms like “competitive offering” lack clear boundaries, making it difficult to know if your use case violates the license without getting legal review. MariaDB limits use to three server instances in production. Each implementation customises this clause differently based on what behaviours they want to restrict.
For non-production use, BSL is permissive. Development environments, testing, CI/CD pipelines, and internal tools are all freely permitted. The restrictions only apply to production deployment, and even then only to uses not covered by the Additional Use Grant.
The problem is definitional ambiguity. BSL doesn’t define “production use” precisely. Is an internal business-critical system production? What about a customer-facing feature that’s still in beta? Different licensors and users might interpret these terms differently, creating compliance uncertainty.
If your production use isn’t covered by the Additional Use Grant, you need to purchase a commercial license from the vendor, wait for the Change Date, or switch to an alternative tool.
MongoDB created the Server Side Public License in 2018, pioneering a pattern of restrictive licensing changes that other infrastructure vendors would follow. SSPL is based on AGPL v3 but expands disclosure requirements beyond traditional copyleft.
AGPL closes the “SaaS loophole” in standard GPL by requiring source disclosure when users access the software over a network.
SSPL goes further. If you offer SSPL software as a service, you must release source code for your entire infrastructure stack—management software, monitoring tools, APIs, orchestration, storage systems, and hosting automation. Everything you use to make that program available as a service.
In 2019, OSI declined to approve SSPL because it violates two core criteria. It discriminates against cloud hosting (criterion #6). It imposes obligations on unrelated software in your stack (criterion #9).
MongoDB designed SSPL to prevent AWS, Google Cloud, and Azure from offering MongoDB-as-a-service without contributing financially.
The targeting worked. AWS built DocumentDB rather than comply with SSPL. But Debian and Red Hat removed MongoDB from their distributions because it no longer met open source standards. When Redis adopted SSPL in 2024, it triggered an even more dramatic community response with the Valkey fork achieving 83% enterprise adoption within months.
For internal use, SSPL behaves like AGPL. You can fork it, modify it, run it at scale within your organisation without triggering disclosure obligations. The infrastructure stack requirement only applies when you “offer the functionality of the Program as a service to third parties.”
The definition of “offering as a service” creates compliance uncertainty. Does hosting for a single customer count? What about internal use at scale? These grey areas require legal interpretation.
License selection starts with your project goals. Broad adoption? Protection from cloud competition? Revenue? The answer determines which license makes sense.
For broad adoption, Apache 2.0 is the standard choice because the patent grant provides legal safety. Companies can integrate it into commercial products without worrying about patent litigation.
For sustainability with openness, copyleft licenses ensure derivative works stay open. AGPL works well for SaaS where you want to prevent proprietary forks. MPL provides file-level protection while allowing combination with proprietary code.
For competitive protection, BSL provides time-delayed conversion while restricting production competitors. Choose your Change Date—two years for fast-moving infrastructure, four years for stable platforms. Craft your Additional Use Grant carefully to reduce compliance uncertainty.
SSPL prevents cloud provider monetisation but triggers community fragmentation and distribution exclusion. The Redis experiment suggests AGPL might offer better balance.
If you lack legal teams, stick to OSI-approved licenses to reduce legal review burden and vendor lock-in risk.
When evaluating BSL or SSPL dependencies, plan for license changes. Have a fork readiness plan, budget for commercial licenses, or identify migration alternatives.
A simple framework: Start with “Do I need to prevent cloud provider competition?” If no, use Apache 2.0. If yes, try AGPL first. It’s OSI-approved, well-understood, and maintains distribution access. Only move to BSL if you need broader production restrictions. Only consider SSPL if you’re willing to accept community fork risk.
Permissive license compliance is straightforward. Keep license notices in the code. Include attribution in your documentation. SBOM tools automate this entirely.
Copyleft compliance requires sharing source code when you distribute or provide network access. GPL, LGPL, and AGPL have well-documented processes and clear case law.
BSL compliance gets murky. Interpreting “production use” and Additional Use Grant boundaries requires legal analysis. The licensor’s interpretation is binding, so you need clarity directly from them.
SSPL compliance centres on infrastructure stack boundaries. What counts as “programs you use to make the Program available as a service”? The definition varies by context, creating subjective determinations.
Your internal approval process needs to match license types. Permissive licenses can flow through automated approval. Copyleft requires checking disclosure requirements. Source-available demands manual legal review because terms vary by implementation.
Most SBOM tools can detect BSL and SSPL licenses but can’t automate compliance decisions. You’ll need human legal interpretation.
Violation consequences differ by license type. Permissive and copyleft violations typically result in injunctions requiring compliance. Source-available violations might void the license entirely, requiring retroactive commercial license purchase.
Redis adoption now requires legal review for each release because the license terms changed. Without in-house counsel, that friction can become blocking.
On the Change Date, that version automatically converts to the Change License specified in the BSL notice. The conversion is permanent and that version becomes truly open source with no production restrictions. Each version has its own Change Date, creating a rolling window.
Yes. Forking SSPL software for internal use is permitted without triggering disclosure obligations. SSPL’s infrastructure stack requirement only applies when you “offer the functionality of the Program as a service to third parties.” Internal use doesn’t constitute offering as a service. If you host the software for customers as a managed service—even a single customer—SSPL obligations kick in.
Debian and Red Hat removed MongoDB because it no longer met their open source standards. SSPL’s requirement to disclose infrastructure stack code discriminates against cloud hosting, violating Open Source Definition criterion #6. SSPL’s source-available status made it ineligible for inclusion.
Read the specific Additional Use Grant in the software’s LICENSE file. Each BSL implementation customises this clause differently. If your use case isn’t clearly permitted, purchase a commercial license, wait for the Change Date, or choose an alternative tool. When in doubt, contact the vendor—their interpretation is binding.
This framing is technically accurate but misleading. While BSL eventually converts to open source after the Change Date, during the BSL period it’s source-available, not open source. Production use restrictions violate Open Source Definition criterion #6. For commercial adopters, those 2-4 years of restrictions create vendor lock-in risk and compliance obligations identical to proprietary software.
AGPL requires sharing source code modifications when users access the software over a network. This closes the “SaaS loophole” in standard GPL. SSPL expands obligations dramatically. Beyond sharing modifications, SSPL requires releasing source code for “all programs you use to make the Program available as a service”—management software, monitoring tools, APIs, orchestration, storage, and hosting automation. SSPL effectively requires disclosing your entire infrastructure stack, which is why OSI rejected it.
Yes. License compatibility flows in one direction. Code under permissive licenses can be incorporated into projects using more restrictive licenses. The combined work’s license is determined by the most restrictive license present.
Source-available licenses allow unilateral license changes that can retroactively prohibit your use case. Under BSL, a vendor could tighten the Additional Use Grant in future versions, making upgrades require commercial licenses. Unlike true open source where you could fork and continue, source-available licenses restrict competitive forks, forcing you to pay or migrate.
Check the OSI’s official list at opensource.org/licenses. If a license isn’t on this list, it’s not officially open source regardless of marketing claims. Many source-available licenses deliberately mimic open source names—Business “Source” License, Server Side “Public” License—but lack OSI approval. Verify OSI approval rather than trusting terminology.
Most SBOM and dependency scanning tools like FOSSA, Snyk, WhiteSource, and Black Duck can detect BSL and SSPL licenses and flag them for manual review. However, unlike permissive and copyleft licenses, BSL and SSPL require human legal interpretation. Additional Use Grant clauses vary by implementation. “Production use” definitions are context-dependent. Tools can alert you but can’t automate compliance decisions.
Engage legal counsel when considering BSL or SSPL for your own project—Additional Use Grant drafting has commercial implications. Also consult when adopting BSL or SSPL dependencies in commercial products, receiving vendor license change notifications, facing M&A due diligence, operating in regulated industries, or planning to fork source-available projects. For permissive and copyleft licenses, compliance is typically straightforward without legal review.
The shift toward source-available licensing reflects infrastructure companies’ response to cloud providers monetising open source projects without contributing financially. While BSL and SSPL provide revenue protection, they fragment communities. Elasticsearch forked to OpenSearch. When Redis switched to SSPL in March 2024, the Linux Foundation announced Valkey, backed by AWS, Google, and others. The Redis experiment is instructive—moved to SSPL in March 2024, faced backlash, returned to AGPLv3 in 2025. This suggests AGPL might offer better balance between protection and openness.
For a comprehensive overview of how these licensing changes have impacted major infrastructure projects and what CTOs should watch for, see our complete open source licensing wars guide.
The IDE Wars: Cursor’s $29B Bet, AI Code Security Crisis, and the Battle for Developer ProductivityThe integrated development environment war has evolved beyond text editors. When Cursor raised $2.3 billion at a $29.3 billion valuation after just 24 months in operation, it signalled that the tools developers use to write code have become strategic battlegrounds worth tens of billions. GitHub Copilot, Windsurf, Claude Code, and a dozen other AI-powered IDEs are racing to redefine how software gets built.
But behind the venture capital excitement and productivity claims lies a more complex reality. Veracode research reveals 45% of AI-generated code contains security vulnerabilities. GitHub’s own data shows developers accept only 29% of suggested code, improving to just 34% after six months. The productivity gains promised by vendors don’t match what engineering leaders measure in production environments.
This guide cuts through the marketing to help you understand what’s happening in the AI IDE space, what risks you’re taking on, and how to make informed decisions. Whether evaluating tools for the first time or measuring ROI on existing investments, you’ll find frameworks for thinking clearly about autonomous coding assistance.
What you’ll find:
Each topic links to detailed cluster articles. Use this hub to orient yourself, then explore areas most relevant to your evaluation.
The AI IDE market has moved from experimental to mainstream faster than most enterprise software categories. Cursor’s 2025 Series D—$2.3 billion at a $29.3 billion valuation—came after surpassing $1 billion ARR in just 24 months, the fastest any SaaS company has reached that milestone. The company now serves millions of developers globally.
GitHub Copilot, launched in 2021, proved developers would pay for AI assistance. Competition in 2026 centres not on whether to offer AI assistance, but on which architecture genuinely improves how developers work.
Microsoft reports 30% of new code comes from AI assistance, with comparable adoption at Meta and Google. This is standard infrastructure now. The strategic question is no longer “should we adopt?” but “which approach fits our security posture and long-term strategy?”
Tool selection affects security models, training requirements, and architectural decisions. When your IDE reads local files and pushes code to production, you’re making infrastructure decisions shaping your entire development organisation.
For a complete analysis of Cursor’s growth trajectory and what it reveals about the AI IDE market, see How Cursor Reached a $29 Billion Valuation and Fastest Ever $1 Billion ARR in 24 Months.
Veracode’s research analysing over 100 large language models across 80 coding tasks spanning four programming languages found only 55% of AI-generated code was secure. Even as models have dramatically improved at generating syntactically correct code, security performance has remained largely unchanged. Newer and larger models don’t generate significantly more secure code than their predecessors.
Vulnerability patterns vary: SQL injection sees 80% pass rates, but Cross-Site Scripting and Log Injection fail 86-88% of the time. Language-specific performance shows Python at 62% security pass rate, Java at just 29%.
Cloud Security Alliance research identifies four risk categories: insecure pattern replication from training data, security-blind optimisation when prompts lack specificity, missing security controls when prompts don’t mention them, and subtle logic errors that function correctly for single-role users but fail with multi-role scenarios.
Root causes trace to training data contamination and limited semantic understanding, producing tools that generate functional but unsafe code.
As AI usage scales, vulnerable code volume grows exponentially. AI-generated vulnerabilities often lack clear ownership, making remediation complex.
For detailed analysis of the vulnerability patterns and language-specific risks, read Why 45 Percent of AI Generated Code Contains Security Vulnerabilities.
Instead of abandoning AI code generation, treat it as untrusted input that requires verification. Your security model needs to account for the reality that coding assistants can read and edit code, access local files including .env files and secrets, and utilise external tools through Model Context Protocol integrations.
Embed automated scanning into development workflows. Static Application Security Testing (SAST) scans AI-generated code before deployment, Dynamic Application Security Testing (DAST) evaluates runtime vulnerabilities, and Software Composition Analysis (SCA) tracks dependencies AI tools introduce.
Enterprise security platforms address agent-centric attack surfaces through build-time instrumentation, runtime mediation, and MCP governance. Implementation typically starts in “Detect mode,” then transitions to “Prevent mode” with contextual guidance preserving developer workflow.
AI-powered remediation tools like Veracode Fix employ AI trained specifically for security remediation, showing 92% reduction in vulnerability detection time and 80%+ fix acceptance rates.
Establish AI governance with organisational guidelines for tool usage, security review requirements, and developer training on secure prompting. Maintain audit trails documenting AI usage for regulatory compliance and incident investigation.
For implementation guidance including MCP governance policies and ISO/IEC 42001 compliance frameworks, see How to Implement Security Scanning and Quality Controls for AI Generated Code.
When GitHub revealed that users initially accept only 29% of suggested code—improving to just 34% after six months despite substantial learning—it exposed a tension in the AI coding narrative. Vendors cite dramatic productivity gains while developers report mixed results and aggregate metrics show no corresponding explosion in software releases.
Analysis of release metrics across iOS, Android, web domains, and Steam shows no exponential growth correlating with AI tool adoption from 2022 to 2025. Yet 78% of developers report productivity gains, with 14% claiming “10x” improvements. How do we reconcile these numbers?
The answer lies in measurement methodology. Industry leaders cite inflated figures—Microsoft says AI is writing 20 to 30% of code, Google puts that number at 30%—but rigorous measurement reveals more modest gains. Real gains average 20-40% on specific tasks (debugging, test generation, documentation), 10-25% increases in pull request throughput, and 2-3 hours weekly time savings averaged across teams.
Real-world case studies show complexity. One enterprise job platform found heavy AI users merged nearly 5x more pull requests weekly, while a financial services firm documented 30% throughput increases. Top applications focus on debugging, refactoring, test generation, and documentation—not wholesale feature development.
Measurement challenges abound. Most engineering organisations lack productivity baselines—only about 5% currently use software engineering intelligence tools. Developers use multiple tools (Copilot in the IDE, ChatGPT in the browser), making comprehensive measurement difficult. Vendor statistics like GitHub’s 55% productivity increase come from controlled experiments that don’t necessarily translate to real-world scenarios with complex codebases.
For frameworks to establish baselines, measure correlations, and avoid common pitfalls, read The AI Code Productivity Paradox: 41 Percent Generated but Only 27 Percent Accepted.
Understanding agentic IDE architecture helps you evaluate vendor claims and assess security implications. Model Context Protocol (MCP) is the open-source standard connecting AI applications to external systems. Think of MCP as USB-C for AI applications—providing standardised connections to data sources, tools, and workflows.
Autonomous agent capabilities represent the next evolution. GitHub Copilot’s coding agent allows users to assign GitHub issues, which Copilot works on independently in the background. The agent handles low-to-medium complexity tasks in well-tested codebases, analysing code using retrieval augmented generation (RAG) and pushing changes as commits to draft pull requests with session logs showing its reasoning.
Security features include access limited to branches agents create, required review policies, internet restrictions, and manual approval requirements for workflow execution.
Future patterns include high-level task descriptions generating implementations, multi-agent delegation, automated pipeline validation, and humans providing vision while AI handles execution. Vendor technical choices—context windows, RAG strategies, checkpoint systems—affect what you can build, operational safety, and vendor lock-in risk.
For deep technical analysis of MCP architecture, context window strategies, and autonomous agent implementation patterns, see How Agentic IDEs Work: Model Context Protocol, Context Windows, and Autonomous Agents.
Subscription pricing is the smallest component of AI IDE total cost of ownership. The real expenses show up in training time, productivity variance, security remediation, tool sprawl management, and long-term technical debt from poorly understood AI-generated code.
Most engineering organisations haven’t established productivity baselines, making ROI calculation difficult.
Effective measurement tracks pull request collaboration patterns, cycle time, throughput, bug backlog trends, and the proportion of maintenance versus feature work. Implementation timelines typically span months: establish baselines (months 1-2), pilot rollout (months 3-4), measure correlations (months 5-6), then optimise monthly. Avoid prioritising vanity metrics, expecting immediate gains, or measuring before allowing 3-6 months for adoption maturity.
For detailed TCO calculation frameworks, pricing model comparisons, and calculator methodologies, see Calculating Total Cost of Ownership and Real ROI for AI Coding Tools.
The vendor landscape splits into two approaches: AI-augmented traditional IDEs versus agent-native platforms. GitHub Copilot works within VS Code, Visual Studio, JetBrains IDEs, and Neovim without requiring tool switches, prioritising speed and ecosystem integration.
Cursor takes the opposite approach, building an agent-native platform with proprietary models designed for autonomous operation. It excels at multi-file editing with project-wide context, but requires working in Cursor’s environment.
Copilot suits developers prioritising GitHub integration within existing IDEs. Cursor benefits those managing complex codebases requiring autonomous multi-file operations.
Competition centres on which approach genuinely improves how developers work. Vendor lock-in becomes a concern with proprietary models—Cursor’s custom models create switching dependencies. Enterprise requirements like security posture and compliance vary significantly. Onboarding ranges from hours (Copilot) to weeks (agent-native platforms).
For vendor comparisons including Windsurf and Claude Code positioning, feature matrices, and selection decision trees, read Enterprise AI IDE Selection: Comparing Cursor, GitHub Copilot, Windsurf, Claude Code and More.
Autonomous agents represent the most powerful and risky AI IDE capabilities. GitHub Copilot’s coding agent demonstrates the pattern: users assign GitHub issues which Copilot works on independently, requesting review once complete. Developers can request modifications that the agent implements automatically.
Background agent patterns enable development while humans focus elsewhere. Parallel agent orchestration allows teams to parallelise work—one agent handles frontend refactoring while another updates backend services.
The developer role evolves rather than disappears. The emerging model positions developers as “conductors”—defining objectives, reviewing output, and making architectural decisions—while agents handle implementation. Developers must learn to write effective AI specifications, understand where agent reasoning falters, and maintain code quality through review. Running multiple agents simultaneously accumulates token expenses rapidly, requiring thoughtful oversight.
Risk controls address several threat vectors. Checkpoint systems enable rollback, approval gates require manual review before high-risk operations, audit logs track agent decisions, and sandbox environments isolate operations from production.
Monitoring becomes important as autonomous operation increases. Session logs show agent reasoning, while metrics reveal success rates, retry patterns, and intervention requirements.
Cultural change often determines implementation success. Developers need training in recognising appropriate use cases, understanding limitations, and maintaining quality standards. Code review practices must adapt to evaluate AI-generated code without creating bottlenecks.
For platform-specific configuration guidance, checkpoint system implementation details, and approval gate patterns for Cursor, Windsurf, and Claude Code, see Implementing Background Agents, Multi-File Editing, and Approval Gates.
This guide provides orientation to the AI IDE landscape. Each cluster article below goes deep on specific decision points, implementation strategies, and measurement frameworks.
Market Analysis & Competitive Landscape
Security & Compliance
Productivity & Business Justification
Technical Architecture
Enterprise Selection & Implementation
The market won’t “mature” in the traditional sense—it’s evolving too rapidly. Approximately 85% of developers already use at least one AI tool in their workflow. The question isn’t whether to adopt but how to do so safely with proper security controls, measurement frameworks, and risk management. Start with pilots on non-critical codebases to build expertise while the space evolves. See Enterprise AI IDE Selection for evaluation frameworks.
The 45% vulnerability rate makes AI-generated code comparable to untrusted input—it requires verification, not blind trust. Embed SAST/DAST scanning directly into development workflows, implement MCP governance for external tool access, establish approval gates for high-risk operations, and train developers to include security requirements in AI prompts. The key is treating AI assistance as productivity amplification, not security replacement. Read How to Implement Security Scanning and Quality Controls for implementation guidance.
Realistic expectations based on rigorous measurement show 20-40% speed improvements on specific tasks (debugging, test generation, documentation), 10-25% increases in pull request throughput, and 2-3 hours weekly time savings averaged across teams. Avoid vendor claims of 10x improvements—these rarely materialise in production environments with complex codebases. The productivity paradox stems from low acceptance rates (27-34%) and context-switching overhead. See The AI Code Productivity Paradox for measurement frameworks.
GitHub Copilot suits organisations prioritising ecosystem integration, working within existing IDEs, and leveraging GitHub-centric workflows. Cursor benefits those managing complex codebases requiring multi-file editing and willing to adopt agent-native environments. Consider your security posture (on-premises versus cloud), existing tooling investments, developer workflow preferences, and tolerance for vendor lock-in with proprietary models. Both approaches are viable; alignment with your specific requirements determines which fits better. Compare in detail at Enterprise AI IDE Selection.
MCP is the open standard enabling AI applications to connect to external systems—data sources, tools, and workflows. It functions as “USB-C for AI applications,” providing interoperability across platforms. For enterprise evaluation, MCP matters because it affects vendor lock-in (proprietary versus standard integrations), security posture (what external systems your IDE can access), and future flexibility (ability to switch platforms or add capabilities). Understanding MCP architecture helps you assess vendor technical strategies and predict where the technology is headed. Learn the technical details at How Agentic IDEs Work.
ROI measurement requires three layers: adoption metrics (monthly/daily active users, tool diversity index), direct impact metrics (time savings, task acceleration, acceptance rates, PR throughput), and business impact (deployment quality, review cycle time, developer experience scores). Track pull request collaboration patterns to prevent knowledge silos, monitor bug backlog trends and production incident rates for quality impacts, and measure the proportion of maintenance versus feature work. Establish baselines before rollout, allow 3-6 months for adoption maturity, and avoid prioritising vanity metrics over business outcomes. See Calculating Total Cost of Ownership and Real ROI for frameworks.
Autonomous agents introduce risks in four areas: security (agents can access local files including secrets, call external services via MCP, and push code to repositories), code quality (autonomous changes may not meet standards without proper review), cost (running multiple agents simultaneously accumulates token expenses rapidly), and knowledge gaps (developers may struggle to understand or maintain AI-generated code). Mitigate through checkpoint systems enabling rollback, approval gates for high-risk operations, sandbox environments isolating agent operations, audit logging, and developer training on effective agent supervision. Implementation guidance at Implementing Background Agents, Multi-File Editing, and Approval Gates.
Standardisation simplifies security governance, reduces training overhead, enables better ROI measurement, and streamlines licence management. Developer choice increases satisfaction, accommodates different workflow preferences, and enables experimentation with emerging tools. Most organisations start with pilot programmes allowing choice, then standardise on 1-2 enterprise-supported options once they understand usage patterns and security requirements. Maintain approved tool lists rather than complete lockdown, establish security baselines all approved tools must meet, and provide clear guidance on which tools suit which use cases.
The AI IDE wars represent more than vendor competition—they signal changes in how software gets built. Cursor’s $29 billion valuation after 24 months and fastest-ever path to $1 billion ARR demonstrate market momentum that’s impossible to ignore. With 85% of developers already using AI tools and major technology companies reporting 30% of new code coming from AI assistance, this isn’t emerging technology anymore.
But the hype obscures important realities. Nearly half of AI-generated code contains security vulnerabilities. Developers accept less than a third of suggestions. Promised productivity gains often fail to materialise when measured rigorously. The gap between vendor marketing and production reality demands frameworks for thinking clearly about adoption, measurement, and risk management.
Success requires treating AI IDEs as powerful tools that amplify capabilities rather than magic solutions eliminating complexity. Embed security scanning into workflows. Establish baselines before rollout. Train developers on effective prompting and code review. Implement approval gates and audit logging for autonomous operations. Choose vendors aligned with your security posture and strategic requirements.
The cluster articles linked throughout provide detailed implementation frameworks for each decision point. Whether conducting initial evaluation, measuring existing deployments, or planning autonomous agent rollout, you’ll find specific guidance for moving from vendor promises to production reality.
The IDE wars will continue evolving rapidly. Vendors with sustainable advantages will solve real problems—security, quality, genuine productivity—rather than simply generating more code faster. Your job is to separate signal from noise, implement appropriate controls, and extract value without unmanageable risk.
Start with the cluster articles most relevant to your decision points, establish measurement frameworks revealing actual impact, and build capability for working effectively with AI assistance. The tools are powerful. Your implementation strategy determines whether they deliver value or create expensive new problems.