Ir al contenido principal

Software, apps, sitios web, redes y automatización con IA

Perspectivas tecnológicas

Open Source Relicensing in 2026: Why Redis, Terraform and Elasticsearch Changed Their Licences, What Forks Like Valkey and OpenTofu Actually Mean for You, and How to Check Your Stack Before It Bites

Open Source Relicensing in 2026: Why Redis, Terraform and Elasticsearch Changed Their Licences, What Forks Like Valkey and OpenTofu Actually Mean for You, and How to Check Your Stack Before It Bites

  • Equipo de Internet Pros
  • September 26, 2026
  • Desarrollo de software

Este artículo está disponible solo en inglés.

For most of the last two decades, businesses treated open source infrastructure as a fixed thing. You picked a database, a cache or a provisioning tool, and the licence stayed the same for as long as you ran it. That assumption no longer holds. Since 2018 a string of well known projects, including MongoDB, Elasticsearch, Terraform, Redis and CockroachDB, have moved new releases to licences that are no longer open source in the formal sense. Each time, part of the community forked the last open version. If your website, app or internal tools depend on any of them, a licence change can affect your costs, your cloud options and your upgrade path as much as a security patch can.

Why Vendors Keep Changing the Rules

The motive is almost always the same. A company builds a popular project, gives it away under a permissive licence, and funds development by selling a hosted version. Then a large cloud provider offers the same software as a managed service, often more cheaply and with more reach, and the company that wrote the code captures little of the revenue.

Relicensing is the response. The new licences usually leave ordinary users alone and target one behaviour: offering the software to others as a competing service. That is why most businesses running Redis or Terraform internally were never directly affected. The trouble is that "most" is not "all", and the edge cases are exactly the ones that surprise people.

A licence is part of your supply chain. Do not stop reading the LICENSE file after the first install.

The Main Licences, in Plain Terms

Four licence families come up again and again, and the practical differences are easy to summarise.

Licence What it usually allows What to watch for
Business Source License (BSL 1.1) Free use, modification and production use, subject to an "Additional Use Grant" written by the vendor The grant differs per project and often bars competing hosted offerings; each release converts to an open licence only after a change date of up to four years
Server Side Public License (SSPL) Normal internal use of the software Offering it as a service requires releasing the source of your whole service stack; the Open Source Initiative does not approve it
Functional Source License (FSL) Any use except a competing commercial product Simpler than BSL, and each release becomes Apache 2.0 or MIT after two years
AGPLv3 Fully open source, including commercial and hosted use If you modify it and let users interact with it over a network, you must offer those users your modified source

The word to be careful with is "source available". It means you can read the code. It does not mean you can do whatever you like with it, and procurement or legal teams that approve "open source" by default may not have approved these terms.

Four Changes and What Happened Next

  • Elasticsearch (2021). Elastic moved from Apache 2.0 to a choice of SSPL or its own Elastic License. AWS forked the last Apache version as OpenSearch, which moved to its own foundation under the Linux Foundation in 2024. Later that year Elastic added AGPLv3 as a third option, so Elasticsearch is once again available under an OSI approved licence.
  • Terraform (2023). HashiCorp moved Terraform and its other products from MPL 2.0 to BSL 1.1. Within weeks a group of companies forked it as OpenTofu, now a Linux Foundation project that has shipped features of its own, such as encrypted state files. IBM completed its acquisition of HashiCorp in 2025, and Terraform stayed under BSL.
  • Redis (2024). Redis moved from the BSD licence to a choice of its own Redis Source Available License or SSPL. Former contributors, backed by several cloud providers, forked Redis 7.2 as Valkey under the Linux Foundation, and major managed services adopted it quickly. In 2025 Redis 8 added AGPLv3 as an option, partly reversing course.
  • CockroachDB (2024). Cockroach Labs retired its free core edition in favour of a single enterprise licence with a free tier for smaller companies, which means larger users now need a paid agreement to run it.

The pattern worth noticing is that relicensing is rarely the end of the story. Two of the four vendors later added an open licence back. The forks, meanwhile, did not fade away. They gained foundations, maintainers from several companies, and in some cases features the original lacks. You now have a real choice, and it deserves a deliberate decision rather than whatever your package manager happens to install.

Does Any of This Affect a Normal Business?

For many small and mid-sized companies the honest answer is "probably not directly". If you run Redis as a cache behind your own website, or use Terraform to manage your own cloud account, the new licences generally permit it. The risk sits in three specific situations.

When a Licence Change Can Bite

  • You sell a product built on the software. A hosting platform, a SaaS tool that exposes search or caching to customers, or a DevOps product that wraps Terraform may fall inside the restricted "competing service" language.
  • You ship software to customers. Bundling a source available component in an appliance or an installed product can bring obligations your contracts never anticipated.
  • You rely on the ecosystem, not just the core. Plugins, providers, client libraries and managed services may follow the fork or the original.
  • You depend on a vendor that can change again. A single company controlling a project can relicense future versions at any time. A project run by a neutral foundation with many contributing companies is much harder to change.

How to Check Your Stack

You do not need a lawyer to get a clear picture. You need an inventory and an hour.

  • List what you actually run. A software bill of materials from your build pipeline or container scanner lists every component and its declared licence. Filter for BSL, SSPL, FSL, "Elastic License" and "RSAL".
  • Check versions, not just names. Licences change at a release boundary. Redis 7.2 and earlier is BSD; later versions are not. Pin versions deliberately so an automatic upgrade does not move you onto new terms.
  • Look at your managed services. Many cloud caches and search services now run Valkey or OpenSearch underneath. Know which one you are on, because the upgrade paths differ.
  • Weigh governance, not only the licence. Prefer projects with a foundation, a public roadmap and maintainers from more than one employer. That is the best predictor that today’s licence will still apply in five years.
  • Decide before the next upgrade. Switching from Redis to Valkey or from Terraform to OpenTofu is usually straightforward while the projects remain close. It gets harder every release they drift apart.

En resumen

Open source is not going away, but the assumption that popular infrastructure will stay freely licensed forever is gone. Treat licences like any other dependency: record them, pin them, watch for changes, and choose projects whose governance makes a surprise unlikely.

Not sure which licences are sitting in your website, apps or cloud setup? Talk to Internet Pros. We inventory the software you depend on, flag licence and support risks, and plan clean migrations to open alternatives when they make sense.

Compartir:
Etiquetas: Desarrollo de software Business

Artículos relacionados