The 2023 to 2026 relicensing wave explained.

The 2023 to 2026 relicensing wave explained in one sentence: a cluster of foundational open source projects decided that source visible was enough and open source was too costly to give away, and they changed terms in quick succession. What had been isolated moves became a pattern, and the pattern matters more than any single change, because it tells buyers that no widely used project is permanently safe from a relicense. The software you adopted as open source can become source available on a release note, and the wave shows this is now a normal event rather than a rare one.

This article lays out the timeline, explains the shared commercial logic, distinguishes source available from open source, and draws the lesson for buyers. For the full treatment of how a relicense works and what to do about it, the pillar on license change and relicensing is the place to start.

The timeline of the relicensing wave

The wave has roots before its name. MongoDB moved to the Server Side Public License in 2018, the first major project to take that step. Elasticsearch and Kibana followed in 2021, moving from Apache 2.0 to the Server Side Public License and the Elastic License, which prompted the AWS led fork OpenSearch. Then the pace picked up. HashiCorp moved Terraform, Vault, Consul, Nomad, and Packer to the Business Source License 1.1 as of August 2023, and the community responded with the fork OpenTofu. IBM later acquired HashiCorp. Redis moved to a Redis Source Available License and Server Side Public License model as of March 2024, and later added an open license option, with the fork Valkey emerging in parallel.

Seen together, these are not coincidences. They are a sequence in which each move lowered the barrier to the next, and the years 2023 through 2026 are when the practice became expected rather than shocking. The mechanics of the two dominant licenses are set out in the Business Source License explained and the Server Side Public License explained.

Why the wave happened

The shared driver was commercial. Each of these projects sat behind a company that funded most of its development and watched large cloud providers offer the same software as a managed service at scale, capturing revenue the original vendor felt it had earned. The Business Source License and the Server Side Public License were the instruments of response. The Business Source License restricts production use that competes with the vendor and converts to an open license after a delay, commonly four years. The Server Side Public License attaches a strong copyleft style condition aimed squarely at parties offering the software as a service. Both keep the source readable while removing the freedom that made the projects attractive to redistribute commercially.

The logic is coherent from the vendor's chair. The point for a buyer is that the same logic can be applied by any commercially backed open source project that decides its model is under threat, which is why the wave is a forward looking warning and not a closed chapter.

Source available is not open source

The single most important distinction in the whole wave is that source available is not open source. The code remains visible, which leads many teams to assume nothing of substance changed. The substance is exactly what changed. Neither the Business Source License nor the Server Side Public License is OSI approved, and both narrow the rights that govern production use. A team that can still read the source can easily miss that it can no longer use that source in the way it did last year. Treating visibility as permission is the error the wave punishes most often, and we unpack it in source available is not open source and why it matters.

This is where exposure hides. The software keeps working, the source stays open to inspection, and the terms quietly no longer match the use. Months can pass before anyone asks the question that surfaces the gap.

What the wave means for buyers

The practical lesson is to stop treating any single open source license as permanent and to build for change instead. Three habits follow. Know what you run, because you cannot react to a relicense in software you have not inventoried. Watch the projects you depend on, so a change is a tracked event rather than an audit surprise. And know your options in advance: each major relicense produced a community fork, OpenTofu from Terraform, Valkey from Redis, and OpenSearch from Elasticsearch, and the fork story is told in the OpenTofu and Valkey fork story. A fork is a real path, though migrating to one is engineering work that has to be planned rather than assumed.

The 2023 to 2026 relicensing wave is best read as a standing condition rather than a passing event. The projects that have already moved are the visible part. The lesson is to be ready for the next one. This article is commercial and licensing risk advisory, not legal advice. For interpretation of a specific license and your compliance position, your own counsel is the right place to turn.