General Sovereignty

Who Can Switch It Off

7. Oct 2026

Aarno Aukia, VSHN. October 2026

Most sovereignty conversations are about who can read your data. That question has good answers by now: encryption, data residency, access logs, a data processing agreement naming every subprocessor. The question that gets asked far less often, and that would hurt far more, is who can switch your service off.

Losing confidentiality is bad. Losing the service is worse, because the business stops that afternoon. And the two risks do not have the same owner: your data can stay in Zurich while the decision to keep serving it is made somewhere else entirely.

Four ways a running service stops without anyone touching your data

These are not four versions of one risk. What separates them is how much notice you get: the first stops the service today, the next two hand you a migration on a date you did not choose, and the fourth needs nobody to decide anything at all.

1. Someone orders it off. Days, and no appeal. A provider obeys the law of the jurisdiction it belongs to. Sanctions, export controls and court orders reach the vendor, not the data center, and the customer is rarely a party to the decision. Adobe deactivated every account in Venezuela in October 2019 to comply with a US executive order, three weeks after telling customers, and said at first that it was not permitted to refund prepaid subscriptions before reversing that under public pressure. In May 2025 the chief prosecutor of the International Criminal Court lost access to his Microsoft account after the US sanctioned ICC officials. Microsoft’s president denies that the company suspended services to the court. What the court did next is on the record: in October 2025 it confirmed it is moving some 1,800 workstations to openDesk.

2. The license changes under you. Months, and a bill. This one needs no politics. In December 2020 Red Hat moved CentOS Linux 8’s end of life from May 2029 to December 2021, removing eight years of planned life with twelve months’ notice and breaking no agreement with anyone. Broadcom ended perpetual VMware sales in December 2023 and went subscription-only, and in May 2025 it sent cease-and-desist letters to perpetual licensees whose support had lapsed, requiring them to uninstall every update and patch released after their contract ended. The right to run the software survived. The right to patch it did not, and nobody keeps an unpatched hypervisor in production. Oracle has priced Java SE per employee since January 2023, counted on total headcount rather than on who uses Java: same software, same deployment, a bill computed from the HR system.

3. The product is retired and the vendor is fine. Months, and a migration nobody budgeted. The fear attached to small providers is insolvency, and it is the wrong fear. The ordinary case is a vendor in good health discontinuing a product. Microsoft retired Azure Database for MariaDB on 19 September 2025, announced two years ahead, with new instances blocked eighteen months ahead, and its own documentation says that workloads still running on the retirement date are deleted and their data lost. AWS retired Amazon QLDB on 31 July 2025 with about a year’s notice, and the replacement it recommends has no cryptographic verification, which was the reason to pick QLDB in the first place, so the migration was a redesign. Google retired Cloud IoT Core in August 2023 with twelve months’ notice, saying its partners served those needs better. Azure Blockchain Service stopped accepting new deployments in May 2021 and was switched off that September, four months later. Every one of those vendors is still trading.

4. Nobody decides anything and it stops anyway. The fuse is the obligation to phone home. Software running on your own hardware often has to reach its vendor to keep working, and few teams have looked up how long it lasts without that. Azure Local, which Microsoft positions for sovereign and distributed locations, documents the answer in its own FAQ: if the system does not sync with Azure for 30 consecutive days, its status goes to “Out of policy” and it enters a reduced functionality mode in which existing VMs keep running and new ones cannot be created until it syncs again. Your hardware, your building, your data, and a license to start a VM that renews monthly from a cloud. Microsoft does sell a disconnected edition for permanently offline sites, so the fuse is in the default build and taking it out is a separate purchase. Microsoft 365 is the same mechanism on a shorter fuse. Microsoft’s lifecycle gives a subscription 30 days of normal access past its end date, after which the applications move into what its own documentation calls a read-only, reduced functionality mode: you can look at your documents and not edit them. And it does not take a lapse. In November 2020 Macs worldwide hung when launching applications because Apple’s certificate-status server stopped answering, and the workaround that circulated was to disconnect from the internet.

The database world’s most instructive case belongs to the third category rather than the first. Sun Microsystems bought MySQL in 2008, Oracle bought Sun in 2009, and MySQL’s creator forked the code rather than wait to find out what the new owner would do with it. Oracle did not disappear and MySQL was not discontinued. The fork happened over what the owner might decide, and it was possible because the license permitted it. MariaDB exists because of that.

Why a contract does not settle it

A contract binds your vendor. It does not bind the state that regulates your vendor, and it does not survive the vendor. Contractual protection is worth having, and it is the layer most procurement processes spend all their time on, which is why the gap is so common: the paperwork is thorough about liability and silent about continuity if the counterparty is compelled, acquired or gone.

Data residency has the same shape of gap. It tells you where the bytes are. It tells you nothing about who operates the service, under which law the operating company sits, and who can be ordered to stop. Those are three separate questions, and each one has a different answer for each provider.

What actually reduces the risk

Four questions, in the order they matter:

1. Can anyone withdraw your right to run the software? With a proprietary engine, yes, by changing the terms or ending the product. With an engine under GPLv2 or a comparable license, no. The code you are running stays yours to run, and a fork stays possible, which is the structural reason the MySQL story could have a sequel at all.

2. Who operates it, and under which law? Running software is not the same as owning its license. If the operator is a foreign subsidiary, the operating decisions sit in the parent’s jurisdiction, whatever the data center’s address says.

3. What stops working if you stop paying? This is the sharpest test, and almost nobody runs it. Take the commercial components out on paper and see what is left. If what remains is a database that keeps serving queries, you have an exit. If what remains is nothing, you have a dependency you have been calling a partnership. Then run the same test for reachability instead of payment: what stops working if the vendor cannot be reached for a month? Both answers are in the documentation. Neither is in the contract.

4. Who answers at three in the morning? Independence that nobody can operate is not independence, it is a hobby. The point of sovereignty is continuity, and continuity needs someone contractually obliged to restore service, close enough to your timezone and your language to do it.

What this looks like in practice

Take a MariaDB deployment, which is the example I know best, and separate it into layers:

  • MariaDB Server and Galera Cluster are GPLv2. Free to run in production, with no audit exposure on the database itself. Nobody can withdraw that right, this year or in five years.
  • The connectors are LGPL, so they link into proprietary applications without obliging you to open your own code.
  • MaxScale, the Enterprise Kubernetes Operator, Enterprise Manager and the analytics components are commercial, and come with a subscription.

Run question 3 against that stack. Drop the subscription and the database keeps running: you lose the proxy layer, the hardened builds and the vendor’s support, which are real losses, and you keep serving queries while you decide what to do next. That is what an exit looks like when it is structural rather than contractual.

Then run question 2. The subscription is a commercial relationship with a European vendor. The operations can sit with a Swiss company, under Swiss law, with the infrastructure in a Swiss data center or in your own. Two suppliers, two different kinds of accountability, neither of them able to end the other’s part unilaterally.

This is the arrangement VSHN and MariaDB described at our joint webinar on 1 October, which is recorded and online: MariaDB builds the database and stands behind the engine, VSHN resells the subscription in CHF and runs the platform. A customer signs one Swiss contract and still has the database vendor’s engineers behind it.

The uncomfortable part

Sovereignty bought this way is not free. The commercial components cost money, the operations cost money, and someone has to run the architecture that makes a failover invisible instead of hoping the single node holds. What it buys is the ability to answer a regulator, an auditor or your own board with facts rather than assurances: here is who holds the license, here is who operates it, here is the law the contract sits under, and here is what we keep running if any of them walks away.

The Swiss public sector has started paying that price deliberately, and its decisions are a matter of record. EMBAG has required federal agencies to publish the software they develop or commission as open source since 1 January 2024, which makes Switzerland one of the first countries to put that in law. In June 2026 the Ständerat went further and adopted a motion for an impulse program on digital sovereignty by 30 votes to 7, against the Federal Council’s recommendation; the Nationalrat has not voted yet. The same reasoning applies one layer down, at the database under the application that the business actually runs on.

Where to start

Look at the systems the business cannot lose for a day, and for each one write down five answers: who holds the engine’s license, who operates it, which law the contract sits under, what still runs if you stop paying, and what still runs if nothing can reach the vendor. Most teams can fill in the first three from memory and go quiet on the last two.

If MariaDB is one of those systems, we will do that review with you. VSHN and MariaDB are offering a joint estate check: which versions you run, where they are exposed, what is under support and what is not. It is free and it ends in a written answer, not a quote.

Book a free estate review

If you would rather start with the technology than with your own estate, we are running a hands-on afternoon at the VSHN Tower in Zurich on 19 October with the MariaDB engineers and Michael “Monty” Widenius, who wrote MySQL and MariaDB: a live MaxScale failover, the Enterprise Kubernetes Operator, and migrations. Forty seats.

Reserve a seat for 19 October in Zurich


Sources:

Aarno Aukia

Aarno is Co-Founder of VSHN AG and provides technical enthusiasm as a Service as CTO.

Contact us

Our team of experts is available for you. In case of emergency also 24/7.

Contact us