Übersetzung des englischen Originals von Italo Vignoli
Es existiert ein ausgeklügelter Mechanismus, durch den proprietäre Technologie-Ökosysteme Nutzer und Institutionen an sich binden – selbst dann, wenn diese glauben, freie Entscheidungen zu treffen, offene Standards zu nutzen und eine unabhängige digitale Infrastruktur aufzubauen.
Dieser Mechanismus funktioniert nicht durch Zwang, sondern durch eine subtilere und beständigere Strategie: die Schichtung von Abhängigkeiten. Dabei verdeckt jede Schicht die darunterliegende, sodass im Falle eines Systemausfalls die offensichtliche Ursache eine andere ist als die tatsächliche.
Es handelt sich um ein strukturelles Muster mit identifizierbaren Komponenten und vorhersehbaren Ausfallszenarien, das eine einzige politische Konsequenz nach sich zieht: Probleme bei der Interoperabilität werden systematisch offenen Alternativen zugeschrieben, anstatt den proprietären Abhängigkeiten, die sie tatsächlich verursachen.
Das Verständnis all dessen ist für jeden unerlässlich, der an einer echten Interoperabilitätsstrategie arbeitet; denn ohne dieses Wissen gehen selbst die am besten gemeinten politischen Maßnahmen lediglich das sichtbare Symptom an, während das eigentliche, umfassendere Problem der zugrundeliegenden Architektur unangetastet bleibt – und diese funktioniert weiterhin genau so, wie sie ursprünglich konzipiert wurde.
Die Wahrnehmung einer Fehlfunktion
Gehen wir von der Erfahrung der Nutzer aus, denn genau hier entsteht der politische Schaden.
Ein Dokument wird in Microsoft Word erstellt und an einen Kollegen gesendet, der LibreOffice auf einem Linux-Desktop nutzt. Der Kollege öffnet die Datei. Irgendetwas stimmt nicht: Eine Tabelle hat sich verschoben, der Textumbruch hat sich verändert, eine Schriftart sieht anders aus, die Seitenumbrüche sitzen an einer anderen Stelle.
Diese Erfahrung ist Millionen von Menschen in Institutionen vertraut, die Open-Source-Software bereits eingeführt haben oder deren Einführung erwägen. Es ist die Erfahrung, die zu Support-Anfragen und frustrierten E-Mails an die IT-Abteilung führt, zu Gesprächen, die mit der Frage „Kannst du mir nicht einfach ein PDF schicken?“ enden, und zu der sich mit der Zeit verfestigenden Ansicht, dass Open-Source-Software für den professionellen Einsatz nicht geeignet sei.
Was ist die Ursache dieses Fehlers? Nutzer geben LibreOffice die Schuld, IT-Manager der Formatinkompatibilität und politische Entscheidungsträger der mangelnden Reife offener Standards.
Das sind alles falsche Antworten. Genauer gesagt: Sie beantworten die falsche Frage, denn sie beschreiben, wo der Fehler auftritt, anstatt seine Ursache zu finden.
Die eigentliche Ursache ist ein Geflecht voneinander abhängiger technischer Systeme, von denen jedes einen anderen Fehlermodus beiträgt und die alle zu einem einzigen sichtbaren Ergebnis führen.
Das Format enthält proprietäre Strukturen, die nur von der Microsoft-Implementierung korrekt verarbeitet werden. Bei der Darstellung treten plattformabhängige Abweichungen auf, die von der Formatspezifikation nicht geregelt werden. Die proprietären Schriftarten dürfen nicht rechtmäßig mit Open-Source-Software gebündelt werden.
Drei verschiedene Fehlerursachen führen zum selben Symptom, das für den Benutzer gleichermaßen unsichtbar bleibt; dieser nimmt lediglich wahr, dass die Dinge in Word funktionierten, in LibreOffice jedoch nicht.
Dies ist die Architektur der gestuften Abhängigkeit. Jede Ebene nimmt die Kausalkette auf und gibt ein anderes Signal aus – eines, das auf die offene Alternative verweist.
Ebene eins: das Format und seine verborgenen Funktionen
Die erste Ebene ist die am meisten diskutierte und politisch sichtbarste: das Dokumentenformat. Der Konflikt zwischen ODF und OOXML wurde umfassend dokumentiert, in Normungsgremien juristisch ausgetragen sowie in nationalen Parlamenten und europäischen Institutionen debattiert.
Doch selbst in diesem hinlänglich bekannten Terrain lohnt es sich, den spezifischen Mechanismus der Verschleierung auf der Formatebene zu beleuchten.
OOXML, das von Microsoft Office standardmäßig erzeugte Format, existiert in zwei Konformitätsstufen. „Strict“ ist eine weitgehend saubere Spezifikation. „Transitional“ hingegen ist etwas grundlegend anderes: ein Format, das darauf ausgelegt ist, das über die Zeit gewachsene Verhalten früherer Microsoft-Office-Versionen abzubilden und dabei jahrzehntelange proprietäre Implementierungsentscheidungen als normative Bestandteile eines scheinbar offenen Standards zu bewahren.
OOXML Transitional umfasst VML (Vector Markup Language) – ein proprietäres Grafikformat aus den späten 1990er Jahren, das zeitlich vor dem an anderer Stelle derselben Spezifikation definierten DrawingML-System entstand und diesem widerspricht.
Es enthält Verweise, die als „wie in früheren Versionen von Microsoft Office“ definiert sind; diese ergeben nur dann einen Sinn, wenn man Zugriff auf jene früheren Versionen sowie auf deren undokumentierte Implementierungsdetails hat.
Es beinhaltet Erweiterungen, die es Microsoft ermöglichen, proprietäre Funktionen in Dokumente einzubetten, die für Nicht-Microsoft-Implementierungen unsichtbar sind und unbemerkt zu Darstellungsunterschieden führen können – von geringfügigen optischen Abweichungen bis hin zum völligen Zusammenbruch des Layouts.
Entscheidend ist, dass Microsoft Office standardmäßig OOXML Transitional verwendet.
Jedes Mal, wenn ein Benutzer ein Word-Dokument speichert, ohne ein anderes Format auszuwählen, wird eine für das Microsoft-Ökosystem optimierte Datei erstellt, die mit anderen Systemen inkompatibel ist.
Benutzer bemerken dies nicht, da die Formatauswahl automatisch getroffen wird. Wenn das Dokument in LibreOffice nicht angezeigt werden kann, bleibt der Einfluss der Formatierungsebene auf den Fehler unsichtbar. Der Benutzer sieht ein Darstellungsproblem, kein Formatproblem.
Dies ist die erste Ebene der Verschleierung: Proprietäre Formatstrukturen werden als „Industriestandard“ getarnt und erzeugen Fehler, die wie Implementierungsmängel in der empfangenden Software erscheinen.
Ebene zwei: Rendering und dessen nicht spezifiziertes Verhalten
Die zweite Ebene wird weniger diskutiert und ist politisch weniger sichtbar – und genau aus diesen Gründen ist sie eine umso beständigere Ursache für Interoperabilitätsprobleme: das Text-Rendering.
Standards für Dokumentformate legen die Inhalte fest. Sie definieren, was ein Dokument enthält: Text, Struktur, logische Beziehungen, eingebettete Objekte und Formatierungsanweisungen.
Was sie jedoch nicht festlegen – und was auch keiner der gängigen Standards für Dokumentformate je festgelegt hat –, ist die Art und Weise, wie diese Inhalte dargestellt (gerendert) werden sollen. Die Umsetzung der kodierten Inhalte in sichtbare Schriftzeichen auf einem Bildschirm oder einer Seite bleibt der jeweiligen Implementierung überlassen, und verschiedene Implementierungen treffen hierbei unterschiedliche Entscheidungen.
Diese Entscheidungen wirken sich auf mehrere Subsysteme aus.
Zeichensatz-Engines – die Softwarekomponenten, die Unicode-Zeichenfolgen in Glyphenfolgen übersetzen und die komplexen Regeln von Schriftsystemen wie Arabisch, Devanagari und Thailändisch verarbeiten – unterscheiden sich je nach Plattform.
HarfBuzz, die Open-Source-Zeichensatz-Engine, die von LibreOffice und den meisten Linux-Anwendungen verwendet wird, erzeugt korrekte, standardkonforme Ergebnisse. Diese können sich jedoch im Detail von den Uniscribe- oder DirectWrite-Engines von Windows unterscheiden, insbesondere bei komplexen Schriftsystemen mit kontextsensitiver Glyphenauswahl.
Die Unterschiede sind bei lateinischen Texten fast immer unsichtbar, können aber bei den nicht-lateinischen Schriftsystemen, die von einem Großteil des europäischen öffentlichen Sektors und der Bevölkerung verwendet werden, erheblich sein.
Die Interpretation von Hinting-Anweisungen variiert je nach Rendering-Engine. Schriftarten enthalten eingebettete Hinting-Anweisungen – Algorithmen, die die Konturen von Schriftzeichen für eine scharfe Darstellung bei niedrigen Bildschirmauflösungen anpassen –, doch diese Anweisungen werden von verschiedenen Rendering-Systemen unterschiedlich interpretiert.
Eine für die GDI-Rendering-Engine von Windows optimierte Schriftart kann unter FreeType (Linux) eine andere Strichstärke und Zeichenabstände aufweisen, selbst bei identischer Schriftgröße.
Die Unterschiede sind bei einzelnen Zeichen zwar minimal, beeinflussen jedoch die wahrgenommene Qualität des Textes und tragen zu dem allgemeinen Eindruck bei, dass Open-Source-Umgebungen etwas weniger ausgereift wirken.
Algorithmen für den Zeilenumbruch und den Blocksatz stellen die bedeutendste Ursache für Unterschiede in der Darstellung sowie den direkten Grund für Veränderungen im Textfluss (Reflow) eines Dokuments dar.
Der Algorithmus, der die Zeilenumbrüche festlegt – also wie Wörter auf eine Zeile bestimmter Breite verteilt werden, ob und wie getrennt wird und wie Blocksatz gehandhabt wird –, ist eine Implementierungsentscheidung, die in keiner Formatbeschreibung geregelt ist.
Der Zeilenumbruch-Algorithmus von Microsoft Word ist proprietär und nicht dokumentiert; er unterscheidet sich erheblich von dem in LibreOffice. Beide sind legitime Implementierungen derselben Funktion und können zu unterschiedlichen Zeilenumbrüchen führen. Unterschiedliche Zeilenumbrüche bedeuten unterschiedliche Seitenumbrüche, was wiederum zur Folge hat, dass ein in Word paginiertes Dokument in LibreOffice nicht identisch paginiert wird.
Dies ist kein Mangel an der Qualität der Implementierung, sondern die normale und vorhersehbare Folge unterschiedlicher Entscheidungen bei der Darstellung, die in den Standards für Dokumentenformate nicht festgelegt sind. Daraus resultieren Fehler, die ausnahmslos der Software zugeschrieben werden, welche das Dokument empfängt – da dort der sichtbare Unterschied zutage tritt –, anstatt den Spezifikationen, die die eigentliche Ursache darstellen.
Die Darstellungsebene ist die technisch komplexeste Komponente dieser mehrschichtigen Abhängigkeitsstruktur und am schwierigsten zu handhaben; zugleich ist sie jedoch jene Ebene, die das Ausmaß des Problems am deutlichsten offenbart: Ein Fehler, der durch unterschiedliche Entscheidungen zweier Projekte entsteht, wird allein der Open-Source-Software angelastet – und zwar auf der Grundlage eines völlig unbegründeten, fast schon auf blindem Glauben beruhenden Vertrauens in die Qualität der proprietären Software.
Ebene drei: Schriftarten und die Abhängigkeit von proprietären Ressourcen
Die dritte Ebene vervollständigt das Bild und verursacht in vielen praktischen Szenarien den größten Schaden: Schriftarten. Hier analysieren wir nicht die Bindung an bestimmte Schriftarten (Lock-in) an sich, sondern erläutern, wie die Schriftartenebene innerhalb des Schichtenmodells der Abhängigkeiten funktioniert.
Schriftarten interagieren mit den beiden darüberliegenden Ebenen. Auf der Formatebene treten Schriftarten als benannte Referenzen auf: Ein Dokument legt fest, dass der Fließtext in Calibri und die Überschriften in Cambria gesetzt sind. Sind diese beiden Schriftarten auf dem empfangenden System nicht verfügbar – was bei jedem System der Fall ist, für das keine Lizenz für die proprietären Schriftarten erworben wurde –, muss die Software sie ersetzen.
Diese Ersetzung verändert die Metriken, und die Metriken wiederum verändern die Geometrie. Eine veränderte Geometrie führt zu Textumbruchverschiebungen, zerstörten Layouts und Formularelementen, die über ihre Ränder hinausragen; auch hier wird das Problem der Anwendung zugeschrieben, die das Dokument empfängt.
Auf der Ebene des Renderings interagieren Schriftarten mit der Shaping-Engine, dem Hinting-System und der Anti-Aliasing-Pipeline – und zwar auf eine Weise, die vom jeweiligen Design der Schriftart und den darin eingebetteten Anweisungen abhängt. Eine für den Windows-Rendering-Stack optimierte Schriftart wird unter FreeType anders dargestellt – noch bevor es überhaupt zu einer Ersetzung kommt –, was zu den sichtbaren Unterschieden zwischen den verschiedenen Umgebungen beiträgt.
Was die Schriftartenebene als Instrument zur Kundenbindung (Lock-in-Mechanismus) besonders wirksam macht, ist die Kombination aus rechtlicher Nichtverfügbarkeit und mangelndem Wissen der Nutzer. Die proprietären Schriftarten, die im Zentrum des Problems stehen – Calibri und Cambria sowie zuvor Arial und Times –, sind unter keiner Open-Source-Lizenz verfügbar.
Hierbei handelt es sich um eine rechtliche Einschränkung, die von Open-Source-Software nicht überwunden werden kann. Nutzer nehmen sie jedoch nicht als Lizenzproblem wahr, sondern als Softwareproblem – nicht als Folge einer Strategie, sondern als Beweis dafür, dass Open-Source-Software mit alltäglichen Dokumenten nicht zurechtkommt.
Lediglich Aptos, die neueste der proprietären Schriftarten von Microsoft, wird unter einer teilweise restriktiven Lizenz bereitgestellt, da die Nutzung an einen Download von der Microsoft-Website geknüpft ist. Sie kann daher auch von Linux-Nutzern installiert und legal verwendet werden; da dies jedoch nicht hinreichend kommuniziert wurde, ist der Lock-in-Mechanismus zwar abgeschwächt, aber nicht beseitigt.
Warum „unsichtbar“ das Schlüsselwort ist
Jede der drei Ebenen wäre ein beherrschbares Problem, wenn sie sichtbar wäre und die Nutzer klar erkennen könnten, dass der Fehler im proprietären Format, in den unzureichenden Rendering-Spezifikationen oder in der proprietären Schriftart begründet liegt. Sichtbare Probleme lassen sich durch präzise Diagnose und gezielte Eingriffe beheben.
Die Stärke dieses Ansatzes liegt in seiner Verschleierung. Jede Ebene fungiert als Signalumwandler: Sie nimmt die Ausgabe der darunterliegenden Ebene auf und gibt sie als etwas aus, das wie ein anderes Problem aussieht.
So erzeugt die Abhängigkeit von proprietären Schriftarten einen Fehler, der wie ein Software-Rendering-Problem aussieht; das Rendering-Problem erzeugt einen Fehler, der wie ein Implementierungsmangel aussieht; und schließlich erzeugt die Struktur des proprietären Formats einen Fehler, der wie ein Verstoß gegen Standards aussieht.
Bis der Fehler den Benutzer erreicht, ist sein Ursprung vollständig verschleiert, und die Verantwortung wird systematisch auf das letzte Glied in der Kette abgewälzt: die Open-Source-Software, die lediglich ein Dokument anzeigen wollte, das den Fehler umgehen sollte.
Dies ist kein Zufall aufgrund schlechten Designs.
Software, die zufällige Fehler erzeugt, wäre ein Problem für das entwickelnde Unternehmen, da die Frustration der Benutzer auf die ursprüngliche Software zurückfallen würde. Ein System, das Fehler an der Schnittstelle zu Wettbewerbern so erzeugt, dass diese stets den Wettbewerbern zugeschrieben werden, ist ein Wettbewerbsvorteil.
Hier ist die Frage der Absicht weniger wichtig als die der Struktur: Ungeachtet der Motivation hinter den ursprünglichen Designentscheidungen fungiert die resultierende Architektur als Einschränkung, und ihre Auswirkungen sind beobachtbar und messbar.
Wie die Politik reagierte – und wo sie versagte
Die politischen Maßnahmen gegen die Bindung an bestimmte Dokumentenformate (sog. „Document Lock-in“) haben sich auf das Format konzentriert: Es wurde die Verwendung von ODF und offenen Formaten bei der öffentlichen Auftragsvergabe vorgeschrieben sowie sichergestellt, dass Behördendokumente ohne proprietäre Software erstellt und eingesehen werden können. Leider waren diese Maßnahmen so gut wie nie mit Sanktionen zur Durchsetzung der Vorgaben verbunden, weshalb die Regeln häufig missachtet wurden.
Zudem ließen diese Formatvorgaben die Verwendung proprietärer Schriftarten in Dokumentvorlagen außer Acht; indem man sich also nur auf die oberste Ebene konzentrierte, ließ man die darunterliegende Ebene unangetastet und voll funktionsfähig – dort, wo sie weniger sichtbar und politisch weniger brisant und somit beständiger ist.
Beim Einsatz von Open-Source-Software kommt es im Umgang mit Dokumenten weiterhin zu Problemen, für die die Nutzer meist die Software verantwortlich machen. Der politische Wille hinter der Vorgabe bestimmter Dateiformate wird zunehmend durch Nutzerbeschwerden über Interoperabilitätsprobleme untergraben; diese scheinen dem eigentlichen Versprechen offener Standardformate zu widersprechen.
Eine Institution, die LibreOffice einführt, dabei aber die konsistente Darstellung vernachlässigt – etwa indem sie in einer gemischten Infrastruktur aus Windows- und Linux-Systemen den Dokumentenaustausch zulässt, ohne zu berücksichtigen, dass unterschiedliche Darstellungen keinen Softwarefehler darstellen –, riskiert die Entstehung interner Interoperabilitätsprobleme. Solche Probleme könnten als Argument für eine Rückkehr zur Monokultur dienen.
Der Rendering-Ebene wurde in politischen Regelwerken bislang kaum Beachtung geschenkt. Kein bedeutendes Rahmenwerk zur digitalen Souveränität legt Anforderungen an die Rendering-Treue fest. Kein Beschaffungsstandard definiert Konformität über die visuelle Konsistenz hinweg zwischen verschiedenen Implementierungen.
Die Instrumente zur Bewältigung dieses Problems – Referenzimplementierungen für das Rendering, Testsuiten und Benchmarks zur Wiedergabetreue – existieren lediglich als Prototypen oder Vorschläge und wurden bislang in kein ernsthaftes politisches Regelwerk integriert.
Dieses Muster zu kennen, ist ein politischer Akt
Die unsichtbare Schichtung von Abhängigkeiten ist ein Muster, das aus fast fünfzig Jahren unregulierter Entwicklung von Software für die persönliche Produktivität entstanden ist und den Weg zur digitalen Souveränität erheblich verkomplizieren könnte.
Es ist wichtig, diesem Muster einen Namen zu geben, damit es in politischen Diskussionen, parlamentarischen Anfragen, Vergabevorschriften und der öffentlichen Debatte über digitale Souveränität auf allen Ebenen, einschließlich der Medien, Anwendung finden kann.
Die unsichtbare Schichtung von Abhängigkeiten verbindet Phänomene, die scheinbar nicht zusammenhängen – Inkompatibilitäten von Dokumentformaten, Darstellungsabweichungen, Fehler bei der Schriftartersetzung – und zeigt, dass sie Ausdruck derselben zugrundeliegenden Architektur sind.
Sobald diese Phänomene nicht mehr als isolierte technische Probleme, sondern als Muster betrachtet werden, zeichnet sich eine angemessene politische Reaktion deutlicher ab; denn es genügt nicht, lediglich eine einzelne Ebene zu korrigieren und einen einzigen Standard vorzuschreiben – auch wenn dies einen grundlegenden ersten Schritt darstellt.
Es ist erforderlich, sämtliche Abhängigkeiten transparent zu machen und sie in Strategien zur Interoperabilität zu integrieren, die explizit und gezielt auf Formate, Rendering und Schriftarten eingehen, wobei Durchsetzungsmechanismen für alle drei Ebenen gelten müssen.
Die Community für Open Source und offene Standards hat die technischen Grundlagen für echte Interoperabilität geschaffen: Offene Formate sind ausgereift und zuverlässig, Open-Source-Anwendungen sind den Anforderungen vollauf gewachsen, und es gibt Hunderte von frei lizenzierten Schriftarten, von denen viele metrisch mit proprietären Pendants kompatibel sind.
Die Architektur der Anbieterbindung (Lock-in) besteht nicht fort, weil die Alternativen unzureichend wären. Sie bleibt bestehen, weil die Politik noch nicht gelernt hat, über die sichtbare Oberfläche der Formatkonformität hinauszublicken und jene tieferliegenden Ebenen zu erkennen, auf denen proprietäre Abhängigkeiten weiterhin wirken – unsichtbar und ignoriert –, indem sie genau jene Funktion erfüllen, für die sie einst konzipiert wurden.
