Free Today, Paid Tomorrow: What's Really Behind Open Source's Licensing Identity Crisis

There's a specific kind of gut-punch that hits when a tool you've built your entire pipeline around suddenly changes the terms of the relationship. No breakup text, no warning shot — just a blog post, a new license file in the repo, and a sinking feeling that your stack just got a lot more complicated.

That's the reality a lot of Linux developers and DevOps engineers have been living through lately. Redis, Terraform, Elasticsearch, MongoDB — projects that were practically synonymous with open-source culture — have each, in their own way, moved the goalposts. And if you're not paying close attention to licensing language, you might not even realize it's happened until you're already in violation.

So what's actually going on here? And more importantly, what should you do about it?

The Shift Has a Name (And It's Not New)

The trend has a somewhat dry but accurate label: open-core or source-available licensing. The idea is that a company releases the core of their software under a license that looks permissive on the surface but includes restrictions that traditional open-source definitions — specifically the Open Source Initiative's definition — would reject outright.

HashiCorp made waves in 2023 when it moved Terraform from the Mozilla Public License to the Business Source License (BSL). Redis Labs followed a similar path, eventually rebranding and relicensing Redis under a dual-license model that restricts cloud providers from offering it as a managed service without paying up. Elastic did it with Elasticsearch back in 2021, citing Amazon's habit of packaging and selling the product without meaningfully contributing back.

The companies involved frame these moves as survival. And honestly? They're not entirely wrong.

The Cloud Provider Problem Is Real

Here's the uncomfortable truth that often gets lost in the outrage cycle: a significant chunk of this licensing upheaval traces back to hyperscalers — primarily AWS, Google Cloud, and Azure — taking open-source projects, slapping them inside a managed service, and generating enormous revenue without contributing code, funding, or much of anything back to the original maintainers.

From a pure business standpoint, that's brutal. You spend years building something valuable, release it freely to the world, and then watch a trillion-dollar company turn your work into a profit center while you're still trying to make payroll for a team of twelve.

Redis's CEO put it plainly: the old model assumed a community of contributors. What they got instead was a community of consumers — and a handful of very large, very profitable ones at that.

So the companies adapted. The licenses changed. And the Linux community, which had been happily building on these tools assuming the "open" label was permanent, suddenly had to reassess.

What the New Licenses Actually Say

This is where it gets technical, and where a lot of developers get tripped up. Not all restrictive licenses are created equal, and the devil is absolutely in the details.

Business Source License (BSL/BUSL): Used by HashiCorp for Terraform and MariaDB for some components. The code is viewable and modifiable, but you can't use it in production for competing commercial purposes. There's typically a conversion clause — after a set period (often four years), the code converts to a true open-source license. Sounds reasonable until you realize "competing" is defined by the licensor.

Server Side Public License (SSPL): MongoDB's creation, later adopted by Elasticsearch (briefly). Requires that if you offer the software as a service, you must open-source your entire service stack. It's designed to be deliberately burdensome for cloud providers. The OSI has not approved it as an open-source license.

Dual Licensing: Some projects offer a community edition under a permissive license alongside an enterprise edition with more features under a commercial license. This one is older and generally less controversial, but the community editions have a habit of getting thinner over time.

If you're running any of these in production — especially in a commercial context — you should be reading the actual license text, not just the marketing language around it.

The Community Forks Back

Here's where the Linux ethos gets interesting. The open-source community's response to these license changes has been, in many cases, to fork.

When HashiCorp changed Terraform's license, the community spun up OpenTofu under the Linux Foundation almost immediately. When Elastic changed Elasticsearch's terms, AWS created OpenSearch — itself now a legitimate community project with broad adoption. Redis's relicensing prompted Valkey, another Linux Foundation project that's gaining serious traction.

This is the open-source immune system doing exactly what it's supposed to do. If a company closes the door, the community builds a new door. It's messy, it fragments ecosystems, and it creates migration headaches — but it works.

The catch is that forks require sustained maintenance, funding, and community energy. Not every project has the gravity to support a healthy fork long-term. Some just quietly die.

What This Means for Your Workflow

If you're a developer, a sysadmin, or someone who manages infrastructure on Linux, there are a few practical things worth doing right now:

Audit your dependencies. Go through your stack and identify every tool that has a corporate backer. Not because corporate-backed projects are bad — many are excellent — but because they carry different risk profiles than pure community projects. Know what license each tool is under today.

Watch the governance model. Projects hosted under the Linux Foundation, Apache Software Foundation, or similar neutral bodies are structurally harder to relicense. A single company controlling the copyright on all contributions is a yellow flag.

Read the CLA. Contributor License Agreements often grant the company the right to relicense your contributions however they see fit. If you're contributing to a project with a corporate CLA, you're technically helping them build the asset they might one day lock down.

Have a contingency. For critical infrastructure tools, know what the fork or alternative looks like before you need it. OpenTofu, Valkey, and OpenSearch all exist precisely because communities planned ahead.

The Bigger Question Nobody Wants to Answer

The licensing crisis forces a question that the open-source world has been quietly avoiding for years: how do we sustainably fund the infrastructure the entire internet runs on?

Projects like curl, OpenSSL, and countless others run on volunteer labor and sporadic donations while supporting billions of devices. That's not a stable foundation, and companies that try to build a business around it are discovering that the hard way.

Dual licensing and open-core models are imperfect answers. They compromise the ideals that make open source worth caring about. But they're also, in some cases, the only thing keeping the lights on for teams that built genuinely critical software.

The Linux community has always been good at building things. The next challenge is figuring out how to sustain them — without quietly handing the keys back to the proprietary world we were trying to escape in the first place.

Keep your eyes on the license file. It'll tell you everything you need to know.