Liebe Verlagsbranche, wir müssen über Openwashing reden. Manchmal beschleicht mich das Gefühl, dass dich bestimmte Trends zehn Jahre später erreichen. Das ist nicht gut, schlimm wird es aber, wenn du Versprechungen Glauben schenkst, die schon vor zehn Jahren durchschaut wurden, etwa dass man beim Jamba-Sparabo was sparen würde.
Was ist Openwashing? Im Grunde geht es schlicht darum, einem Projekt aus Marketingzwecken den Anstrich von Offenheit zu geben, obwohl es weiterhin so geschlossen und undurchsichtig ist wie ein mit hohen Hecken umsäumter Schrebergarten. Häufig findet man Openwashing im Softwarebereich, wo sich diese Praktik gegen die Konkurrenz tatsächlicher Open-Source-Lösungen richtet.
Das Etikett „offen und frei“ hat auch in der Verlagsbranche Einzug gehalten. Ein Verlagsdienstleister bietet das XML-Schema seines proprietären Produktes zum Download an und spricht von einem „offenen XML-Datenformat“, das „frei zugänglich“ sei, an anderer Stelle ist von einem „offenen Datenstandard“ die Rede. Ich mag keine Absicht unterstellen, aber es scheint sich ein Missverständnis zu verfestigen, wenn mich Verlagsleute darauf ansprechen und angeben, dass dieses Produkt nun auch „Open Source“ sei. Das zeigt wie leicht diese Begriffe verfangen, obwohl das Produkt selbst nicht Open Source ist und nicht mal dessen Dokumentenformat wirklich offen ist.
Das Dokumentenformat ist unter einer CreativeCommons CC BY-ND 4.0-Lizenz veröffentlicht. Diese Lizenz besagt, dass man das „das Material in jedwedem Format oder Medium vervielfältigen und weiterverbreiten“ darf, verbietet aber sogenannte Bearbeitungen:
Keine Bearbeitungen — Wenn Sie das Material remixen, verändern oder darauf anderweitig direkt aufbauen, dürfen Sie die bearbeitete Fassung des Materials nicht verbreiten.
Bei freier Software geht es aber gerade darum, dass man den Code verändern und erweitern darf. Solche Anpassungen sind meist sogar notwendig, damit man den Code in andere Software integrieren kann. Daher haben sich in der Open Source Community eine Reihe von Software-Lizenzen wie die BSD- oder GPL-Lizenz etabliert, welche diesen Punkt ausdrücklich erlauben, um für alle Beteiligten Rechtssicherheit zu schaffen und sie vor Patentklagen zu schützen.
Eine CC-Lizenz für Software zu verwenden ist unüblich – so unüblich, dass sogar die CreativeCommons-Organisation selbst ihre, für kreative Inhalte wie Texte, Bilder und Musik geschaffenen Lizenzen nicht für Software empfehlen. Auf der Website von CreativeCommons heißt es daher:
We recommend against using Creative Commons licenses for software. Instead, we strongly encourage you to use one of the very good software licenses which are already available. We recommend considering licenses listed as free by the Free Software Foundation and listed as “open source” by the Open Source Initiative.**
Openwashing betrifft aber nicht nur Lizenzen, sondern auch was ein Hersteller veröffentlicht und was geschlossen bleibt. So kann man zwar das XML-Schema kostenfrei herunterladen, nicht aber die Software um das Dokumentenformat zu erstellen oder zu verarbeiten. Für die Anwendung des Herstellers selbst braucht man weiterhin die Lizenz des Unternehmens, was freilich genau das Gegenteil des Versprechens von Open-Source-Software ist, nämlich die Abhängigkeit von einem Anbieter zu lösen und der Community die restriktionsfreie Möglichkeit der Verbreitung und Veränderung des Quellcodes zu geben.
Dass von meinem Laden entwickelte transpect ist hingegen seit 2013 unter einer BSD-Lizenz veröffentlicht und seit 2015 nicht nur in unserem offenen Repository sondern auf Github verfügbar. Das transpect-Modul docx2tex hat sogar über 7.000 Downloads, ohne dass wir dafür einen Cent von den Nutzer:innen sehen wollen – schlimmer noch, wir leisten sogar kostenfreien Support. Das Geschäftsmodell von transpect beruht nicht auf dem Verkauf proprietärer Software-Lizenzen, sondern auf Implementierung, Entwicklung und Support für Geschäftskunden, welche ihre Wünsche auch untereinander in Form eines Interessen-Poolings abstimmen. Der Rest kann sich den Code herunterladen und damit anstellen, was er will.
Gerade die Verlagsbranche hat oft schmerzhaft die Auswirkungen proprietärer Software gespürt: Ob Adobes Wechsel auf ein Abo-Modell für seine CC-Suite, verknöcherte Verlagssoftware oder zuletzt die Abhängigkeit von Amazons Kindle-Ökosystem, zugleich verfügt sie aber auch über starke offene Standards wie ONIX für den Austausch von Metadaten oder EPUB für elektronische Bücher. Gerade bei diesen offenen Standards können sich Verlage selbst in offenen, internationalen Gremien einbringen und Einfluss auf die Entwicklung nehmen, wie z.B. auch bei den tatsächlich offenen XML-Dokumentenformaten wie DocBook, TEI und JATS.
Nicht zuletzt möchte ich hier anmerken, dass ich natürlich das besagte Unternehmen und seine tollen Mitarbeiter:innen sehr schätze. Wir sind zusammen in der kleinen aber feinen XML-Szene engagiert, kooperieren gemeinsam mit anderen Publishing-Dienstleistern auf der Frankfurter Buchmesse und das Unternehmen hat sich seine Sporen damit verdient, innovative Technologien zu pushen oder selbst Open-Source-Projekte mit manpower zu fördern.
Dass man dem Produkt einen offeneren Anstrich geben möchte, ist vielleicht sogar keine schlechte Entwicklung. Es zeigt, dass Open Source und offene Standards offenbar für Verlage ein wichtiges Argument geworden sind. Ganz persönlich fände ich es aber besser, wenn Offenheit kein Kriterium darstellt, weil dann für dich, liebe Verlagsbranche, nur zählt welche Lösung den besseren Job macht.
Ergänzung, 4.12.2020: Nach Gesprächen mit einzelnen Mitarbeiter:innen des Unternehmens, die ich sehr schätze, habe ich mich dazu entschlossen, den Namen des Unternehmens und dessen Produkt zu anonymisieren und die Links auf dessen Webseiten zu entfernen. Auch wenn mir daran gelegen ist, Rücksicht zu nehmen, möchte ich das ausdrücklich nicht als eine Abschwächung meiner geäußerten Kritik verstanden wissen.