Source files of fsfe.org, pdfreaders.org, freeyourandroid.org, ilovefs.org, drm.info, and test.fsfe.org. Contribute: https://fsfe.org/contribute/web/ https://fsfe.org
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

msooxml-questions.de.xhtml 11KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263
  1. <?xml version="1.0" encoding="UTF-8" ?>
  2. <html>
  3. <head>
  4. <title>FSFE - Sechs Fragen an die nationalen Standardisierungsgremien zu
  5. MS-OOXML</title>
  6. </head>
  7. <body>
  8. <h1>Sechs Fragen an die nationalen Standardisierungsgremien</h1>
  9. <center>
  10. [<a href="msooxml-questions.pdf">Auch als PDF verfügbar (englisch)(28k)</a>]
  11. </center>
  12. <p>
  13. Die folgenden Fragen befassen sich mit der Anerkennung des
  14. ECMA/MS-OOXML-Formats als IEC/ISO-Standard. Solange die nationalen
  15. Standardgremien keine schlüssigen Antworten auf diese Fragen haben,
  16. sollten sie in der IEC/ISO-Abstimmung mit "Nein" stimmen und beantragen,
  17. dass Microsoft seine Arbeit an MS-OOXML in ISO/IEC 26300:2006 (Open
  18. Document Format) einbringt.
  19. </p>
  20. <p>
  21. Dies ist eine Zusammenfassung. Ausführlichere Informationen
  22. finden Sie online.
  23. </p>
  24. <ul>
  25. <li>
  26. <a
  27. href="http://www.grokdoc.net/index.php/EOOXML_objections">http://www.grokdoc.net/index.php/EOOXML_objections</a>
  28. </li>
  29. <li>
  30. <a href="http://fsfe.org/activities/os/msooxml-questions">http://fsfe.org/activities/os/msooxml-questions</a>
  31. </li>
  32. <li>
  33. <a href="http://www.noooxml.org/arguments">http://www.noooxml.org/arguments</a>
  34. </li>
  35. </ul>
  36. <ol>
  37. <li>
  38. <h3>Unabhängigkeit?</h3>
  39. <p>
  40. Ein Standard sollte niemals von einem bestimmten Betriebssystem,
  41. einer speziellen Umgebung oder Software abhängig sein.
  42. Anwendungs- und Implementierungs-Unabhängigkeit gehören zu den
  43. wichtigsten Eigenschaften eines Standards.
  44. </p>
  45. <blockquote>
  46. <strong>
  47. Ist die MS-OOXML-Spezifikation frei von jeglichen Verweisen auf
  48. einzelne Produkte eines Herstellers und deren spezifisches
  49. Verhalten?
  50. </strong>
  51. </blockquote>
  52. </li>
  53. <li>
  54. <h3>Unterstützung bereits existierender Offener Standards?</h3>
  55. <p>
  56. Wann immer anwendbar und möglich, sollten Standards auf bereits
  57. erzielten Erfolgen der Standardisierung aufbauen und die Abhängigkeit
  58. von proprietären, herstellergebundenen Technologien vermeiden.
  59. </p>
  60. <p>
  61. MS-OOXML vernachlässigt verschiedene, vom W3C empfohlene Standards
  62. wie MathML und SVG, und benutzt stattdessen eigene,
  63. herstellerspezifische Formate. Dadurch werden alle anderen
  64. Hersteller, wenn sie MS-OOXML vollständig implementieren wollen,
  65. gezwungen, sich in die proprietäre Infrastruktur einzuordnen, die
  66. durch Microsoft in den vergangenen 20 Jahren aufgebaut wurde.
  67. Es erscheint fraglich, ob ein Dritter diese Spezifikation
  68. jemals in derselben Qualität wie Microsoft implementieren können
  69. wird.
  70. </p>
  71. <blockquote>
  72. <strong>
  73. Was nützt es, wenn auf diesem Gebiet ein herstellergebundenes
  74. Format auf Kosten der Standardisierung akzeptiert wird? Wo bekommen
  75. andere Hersteller wettbewerbsfähige, kompatible und vollständige
  76. Implementierungen dieser Formate für alle Plattformen, um untragbar
  77. hohe Kosten zu vermeiden?
  78. </strong>
  79. </blockquote>
  80. </li>
  81. <li>
  82. <h3>Abwärtskompatibilität für jeden Hersteller?</h3>
  83. <p>
  84. Einer der angeblich größten Vorteile von MS-OOXML ist seine
  85. Fähigkeit, Abwärtskompatibilität erlauben zu können, wie sie auch in
  86. der <a
  87. href="http://www.ecma-international.org/news/PressReleases/PR_TC45_Dec2006.htm">
  88. Pressemitteilung der Ecma international</a> genannt wird.
  89. </p>
  90. <p>
  91. Es ist für einen Standard unverzichtbar, dass er von jedem Hersteller
  92. umgesetzt werden kann, ohne dass dieser auf die Kooperationsbereitschaft
  93. anderer Firmen angewiesen ist, auf verborgene zusätzliche
  94. Informationen zugreifen, zusätzliche juristische Abkommen schließen,
  95. oder Zahlungen leisten muss. Ebenso muss ein Standard gewährleisten,
  96. dass alle Hersteller ihn, ohne mit Wettbewerbern kooperieren zu
  97. müssen, in der gleichen Qualität und im selben Umfang verwenden
  98. können, um die notwendige Interoperabilität zu erreichen.
  99. </p>
  100. <blockquote>
  101. <strong>
  102. Kann ein Hersteller, unabhängig von seinem Geschäftsmodell, ohne
  103. Zugriff auf zusätzliche Informationen und ohne die
  104. Kooperationsbereitschaft Microsofts die Abwärtskompatibilität
  105. seiner Produkte und die Umwandlung der eigenen Dokumentenformate in
  106. das MS-OOXML-Format in derselben Qualität, wie sie von Microsoft
  107. erreicht wird, erreichen?
  108. </strong>
  109. </blockquote>
  110. </li>
  111. <li>
  112. <h3>Proprietäre Erweiterungen?</h3>
  113. <p>
  114. Die Verwendung proprietärer, anwendungsspezifischer Erweiterungen ist
  115. eine von Microsoft angewandte Maßnahme, um ihre Vormachtstellung im
  116. Bereich der Desktopanwendungen zu missbrauchen und weiter auszubauen.
  117. Wegen dieses Verhaltens sah die Europäische Kommission sich im Jahre
  118. 2004 veranlasst, eine Entscheidung gegen Microsoft zu fällen und den
  119. Konzern aufzufordern, Informationen zu veröffentlichen, die die
  120. Interoperabilität der Software anderer Hersteller mit der Software
  121. des Konzerns ermöglicht. Microsoft weigert sich bis zum heutigen
  122. Tage, dieser Aufforderung Genüge zu tun.
  123. </p>
  124. <p>
  125. Aus diesem Grunde ist allgemein anerkannt, dass Offene Standards
  126. niemals proprietäre Erweiterungen zulassen sollten und dass
  127. wettbewerbsverzerrenden Verhaltensweisen, wie die oben genannten,
  128. durch Offene Standards nicht unterstützt werden sollten.
  129. </p>
  130. <blockquote>
  131. <strong>
  132. Erlaubt MS-OOXML proprietäre Erweiterungen? Ist Microsofts
  133. MS-OOXML-Implementierung vertrauenswürdig, ist sie z.B. frei von
  134. undokumentierten Zusätzen? Existieren Maßnahmen, um dergestalten
  135. Missbrauch zu vermeiden?
  136. </strong>
  137. </blockquote>
  138. </li>
  139. <li>
  140. <h3>Doppelte Standards?</h3>
  141. <p>
  142. Das Ziel aller Standardisierungsbemühungen ist die Einigung auf
  143. einen einzigen Standard, weil mehrere unterschiedliche Standards
  144. Wettbewerbsnachteile mit sich bringen. Die hier durch Microsoft
  145. vorangetriebene Zersplitterung des Standards ist eine strategische
  146. Maßnahme mit dem Ziel, die Kontrolle über bestimmte Bereiche des
  147. Marktes zu erlangen, wie mehrere Beispiele aus der Vergangenheit
  148. deutlich zeigen.
  149. </p>
  150. <p>
  151. Es existiert bereits ein anerkannter Offener Standard für
  152. Officedokumente, namentlich das Open Document Format (ODF) (ISO/IEC
  153. 26300:2006). Sowohl MS-OOXML als auch ODF liegt dieselbe
  154. XML-Technologie zugrunde, wodurch beide Spezifikationen über
  155. dieselben theoretischen Möglichkeiten verfügen. Microsoft ist
  156. Mitglied der OASIS-Gruppe, jener Organisation, durch die der
  157. ODF-Standard entwickelt wurde und gepflegt wird. Microsoft war über
  158. den Prozess informiert und eingeladen, daran zu partizipieren.
  159. </p>
  160. <blockquote>
  161. <strong>
  162. Warum wies und weist Microsoft das Angebot bis heute zurück, an dem
  163. bereits existierenden Standard mitzuwirken? Warum haben sie ihre
  164. technischen Lösungen OASIS nicht zur Aufnahme in ODF vorgelegt?
  165. </strong>
  166. </blockquote>
  167. </li>
  168. <li>
  169. <h3>Juristisch sicher?</h3>
  170. <p>
  171. Für einen Standard ist es wichtig, dass alle Wettbewerber die
  172. Möglichkeit haben, einen Standard ohne die Gefahr juristischer
  173. Verfolgung implementieren zu können. Diese Zusicherung muss klar,
  174. nachvollziehbar, verlässlich und weit genug gefasst sein, um alle für
  175. die Interoperabilität notwendigen Prozesse abzusichern um einen
  176. echten Wettbewerb zu ermöglichen.
  177. </p>
  178. <p>
  179. MS-OOXML kommt, statt mit den typischen Patentrechtsbestimmungen, mit
  180. einem unüblich komplexen und sehr eng gefassten "Vertrag, niemanden
  181. zu verklagen" daher. Aufgrund seiner Komplexität ist unklar, wie
  182. weit der Schutz vor Klagen tatsächlich gewährt wird.
  183. </p>
  184. <p>
  185. Eine oberflächliche Überprüfung dieser Zusicherung ergab, dass nicht
  186. alle optionalen Features und proprietären Formate, die für eine
  187. vollständige Implementierung von MS-OOXML verwendet werden müssen,
  188. durch diese Zusicherung abgedeckt werden. Dadurch ist die
  189. Rechtssicherheit der Wettbewerber bei der Implementierung des
  190. MS-OOXML-Formats gefährdet und hinsichtlich der Kernkomponenten
  191. mindestens fraglich.
  192. </p>
  193. <blockquote>
  194. <strong>
  195. Hat Ihr nationales Standardisierungsgremium eigene, unabhängige
  196. Untersuchungen über die juristische Natur des "Vertrages, niemanden
  197. zu verklagen" vorgenommen, aus denen hervorgeht, ob tatsächlich das
  198. gesamte Spektrum der möglichen MS-OOXML-Implementierungen abgedeckt
  199. wird?
  200. </strong>
  201. </blockquote>
  202. </li>
  203. </ol>
  204. <p>
  205. Jede dieser Fragen sollte durch die nationalen Standardisierungsgremien,
  206. auf Grundlage der Untersuchungsergebnisse unabhängiger Sachverständiger,
  207. insbesondere frei von der Beeinflussung durch Microsoft oder ihre
  208. Geschäftspartner, die in diesem Fall naturgemäß einem direkten
  209. Gewissenskonflikt unterliegen, beantwortet werden.
  210. </p>
  211. <p>
  212. Sollte auch nur eine der Fragen unzureichend beantwortet werden, muss das
  213. Standardisierungsgremium in der ISO/IEC-Abstimmung mit "Nein" stimmen.
  214. </p>
  215. <h2>Verwandte Themen</h2>
  216. <ul>
  217. <li><a href="/documents/msooxml-interoperability.html">Interoperabilität leidet unter MS-OOXML</a></li>
  218. <li><a href="/documents/msooxml-idiosyncrasies.html">DIS-29500 Normenentwurf noch vor seinem Einsatz veraltet?</a></li>
  219. <li><a href="/documents/msooxml-converter-hoax.html">Der Konverter-Scherz</a></li>
  220. <li><a href="/documents/msooxml-questions-for-ms.html">Fragen an Microsoft zu offenen Formaten</a></li>
  221. </ul>
  222. </body>
  223. <timestamp>$Date$ $Author$</timestamp>
  224. </html>
  225. <!--
  226. Local Variables: ***
  227. mode: xml ***
  228. End: ***
  229. -->