In August 2023, HashiCorp announced it was relicensing Terraform from the Mozilla Public License 2.0 to the Business Source License (BSL). The move sent shockwaves through the infrastructure-as-code community. Within weeks, a fork named OpenTofu emerged, backed by the Linux Foundation and major cloud vendors. The controversy wasn't about the license itself—it was about what it represented: a playbook for turning open source into a tool for vendor lock-in.

The BSL Promise: A Shield or a Sword?

The Business Source License was introduced by MariaDB in 2013 as a compromise. The idea was simple: let the source code be open and available, but restrict commercial use for a limited time—typically three years—after which the code converts to a permissive license like Apache 2.0. Proponents argue this gives vendors a chance to monetize before competitors can offer the same code as a service. Critics counter that the BSL creates a window of vendor lock-in, during which users become dependent on the vendor's proprietary offerings.

MariaDB positioned the BSL as a middle ground between open source and traditional proprietary software. It allowed anyone to use, modify, and distribute the code for non-production purposes, but restricted production use by competitors. The hope was that this would encourage investment in open-source projects while still generating revenue. For a while, it worked—MariaDB itself used BSL for its MaxScale product, and other companies like Cockroach Labs followed suit.

But the BSL's real test came when HashiCorp adopted it for Terraform. Terraform was one of the most popular open-source infrastructure tools, with a massive ecosystem of providers and modules. The license change wasn't just a legal adjustment; it was a strategic move that rewrote the rules of the game for an entire community.

How Terraform's BSL Shift Rewrote the Rules

HashiCorp's decision to relicense Terraform under BSL in August 2023 was ostensibly about protecting its commercial interests. The company argued that cloud vendors were profiting from Terraform without contributing back. The BSL prevented competitors from offering a managed Terraform service without a commercial agreement with HashiCorp. In practice, it meant that any company wanting to run Terraform as a SaaS had to either go through HashiCorp or risk legal exposure.

The lock-in was subtle but effective. While users could still use Terraform's open-source core for free, the most valuable features—such as Sentinel policy-as-code, private module registry, and remote state management—remained proprietary and tied to HashiCorp's cloud platform. Teams that had built their infrastructure around Terraform now faced a choice: stay with the community fork or migrate to HashiCorp's paid offerings. Switching costs were high because the ecosystem of providers and modules was deeply intertwined with HashiCorp's tooling.

HashiCorp's 2024 earnings showed a revenue bump, some of which analysts attributed to conversions from free users to paid customers after the license change. But the move also eroded trust. The license change that split a database community offered a cautionary tale, and many saw Terraform's shift as a repeat of that pattern.

The Fork That Proved the Playbook Works

OpenTofu launched in September 2023 with a clear mission: preserve the open-source nature of Terraform under a permissive license. Backed by the Linux Foundation and supported by companies like Gruntwork, Spacelift, and env0, OpenTofu quickly achieved full compatibility with Terraform's provider ecosystem. The fork was technically successful, but enterprise adoption proved slower.

Why? Inertia played a role. Many organizations had already invested in HashiCorp's tooling and training. Brand trust also mattered—HashiCorp was a well-known company with a track record of reliable releases. OpenTofu, despite its community governance, lacked the same level of funding and marketing muscle. Some enterprises worried about long-term maintenance and support, even though the Linux Foundation provided a neutral home.

The fork demonstrated that BSL could be countered, but at a cost. The community had to invest significant effort to replicate what HashiCorp had built. For smaller teams, the migration was a distraction they couldn't afford. The BSL playbook worked because it exploited the asymmetry between vendor resources and community capacity.

Vendor Lock-In by Another Name

The BSL's non-production use allowance is often cited as a safeguard, but it masks real restrictions. A company can use BSL-licensed software internally for development and testing, but once they want to offer it as a service—say, a managed Terraform deployment platform—they need a commercial license from the vendor. This effectively funnels commercial users toward the vendor's own cloud offerings.

This pattern isn't unique to HashiCorp. Redis Labs used a similar license change to protect its Redis Modules, Cockroach Labs adopted BSL for its core database, and Elastic changed its license to prevent cloud providers from offering Elasticsearch as a service. Each case followed the same arc: an open-source project gains popularity, a vendor emerges, and then a license change locks out competitors while locking in users.

The result is a landscape where open-source software increasingly comes with strings attached. As the VC fund that backs the npm package you already depend on shows, venture capital often drives these decisions, prioritizing monetization over community freedom.

The Economics of the BSL Trap

Vendors who switch to BSL are betting that switching costs will outweigh the effort of migrating to a fork. This is a rational bet. Once a company has built its infrastructure around a tool—writing configurations, training staff, integrating with CI/CD pipelines—the cost of moving can be enormous. The BSL creates a window during which the vendor can convert free users into paying customers, often through the lure of proprietary features that aren't available in the open-source version.

Enterprise contracts typically include service-level agreements (SLAs) and support that free users don't get. Audit clauses in BSL licenses also scare small and mid-size businesses into compliance, even when they might be within their rights. Some estimates suggest that roughly 70% of BSL users never exercise the conversion right to the permissive license after three years, either because they've already migrated to the vendor's cloud or because the project has moved on.

The economics work for vendors but create a tragedy of the commons for the broader ecosystem. Open-source communities lose contributors, innovation shifts to proprietary forks, and users become dependent on a single vendor's roadmap. The BSL trap is a rational choice for individual vendors, but it undermines the collaborative model that made open source successful in the first place.

Case Studies: BSL in the Wild

Beyond Terraform, several prominent projects have adopted BSL or similar source-available licenses, each with distinct outcomes. Cockroach Labs switched its core database to BSL in 2019, arguing that cloud providers were free-riding on its open-source work. The move allowed Cockroach Labs to offer a managed cloud service without direct competition from AWS or GCP using the same code. However, it also led to the creation of a community fork called CockroachDB Community Edition, which remains under the original Apache 2.0 license. Adoption of the fork has been limited, partly because Cockroach Labs continues to develop the most advanced features in the BSL-licensed version.

Redis Labs took a different approach: it kept the Redis core under BSD but changed the license of its Redis Modules to a proprietary license, later moving to the Redis Source Available License (RSAL). This allowed the core to remain open while protecting the value-added modules. The result was a two-tier ecosystem where the core is free but the modules require a commercial license for production use. This strategy has been financially successful for Redis Labs, but it also fragmented the community; some users migrated to alternative key-value stores like KeyDB or Dragonfly.

Elastic's license change in 2021 was perhaps the most controversial. The company moved Elasticsearch and Kibana from Apache 2.0 to the Elastic License and the Server Side Public License (SSPL), effectively preventing cloud providers like AWS from offering Elasticsearch as a service. AWS responded by forking Elasticsearch into OpenSearch, which is now managed under the Apache 2.0 license by the Linux Foundation. OpenSearch has gained significant traction, especially among users who want to avoid vendor lock-in. Elastic's revenue growth since the change has been strong, but the company lost the goodwill of a portion of its community.

These case studies illustrate a common pattern: the BSL or similar licenses can protect a vendor's commercial interests, but they often trigger forks and community fragmentation. The long-term impact depends on the vendor's ability to retain mindshare and the fork's ability to sustain development. For users, the safest strategy is to monitor license changes closely and have a fallback plan.

Alternatives That Avoid the Lock-In Trap

Not all licenses are created equal when it comes to preventing lock-in. The Apache 2.0 and MIT licenses offer no protection against commercial exploitation, but they also impose no restrictions on users. The AGPL enforces reciprocity by requiring that modified versions be distributed under the same license, but it doesn't restrict SaaS use directly—a loophole some vendors have exploited.

The PolyForm Shield License was designed as a less restrictive alternative to BSL, allowing non-production use and small-scale production use without a commercial agreement. It's a compromise, but one that still imposes limits. Community-owned foundations like the CNCF and Linux Foundation reduce single-vendor risk by ensuring that no single company controls the direction of a project. Copyfree licenses like 0BSD and CC0 give maximum freedom but offer no protection against proprietary forks.

For maintainers, the choice of license is a strategic decision that should align with their business model, not ideology. If a vendor plans to sell a SaaS product, BSL may be rational—but they should expect community backlash and potential forks. For users, the best defense is to audit license change clauses in every dependency and prefer infrastructure tools backed by neutral foundations.

Trade-Offs: Balancing Monetization and Community Trust

Vendors that adopt BSL face a classic trade-off: short-term revenue gains versus long-term community trust. A 2023 survey by the Linux Foundation found that 45% of developers consider license compatibility a critical factor when choosing open-source tools, and 30% have abandoned a project after a license change. This suggests that while BSL can boost immediate revenue, it may erode the user base over time.

On the other hand, permissive licenses like Apache 2.0 can lead to a situation where cloud providers capture most of the value, leaving the original developers with little revenue. This is the "open-source rug pull" that BSL aims to prevent. The ideal balance might be a license that grants broad usage rights but requires a fee for large-scale commercial hosting, similar to the Commons Clause or the Fair Source License. However, these licenses have their own controversies and are often seen as "open source washing."

For users, the trade-off is between convenience and freedom. Sticking with a vendor that uses BSL can be easier in the short term, especially if the vendor offers integrated tools and support. But over time, the lack of a viable alternative can lead to dependency and higher costs. The OpenTofu fork demonstrates that community-driven alternatives can emerge, but they require sustained effort and funding.

A Pragmatic Path Forward for Maintainers and Users

The BSL era has taught us that open-source licensing is a business lever, not just a legal formality. Maintainers should choose a license based on how they intend to generate revenue. If the goal is to sell a managed service, BSL or a similar source-available license may be the right call, but it comes with a cost: community trust. Users, on the other hand, should treat every dependency as a potential lock-in risk. Audit the license, understand the change clauses, and have a migration plan ready.

For infrastructure tools, the safest bet is to prefer projects backed by neutral foundations like the CNCF or Linux Foundation. These organizations have governance models that prevent any single vendor from hijacking the project. The CDN engineer who lives on 3ms cache miss margins might not worry about licensing, but for teams managing large-scale deployments, the license is as critical as the code.

Ultimately, the BSL playbook works because it exploits the asymmetry between vendor resources and community capacity. The only real defense is a vigilant community that's willing to fork when necessary—and a user base that's prepared to follow. The open-source ecosystem has survived license changes before, and it will survive this one. But the scars will remain, and the next playbook is already being written.