Technological sovereignty starts with a practical question: if I want to leave, can I actually do so? Not in the abstract — in fact, within deadlines, with which tools, at what cost. Reversibility and portability are the two faces of this question, depending on the service model.
For SaaS solutions — where the publisher operates the service and the customer entrusts it with their data — the question is one of export: can the data be retrieved in an open format, within a quantified contractual deadline, with tested scripts? Without a precise clause, the “exportability” stated in a contract is at best a promise, at worst a trap (see commitment pub-009).
For PaaS solutions — where the customer has deployed code and configuration on the platform — the question is one of application portability: can the workload be moved to another target (a Compose VPS, another PaaS, an alternative orchestrator) without a rewrite project that drags on for months? The stake is deeper than for SaaS, because it concerns code and architecture, not data alone (see commitment pub-014).
For proprietary solutions in general, reversibility also relies on arrangements ensuring continuity of the software itself: a software escrow held by a European trusted third party, or a public release commitment to publish the source code under a free licence in named triggering circumstances — bankruptcy, liquidation, non-EU acquisition (see commitment pub-005). Escrow guarantees that the code remains usable even if the publisher disappears; the reversibility clause guarantees the portability of what runs on top of it.
These three mechanisms form the reversibility block of the equivalence conditions for proprietary publishers (see the device’s philosophy page). They are not exclusive: a provider operating both SaaS and PaaS, whose software component remains proprietary, gains by combining them.
A point worth flagging on the technical PaaS target. Many providers implicitly assume that the relocation target is Kubernetes. This assumption calls for two reservations: Kubernetes is itself a project under American governance (CNCF, Linux Foundation, US-based sponsors and lead maintainers), with no established European alternative; and self-hosted Kubernetes is a heavy infrastructure whose maintenance falls on the customer. The target favoured by the commitments on this page is self-hosted via Docker Compose — accessible, runnable on a standard VPS, with no cluster nor dependency on a third-party orchestrator. Kubernetes (managed or self-hosted) and other PaaS remain options, not prescriptions.
Finally, without a minimum contractual notice period before any support termination or unilateral flip, even the best reversibility clause stays theoretical: it takes time to activate an escrow, export data, relocate a workload. The notice period is the temporal envelope that makes reversibility operative (see commitment pub-010).
On the buyer side, reversibility is not merely declared — it is tested: seriously studying, ahead of the contract, the migration scenario and its cost (see commitment user-004) is what turns a paper clause into actual leverage.
This page brings together the concrete commitments on the provider side and the buyer side. For an analysis of cases where reversibility was missing, see the documentary annex Family 1 — Licence flips.