Allgemein Sovereignty

Wer kann es abschalten

7. Okt. 2026

Aarno Aukia, VSHN. Oktober 2026

In Diskussionen über digitale Souveränität geht es fast immer darum, wer deine Daten lesen kann. Dafür gibt es inzwischen brauchbare Antworten: Verschlüsselung, Datenstandort, Zugriffsprotokolle, ein Auftragsverarbeitungsvertrag, der jeden Unterauftragnehmer benennt. Seltener gestellt und deutlich schmerzhafter ist die andere Frage: Wer kann deinen Dienst abschalten?

Vertraulichkeit zu verlieren ist schlimm. Den Dienst zu verlieren ist schlimmer, denn dann steht das Geschäft noch am selben Nachmittag. Und die beiden Risiken haben nicht denselben Eigentümer: Deine Daten können in Zürich liegen, während der Entscheid, sie weiter auszuliefern, ganz woanders fällt.

Vier Wege, auf denen ein laufender Dienst endet, ohne dass jemand deine Daten anfasst

Das sind nicht vier Varianten desselben Risikos. Der Unterschied liegt im Vorlauf: Der erste beendet den Dienst heute, die nächsten zwei setzen dir eine Frist, die du nicht gewählt hast, und beim vierten muss niemand etwas entscheiden.

1. Jemand ordnet die Abschaltung an. Tage, ohne Rekurs. Ein Anbieter befolgt das Recht der Rechtsordnung, zu der er gehört. Sanktionen, Exportkontrollen und Gerichtsentscheide treffen das Unternehmen, nicht das Rechenzentrum, und der Kunde sitzt bei diesem Entscheid selten mit am Tisch. Adobe deaktivierte im Oktober 2019 sämtliche Konten in Venezuela, um ein US-Dekret zu befolgen, drei Wochen nach der Ankündigung, und erklärte zunächst, bereits bezahlte Abonnemente nicht zurückerstatten zu dürfen, bevor es diese Haltung unter öffentlichem Druck korrigierte. Im Mai 2025 verlor der Chefankläger des Internationalen Strafgerichtshofs den Zugang zu seinem Microsoft-Konto, nachdem die USA Sanktionen gegen Mitarbeitende des Gerichts verhängt hatten. Microsofts Präsident bestreitet, dass das Unternehmen Dienste für das Gericht ausgesetzt hat. Was das Gericht daraus gemacht hat, ist belegt: Im Oktober 2025 bestätigte es die Umstellung von rund 1’800 Arbeitsplätzen auf openDesk.

2. Die Lizenz ändert sich unter dir. Monate, plus Rechnung. Dafür braucht es gar keine Politik. Red Hat verschob im Dezember 2020 das Lebensende von CentOS Linux 8 von Mai 2029 auf Dezember 2021: acht Jahre eingeplante Laufzeit weg, zwölf Monate Vorlauf, und kein Vertrag gebrochen. Broadcom beendete im Dezember 2023 den Verkauf von VMware-Dauerlizenzen und stellte vollständig auf Subscriptions um. Im Mai 2025 verschickte es Unterlassungsschreiben an Inhaber von Dauerlizenzen mit abgelaufenem Support, mit der Aufforderung, alle nach Vertragsende veröffentlichten Updates und Patches zu deinstallieren. Das Recht, die Software zu betreiben, blieb. Das Recht, sie zu patchen, nicht, und einen ungepatchten Hypervisor betreibt niemand weiter. Oracle rechnet Java SE seit Januar 2023 pro Mitarbeitenden ab, gezählt auf dem gesamten Personalbestand und nicht auf denen, die Java nutzen: gleiche Software, gleiche Installation, eine Rechnung aus dem HR-System.

3. Das Produkt wird eingestellt, dem Anbieter geht es gut. Monate, plus eine Migration, die niemand budgetiert hat. Bei kleinen Anbietern fürchten alle den Konkurs, und das ist die falsche Furcht. Der Normalfall ist ein gesundes Unternehmen, das ein Produkt einstellt. Microsoft stellte Azure Database for MariaDB am 19. September 2025 ein, angekündigt zwei Jahre vorher, neue Instanzen gesperrt achtzehn Monate vorher, und laut eigener Dokumentation werden am Stichtag noch laufende Workloads gelöscht und ihre Daten sind verloren. AWS stellte Amazon QLDB am 31. Juli 2025 ein, mit rund einem Jahr Vorlauf, und dem empfohlenen Ersatz fehlt die kryptografische Nachweisbarkeit, also genau der Grund, QLDB zu wählen: Aus der Migration wurde ein Redesign. Google stellte Cloud IoT Core im August 2023 mit zwölf Monaten Vorlauf ein, mit der Begründung, Partner bedienten diesen Bedarf besser. Azure Blockchain Service nahm ab Mai 2021 keine neuen Deployments mehr an und war im September abgeschaltet, vier Monate später. Alle diese Anbieter sind weiterhin im Geschäft.

4. Niemand entscheidet etwas, und es hört trotzdem auf. Die Zündschnur ist die Pflicht, den Hersteller zu erreichen. Software auf deiner eigenen Hardware muss oft ihren Hersteller erreichen, um weiterzulaufen, und kaum ein Team hat nachgelesen, wie lange sie ohne diese Verbindung durchhält. Azure Local, das Microsoft für souveräne und verteilte Standorte positioniert, schreibt die Antwort in die eigene FAQ: Synchronisiert das System 30 aufeinanderfolgende Tage nicht mit Azure, wechselt der Status auf „Out of policy“ und das System in einen Modus mit reduzierter Funktionalität, in dem bestehende VMs weiterlaufen und neue nicht mehr erstellt werden können, bis die Synchronisierung wieder gelingt. Deine Hardware, dein Gebäude, deine Daten, und das Recht, eine VM zu starten, erneuert sich monatlich aus einer Cloud. Für dauerhaft getrennte Standorte verkauft Microsoft eine Disconnected-Variante: Die Zündschnur steckt also im Standardprodukt, und sie herauszunehmen ist ein eigener Kauf. Microsoft 365 ist derselbe Mechanismus mit kürzerer Schnur. Nach dem Enddatum eines Abonnements gibt Microsoft 30 Tage mit normalem Zugriff, danach wechseln die Programme in einen Modus, den die eigene Dokumentation „read-only, reduced functionality mode“ nennt: Du kannst deine Dokumente ansehen, nicht bearbeiten. Und es braucht nicht einmal ein abgelaufenes Abonnement: Im November 2020 blieben weltweit Macs beim Starten von Programmen hängen, weil Apples Server für den Zertifikatsstatus nicht mehr antwortete, und der Tipp, der die Runde machte, war, das Internet zu trennen.

Der lehrreichste Fall der Datenbankwelt gehört in die dritte Kategorie, nicht in die erste. Sun Microsystems kaufte 2008 MySQL, Oracle kaufte 2009 Sun, und der Erfinder von MySQL forkte den Code, statt abzuwarten, was der neue Eigentümer damit vorhat. Oracle ist nicht verschwunden, und MySQL wurde nicht eingestellt. Der Fork geschah wegen dessen, was der Eigentümer entscheiden könnte, und er war möglich, weil die Lizenz ihn erlaubte. Deshalb gibt es MariaDB.

Warum ein Vertrag die Frage nicht erledigt

Ein Vertrag bindet deinen Anbieter. Er bindet nicht den Staat, der deinen Anbieter reguliert, und er überlebt den Anbieter nicht. Vertraglicher Schutz lohnt sich, und er ist die Ebene, auf der Beschaffungsprozesse die meiste Zeit verbringen. Genau deshalb ist die Lücke so verbreitet: Die Unterlagen sind gründlich bei Haftung und schweigen zur Fortführung, wenn die Gegenseite verpflichtet, übernommen oder verschwunden ist.

Beim Datenstandort ist die Lücke gleich geformt. Er sagt dir, wo die Bytes liegen. Er sagt nichts darüber, wer den Dienst betreibt, welchem Recht die betreibende Gesellschaft untersteht und wer zum Abschalten verpflichtet werden kann. Das sind drei getrennte Fragen, und jeder Anbieter beantwortet sie anders.

Was das Risiko tatsächlich senkt

Vier Fragen, in der Reihenfolge ihrer Bedeutung:

1. Kann dir jemand das Recht entziehen, die Software zu betreiben? Bei einer proprietären Engine ja, über geänderte Bedingungen oder ein eingestelltes Produkt. Bei einer Engine unter GPLv2 oder einer vergleichbaren Lizenz nein. Der Code, den du betreibst, bleibt deiner, und ein Fork bleibt möglich. Das ist der strukturelle Grund, warum die MySQL-Geschichte überhaupt eine Fortsetzung bekommen konnte.

2. Wer betreibt die Lösung, und nach welchem Recht? Software zu betreiben ist etwas anderes, als ihre Lizenz zu halten. Sitzt der Betreiber als Tochtergesellschaft im Ausland, fallen die Betriebsentscheide in der Rechtsordnung der Mutter, ganz gleich, welche Adresse das Rechenzentrum hat.

3. Was hört auf zu funktionieren, wenn du aufhörst zu zahlen? Das ist der schärfste Test, und fast niemand führt ihn durch. Streiche die kommerziellen Komponenten auf dem Papier und schau, was übrig bleibt. Bleibt eine Datenbank übrig, die weiter Abfragen beantwortet, hast du einen Ausstieg. Bleibt nichts übrig, hast du eine Abhängigkeit, die du bisher Partnerschaft genannt hast. Stelle die Frage danach ein zweites Mal, nicht zur Zahlung, sondern zur Erreichbarkeit: Was hört auf zu funktionieren, wenn der Hersteller einen Monat lang nicht erreichbar ist? Beide Antworten stehen in der Dokumentation. Keine davon steht im Vertrag.

4. Wer nimmt um drei Uhr nachts ab? Unabhängigkeit, die niemand betreiben kann, ist keine Unabhängigkeit, sondern ein Hobby. Souveränität zielt auf Fortführung, und Fortführung braucht jemanden, der vertraglich verpflichtet ist, den Betrieb wiederherzustellen, nahe genug an deiner Zeitzone und deiner Sprache, um es auch zu tun.

Wie das konkret aussieht

Nimm eine MariaDB-Installation, das Beispiel, das ich am besten kenne, und zerlege sie in Schichten:

  • MariaDB Server und Galera Cluster stehen unter GPLv2. Produktiv frei betreibbar, ohne Lizenzaudit-Risiko auf der Datenbank selbst. Dieses Recht kann dir niemand entziehen, dieses Jahr nicht und in fünf Jahren nicht.
  • Die Connectors stehen unter LGPL, lassen sich also in proprietäre Anwendungen einbinden, ohne dass du deinen eigenen Code offenlegen musst.
  • MaxScale, der Enterprise Kubernetes Operator, der Enterprise Manager und die Analytik-Komponenten sind kommerziell lizenziert und kommen mit einer Subscription.

Führe Frage 3 gegen diesen Stapel aus. Kündigst du die Subscription, läuft die Datenbank weiter: Du verlierst die Proxy-Schicht, die gehärteten Builds und den Support des Herstellers, was echte Verluste sind, und du beantwortest weiter Abfragen, während du entscheidest, wie es weitergeht. So sieht ein Ausstieg aus, wenn er strukturell verankert ist und nicht nur vertraglich.

Dann führe Frage 2 aus. Die Subscription ist eine Geschäftsbeziehung mit einem europäischen Hersteller. Der Betrieb kann bei einem Schweizer Unternehmen liegen, nach Schweizer Recht, mit der Infrastruktur in einem Schweizer Rechenzentrum oder in deinem eigenen. Zwei Lieferanten, zwei Arten von Verantwortung, und keiner von beiden kann den Teil des anderen einseitig beenden.

Genau diese Aufteilung haben VSHN und MariaDB am gemeinsamen Webinar vom 1. Oktober beschrieben, dessen Aufzeichnung online ist: MariaDB baut die Datenbank und steht hinter der Engine, VSHN verkauft die Subscription in CHF und betreibt die Plattform. Du unterschreibst einen Schweizer Vertrag und hast trotzdem die Entwickler der Datenbank im Rücken.

Der unbequeme Teil

So gekaufte Souveränität ist nicht gratis. Die kommerziellen Komponenten kosten Geld, der Betrieb kostet Geld, und jemand muss die Architektur betreiben, die ein Failover unsichtbar macht, statt zu hoffen, dass der einzelne Knoten durchhält. Dafür bekommst du die Fähigkeit, einer Aufsicht, einer Revision oder dem eigenen Verwaltungsrat mit Fakten zu antworten: Hier liegt die Lizenz, hier liegt der Betrieb, das ist das anwendbare Recht, und das läuft weiter, wenn eine der Parteien wegfällt.

Der Schweizer öffentliche Sektor zahlt diesen Preis inzwischen bewusst, und die Entscheide dazu sind aktenkundig. Das EMBAG verpflichtet die Bundesverwaltung seit dem 1. Januar 2024, Software, die sie selbst entwickelt oder entwickeln lässt, als Open Source zu veröffentlichen. Damit gehört die Schweiz zu den ersten Ländern, die das gesetzlich festschreiben. Im Juni 2026 ging der Ständerat weiter und nahm eine Motion für ein Impulsprogramm zur digitalen Souveränität mit 30 zu 7 Stimmen an, entgegen der Empfehlung des Bundesrats; im Nationalrat ist sie noch offen. Dieselbe Überlegung gilt eine Schicht tiefer, bei der Datenbank unter der Anwendung, von der das Geschäft lebt.

Wo du anfängst

Schau dir die Systeme an, die du keinen Tag verlieren darfst, und schreib für jedes fünf Antworten auf: Wer hält die Lizenz der Engine, wer betreibt sie, welchem Recht untersteht der Vertrag, was läuft weiter, wenn du aufhörst zu zahlen, und was läuft weiter, wenn nichts mehr den Hersteller erreicht. Die ersten drei können die meisten Teams aus dem Kopf beantworten, bei den letzten zwei wird es still.

Gehört MariaDB zu diesen Systemen, machen wir diese Bestandsaufnahme mit dir. VSHN und MariaDB bieten sie gemeinsam an: welche Versionen laufen, wo sie exponiert sind, was unter Support steht und was nicht. Die Bestandsaufnahme ist kostenlos und endet mit einer schriftlichen Antwort, nicht mit einer Offerte.

Kostenlose Bestandsaufnahme buchen

Wenn du lieber mit der Technik anfängst als mit deinem eigenen Bestand: Am 19. Oktober läuft im VSHN Tower in Zürich ein Hands-on-Nachmittag mit den MariaDB-Engineers und Michael „Monty“ Widenius, der MySQL und MariaDB geschrieben hat. Auf dem Programm stehen ein Failover mit MaxScale live, der Enterprise Kubernetes Operator und Migrationen. Vierzig Plätze.

Platz für den 19. Oktober in Zürich reservieren


Quellen:

Aarno Aukia

Aarno ist Mitgründer der VSHN AG und als CTO für die technische Begeisterung zuständig.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt