Was ist wirklich Open?

Open Source, offene Standards und offene Schnittstellen
für Verlage

Gerrit Imsieke (@gimsieke), le-tex publishing services (@letexml)

transpect User Group, 2019-11-29

CC-BY licensed

Openness-Begriffe

  • Open Source
  • Open Access
  • Open Data
  • Open Standards
  • Open APIs

Fragen

  • Was bringen Open-Source-Entwicklung, offene Standards, APIs?
  • Was kostet es mitzumachen?
  • Was kostet es, nicht mitzumachen?
  • Wie identifiziert man erfolgversprechende Ansätze?
  • Wie kann man als kleiner/mittelgroßer Verlag mit begrenzten Ressourcen teilhaben?

Gliederung

  • Open-Source-Finanzierung: Warum soll ich zahlen, was andere kostenlos nutzen?
    • Beispiele: epubcheck, MathJax, MathML in Chromium
  • Übersicht: Openness-Begriffe und ihre rechtlichen Grundlagen/​Implikationen
  • Offene Standards und APIs im Verlagswesen
  • Interessen-Pooling bei Standard- und Software-Entwicklung
    • Beispiele: EPUB-Standardisierung, transpect

Beispiel epubcheck

EPUB: Offener Standard

epubcheck: Open-Source-Tool

Beispiel epubcheck

Nutzen

  • EPUB-Standard: Verlage müssen (im Prinzip) nur noch ein E-Book-Format unterstützen
  • epubcheck: Konformität wird in der gesamten Branche mit diesem Open-Source-Tool geprüft

Kosten

  • Standardentwicklung kostet
  • Open-Source-Entwicklung kostet noch mehr

Wer sollte die epubcheck-Entwicklung finanzieren?

  • Standardisierungsgremium (aus Mitgliedsbeiträgen)?
  • Distributoren/Händler?
  • Verlage?
  • Entwickler von Lesesystemen?
  • Konvertierungs-Dienstleister?

⇒ Eigentlich Apple 😉

A propos MathML

  • Teil des HTML5-Standards
  • Teil der meisten Formelworkflows in Verlagen
  • Firefox und Safari unterstützen es ohne MathJax (Javascript), Chrome und Edge nicht
  • Javascript-Renderer hat Performance-, Umbruch- und Barrierefreiheitsprobleme

MathML in Chromium

  • 2017: Fundraising-Kampagne von Igalia, le-tex und MathML Association
    • „Wir sind zufrieden mit MathJax“ — Größter STEM-Verlag in D
    • „Nicht in unerem Kerninteresse“ — Größter Schulbuchverlag in D
    • Finanzierung letztlich über Kontakt zu Todd Carpenter (NISO) → Sloan Foundation
  • 2019: Igalia beginnt mit der Implementierung

Open-Source-Grundproblem

Warum soll ich für die Entwicklung von etwas zahlen, was andere dann frei nutzen können (z.B. epubcheck, Readium, Readium LCP)?

  • Weil ich es mir leisten kann
  • vor allem, wenn sich die Last auf viele Schultern verteilt, so dass mein Kostenbeitrag gering ist
  • Weil ich andere kostenlose Dinge nutze, für die andere bereits gezahlt haben
  • Weil ich Richtung/Prioritäten mitbestimmen kann
  • Weil es unabhängig von großen Playern machen kann
  • Wenn niemand ins (EPUB-) Ökosystem investiert, zahlen wir alle fürs (Amazon-) Monopol

Wie sähe die Welt ohne EPUB aus?

Kindle einziges relevantes E-Book-Format

Kompatibel ist, was Kindle Create erzeugt

Vertrieb nur über Amazon

⇒ Investition in Open Source und offene Standards, um Monopole zu verhindern

These

Große Player setzen nur dann auf offene Standards, wenn andere große Player marktbeherrschend zu werden drohen.

Beispiele

  • Internet Explorer als Antwort auf Netscape
  • Apples Hinwendung zu EPUB

Typische Verlage…

  • … sind keine großen Player
  • … haben kaum Interesse an technologischer Alleinstellung
  • … profitieren von Standards
  • … entwickeln sie aber selten mit
  • … sondern warten ab, was sich durchsetzt
  • … haben selten den Anspruch, die Welt zu retten (d.h., begreifen es nicht als ihre Aufgabe, Monopole zu verhindern)

Übersicht: Open-Begriffe und ihre rechtlichen Grundlagen/Implikationen

Rechtl. Rahmen Prozess Resultat-Zugang Weiter­verwendung Patente Haftung
Open Source Urheber­recht offen* offen ja Verzicht* Ausschluss
Open Access Urheberr. (CC-BY*) divers offen lizenzabh. n/a n/a
Open Data Urheberr. (CC-…*) divers offen ja* n/a Ausschluss*
Offene Standards Urheber­recht halb­offen* offen n/a Verzicht* n/a
Offene APIs unklar divers offen unklar unklar divers
* häufig/typisch

Open Source impliziert nicht Open APIs (it’s complicated)

Android und Java-APIs, Oracle America, Inc. v. Google, Inc.

2012, District Court
Keine Patentverletzung, APIs nicht urheberrechtlich geschützt
2014, Federal Circuit
APIs doch urheberrechtlich geschützt, zurück an District Court
2016, District Court
APIs urheberrechtlich geschützt, aber Fair Use seitens Google
2018, Federal Circuit Court of Appeals
APIs urheberrechtlich geschützt, kein Fair Use
Aktuell, Supreme Court
Sind APIs durch Copyright schützbar?

Lehren aus Oracle v. Google

  • Nicht alles, wo open* draufsteht, ist in jedem Sinne open
  • Patent Policy ist wichtig sowohl bei Open-Source-Lizenzen als auch bei Standardisierungsprozessen
  • In dieser juristischen Liga möchte man als Verlag nicht mitspielen**

* Die Java-Referenz-Implementation, OpenJDK, ist Open Source und wird von Oracle gepflegt. Android ist ebenfalls Open Source. Androids Verwendung der Java-APIs verletzt aber angeblich Oracles Copyright, weil Android die Java-Spezifikation nicht ganz spezifikationsgemäß implementiert.

** Obwohl. Stichwort: Leistungsschutzrecht

Was sind Offene APIs?

  • Open API = Public API
  • Schnittstelle zu Open Data oder zum Datenaustausch
  • Meistens über HTTP(S)
  • Manchmal mit Registrierung / API-Key
  • Manchmal mit Volumenbegrenzung
  • Basis für lose gekoppelte Systeme / Microservices

Beispiele

Wofür sind offene APIs gut?

Beispiel: Integrating the Publishing Environment

  • Metadatenaustausch, Druckdatenaustausch, E-Produkt-Austausch, …
    • Weniger Handarbeit (Excel-Pflege, Copy&Paste, …)
    • Vendor-Lock-In durch Interoperabilität verhindern
    • Best-of-Breed-Lösungen ermöglichen
  • IPE: Meta-Standard, der existierende Standards und Applikationen mit Hilfe offener Schnittstellen verbindet
  • Scheint jedoch etwas an Schwung eingebüßt zu haben

Metastandard ≠ allumfassender Standard

(Randall Munroe, CC-BY-NC)

Offene Standards im Verlagswesen

  • ISBN (International ISBN Agency, MVB GmbH)
  • ONIX (EDItEUR)
  • JATS/BITS/STS (NISO)
  • HTML, CSS, WAI, EPUB, … (W3C)
  • DOI (ISO, Intl. DOI Foundation)
  • Job Definition Format (CIP4)
  • …

Offener Standardisierungsprozess

  • freiwillig (keiner muss)
  • nicht-diskriminierend (jeder darf)
  • von interessierten Parteien (nicht nur von einer) organisiert
  • Vorteil für alle: Netzwerkeffekte, Kostenersparnis
  • Vorteil für Mitwirkende: „Wer schreibt, der bleibt“
  • Aber: i.d.R. pay to play (Mitgliedschaft in Gremium)

Bis wieviel € ist ein Standardisierungsprozess offen?

Beitrags-Hürde (EPUB: IDPF 1000 $ / W3C > 5000 €)

Aber: W3C Community/Business Groups offen für alle

Aber: EPUB 4 wird in Publishing WG ($$) entwickelt,
nicht in EPUB 3 CG

⇒ de facto nicht offen für kleine/mittelgroße Verlage

Erfolgreiche Standards…

  • … haben Implementatoren an Bord
  • … sind nicht schwammig
  • … sind interoperabel
  • … reagieren schnell auf neue Anforderungen
  • … sind weit verbreitet (Tautologie? Netzwerkeffekt!)

Warum wirken so wenig Verlage bei EPUB-Standardisierung mit?

  • zu wenig technisches Personal
  • kein Budget
  • Abwarten, was sich durchsetzt
  • Unterschätzen der Einflussmöglichkeiten

Lösungsansatz: Interessen-Pooling

Idee aus der IG Digital: Der Börsenverein (€€-W3C-Mitglied!) entsendet eine Expertin

Börsenverein-Vorstand findet das gut, möchte aber dafür keine €€€-Mittel bereitstellen

Ausweg: Interessenpooling mit EDRLab

Pooling bei Open-Source-Entwicklung?

z.B. gesparte InDesign-Lizenzen in Scribus-Finanzierung investieren

Kann durchaus bei komplexen Anwendungen funktionieren. Vorbilder:

  • im 3D-Bereich: Blender (Blender Foundation)
  • im Office-Bereich: LibreOffice (The Document Foundation)

Initiative geht selten von Nutzern aus

InDesign, Quasistandard und proprietäre Software

Probleme/Risiken

  • Verlage warten 10 Jahre auf Endnoten, Tabellenfußnoten
  • Verlage warten immer noch auf brauchbare XML-Unterstützung
  • Verlage/Satzbetriebe müssen plötzlich hohe Abo-Gebühren zahlen (oder auf Features und Bugfixes verzichten)

Pooling bei transpect-Weiterentwicklung

Kritische Masse war durch Eigenbedarfs-Entwicklung gegeben

Open-Sourcing u.a. aus Unlust an Vertrieb und Marketing

  • Pooling erfolgreich bei Feature-Entwicklung, z.B.
    • MathType→MathML-Konverter (Sponsoren: Hanser, VDE, stmdocs.in)
    • gemeinsamer IDML→TEI→EPUB-Basisworkflow für C.H. Beck, Beltz, Campus, Klett-Cotta, Unionsverlag, Suhrkamp, Hanser

Kaum Bedenken (mehr) bzgl. Freeloading (Schmarotzertum)

transpect

Framework zum Konvertieren und Prüfen XML-basierter Daten (IDML, docx, EPUB, …)

Offene Standards:

  • XSLT
  • XProc
  • Relax NG
  • Schematron
  • DocBook, JATS/BITS, TEI, HTML, …

Offene HTTP-API gibt es dazu

transpect

  • Offene Standards und Open Source für viele Kunden ausschlaggebend
  • Erlösmodell
    • Customizing
    • Support
    • Feature-Priorisierung (z.B. Citavi-Referenzen)
    • Kompatibilitätstests

Warum finanziert sich transpect besser als epubcheck?

  • Autoren, Lektoren und Setzer verwenden Word und InDesign kreativ (ständiger Support- und Weiterentwicklungs­bedarf)
  • Customizing nötig für Verlagsworkflows/-schemas
  • Produktionssicherheit, Verfügbarkeit wichtig & dafür zahlt man
  • Ausnahme: transpect-Anwendung docx2tex eher undankbar
    • 4900 Downloads
    • nur wenig Umsatz mit Feature-Entwicklung
    • aber tw. typisches Open-Source-Anspruchsdenken der Nutzer
    • trotzdem gutes Marketingtool & viele Tester

Fazit

  • Open Source und zunehmend (wegen digitaler Endprodukte) offene Standards sind wichtig für Verlage
  • Mehr Engagement wäre wünschenswert (im Eigeninteresse)
  • Allerdings ist es für viele nur gemeinsam zu stemmen
  • Crowdfunding unter Verlagen war bisher nur begrenzt erfolgreich
  • Mehr (auch kollektive) Urteilsfähigkeit wünschenswert, weniger „abwarten, was sich durchsetzt“
  • Mehr Ideologie wünschenswert (offen aus Prinzip, im langfristigen Interesse)