Domain 5 — Continuity in the event of failure

What this domain covers#

The fifth domain asks a simple but structuring question: what happens to your clients if you, the provider, fail? Failure can take several forms — bankruptcy, court-ordered liquidation, voluntary cessation of activity, strategic pivot that abandons the product, hostile takeover by a non-EU entity that dismantles the offer, unilateral decision to close the European service. Without a prepared mechanism, the client loses access to its tool without recourse, and its data may become difficult to operate.

The domain asks the declarant to describe the mechanisms in place: software escrow with a trusted third party, public commitment to release the source code under specified circumstances, sector guarantee fund, organised transfer of the client relationship, documented and tested export formats, minimum contractual notice period before cessation of service.

Why this domain matters#

Thesis 13 of the manifesto, which closes the block of theses, founds this domain directly: “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: the failure of a provider, geopolitical conflict, sanctions, hostile takeover, the unilateral flip of a publisher. It is a right, not a comfort.” Domain 5 is the practical embodiment of this thesis at the level of the provider-client contract.

The scenario is not hypothetical. Aleph Alpha, presented in 2023 as the European answer to OpenAI after raising more than $500M, was acquired by Cohere (Toronto) in April 2026; Silo AI was acquired by AMD in August 2024 for $665M; MariaDB came under K1 Investment Management in September 2024. With each event, European clients discover that their provider changes its reference jurisdiction without any contractual protection being offered to them. Beyond the spectacular cases, dozens of European SaaS publishers cease their activity each year without their clients having a continuity plan prepared.

This is also the domain where the proprietary solution is intrinsically weaker than open source. For an open source solution published under a free license, the publisher’s failure does not prevent the client from continuing to use the code, or even from forking it. For a closed proprietary solution, without a prepared mechanism, the client is exposed without recourse. Domain 5 is the domain where a proprietary publisher can concretely demonstrate its guarantees and bridge that gap.

What is asked, by category of declarant#

For a software publisher. Existence of a software escrow mechanism with a trusted European third party, with mention of that third party, of the jurisdiction, and of the release conditions. Failing a formal escrow, public commitment to release the source code under a free license under specified circumstances (bankruptcy, liquidation, definitive cessation, non-EU acquisition). Minimum contractual notice period before end of support. Existence of a standard reversibility clause in client contracts. For open source publishers, specification of the license of the current versions, of the conditions of fork, of the project’s governance, and of the mechanisms in the event of failure of the commercial entity that carries it.

For a hosting provider. Continuity plan for client data and workloads in the event of cessation. Contractual notice period. Documented and ideally tested export tools. Interoperable formats for the recovery of data. Possible existence of a sector guarantee fund or of a continuity arrangement operated with a peer (mutual takeover commitment).

For a distributor or integrator. What happens to clients in the event of cessation of the distributor? Existence of a possible transfer of the client relationship to another integrator, or directly to the original publisher. Residual skills allowing clients to continue autonomously at least the time it takes to find another service provider.

An example of an honest, well-done answer#

A French SaaS document management publisher, 40 staff, declares its domain 5 as follows. Software escrow set up with a French legal escrow agent in Paris since October 2025, with quarterly refresh of the sources and of the build documentation. Release conditions specified by tripartite contract: opening of insolvency proceedings with liquidation, officially announced cessation, finalised acquisition by a non-EU entity. In addition, a public commitment to release the source code under AGPL v3 in a Codeberg repository within 60 days of the official announcement of cessation of service; the migration conditions (data export in ODF formats, migration scripts to a self-hosted instance, architecture documentation) are published simultaneously. Minimum contractual notice period of 12 months before end of support of a stable version. Export tools available in self-service at any time in the client interface.

An anti-pattern to avoid#

A domain 5 formulated in vague terms such as “in the event of difficulty, we will commit to offering continuity solutions to our clients” without a concrete mechanism or specified circumstances gives no real security. An escrow that has been set up but is not refreshed quickly becomes obsolete and loses its protective value. A release commitment under a non-free license (for example, “source available” without effective rights of use and modification) does not respect the spirit of the device. A simple contractual reversibility clause that specifies neither formats, nor lead times, nor tools is purely formal.

Articulation with the other domains and commitments#

Domain 5 is articulated directly with the provider commitment pub-005-establish-software-escrow, which formalises the setting up of the device. It complements domain 2 by covering the scenario of failure of the provider itself (whereas domain 2 covers the failure of a third-party component of the provider). It mirrors, on the provider side, thesis 13 of the manifesto, which founds the client’s right to continuity.

How to fill in the form#

The form is organised into five blocks. Not all apply to all profiles — leave empty what is not relevant and use the general comment to make it explicit if needed.

Software escrow#

Software escrow mechanism: ternary (Yes / No / Partial / Not applicable / Not communicated) with comment and source. Partial is useful if only the source code is in escrow (without the deployment documentation, for example).
Escrow third party: name of the service provider or notary who holds the deposit (NCC Group, Codes-Sources Notariés, EscrowTech…).
Jurisdiction of the escrow: country where the deposit is held. Important if you want to avoid an extraterritorial jurisdiction (a US escrow to protect a French client… does not protect very much).
Release conditions: which events trigger the handover of the deposit to the client. Bankruptcy, cessation of activity, observed contractual breach…

Open source publication in the event of failure#

An alternative or a complement to escrow: the public commitment to publish the code as open source if the commercial entity disappears.

Commitment to publish as open source: ternary with comment and source. The ideal source is a contractual clause or a referenced public commitment.
Triggering circumstances: bankruptcy, liquidation, definitive shutdown, non-EU acquisition…
Target license: the license that will apply to the code once published (AGPL-3.0, MIT, Apache-2.0…). Be precise: “MIT” and “AGPL” do not grant the same rights.

Reversibility and end of support#

Notice period before end of support (months): how many months in advance will the client be notified before the total cessation of the service.
Reversibility clause in contracts: ternary. Is the clause systematic, negotiable, absent?
Export formats: formats in which data can be recovered (CSV, JSON, standard SQL dump, complete archive…). Proprietary formats without public documentation are a red flag.
Lead-time guarantees: within how many days/weeks does the client recover its data after a request.
Associated costs: free? At marginal cost? A tariff included in the contract? A reversibility that is “possible” but at €50,000 is disguised friction.
Data export in the event of cessation: what happens to client data if you cease activity? Temporary retention? Automatic transfer? Deletion?
Continuity fund or continuity partnership: ternary. Have you set up a financial or contractual mechanism guaranteeing continuity (e.g.: a partnership with an integrator capable of taking over maintenance)?
Exit clause in the client contract: ternary.
Protocol for transfer of the client relationship: if maintenance or the relationship can be transferred to a third party, how does it happen concretely?

Specific to open source publishers#

To be filled in if you publish code under an open source license.

Current license of open source projects: license(s) in force at the time of the declaration. If several projects, list them.
Conditions of fork: what a third party can do if it decides to fork. Permissions, restrictions (CLA required? Trademark?), redistribution conditions.
Project governance in the event of failure of the commercial entity: who can take over if the company disappears? Does a foundation hold the trademark? Do external contributors have formalised rights?

Distributors and integrators#

To be filled in if you operate as a network of partner integrators.

Partner integrators for continuity: names (comma-separated). Can these partners take over in the event of failure?
Direct publisher contact available for clients: ternary. Can the client contact the publisher directly, or must it always go through the integrator?

Protection against an extra-EU acquisition#

Statutory protection against an extra-EU acquisition (summary): statutory clauses (golden share, veto right of a European reference shareholder, cap on holdings by a non-EU shareholder, etc.). See also domain 6.