Mehr Openness für Verlage – Open Source, offene Standards und offene APIs

Ohne Software entsteht im Verlag kein Buch mehr. Von der Produktplanung über Manuskriptbearbeitung, Satz, Datenkonvertierung bis hin zur Auslieferung – viele lebenswichtige Prozesse sind heute ohne die Unterstützung von Software nicht mehr denkbar. Dabei machen sich Verlage nicht selten von einzelnen Software-Anbietern abhängig. Open-Source-Software, offene Standards und offene Schnittstellen bieten einen Ausweg.

Während man bei Papier-Engpässen auf einen anderen Papierlieferanten ausweichen kann, ist ein Anbieterwechsel bei Software nicht ohne weiteres möglich. Oftmals fehlt auf dem Markt ein Produkt mit der gleichen Funktionalität. Vielleicht sind die Daten in einem proprietären Dateiformat gespeichert und können nur mit der Anwendung des Herstellers verarbeitet werden. Oder die Kosten eines Umstiegs wären schlicht zu hoch.

Diese Form der Abhängigkeit von einem einzigen Anbieter wird als Vendor-Lock-In bezeichnet. Wer schon mal versucht hat, für seinen Staubsauger einen passenden Beutel zu kaufen, kennt das Prinzip. Unter nüchternen Typenbezeichnungen wie MX 88, Y 101 oder S 67 wartet ein schier undurchdringlicher Dschungel an zueinander inkompatiblen Staubsaugerbeuteln. In der Software-Industrie ist es auch üblich, die Interoperabilität absichtlich einzuschränken. Epische Endbenutzer-Lizenzvereinbarungen, proprietäre Datenformate, herstellerspezifische Standards und nicht-öffentliche Dokumentationen sind probate Mittel. Auf diese Weise wird versucht, einen Wechsel des Kunden zu einem anderen Anbieter unwirtschaftlich zu machen.

Die Risiken eines solchen Vendor-Lock-Ins sind vielfältig. Die Software entwickelt sich zwar weiter, aber nicht in die gewünschte Richtung. Bei InDesign werden etwa im Gegensatz zum XML-basierten IDML-Format die nativen XML-Features seit CS4 von Adobe nicht weiter entwickelt. Noch schwerer wiegt es, wenn der Anbieter Entwicklung und Support ganz einstellt, wie bei Chikriis VBA-Plugin Word2TeX geschehen. Was ein Wechsel des Lizenzmodells bedeutet, ist seit der Einführung der Creative Cloud bekannt. Nachdem neue Versionen ausschließlich über ein Abo bezogen werden konnten, war die Stimmung unter Anwendern ähnlich trüb wie die dunkelgrauen InDesign-Paletten.

Doch wie lassen sich für Verlage solche Abhängigkeiten minimieren? Souveränität lässt sich mit den Worten des Kybernetikers Heinz von Foerster als Anzahl der existierenden Wahlmöglichkeiten beschreiben. Je weniger die Entscheidung durch die Anzahl der Wahlmöglichkeiten determiniert ist, desto mehr Freiheitsgrade bestehen. Souveränes Handeln muss nach Foerster die Anzahl seiner Wahlmöglichkeiten erhöhen. Mehr Wahlmöglichkeiten versprechen Open-Source-Software, offene Standards und offene Schnittstellen.

Open Source

Die Zeiten sind vorbei, als Open-Source-Software noch das Image von Bastelprojekten idealistischer Feierabend-Programmierer anhaftete. Android, Apache HTTP Server, Blender, Chromium, Firefox, Libre Office, MySQL, VLC Media Player und WordPress sind Beispiele für erfolgreiche Open-Source-Projekte, und selbst der frühere Open-Source-Gegner Microsoft wirbt, dass in seiner Azure Cloud auch Linux läuft.

Grundlage des Erfolgs von Open-Source-Software ist frei zugänglicher Quelltext, der dank permissiver Lizenzen wie der GPL oder BSD-Lizenz beliebig oft kopiert, verbreitet und genutzt werden darf. Die Freiheit gegenüber proprietärer Software liegt auf der Hand: Man hat das Recht, die Software notfalls unabhängig vom ursprünglichen Anbieter zu nutzen, zu kopieren und auch weiterentwickeln zu lassen.

Zur typischen Software eines Verlags gehören Schriften. Nachdem Monotype sich Linotype, Bitstream und im letzten Jahr auch FontShop einverleibte, existiert im Markt der Schriftanbieter jedoch nur noch ein großer Player. Infolge der Monopolstellung besteht daher auch bei Schriften das Risiko höherer Lizenzkosten. Für E-Books, Websites und Apps waren die bestehenden Lizenzmodelle für viele Verlage ohnehin nicht mehr wirtschaftlich.

In diesem Bereich haben sich freie Schriften mit SIL Open Font License (OFL) etabliert. Sofern ein Verlag die Schrift nicht als solche verkauft, erlaubt die Lizenz die uneingeschränkte Verwendung in kommerziellen Projekten, ganz gleich ob in gedruckter oder digitaler Form. Unter der Bedingung, dass man nicht den Original-Schriftnamen beibehält, darf man den Zeichensatz verändern oder erweitern lassen. Man kann ruhig mal Monotype fragen, was ein solches Paket kosten würde.

Durch Open-Source-Alternativen ist die Risiko eines Vendor-Lock-Ins bei Schriften noch vergleichsweise gering. Anders sieht es freilich bei WYSIWYG-Satzprogrammen aus. Hier führt kein Weg an InDesign vorbei. Der ewige Konkurrenten Quark ist technologisch abgehängt und auch nicht viel günstiger zu haben. Das freie Satzprogramm Scribus zeigt zwar mit Farbmanagement und PDF-Export-Optionen vielversprechende Ansätze, aber zu einer wirklichen professionellen Alternative reicht es bislang noch nicht. In anderen Segmenten wie z.B. Bürosoftware, Datenbanken, Content-Management-Systemen, sowie Prüf- und Konvertierungs-Tools finden Verlage einfacher professionelle Open-Source-Lösungen.

Dennoch kann auch Open Source Software Abhängigkeiten verursachen, selbst wenn diese geringer ausfällt als bei proprietärer Software. Wenn eine Geschäftsbeziehung in die Brüche geht, kann man zwar jederzeit den Code abzweigen und weiterentwickeln lassen. Doch je komplexer und anspruchsvoller die Software ist, desto schwieriger gestaltet sich die Suche nach geeigneten Kandidaten für die Weiterentwicklung. Für dieses Problem stellen offene Standards einen Schlüssel dar.

Offene Standards

Die Verlagsbranche fußt auf einer Vielzahl von Standards: Die DIN-Formatreihe, ISBN zur eindeutigen Identifikation von Publikationen, ONIX zum Austausch von Metadaten, DOCX zur Textverarbeitung, PDF für Druckvorlagen und nicht zuletzt EPUB für elektronische Bücher.

Diese Standards haben gemein, dass es sich um offene Standards handelt. Non-Profit-Organisationen wie DIN, IDPF und ISO tragen Sorge dafür, dass die Standards öffentlich zugänglich sind. Zwar gibt es auch bei DIN und ISO Lizenzen und Schutzgebühren, allerdings sind diese diskriminierungsfrei, sprich sie sind für alle gleich. Die Weiterentwicklung von offenen Standards geschieht unabhängig von einem einzelnen Anbieter und ist für Dritte offen. Dass ein Format wie PDF ursprünglich als proprietäres Format von Adobe entwickelt wurde, ist kein Widerspruch. Oft werden Formate erst nachträglich einer Normierungsorganisation zur Standardisierung übergeben, weil sich der Hersteller durch eine Freigabe eine weitere Verbreitung erhofft.

Bevor PDF ein offener Standard wurde, galt es in der Verlagsbranche schon als Industriestandard. Adobes Format vereinfachte den Austausch von Druckdaten in einer Weise, dass es schnell Eingang in zahlreiche Software-Anwendungen fand. Im Unterschied zu offenen Standards werden Industriestandards jedoch nicht von unabhängigen Non-Profit-Organisationen, sondern von einzelnen Unternehmen definiert und unterliegen damit noch stärker kommerziellen Interessen. Adobe wollte mit dem PDF auch Segmente jenseits der Druckvorstufe erobern und überfrachtete es dabei mit interaktiven Features wie JavaScript, Adobe Flash und Video. In der Folge löste PDF zwischenzeitlich sogar Word als größten Vektor für Malware ab.

Standards bilden den technologischen Kanon einer Branche. Anders verhält es sich bei herstellerspezifischen Standards. Diese wurden durch einen Hersteller oder ein Konsortium mehrerer Hersteller aufgestellt und sind üblicherweise durch proprietäre Lizenzen geschützt. Spezifikation und Dokumentation sind meistens nicht öffentlich verfügbar bzw. ist der Zugang auf Lizenznehmer beschränkt.

Herstellerspezifische Standards sind jedoch nichts Ungewöhnliches. Jeder Hersteller stellt für eigene Prozesse oder Formate in irgendeiner Form Standards auf. Vielleicht besteht noch kein industrieweit anerkannter Lösungsweg, bestehende Standards haben sich nicht bewährt oder einfach nicht am Markt durchgesetzt. Die Frage ist nur, ob man als Unternehmen einen herstellerspezifischen Standard wählen sollte, wenn für den gleichen Zweck auch offene Standards existieren?

Vor dieser Entscheidung stehen Verlage, wenn sie sich für ein XML-Schema bzw. eine DTD entscheiden müssen. Es gibt drei Möglichkeiten: Der Verlag kann eine verlagseigene DTD entwickeln, eine Dienstleister-DTD auswählen oder sich für eine Standard-DTD entscheiden.

Eine verlagseigene DTD ist ein herstellerspezifischer Standard, nur dass der Verlag selbst der Hersteller ist. Die Entwicklung einer verlagseigenen DTD entsteht meist aus dem Eindruck, dass die eigenen Inhalte sich weder durch Standard- noch durch Dienstleister-DTDs gut abbilden lassen.

Man sollte sich gut überlegen, ob die Entwicklung eines eigenen Schemas auf der grünen Wiese lohnt. Zunächst ist es aufwändig, für alle Inhalte von Grund auf neue XML-Strukturen zu entwickeln. Der Prozess der Definition eines Schemas zieht sich nicht selten über Jahre hin. Oft kristallisieren sich in diesem Prozess Probleme erst spät heraus. So tauchen häufig mit neuen Titeln unerwartete Inhaltselemente auf oder Anforderungen von beteiligten Systemen blieben unberücksichtigt. Zudem ist eine Eigenbau-DTD nicht gerade billig und birgt die Gefahr eines Self-Lock-In. Die Aufwände für Entwicklung und Pflege des Schemas trägt der Verlag allein. Die Kosten steigen auch, beteiligte Systeme und Dienstleister in die eigene Insellösung zu integrieren. Für die Inhalte können keine Bearbeitungswerkzeuge von der Stange verwendet werden, was die Kosten zusätzlich erhöht.

Eine vom Dienstleister entwickelte DTD mag hier als Ausweg erscheinen, schließlich hat er bereits die Kosten für die Entwicklung getragen und sich die Lösung bei seinen Kunden bewährt. Die Risiken eines Vendor-Lock-Ins sind hier aber offensichtlich. Die DTD ist erstmal nur zur Toolchain des Dienstleisters kompatibel. Drittanbieter sind meistens rar, nicht zuletzt wenn der freie Zugang zur DTD durch Lizenzen oder andere Barrieren eingeschränkt ist. Dienstleister-DTDs enthalten aber auch bestimmte Eigenheiten, die sich aus der speziellen Arbeitsweise des Dienstleisters erklären.

Das Hub-Schema von le-tex basiert z.B. auf der Standard-DTD DocBook, jedoch lässt es eine flache Ansammlung von Absätzen und Tabellen zu, und es wurde um das tab-Element für Tabulatoren und CSS-Attribute für Stilinformationen ergänzt. Daher wird das Hub-Schema auch nur als temporäres Zwischenformat für Prüfungen und Konvertierungen verwendet, am Ende erhält der Kunde das Verlags-XML in einer Standard-DTD. Die CSS-Attribute lassen sich dank XML-Namespace mit einem einzeiligen Template entfernen.

Dienstleister-DTDs enthalten bestimmte Elemente nur aus prozesstaktischen Gründen, die sich für den Hersteller als günstig erwiesen haben. Ist die Zahl der Stufen eines Registereintrags wie bei InDesign auf vier beschränkt? Werden Inhalte, die das Schema nicht abbildet, einfach in Pseudo-Elemente gepackt? Oder sieht das Schema Anweisungen für einen speziellen Satzautomaten vor? Eine Dienstleister-DTD kann ihre Herkunft nicht verbergen.

Offene Standards wie DocBook, JATS/BITS und TEI sind hingegen allgemeingültig und herstellerunabhängig. Aufgrund ihrer weltweiten Verbreitung profitiert man von Netzwerkeffekten. Für TEI existiert bereits eine Reihe von Tools und man kann sich bestehende Erfahrungen und Best Practices von anderen Nutzern zu Eigen machen. Dieser Ansicht schließt sich auch die Deutsche Forschungsgemeinschaft zum Thema Digitalisierung an:

„Wenn nicht triftige Gründe dagegen sprechen, müssen Volltexte von Drucken und Handschriften nach dem Modell der Text Encoding Initiative (TEI) kodiert bzw. mit Markup versehen werden. Als transparentes XML-Format ist TEI, sofern sorgfältig dokumentiert, auch für die Langzeitarchivierung die prospektiv beste Wahl.“*

Offene APIs

Die Softwareausstattung eines Verlags erschöpft sich heute nicht mehr in ein paar DTP- und Office-Lizenzen. Hinzu gekommen sind Systeme für Content-Management, Customer Relationship Management, Metadatenverwaltung, Production Tracking usw. Verlage sollten daher schon im eigenen Interesse darauf achten, dass eine Software auch offen in Bezug auf ihre Schnittstellen ist. Eine wesentliche Aufgabe bei der Einführung neuer Software ist es, diese in die bestehende Systemlandschaft zu integrieren. Bestimmte Funktionen einer Software können in Form einer Programmierschnittstelle anderen Programmen zur Verfügung gestellt werden. Dafür hat sich der englische Begriff Application Programming Interface, kurz API etabliert. Je mehr Funktionen die API bietet und je besser diese dokumentiert sind, desto leichter fällt es Entwicklern die Software mit anderen Systemen zu verknüpfen. Zudem können Drittanbieter die API nutzen um Plugins zu schreiben, welche neue Funktionen hinzufügen.

Im Gegensatz zu offenen APIs setzt der Zugang von proprietären APIs eine Lizenz vom Anbieter voraus. Auf diese Weise kann der Anbieter den Kreis möglicher Drittanbieter klein halten und an deren Entwicklungen noch mitverdienen. Benötigt ein Verlag neue Features, ist also sichergestellt, dass der erste Weg immer über den Software-Anbieter geht.

Dabei ist es kein Geheimnis, dass eine Software mit einer offenen API attraktiver für Drittanbieter ist und viel Software von Drittanbietern mithin wiederum den Nutzen der Software steigert. Ein Beispiel für diesen Netzwerk-Effekt ist die Blogging-Plattform WordPress. Der Erfolg von WordPress gründet sich nicht darauf, dass es im Vergleich zu anderen Blogging-Systemen mehr Funktionen geboten hätte, sondern auf sein reiches Ökosystem an Plugins. Die Grundlage schuf der sogenannte WordPress Codex, eine gut dokumentierte, offene API mit der man auf fast alle Funktionen des Systems zugreifen konnte.

Je weniger eine Software isoliert funktioniert, desto nützlicher erweist sich eine offene API. Sie senkt die Barriere für das Schreiben von Plugins und erleichtert die Integration in die bestehende Systemlandschaft.

Wie Print und E-Book können offene APIs auch ein Distributionskanal sein. Das Nachrichtenportal The Guardian stellt seinen Content über eine offene API zur Verfügung. Damit kann der Content von Drittanbietern in deren Webseiten, Apps oder Widgets verwendet werden. Auf diese Weise erreicht man eine größere Zielgruppe und stärkt auf Umwegen die eigene Marke. Zudem kann man von der Entwicklung neuer Ideen profitieren und diese für die eigene Plattform adaptieren. Nicht zuletzt lässt sich eine offene API selbst monetarisieren. So kann man für zahlende Nutzer unbegrenzte Zugriffe zulassen oder zusätzlichen Premium-Content ausliefern.

Verlage können mit offener Software nicht nur von Netzwerkeffekten profitieren und ein Vendor-Lock-In vermeiden. Die Paradigmen offener Software – Transparenz, Kooperation und freier Zugriff auf Information – haben nicht nur wesentlich zur Entwicklung des World Wide Webs beigetragen, sondern auch die Verlagsbranche beeinflusst. Open Access ist inzwischen bei Wissenschaftsverlagen ein selbstverständliches Geschäftsmodell. Verlage kooperieren im Rahmen des IDPF bei der Weiterentwicklung des EPUB-Standards und offene APIs sind ein wichtiger neuer Distributionskanal. Wer mehr Openness wagt hat nicht viel zu verlieren – außer ein paar Abhängigkeiten.

Kommentar schreiben

Es reicht nicht, einfach nur mehr Auswahl zu haben, denn die individuelle Anpassung an eigene Bedürfnisse wäre dann weiterhin bei keinem der proprietären Anbieter möglich. Eine Schrift unter OFL darf verkauft werden, wenn man eine kleines Programm um selbige herum packt (kommerzielle Nutzbarkeit ist ein wichtiger Grundstein für das Freie-Software-Ökosystem). Was wäre, wenn die Leute, die InDesign mieten, auch nur die Hälfte desselben Geldes in die Scribus-Entwicklung stecken würden? Bei der Abhängigkeit von der Komplexität frei lizenzierter Software ist der entscheidende Unterschied, dass diese in der Natur der Sache liegt und nicht absichtlich künstlich zwecks Vendor-Lock-In eingebaut wurde. Von „Offenheit“ kann bei DOCX keine Rede sein (http://www.groklaw.net/article.php?story=20070123071154671, Gedruckt sieht die Spezifikation so aus: http://noooxml.wikidot.com/rice-pudding). Was XML-Schemen (oder nicht langsam auch Relax-NG?) angeht, sollten die Daten idealerweise mit XSLT oder einem dedizierten Konverter in andere Formate überführt werden können. Was dann noch fehlt, ist die freie Lizenzierung der Inhalte. Wo der Verlag kein restriktiver Rechteverwerter, Risiko-Investor und Manuskript-Spekulant mehr ist, sondern ein moderner Dienstleister in einem ganzheitlich digitalverträglichen Ökosystem.

Was offene Formate, offene Schnittstellen und frei lizenzierte Software angeht, möchte ich mich ausdrücklich für den Aufbau von einem Kompetenz-Pool und einer Sammlung interoperabler Software-Bausteine einsetzen. Bei Interesse bitte einfach melden.

Was Scribus betrifft, stimme ich zu. Das Projekt könnte mit mehr Sponsoring und auch personeller Unterstützung schon weiter sein. Aber es gibt ja auch Open-Source-Satzsysteme wie LaTeX oder Vivliostyle, die in bestimmten Bereichen InDesign ersetzen können.
In Sachen DOCX stimmt es natürlich, dass so Hersteller-nahe offene Standards ihre Tücken haben. Aber wenigstens gibt es eine offene Spezifikation. Und auch wenn sie um die 6.000 Seiten hat (ich rede vom PDF), hat sie uns bei der Entwicklung unserer Open-Source DOCX-Tools schon viel geholfen. Und auch die Entwickler von LibreOffice oder anderen Tools haben mit dem ISO-Standard eine gemeinsame Geschäftsgrundlage.

Bezüglich DOCX stimmt es natürlich, dass besser besser ist als nichts, aber angesichts der Umstände, dass Microsoft die Offenlegung nur auf Druck der EU hin gemacht hat (insbesondere England hatte gedroht, Microsoft Office nicht mehr länger in der Verwaltung einzusetzen, Microsoft hat dem womöglich mit unlauteren Geschäftspraktiken entgegenzuwirken versucht), dass ODT vor DOCX ISO-standardisiert wurde und letzteres nun mit ersterem konfligiert, dass Microsoft Word ODT ebenfalls kann und evtl. sogar verlustfrei, dass DOCX intern Datenformate und Konventionen verwendet, die von den für diese Zwecke vorgesehenen ISO-Standards abweichen, muss man feststellen, dass dieses „pseudo-offen“ eben nicht ausreicht. Vor allem bräuchte es mindestens eine frei lizenzierte Anwendung, die DOCX vollständig unterstützt, und ob dies bei LibreOffice/OpenOffice bereits der Fall ist?

Ich persönlich habe noch nie DOCX ausgelesen, aber ich weiß von Fällen, wo infolge dieses Formats einige Zeit unnötig verbraten werden musste. Stattdessen bin ich von RTF betroffen gewesen, und das zu lesen, war ebenfalls nicht gerade billig. Bleibt also zu hoffen, dass Microsoft sich mal auf einen Zettel schreibt, was an ODT „unzureichend“ sein soll, damit dann ein Konsortium zusammengesetzt aus den verschiedenen Textverarbeitungsprogramm-Anbietern ein DOCX2/ODT2 verabschiedet, welches dann auch Microsoft als primäres Dokumentenaustauschformat zu unterstützen hat. Von freier Lizenzierung im Jahr 2015 für ein Textverarbeitungsprogramm mal ganz zu schweigen.

DOCX ist ein Möchtegern-Standard.

Die Nennung unter „Offene Standards“ kann aufgrund der nach wie vor vorhandenen propritären Bestandteile nur als gewagt bezeichnet werden.

Die Norm ISO/IEC 29500 kann sich jeder besorgen. Entwickler können sich die Norm zu Nutze machen, um Tools zum Lesen und Schreiben von DOCX-Daten zu entwickeln. Die frei verfügbare Norm hat beispielsweise sehr geholfen, unseren DOCX-Konverter zu entwickeln (https://github.com/transpect/docx2hub). Welche proprietären Bestandteile beim DOCX-Format sind denn genau gemeint?

> Welche proprietären Bestandteile beim DOCX-Format sind denn genau gemeint?

http://www.groklaw.net/staticpages/index.php?page=20051216153153504#objections oder genauer http://www.groklaw.net/article.php?story=20070123071154671. Der Punkt ist nicht, dass man diese Probleme nicht technisch umschiffen könnte, sondern, dass sie völlig unnötig (und womöglich Absicht) sind und in einem Standard nichts verloren haben.

Im verlinkten Repository unter Copyright (c) 2015, transpect.io widerspricht „All rights reserved“ der X11-Lizenz direkt darunter.

Es handelt sich nicht um eine X11-Lizenz, sondern um eine BSD 2-Clause-Lizenz. Hier ist das Lizenz-Template:
https://opensource.org/licenses/BSD-2-Clause

Oh, Entschuldigung, X11- statt BSD-2-Clause-Lizenz war einfach nur Unachtsamkeit meinerseits. Ist aber auch eine ziemlich ungünstige Formulierung im Lizenztext… Das Fehlen von Copyleft oder die Aushebelung von Nutzerrechten im Online-Betrieb als SaaS haften darüber hinaus ohnehin beiden Lizenzen als ein Mangel an.

Copyleft wie bei der GPL ist für Kundenprojekte unrealistisch. Wir verwenden bei le-tex die BSD-Lizenz, weil sie gerade so liberal ist, dass die Business-Logik für den Kunden auch wieder Closed Source sein darf. Die GPL ist aus meiner Sicht restriktiver als die FreeBSD weil sie einen dazu verdonnert, jede Code-Zeile wieder als Open Source zu publizieren. Das macht aber bei kundenspezifischen Anpassungen überhaupt keinen Sinn und verhindert eher die Verbreitung von Software unter dieser Lizenz in kommerziellen Anwendungen.

Wenn man keine monolithische Architektur der Software hat, sondern eine lose Kopplung generalisierter Komponenten, dann findet auch kein Zusammenlinken zu einer gemeinsamen ausführbaren Datei statt, und restriktiv lizenzierte Komponenten dürfen zusammen mit Komponenten unter GPL verwendet werden, ohne dass Erstere ebenfalls frei lizenziert werden müssen. Wenn aber eine restriktiv lizenziertes Programm von freier Software profitiert, dann sollte es seinerseits etwas zurückgeben, oder doch wenigstens den Nutzern die Rechte gewähren, die zum freien Anteil gehören. Bei einem gemischt lizenzierten, zusammengelinkten Executable wäre der freie Code ohne den proprietären nicht zu demselben Executable zu kompilieren.

Davon gänzlich unbenommen ist der Fall, wo ein Kunde eigene Änderungen am freien Code braucht, das daraus resultierende Kompilat aber nur intern verwendet wird und keine Distribution zu anderen Nutzern erfährt. In diesem Fall besteht keine Veröffentlichungspflicht, sodass es in der Praxis keine Rolle spielt, ob die kundenspezifischen Anpassungen frei lizenziert sind oder nicht, weil ohnehin niemand außerhalb der Firma Zugang zu diesem Programm hat oder es via SaaS nutzen kann (bei der AGPL).

Wenn aber frei lizenzierter Code unter X11 oder BSD-2-Clause oder sonst einer freien Lizenz ohne Copyleft von einem Kunden an dessen Kunden weitergegeben werden soll oder per SaaS genutzt werden kann, und sich der Kunde entscheidet, das Gesamtpaket restriktiv zu lizenzieren, dann wird nicht nur dem Endnutzer Unrecht getan, sondern auch die ursprüngliche Intention der freien Lizenzierung des ursprünglichen Codes ins Gegenteil verkehrt.

Ich weiß jetzt freilich nicht, aus welchem Grund restriktive Lizenzierung bei den Kunden von le-tex angeblich wichtig sein soll; klassischerweise wären der Verkauf von Kopien oder des Zugangs als Geschäftsmodell oder die Erzeugung von künstlichen Abhängigkeiten naheliegend.