The four year delay in the BSL explained.

The four year delay in the BSL explained begins with one feature that sets the Business Source License apart from a plain proprietary license: it is time limited. Each version published under the license carries a change date, and on that date the version converts to a named open license chosen by the vendor. The delay is commonly four years. On the surface this sounds generous, even self correcting, as if the restriction simply expires and the software returns to open terms. The reality is more particular, and the gap between the headline and the mechanics is where buyers get the picture wrong.

This article works through how the change date is set, what actually converts and when, and why waiting for conversion is seldom a real strategy. For the full mechanics of the license itself, see the Business Source License explained, and for the wider response playbook, the pillar on license change and relicensing.

How the change date works

The Business Source License defines two key parameters in its own text: a change date and a change license. The change date is the day a given version stops being governed by the restricted Business Source License terms and starts being governed by the change license, which is the open license the vendor names, often a GNU or Apache style license. The delay between publication and the change date is set by the vendor, and the four year figure is the common choice rather than a rule baked into the license. HashiCorp adopted the Business Source License 1.1 for Terraform, Vault, Consul, Nomad, and Packer as of August 2023, and the four year pattern is what most teams encounter in practice.

The crucial detail is that the change date attaches to each published version, not to the project as a whole. A version released today carries a change date roughly four years out. A version released two years ago will convert sooner. The result is a rolling series of clocks, one per release, rather than a single date after which everything becomes open.

What actually converts, and when

When a version reaches its change date, that specific version becomes available under the open change license. This is real and worth knowing. A version of Terraform published under the Business Source License will, in time, convert to its designated open license. The problem is which version that is. The version converting today was current four years ago. Development has continued the whole time, and the features, fixes, and security patches you care about live in newer releases that are still firmly inside their restricted period. You can have the openly licensed old version or the restricted current version, but the delay does not give you an openly licensed current version, which is the thing most teams actually want.

So the conversion is genuine but lagging. It guarantees that no version stays restricted forever, which has value for long lived deployments that can sit on an old release. It does nothing for a team that needs to track current development, because by the time a version converts, it is no longer the version they run.

Why the delay rarely solves exposure

Waiting for the clock trades one risk for another. To benefit from a conversion you must run a version old enough to have converted, which means running software that is roughly four years behind on security patches and bug fixes. For a secrets manager, a provisioning tool, or anything exposed to the network, that trade is rarely acceptable. The licensing exposure shrinks only as the security exposure grows, and the two move in opposite directions. The delay is therefore a timing feature, not a remedy. It tells you the restriction is finite, but it does not make the version you need open.

This is also why the conversion does not remove the competitive use restriction that matters most in the near term. While a version sits inside its delay period, the restriction on production use that competes with the vendor still applies. Whether your use falls inside that restriction is a separate question, and we examine it for one common case in the competitive restrictions in the SSPL.

How buyers should treat the delay

Read the delay as one input to a decision, not as the decision itself. For a stable, long lived deployment that does not need new features, sitting on a version until it converts can be a legitimate path, provided you accept the security trade and plan for it. For anything that needs current releases, the delay is largely irrelevant, and the real choices are a community fork such as OpenTofu, a replacement component, or a negotiated commercial license. Each version also carries its own change date, so any plan that relies on conversion has to track dates per version rather than assume a single deadline. Notice and effective dates are the foundation of that tracking, covered in notice and effective dates in a relicense.

The four year delay in the BSL is a meaningful and often misread feature. It limits how long any version stays restricted, but it does not hand you an openly licensed current release, and it does not lift the near term restrictions on the versions you actually run. Treat it as context for a plan, not as the plan. 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.