Contractually guarantee a minimum notice period (six to twelve months) before any end of support, unilateral flip, or substantial change to the service#

What this is, concretely#

This commitment addresses a common asymmetry in SaaS contracts: the publisher can, in practice, modify the conditions of use, abandon a version, switch a client to a new architecture, change the licence, or sharply raise prices, leaning on phrasings of the kind “the publisher reserves the right to make the service evolve”. The client, for their part, has no way to anticipate or negotiate, short of discovering the change through an email thirty days before the actual switch. This asymmetry is precisely what turns a provider into a single point of failure.

The commitment consists of writing into the standard contract a guaranteed minimum notice period, calibrated to the service’s criticality: six months for standard services, twelve months for critical or massively production-deployed services. The events covered include:

• End of support for a stable version still in widespread use.
• Unilateral flip of architecture, technical foundation, or data location.
• Substantial change to the service — licence change (cf. the Redis, HashiCorp, MongoDB cases), massive pricing change, withdrawal of a feature documented as included, modification of the data storage scope.

The notice is given in writing, accompanied by migration arrangements, reversibility commitments (cf. pub-009), and the list of changes carried out. This commitment directly informs domain 5 (continuity) and domain 6 (contractual relationship) of the Sovereignty Profile.

Why this commitment matters#

Thesis 13 of the manifesto grounds this commitment: “Technological sovereignty is not an end in itself. It is the condition under which an organisation — a business, an administration, an individual — can continue to operate its data and conduct its operations, whatever happens: provider failure, geopolitical conflict, sanctions, hostile takeover, unilateral flip by a publisher. It is a right, not a comfort.” The minimum notice period is the instrument that turns the “unilateral flip” of this thesis into a framed, foreseeable, negotiable event.

This commitment forms part of the new section “Conditions of equivalence for the proprietary publisher” of the About page. The “minimum contractual notice period” condition is the fourth and complements mechanically pub-005-establish-software-escrow (escrow) and pub-009-standard-reversibility-clause (reversibility): the notice period gives the client the time to activate those two arrangements before it is too late. Without notice, the client is trapped: an email thirty days before the change, and they take the hit. The Redis case (August 2024, SSPL/RSALv2 flip), HashiCorp Terraform (August 2023, BSL flip), MongoDB (October 2018, SSPL flip) all happened on notice periods too short to allow an orderly migration of installed bases: it is this collective experience that this commitment exists to correct.

A concrete example#

A French publisher of a container orchestration PaaS, around 35 employees, takes this commitment in May 2026 with a 6-month horizon. The standard contract is updated as early as autumn 2026. For standard contracts, the guaranteed notice period is six calendar months; for critical contracts (clients whose service runs in production on the publisher’s infrastructure under an enhanced service level commitment), it rises to twelve months. The clause specifies the events covered: end of support for a minor version, removal of a feature from the public API, change of data centre location, change of the applicable licence, price increase greater than 15% per year.

The publisher also publishes an explicit versioning policy: each minor version has a guaranteed support period of at least 18 months, which makes the 6-month notice period compatible with a sustainable migration cycle. This policy is documented on the website on a dedicated page referenced from the Sovereignty Profile. By the horizon date, two clients who had encountered abrupt switches at other providers cite the explicit mention of this notice period as a determining factor in their choice.

Anti-pattern to avoid#

A notice announced verbally or by email, without contractual entry, has no force. A “reasonable” notice without a number lets the publisher decide alone what is reasonable. A notice that covers only complete service shutdowns, leaving substantial changes (licence, pricing, functional scope) out of scope, misses most real cases. A notice not paired with complementary commitments (reversibility, documented migration) remains a warning without a solution. Finally, the use of ambiguous phrasings (“we will endeavour to inform our clients in good time”) amounts to guaranteeing nothing.

Success indicators#

By the 6-month horizon, you can reasonably consider this commitment fulfilled if the standard contract integrates the notice clause with numerical durations, if the list of triggering events is explicit and exhaustive, if the versioning or support policy is public, and if the clause is actually applied at the first triggering event — documented date of announcement, migration arrangements attached.

JSON schema category: publication. Default horizon: 6 months. Applicable to: businesses.