Kommentar des SIUG-Komitees zur Vernehmlassungsantwort von Hartwig Thomas

Auf dieser Seite ist der Kommentar des SIUG-Komitees zu der Vernehmlassungsantwort von Hartwig Thomas ( ODF   PDF ) tabellarisch zusammengestellt.

Die Vernehmlassungsantwort bezieht sich auf Version 0.5 des Definitionsentwurfs.

aus der Vernehmlassungsantwort Kommentar des SIUG-Komitees
„Offener Standard“

Zuerst mal ein paar Beispiele, damit klarer wird, wovon wir reden:

  • Das ZIP-Format ist ein offener (publiziertes appnote.txt auf PKWARE-Seite) Standard, der nie in einem breit abgestützten Prozess entwickelt wurde. Es dient als Basis vieler anderer offener Standards (ISO ODF, ISO OOXML, JAR, WAR, EAR ...)
  • Im Gegensatz zum ANSI-C gibt es kein ISO-JAVA. Es ist aber ein offener, vollständig freigelegter Standard.
  • Die Implementation Mono zeigt, dass auch .NET einem offenen Standard recht nahe kommt. Die Interoperabilität und Portabilität von .NET-Anwendungen scheitert nur an der Verwendung externer plattformspezifischer Komponenten.
  • JPEG, JPEG2000, MPEG 2, MPEG 4 sind Sammelsurium- und Containerstandards, mit denen niemand so recht glücklich ist, auch wenn tausendmal internationale Standardorganisationen dahinter stehen. Trotz Konformität zum Standard ist eine MPEG 4 Datei – wie ein .NET-Programm – von proprietären Komponenten (Codecs) abhängig.
Wir schlagen eine striktere Definition des Begriffs "offener Standard" vor. Beispielsweise sollte unseres Erachtens das ZIP-Format nicht als "offener Standard" bezeichnet werden, weil kein offener Prozess zur Weiterentwicklung des Formats vorgesehen ist.

Die klassischen Standardisierungsorganisationen wie ISO, IEC, ITU usw. haben zwar grundsätzlich einen solchen offenen Prozess, aber sie verwenden ansonsten Offenheitskriterien, die aus der Perspektive der Internet und FOSS Communities nicht streng genug sind.

Wozu dienen Standards?

Die Standardisierung einer Steckdose (wann werden endlich alle Natel-Ladegeräte dem selben Standard folgen?!!) oder einer Radiosendetechnik dient als Schnittstelle für Interoperabilität von Komponenten verschiedener Hersteller, die nicht alle unter einer Decke stecken (vertraglich miteinander verbunden sind).

Ja. Allerdings gibt es auch Standards, die nicht in diesem Sinn Interoperabilitätsstandards sind.

Wir werden in der nächsten Version ausdrücklich darauf hinweisen, dass sich unsere Definition nur auf Interoperabilitätsstandards bezieht.

Zu diesem Zweck muss ein Standard öffentlich publiziert sein. Mindestens eine Kopie muss bei der Library of Congress oder der Schweizerischen Nationalbibliothek gratis einsehbar und kopierbar sein. Es erscheint uns nicht sinnvoll, in der Begriffsdefinition für offene Standards spezifische Bibliotheken zu referenzieren. Mit diesem Ansatz liesse sich wohl keine internationale Fairness erreichen. Wir fordern stattdessen, dass Kopien weitergegeben werden dürfen.
Die Standardisierung eines Containers (z.B. die Container auf den Lastwagen und den Schiffen oder des ZIP-Formats) kann sinnvoll sein, auch wenn der Inhalt proprietär ist. Das aber nur, wenn sich viele unabhängige Beteiligte nur mit dessen Äusseren beschäftigen. Ja, einverstanden.
Damit ein Standard wirklich ein Standard ist, braucht es also mindestens zwei Implementationen, die unabhängig voneinander auf der Basis des Standards entwickelt wurden und miteinander kommunizieren (interoperabel) sind (Steckdose und Stecker, PDF-Reader und PDF-Writer, Radiosender und -empfänger ...). Diese Forderung erscheint uns unnötig streng. Angenommen, ein Standard hat eine FOSS-Referenzimplementation, die so gut ist, dass alle Marktteilnehmer die Referenzimplementation (eventuell mit Anpassungen) verwenden wollen. Soll es deswegen kein Standard sein?

Selbst bei nur einer Referenzimplementation, welche alle verwenden, gilt:

  • Der Standard ist ein Standard, weil er Transparenz fördert (Schulung, Validierung)
  • Nur eine einzige öffentliche Referenzimplementation heisst nicht, dass es nicht noch viel mehr gibt, das nicht öffentlich ist. Beispielsweise hat einer von uns einen kleinen Subset von ODF selber implementiert, einzig mit dem Ziel automatisch Dokumente erstellen zu koennen. Die Implementation war nicht vollständig, sie konnte nur gerade das, was ausgegeben werden musste. Aber es war eine grosse Erleichterung, da man die Dokumente mit Inhalt nur noch in OpenOffice kurz reviewen und korrigieren musste und sie dann versenden konnte.
Die Art, wie ein Standard entwickelt wurde, ist völlig immateriell. Ja, einverstanden. Damit die Spezifikation dann aber zu einen Standard wird, braucht es einen Konsensprozess, und damit es ein offener Standard ist, muss irgendwie gewährleistet sein, dass wenn Weiterentwicklungen des Standards erforderlich erscheinen, es dazu einen offenen Prozess gibt, der nicht z.B. eine Firma gegenüber allen anderen Marktteilnehmern stark bevorzugt.
Ein Standard kann schon lange de facto benutzt sein, bevor er offiziell zum Standard erklärt wird. Ja, einverstanden. Aber die Spezifikation sollte nicht als Standard bezeichnet werden, bevor eine stabile Version vorliegt. (Siehe Punkt 3 unseres Definitionsvorschlags.)
Viele Produkte der offiziellen Standardorganisationen (ISO, ECMA, ...) sind gerade darum Totgeburten, weil die das Produkt eines Interessen ausgleichenden Prozesses sind. Die besten Standards (ZIP, JAVA, XML, DIN A4) wurden von Einzelnen oder kleinen Gruppen entwickelt, den schlechtesten merkt man an, von welcher Firma der Leiter der Standardisierungsgruppe bezahlt wird (z.B. SQL: früher IBM, jetzt Oracle). Am schlimmsten sind „Standards“, die keine sind (z.B. OAIS), sondern auf Ausübung von Macht abzielen (z.B. ISO 90001, Hundehalter- und Kinderhütequalifizierungszertifikate, ...). Wenn Standards es schaffen mit vermeintlicher allgemeiner Geltung sich als zwingende Vorschrift staatlicher Organe durchzusetzen, dienen sie nicht mehr der freien Beteiligung verschiedener Parteien an einer gemeinsamen Schnittstelle, sondern werden zu üblen Instrumenten der Disziplinierung und der Besitzstandswahrung. Die Formulierung „freie Beteiligung verschiedener Parteien an einer gemeinsamen Schnittstelle“ drückt gut aus, was wir uns unter einem offenen Standard vorstellen.
Offenheit

Ein nicht-offener Standard ist ein Widerspruch in sich. Insofern ist „Offener Standard“ ein Pleonasmus.

Manche Organisationen, die Standards entwickeln, wie zum Beispiel ISO und ITU sind viel älter als die FOSS und Internet Communities, und es gibt dort eine entsprechend alte Tradition, was als Standards bezeichnet wird, wobei die Erwartungen der FOSS und Internet Communities insbesondere im Hinblick auf freie Implementierbarkeit ohne patentbasierte Einschränkungen nicht immer erfüllt sind.

GSM, DECT, UMTS etc. sind Standards (viele Hersteller haben Geraete dazu, es gibt Konkurrenz) - aber trotzdem nicht offen, da z.B. ETSI nicht will dass man von der ETSI-Seite heruntergeladene Standards weiter gibt.

http://pda.etsi.org/pda/PriceCode.asp

Je nachdem gibt es auch Abrechnung nach Seitenmenge :-)

Es erscheint uns nicht sinnvoll, bei Spezifikationen, die tatsächlich die Funktion eines Standards haben, darüber zu streiten, ob das nun Standards sind oder nicht.

Darum schliessen wir uns lieber der in weiten Kreisen üblichen Vorgehensweise an, mit „offener Standard“ einen neuen Begriff einzuführen, und darauf zu bestehen, dass dieser Begriff Standards beschrieben soll, die für Softwareentwickler aller Gattungen einschliesslich FOSS Entwicklern als Standard akzeptabel sind.

Weiterentwicklungen, Versionen

Natürlich kann ein Standard in gewissen Bereichen so unklar formuliert sein, dass er nicht als Kontrakt zwischen den an der Schnittstelle beteiligten Parteien taugt.

Eine so unklar formulierte Spezifikation möchten wir nicht als „Standard“ akzeptieren.
In diesem Fall ist es sinnvoll, von einer Bereinigung oder neuen Version des Standards zu reden. In diesem Fall stellt sich kein Migrationsproblem, weil ja nicht das beschriebene Objekt, sondern nur die Beschreibung verändert wurde. Es ist davon auszugehen, dass die neuere Version nicht der alten widerspricht, sondern explizit sagt, was gemeint war. Nein: Es kann sich durchaus ein Migrationsproblem stellen, nämlich für Anwender von Implementierungen, deren Entwickler die unklare Spezifikation anders interpretiert haben, als sie in der neuen Version interpretiert wird.
Eine öffentlich zugängliche Referenzimplementation (wie etwa der Urmeter in Paris) kann hier viele Unklarheiten und „Fehler“ im Standard von vornherein vermeiden helfen. Ausserdem ist das Erstellen irgendeiner Implementierung ab der Spezifikation eine sehr gute Gelegenheit, um Unklarheiten der Spezifikation zu finden und eine Bereinigung zu verlangen. Dafür muss es nicht unbedingt eine offizielle Referenzimplementierung sein. Im Gegensatz dazu ist das Risiko, zu einer Spezifikation mit vielen Unklarheiten zu gelangen, viel grösser, wenn man versucht, aus der Dokumentation eines bestehenden Programms einen Standard zu machen, ohne dabei eine völlig neue Implementierung ab der Spezifikation zu erstellen.
Absolut erforderlich scheint sie aber nicht. (Was wäre die „Referenzimplementation“ der Darstellung von 32-bit-Zahlen im Zweierkomplement?) Hier könnte irgendein Gerät oder Programm als Referenzimplementierung dienen, mit dem Zahlen im Zahlenbereich von -2,147,483,648 bis +2,147,483,647 von der Dezimaldarstellung in die Zweierkomplement-Binärdarstellung und umgekehrt umgewandelt werden können.
Wenn sich jedoch die Struktur der standardisierten Schnittstelle (Dateiformat, Programmiersprache, Steckdose) verändert, sollte man nicht von einer neuen Version, sondern von einem anderen Standard reden. Diese Unterscheidung ist nicht Gegenstand unseres Definitionsvorschlags.
Sicher stimmt der Standard PDF/A zu 95% mit dem offenen Standard (?) PDF 1.4 überein. Es ist aber eine andere Schnittstellenvereinbarung, ein anderer Standard. Eine Migrierbarkeit zu fordern, scheint in diesem Fall keinen Sinn zu machen. Der Grund, warum es in diesem Beispiel nicht sinnvoll ist, Migrierbarkeit zu fordern, ist dass PDF/A explizit und tatsächlich ein anderes Ziel als PDF 1.4 verfolgt. Insbesondere besteht nicht der Wunsch, mit PDF/A die anderen, nicht spezifisch für Archivierbarkeit gedachten PDF-Formate von Markt zu verdrängen.
Freie Benutzbarkeit

Die freie, nicht von Patenten oder anderen Eigentumsrechten eingeschränkte Benutzbarkeit ist eine wesentliche Voraussetzung dafür, dass man etwas als Standard bezeichnen kann. Solange der IDEA-Algorithmus von der ABB patentiert war, konnte man PGP nicht als „offenen Standard“ bezeichnen, obwohl jede Programmzeile publiziert war. Ähnliches gilt von LZW-Patenten und Komprimierungs-Standards. Man kann sagen, diese „Standards“ waren zwar offen, insofern sie nicht geheimgehalten, öffentlich publiziert waren, es waren jedoch keine Standards, weil es sich um interne private Absprachen vertraglich miteinander verpflichteter Parteien handelte. Diese waren zu keinem Zeitpunkt verpflichtet, den Standard beizubehalten. Dritte, die an eine solche Schnittstelle heranprogrammierten, konnten evtl. geduldet werden, waren aber immer Spielball der Inhaber der Schnittstelle (z.B. Microsoft Office VBA-Schnittstelle).

Wie oben unter „Offenheit“ wiederhole ich hiermit: ein proprietärer Standard ist ein Widerspruch in sich, da seine Verlässlichkeit nicht gegeben ist. Auch insofern bleibt „Offener Standard“ ein Pleonasmus.

Siehe oben.
Was ist ein Standard?

Es ist schon sinnvoll, das Wort Standard klar zu definieren – und sei es nur, um „proprietäre“ Standards als Nicht-Standards zu erkennen. Für die Weiterentwicklung der Definition wäre es aber vielleicht sinnvoll, zuerst die Anforderungen an eine Definition genauer zu umschreiben. Was sind „Lock-In“-Effekte und warum wollen wir sie verhindern? Ist das die einzige Anforderung an eine Definition?

Versuchen wir es also: Ein Standard beschreibt eine Schnittstelle zwischen Komponenten verschiedener heutiger und zukünftiger Hersteller eindeutig. Er darf von jedermann auf der ganzen Welt verwendet werden, um Komponenten herzustellen, die mit den Komponenten anderer Hersteller interoperabel sind, welche denselben Standard unterstützen. Ein Standard hat den Charakter eines Kontrakts zwischen Parteien, die sich nicht kennen. Wenn zwei angeblich standardkonforme Komponenten nicht interoperabel sind, muss der einen oder der anderen mangelnde Konformität zum Standard nachweisbar sein.

Wir werden diese Gedanken bei der Überarbeitung der Einleitung zur Definition beachten.