Digitale Souveränität entsteht nicht durch Besitz, sondern durch Kontrolle
Souveränität entsteht nicht durch Besitz von Software, sondern durch Nachvollziehbarkeit und Verantwortung. Offene Technologien schaffen die Grundlage, Entscheidungen selbst zu treffen.
Das Heise-Interview mit BITMi-Präsident Oliver Grün setzt einen Punkt: "Open Source allein ist nicht die Lösung.“ Das klingt ausgleichend. In der Sache führt es in die Irre. Wer Souveränität ernst meint, braucht Transparenz, Nachvollziehbarkeit und Partner, die europäisches Recht leben. Offene Technologie ist kein Dogma. Sie ist die Voraussetzung, Kontrolle überhaupt ausüben zu können.
Klingt vernünftig - ist es aber nicht
"Wir wollen nicht Open Source gegen Closed Source ausspielen“, sagt Oliver Grün. Er argumentiert mit Marktanteilen seiner Mitglieder und warnt vor ideologischen Verboten. Das Problem: Souveränität ist kein Stimmungswert und kein Stimmzettel für Marktquoten. Sie beschreibt die Fähigkeit, Systeme zu prüfen, zu betreiben und weiterzuentwickeln. Offenheit ermöglicht das erst und sorgt für nachvollziehbare Kontrolle.
Einordnung statt Zustimmung
Ja, Europarecht und Datenschutz sind nicht verhandelbar. Auch wir halten "Europarechtstreue“ für zentral. Doch Offenheit ist kein Alternativpfad dazu, sondern Teil der Lösung. Ohne Einblick in Code, Protokolle und Lieferketten bleibt Compliance ein Vertrauensvorschuss. Schleswig-Holstein zeigt, wie verbindliche Anforderungen an Transparenz, Upstream-Beiträge und Dokumentation in einer Open-Source-Strategie verankert werden. Das Ergebnis: bessere Kontrolle, weniger Abhängigkeiten, nachvollziehbare Sicherheit.
Kritik am BITMi-Narrativ
Marktanteil ≠ Argument: Der Hinweis "80 Prozent proprietär" erklärt Status quo, aber nicht Qualität von Souveränität. In Deutschland bündelt die Open Source Business Alliance (OSBA) eine wachsende Anbieterlandschaft und vertritt nach eigenen Angaben rund 250 Mitgliedsunternehmen (osb-alliance.de). Das zeigt: Open Source ist längst kein Nischenthema, sondern wirtschaftlich tragfähig und Teil eines breiten europäischen Ökosystems. Sie erklärt Status quo, aber nicht Qualität von Souveränität. Wenn öffentliche IT beschaffungsseitig Kontrolle als Kriterium setzt, verschiebt sich der Markt in Richtung überprüfbarer Lösungen. Das ist Ziel, nicht Nebeneffekt.
Closed Source bleibt Blackbox: Audits an Schnittstellen helfen, ändern aber nicht den Kern. Bei geschlossener Software entscheiden Hersteller über Einblickstiefe, Update-Takt und Lebenszyklus. Der Staat kauft damit immer auch Vertrauen ein.
Abhängigkeiten werden nur verschoben: Grün betont, dass auch bei Open-Source-Dienstleister benötigt. Wenn es bei Open-Source-Lösungen nur einen oder wenige Dienstleister gibt, hat das in der Regel Gründe: Sie sind oft noch jung, spezialisiert oder wirtschaftlich wenig attraktiv für breite Anbieterlandschaften. Ob in solchen Fällen die notwendige Nachhaltigkeit gegeben ist, sollte genau geprüft werden. Es kann sinnvoll sein, Open-Source-Lösungen zu wählen, die bereits eine stabilere Community oder breitere Dienstleisterbasis haben oder bewusst in Projekte zu investieren, die langfristig wachsen und nachhaltige Strukturen entwickeln können. Richtig. Der Unterschied: Abhängigkeiten sind ersetzbar, wenn Code offenliegt, Standards etabliert sind und Upstream-Pflege stattfindet.
"With software, either the users control the program, or the program controls the users."
Richard Stallman (FSF), https://www.gnu.org/philosophy/keep-control-of-your-computing.en.html
Open Source ist nicht gleich Open Source
Hinter dem Begriff verbergen sich vielfältige Lizenzmodelle, die unterschiedliche Freiheitsgrade, Schutzmechanismen und Verpflichtungen mit sich bringen. Eine permissive Lizenz erlaubt etwa weitgehende Nutzung, Modifikation oder Einbindung in proprietäre Software-Produkte. Eine Copyleft-Lizenz hingegen stellt sicher, dass jede Veränderung oder Weiterverbreitung der Software unter den gleichen Bedingungen geschieht. Für Organisationen, die digitale Souveränität anstreben, heißt das: Lizenzwahl ist kein Randthema, sondern Teil der Architektur, weil sie Einfluss hat auf Nachvollziehbarkeit, Austauschbarkeit und Kontrolle der eingesetzten Lösungen.
Vergleichstabelle der wichtigsten Lizenztypen
| Lizenz | Lizenztyp | Wesentliche Merkmale | Bedeutung für Souveränität |
|---|---|---|---|
| MIT-Lizenz | Permissive | Sehr wenige Bedingungen: Nutzung, Modifikation, Verbreitung erlaubt; Lizenz- und Copyright-Hinweis erforderlich. | Hohe Flexibilität. Keine Pflicht, eigene Änderungen offenzulegen. Kontrollfähigkeit hängt stark von eigenen Prozessen/Partnern ab. |
| BSD (2- oder 3-Klausel) | Permissive | Ähnlich MIT; 2- und 3-Klausel-Varianten ohne historische Werbeklausel der 4-Klausel-BSD. | Gut kombinierbar mit offenem und proprietärem Code. Offenlegung eigener Anpassungen nicht verpflichtend. |
| Apache License 2.0 | Permissive | Mehr Text, explizite Patent- und Markenrechtsklauseln; erlaubt Modifikation und Vertrieb, Lizenz-Hinweise erforderlich. | Explizite Patentlizenz und -beendigungsklauseln; Modifikation und Vertrieb erlaubt; Lizenzhinweise erforderlich. |
| GNU General Public License (GPL) | Starkes Copyleft | Abgeleitete Werke nur unter GPL; Quellcode muss offengelegt werden. | Maximale Verpflichtung zur Offenlegung. Hohe Kontrollfähigkeit und Nachvollziehbarkeit, teils geringere Integrationsfreiheit. |
| GNU Lesser GPL (LGPL) | Schwaches Copyleft | Bibliothekslizenz: Nutzung in proprietären Anwendungen erlaubt; Modifikationen der Bibliothek bleiben offen. | Kompromiss: Kern bleibt offen, Integration bleibt möglich. |
| Mozilla Public License (MPL) | Schwaches Copyleft | Copyleft auf Dateiebene; Modifikationen an MPL-Dateien offenlegen; Kombination mit proprietären Modulen möglich. | Geeignet für hybride Szenarien. Offene Teile bleiben nachvollziehbar, proprietäre Module klar trennbar. |
| Eclipse Public License (EPL) | Schwaches Copyleft | Copyleft auf Dateiebene; Patentlizenz mit Termination bei Patentklagen; modulare Nutzung möglich. | Passend für modulare Architekturen. Kontrolle über offene Kerndateien bleibt erhalten. |
Bewertung der Lizenzen hinsichtlich digitaler Souveränität
| Lizenz | Typ | Transparenz | Kontrollfähigkeit | Nachvollziehbarkeit | Resilienz / Weiterverwendung | Beurteilung |
|---|---|---|---|---|---|---|
| GPL v3 | Starkes Copyleft | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | Offenlegungspflicht sichert Kontrolle und Nachvollziehbarkeit; im Tausch gegen geringere Integrationsfreiheit. |
| LGPL v3 | Schwaches Copyleft | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | Sehr guter Kompromiss: Kern bleibt offen, Integration bleibt möglich. |
| Apache 2.0 | Permissiv | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | Starke rechtliche Klarheit (Patentklauseln); Offenlegung nicht erzwungen, dafür gute Governance-Tauglichkeit. |
| MPL 2.0 | Schwaches Copyleft | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | File-level-Copyleft bewahrt Transparenz in modifizierten Teilen; Integration weiterhin möglich. |
| EPL 2.0 | Schwaches Copyleft | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | Modular, mit Patentklauseln; gut in Unternehmens-Ökosystemen, Resilienz abhängig von Modultrennung. |
| BSD | Permissiv | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ | Einfach, kompatibel. Keine Offenlegungspflicht; Souveränität hängt stark von eigener Governance ab. |
| MIT | Permissiv | ⭐⭐⭐ | ⭐⭐ | ⭐⭐ | ⭐⭐ | Maximale Freiheit, minimale Verpflichtung. Auditierbarkeit ist möglich, aber nicht durch die Lizenz erzwungen. |
Fazit:
Open Source ist vielseitig. Zwischen MIT und GPL liegen Welten. Rechtlich wie strategisch. Für echte digitale Souveränität zählt nicht nur, dass Code offenliegt, sondern auch, wie Offenheit geregelt ist. Copyleft-Lizenzen schaffen überprüfbare Sicherheit und verhindern, dass Wissen wieder verschlossen wird. Permissive Modelle fördern Kooperation, erfordern aber Vertrauen in die Akteure. Souveränität entsteht dort, wo Transparenz verpflichtend wird - nicht optional.
erdfisch-Perspektive: Open Source plus europäische Verantwortung
Digitale Souveränität entsteht dort, wo Technologie, Prozesse und Verantwortung zusammenwirken. Wir unterstützen Organisationen, die ihre digitale Handlungsfähigkeit aktiv gestalten wollen:
- Drupal als Basis: Drupal ist ein offenes, standardkonformes (unter GNU General Public License v2 oder neuer) CMS-Framework mit starker Community. Es erlaubt Code-Einsicht, Rollen- und Rechtemodelle, saubere Trennung von Inhalt und Präsentation sowie barrierearme Auslieferung. Das schafft prüfbare Qualität statt Hersteller-Narrative.
- Verantwortliche Umsetzung: Wir entwickeln in klaren Architekturen, dokumentieren Entscheidungen, liefern Tests und halten uns an Community- und Coding-Standards.
- Wartung mit System: Mit automatisierten, dokumentierten Updates, Monitoring und Berichten bleibt die Plattform auditfähig. Sicherheit ist Standard, nicht Add-on.
- Europäische Partnerkette: Hosting, Betrieb und Support erfolgen mit europäischen Anbietern. Das reduziert rechtliche Grauzonen und schafft Klarheit in Auftragsverarbeitung und Beweissicherung.
"Souveränität heißt nicht, alles zu besitzen - sondern alles verstehen zu können.“
Frank Holldorff, erdfisch
Souveränität heißt, entscheiden zu können und nicht nur zu konsumieren
Die Debatte "Open vs. Closed“ lenkt ab. Entscheidend ist, ob öffentliche Stellen ihre Systeme nachprüfen, betreiben und weiterentwickeln können, ohne an einzelne Anbieter gebunden zu sein. Dafür braucht es offene Technologien, klare Prozesse, die richtigen Open-Source-Lizenzen und europäische Partner, die Verantwortung übernehmen. Besitz ist verhandelbar. Kontrolle nicht.
Quellen zu Lizenzen
- MIT-Lizenz: https://opensource.org/license/mit
- BSD 2-Clause: https://opensource.org/license/bsd-2-clause
- BSD 3-Clause: https://opensource.org/license/bsd-3-clause
- Apache License 2.0: https://www.apache.org/licenses/LICENSE-2.0
- GNU GPL v3: https://www.gnu.org/licenses/gpl-3.0.en.html
- GNU LGPL v3: https://www.gnu.org/licenses/lgpl-3.0.en.html
- Mozilla Public License 2.0: https://www.mozilla.org/en-US/MPL/2.0/
- Eclipse Public License 2.0: https://www.eclipse.org/legal/epl-2.0/
- Drupal-Lizenz: https://www.drupal.org/about/licensing
- Überblick Drupal-Lizenzierung: https://www.drupal.org/docs/user_guide/en/understanding-gpl.html
- Open-Source-Strategie Schleswig-Holstein: https://www.schleswig-holstein.de/DE/landesregierung/themen/digitalisierung/linux-plus1/Projekt/open-source-strategie
- Hintergrund Schleswig-Holstein (heise): https://www.heise.de/hintergrund/Interview-Wie-die-OSS-Umstellung-in-Schleswig-Holstein-laeuft-10629991.html
Frank Holldorff
