eine Initiative der /ch/open
Postfach 1908
CH-8021 Zürich
siug@siug.ch
|
Swiss Internet User Group (SIUG) eine Initiative der /ch/open Postfach 1908 CH-8021 Zürich siug@siug.ch |
|
|
Dies ist Version 0.7 (2010-01-16)
Die jeweils aktuelle Version ist unter folgender URL verfügbar: http://siug.ch/ostandards/def
Author: Norbert Bollow <norbert.bollow@siug.ch>
Das Ziel dieser Definition besteht darin, einen strikt und möglichst präzise definierten Begriff von Offenen Standards im Kontext von Computer-Software zu schaffen. Strikt Offene Standards gewährleisten, dass Programme verschiedener Anbieter miteinander interoperabel sind. Ausserdem ermöglicht es die Verwendung von Strikt Offenen Standards, einzelne Programme oder Systemkomponenten gegen andere auszutauschen. Informatik-Anwender haben so die freie Wahl, ohne unverhältnismässige Schwierigkeiten und Kosten bei Bedarf den Software-Anbieter zu wechseln (Vermeidung von Lock-In Effekten). Für spezielle Anwendungsbedürfnisse, die nicht vollständig durch offene Standards abgedeckt sind, sollten die Interfaces dennoch auf der Grundlage von Offenen Standards definiert werden. Der betreffende Begriff der Offenen Interfaces baut auf dem hier definierten Begriff von Strikt Offenen Standards auf.
Eine technische Spezifikation, die Interoperabilität von Computerprogrammen mit anderen Software- und/oder Hardwarekomponenten bezweckt, kann als Strikt Offener Standard bezeichnet werden, wenn die folgenden sieben Kriterien alle erfüllt sind1:
Anmerkung 1: Wir fordern diese strikten Kriterien ausdrücklich nur für Interoperabilitätsstandards, die für Computerprogramme relevant sind, denn es ist spezifisch in diesem Bereich, dass wegen der verstärkten ökonomischen Netzwerkeffekte des Internet-Zeitalters und aufgrund der zunehmenden Bedeutung von Freier und Open Source Software (FOSS) die traditionellen Kriterien von ISO, IEC, ITU und anderen Standardisierungsorganisationen nicht mehr ausreichen.
(a) Öffentliche Spezifikation: Die Spezifikation ist publiziert. Sie darf unentgeltlich kopiert und weitergegeben werden.2
Anmerkung 2: In dem Bereich der Standardisierung, um den es bei dieser Definition geht, gelingt es in der Regel nicht einmal der ISO, durchzusetzen, dass Kopien des Standards teuer gekauft werden müssen. Standards, die nicht gratis im Internet verfügbar sind, bergen ein sehr hohes Risiko, dass sie nicht von genug vielen unabhängigen Anbietern umgesetzt werden, damit die Gefahr von Lock-In wirksam eingedämmt ist. Darum gehört diese Bedingung in die Definition des Begriffs „Offener Standard”. Die Bedingung, das Kopien des Standards weitergegeben werden dürfen, ist insbesondere bei Standards wichtig, die gratis sind, weil sonst die Gefahr besteht, dass der Standard irgendwann aus dem Internet verschwindet, falls seitens des Urheberrechtsinhabers das Interesse an dem Standard erlischt.
(b) Stringenz: Die Anforderungen der Spezifikation müssen präzise und genug strikt sein, um im Rahmen der angegebenen Zielsetzungen Interoperabilität3 von konformen Implementierungen zu gewährleisten.
Anmerkung 3: „Interoperabilität” ist hier im Sinn der Definition in ISO/IEC 2382-01 gemeint: "The capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units".
(c) Technische Qualität: Die Spezifikation muss technisch korrekt4, ausgereift5 und stabil6 sein.
Anmerkung 4: Korrektheit bedeutet, dass es weder im normativen noch im informativen Teil vom Text der Spezifikation sachliche Fehler wie z.B. Widersprüche oder falsche Anwendung von anderen, als normative Referenzen zitierten Standards geben darf. Solche Fehler fallen bei der sorgfältigen Erstellung einer vollständigen Implementierung aufgrund der Spezifikation auf; es ist daher möglich, solche Fehler zu finden und zu korrigieren, bevor eine Spezifikation formell als Standard anerkannt wird.
Anmerkung 5: Reife bedeutet, dass die Spezifikation soweit absehbar alle vorhersehbaren gegenwärtigen und zukünftigen Bedürfnisse im Bereich der in der Spezifikation definierten Zielsetzungen erfüllt.
Anmerkung 6: Stabilität bedeutet, dass soweit absehbar keine Änderungen an dem Standard zu erwarten sind, die über die mögliche Korrektur einer kleinen Anzahl von relativ geringfügigen Fehlern hinausgehen. Stabilität in diesem Sinn steht nicht im Widerspruch zu der Entwicklung von Erweiterungen oder einer neuen Version des Standards, sofern beim Design von der neuen oder erweiterten Version darauf geachtet wird, dass diese parallel zur alten Version des Standards verwendet werden kann.
(d) Vollständig implementiert: Falls es keine vollständige Implementierung mit publiziertem Quellcode gibt, muss es mindestens zwei miteinander interoperable vollständige Implementierungen geben.7
Anmerkung 7: Wenn es nur eine einzige vollständige Implementierung gibt (und es sich dabei nicht um eine formelle Referenzimplementierung handelt), dann ist wahrscheinlich nicht das Programm durch Implementation der Spezifikation entstanden, sondern die Spezifikation als Dokumentation für das Programm. In diesem Fall ist nicht gewährleistet, dass die Spezifikation alle Informationen enthält, die für die unabhängige Erstellung einer kompatiblen und interoperablen Implementierung erforderlich sind.
(e) Freie Implementierbarkeit: Es darf keine Einschränkungen8 geben, die es verhindern würden, die Spezifikation in Software mit irgend einem Lizenzmodell teilweise, vollständig oder mit Erweiterungen zu implementieren9. Insbesondere darf keine Form der Nutzung der Spezifikation mit der Entrichtung von Lizenzgebühren verknüpft sein, weil das der Implementierung in Freier und Open Source Software (FOSS) widersprechen würde. Einschränkungen, die gegen andere Software-Lizenzmodelle diskriminieren, sind ebenso unzulässig. Falls für die Implementierung der Spezifikation oder für das Deployment einer Implementierung Patentlizenzen nötig sind, dann dürfen diese Lizenzen als Bedingung voraussetzen, dass der Nutzer der Patentlizenz eventuelle eigene Patente auch unter analogen Bedingungen lizenziert. Die Lizenzen dürfen jedoch keine darüber hinausgehenden Bedingungen stellen und müssen ohne Diskriminierung für jede interessierte Partei frei zugänglich sein, ohne dass dafür die explizite Zustimmung zu einem Lizenzvertrag nötig ist.10
Anmerkung 8: Die Situation im Hinblick auf Patente kann sich von Land zu Land unterscheiden; Offene Standards müssen aber global frei von patentbasierten Einschränkungen sein.
Anmerkung 9: Die freie Implementierbarkeit muss dabei auch für alle Datenformate, Protokolle und kryptographische Algorithmen gelten, die im normativen Text der Spezifikation referenziert werden.
Anmerkung 10: Solche Lizenzen werden typischerweise als ein Versprechen formuliert, den Standard betreffende Patentrechte nicht einzufordern, unter der Voraussetzung, dass der Nutzer des Standards ebenfalls keine betreffenden Patentrechte einfordert. Siehe zum Beispiel das OpenDocument Patent Statement von Sun oder die Open Specification Promise von Microsoft.
(f) Offene Weiterentwicklung: Gewährleistung11 eines für alle Marktteilnehmer uneingeschränkt zugänglichen Prozesses, durch den der Standard weiterentwickelt12 werden kann, wenn dies nötig ist. Dabei muss gewährleistet sein, dass Änderungsvorschläge nur dann akzeptiert werden, wenn sie keine Gruppe von Marktteilnehmern in unfairer Weise benachteiligen.
Anmerkung 11: Mit „Gewährleistung” ist hier gemeint, dass es einerseits klare prozedurale Regeln geben muss, die allen Marktteilnehmern Mitsprachemöglichkeiten versprechen, und dass andererseits in der realen Arbeit der betreffenden Komitees diese Regeln auch so eingehalten werden, dass alle Gesichtspunkte, die eingebracht werden, bei der Weiterentwicklung des Standards tatsächlich in angemessener Weise berücksichtigt werden.
Anmerkung 12: Dieses Kriterium bezieht sich ausdrücklich nur auf Änderungen bzw. Weiterentwicklungen einer bereits als Standard akzeptierten Spezifikation. Es ist egal, wie die Spezifikation ursprünglich entwickelt wurde.
(g) Verlustfreie Migration: Wenn mit der Spezifikation eines Datenformats beabsichtigt wird, eine frühere Version oder einen anderen älteren Standard zu ersetzen13, muss die neue Spezifikation Features definieren, die alle Informationen14 auszudrücken erlauben, die im Datenformat des alten Standards ausgedrückt werden können. (Die Implementierung solcher Features kann als optional deklariert werden.)
Anmerkung 13: Gemeint sind Situationen, wo die Anwenderbedürfnisse, die durch die alte Version oder einen anderen, alten Standard abgedeckt werden sollten, vollständig durch den neuen Standard abgedeckt werden sollen. Dies betrifft beispielsweise die Situation eines konkurrierenden Standards, der auf einem anderen, möglicherweise besseren, Lösungsansatz beruht. Dieses Kriterium ist daher eine Abschwächung des von der ISO postulierten (aber nicht durchgesetzten) Prinzips, dass konkurrierende Standards für denselben Zweck vermieden werden sollen.
Anmerkung 14: Wenn ein Standard zu viele für typische Anwendungssituationen nicht benötigte Features definiert, ist das richtige Vorgehen nicht das Weglassen von Features aus dem Standard, sondern die Standardisierung von Profilen, die eine Auswahl von Features darstellen.
|
Entwürfe und verabschiedete Fassungen dieser Definition stehen unter der Creative Commons Attribution-No Derivative Works 2.5 Switzerland Lizenz. |