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
Você não pode selecionar mais de 25 tópicos Os tópicos devem começar com uma letra ou um número, podem incluir traços ('-') e podem ter até 35 caracteres.

bsa-letter-analysis.de.xhtml 21KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400
  1. <?xml version="1.0" encoding="UTF-8" ?>
  2. <html>
  3. <head>
  4. <meta name="author-name-1" content="Karsten Gerloff" />
  5. <meta name="author-link-1" content="/about/gerloff/gerloff.html" />
  6. <meta name="author-name-2" content="Carlo Piana" />
  7. <meta name="author-name-3" content="Sam Tuke" />
  8. <meta name="author-link-3" content="/about/tuke/tuke.html" />
  9. <meta name="publication-date" content="2010-10-15" />
  10. <meta name="pdf-link" content="/activities/os/bsa-eif-letter-fsfe-response.pdf" />
  11. <title>EIF-BSA-Brief</title>
  12. </head>
  13. <body>
  14. <h1>Offene Standards verteidigen: Die FSFE widerlegt die falschen
  15. Behauptungen der BSA gegenüber der Europäische Kommission</h1>
  16. <p id="introduction">Die Business Software Alliance (BSA) übt Druck auf
  17. die Europäische Kommission aus, um aus der aktuellen Version der
  18. Interoperabilitätsempfehlungen der EU, dem European Interoperability
  19. Framework (EIF), auch die letzten Überbleibsel einer Unterstützung für
  20. Offene Standards zu entfernen.
  21. <br /><br />
  22. Die FSFE ist in den Besitz der Kopie
  23. <a href="/activities/os/bsa-letter-ec.pdf">eines Briefs</a> gekommen, den
  24. die BSA letzte Woche an die Kommission geschickt hat. Im Folgenden
  25. analysieren wir die Argumente der BSA und erklären, warum ihre
  26. Behauptungen falsch sind, und warum Offene Standards ein wesentliches
  27. Element für Interoperabilität und Wettbewerb im europäischen
  28. Software-Markt sind. Wir haben die Europäische Kommission über diese
  29. Analyse <a href="/activities/os/bsa-eif-letter-fsfe-response.pdf">in
  30. Kenntnis gesetzt</a>.</p>
  31. <ol>
  32. <li><a href="#1">Gebührenfreie Patentlizenzierung eröffnet
  33. Möglichkeiten zur Marktteilnahme und fördert Innovation</a></li>
  34. <li><a href="#2">Die von der BSA als Beispiele angeführten Standards
  35. sind im Software-Bereich irrelevant</a></li>
  36. <li><a href="#3">(F)RAND-Lizenzierung in Software-Standards ist
  37. unfair und diskriminierend</a></li>
  38. <li><a href="#4">Die BSA repräsentiert nicht einmal ihre eigenen
  39. Mitglieder, geschweige denn die Software-Industrie als Ganzes</a></li>
  40. <li><a href="#5">(F)RAND ist inkompatibel mit den meisten
  41. Freie-Software-Lizenzen</a></li>
  42. <li><a href="#6">Eine Bevorzugung Offener Standards steht in
  43. keinerlei Zusammenhang mit der Verhandlungsposition der EU gegenüber
  44. China</a></li>
  45. <li><a href="#7">Spezifikationen ohne Beschränkungen werden
  46. Standardisierung, Wettbewerb und Interoperabilität fördern</a></li>
  47. <li><a href="#8">Empfehlungen</a></li>
  48. </ol>
  49. <h2 id="1">Gebührenfreie Patentlizenzierung eröffnet Möglichkeiten zur
  50. Marktteilnahme und fördert Innovation</h2>
  51. <p>In ihrem Brief argumentiert die BSA, dass „wenn die EU eine
  52. Bevorzugung gebühren-/patentfreier Spezifikationen beschließt, die
  53. Anreize für Firmen untergraben werden, Spitzen-Innovationen in die
  54. Standardisierung einzubringen, was in weniger innovativen europäischen
  55. Spezifikationen und weniger wettbewerbsfähigen europäischen Produkten
  56. resultiert.“</p>
  57. <p>In Wirklichkeit stellt dies ein grobes Missverständnis von Standards,
  58. ihrer Rolle und ihrer Funktionsweise dar.</p>
  59. <ol>
  60. <li>Gebührenfreie Lizenzbedingungen verhindern nicht, dass patentierte
  61. Technologien in Standards aufgenommen werden. Der Beitragende ist
  62. nur angehalten, keine Lizenzgebühren für Implementierungen zu
  63. erheben.</li>
  64. <li>Die auf einzigartige Weise erfolgreichste
  65. Technologie-Plattform der Welt, das
  66. Internet, baut auf Standards auf, die vollständig unter gebührenfreien
  67. Lizenzbedingungen verfügbar gemacht wurden. In der Tat hat das W3C,
  68. die für Web-Standards zuständige Standardisierungsorganisation (SSO),
  69. im Konsens eine gebührenfreie „Geistiges-Eigentum-Richtlinie“
  70. beschlossen, nach der gebührenpflichtige Technologien nur in seltenen
  71. Ausnahmefällen verwendet werden dürfen. Anstatt Innovationen zu
  72. behindern, wie von der BSA behauptet, hat dies das Internet zu einer
  73. Hochburg der Innovation gemacht. Tatsächlich ist es gerade das
  74. Wesen von Standards, dass sie eine Plattform stabilisieren, auf deren
  75. Grundlage Marktteilnehmer innovative oder interoperable Lösungen
  76. entwickeln können<a class="fn" href="#refs">1</a>.</li>
  77. <li>Im Widerspruch zur Behauptung der BSA eröffnen gebührenfreie
  78. Patentlizenzierungsrichtlinien der größtmöglichen Anzahl von
  79. Marktteilnehmern und Implementierern die Möglichkeit, am
  80. Standardisierungsprozess für Software teilzunehmen. Im Ergebnis sind
  81. Software-Standards, die von Standardisierungsorganisationen mit
  82. gebührenfreien Patentlizenzierungsrichtlinien, wie dem W3C,
  83. beschlossen werden, weit verbreitet, dabei ist der HTML-Standard nur
  84. das bekannteste Beispiel.</li>
  85. </ol>
  86. <p>Aus einer umfassenderen Sicht hinsichtlich Richtlinien ist es auch
  87. fragwürdig, dass Innovatoren, die bereits einen Anreiz durch ein
  88. Patent haben, einen weiteren Anreiz bräuchten, indem das Patent in
  89. einen Standard aufgenommen wird. Ein Patent bedeutet nicht das Recht
  90. auf eine garantierte Einkommensquelle.</p>
  91. <h2 id="2">Die von der BSA als Beispiele angeführten Standards sind im
  92. Software-Bereich irrelevant</h2>
  93. <p>Die BSA argumentiert, dass „viele der heute am weitesten
  94. verbreiteten offenen Spezifikationen patentierte Innovationen
  95. beinhalten, die von kommerziellen Firmen entwickelt wurden … darunter
  96. WiFi, GSM und MPEG.“</p>
  97. <p>Damit wird unterstellt, es gebe einen zwingenden Zusammenhang zwischen
  98. „kommerziell“ und „patentiert“. Kommerzielle Unternehmen würden die von
  99. ihnen entwickelten Technologien grundsätzlich patentieren, während
  100. nicht-patentierte Erfindungen nur im nicht-kommerziellen Bereich zu
  101. finden seien.
  102. In Wirklichkeit stellt ein Großteil
  103. der nicht patentierten modernen Technologie, die ihren Ursprung in
  104. kommerziellen Unternehmen hat, weltweit eingesetzte Standards dar (wie
  105. z.&#160;B. HTML5), die auch weiterhin ihre Entwickler mit Einkommen
  106. versorgen. Es gibt keine derartige Trennlinie, weder ökonomisch noch
  107. ideologisch, zwischen Hardware- und Software-Technologien, die patentiert
  108. sind, und denen, die es nicht sind. Trotzdem legt die BSA
  109. nahe, dass es einen Unterschied zwischen konventionellen
  110. und akzeptierten Geschäftsmethoden, die sie mit Patenten in Verbindung
  111. bringen, und nicht-geschäftsmäßigen, nicht-kommerziellen Organisationen,
  112. die sie mit patentfreier Technologie in Verbindung bringen, gebe. Im
  113. Hinblick auf die zunehmende Verbreitung von Freier Software im
  114. europäischen IT-Dienstleistungsmarkt ist solch eine Behauptung schlicht
  115. und einfach falsch.</p>
  116. <p>Die von der BSA als Beispiele aufgeführten Standards beziehen sich (mit
  117. Ausnahme von MPEG<a class="fn" href="#refs">2</a>) auf hardwarebasierte
  118. Technologien. Die Ökonomie des Hardware-Markts unterscheidet sich
  119. wesentlich von der des Software-Markts. Während der Eintritt in den
  120. Hardware-Markt beträchtliche Investitionen voraussetzt, kann ein
  121. Software-Unternehmen mit einem sehr kleinen Startkapital gegründet
  122. werden. Von solch einem Software-Startup-Unternehmen zu verlangen,
  123. Gebühren für die Implementierung von Software-Standards zu bezahlen,
  124. würde die Markteintrittsbarriere signifikant erhöhen, Innovationen
  125. verringern und den Wettbewerb behindern, und daneben auch die Preise für
  126. Konsumenten (einschließlich Organisationen des öffentlichen Sektors)
  127. erhöhen.</p>
  128. <p>Für Software ist es eindeutig, dass die Akzeptanz der Aufnahme
  129. von Patenten in Standards unter (F)RAND-Bedingungen die
  130. Eintrittsbarriere in den europäischen Software-Markt auf unangemessene
  131. und unnötige Art erhöht, und dadurch die europäische IKT-Wirtschaft
  132. weniger wettbewerbsfähig macht.</p>
  133. <h2 id="3">(F)RAND-Lizenzierung in Software-Standards ist unfair und
  134. diskriminierend</h2>
  135. <p>Die BSA argumentiert, dass „die Bedingungen, dass eine offene
  136. Spezifikation ‚frei implementierbar‘ sein muss, sowie frei
  137. verbreitet und wiederverwenden werden kann, mehrdeutig sind,
  138. und darauf hindeuten, dass der Standard frei von geistigen
  139. Eigentumsrechten sein muss.“</p>
  140. <p>Weiter argumentiert die BSA, dass FRAND sicherstellt, dass diese
  141. Innovationen unter fairen Bedingungen benutzt werden können, um den
  142. Standard zu implementieren.
  143. Dadurch wird es Erfindern erlaubt, eine
  144. angemessene Gebühr zu erheben, wenn ihre Technologien in Spezifikationen
  145. verwendet werden.“ In Software-Standards sind (F)RAND-Bedingungen aber
  146. diskriminierend gegenüber Freier Software und allen darauf basierenden
  147. Geschäftsmodellen. Die am häufigsten verwendeten Freie-Software-Lizenzen
  148. erlauben nicht, dass den Benutzern der Software zusätzliche Bedingungen
  149. auferlegt werden. Doch (F)RAND würde verlangen, dass solche Bedingungen
  150. gestellt würden, normalerweise in Form von Lizenzgebühren, die von der
  151. Zahl der Benutzer abhängen, was (F)RAND-Lizenzierungsrichtlinien
  152. inkompatibel mit Freier Software macht. Was Software-Standards betrifft,
  153. ist die (F)RAND-Herangehensweise weder vernünftig, noch
  154. nicht-diskriminierend.</p>
  155. <p>Im umgekehrten Fall schließt eine Gebührenfreiheit proprietäre
  156. Implementierungen nicht aus (nicht einmal solche, die in hohem Ausmaß
  157. patentiert sind). Tatsächlich bedeutet Gebührenfreiheit, dass, insofern
  158. bestimmte Technologien in einem Standard vorgeschrieben sind, diese jedem
  159. ohne die Zahlung einer Lizenzgebühr zur Verfügung stehen müssen. Indessen
  160. können die Implementierungen unter beliebigen Lizenzen vertrieben werden
  161. und beliebige Technologien beinhalten, solange sie sich an den Standard
  162. halten.</p>
  163. <p>Der gebührenfreie HTML-Standard ist beispielsweise in einer Vielzahl
  164. von Browsern implementiert, sowohl solchen, die auf Freier Software
  165. beruhen, als auch proprietären. Dies zeigt deutlich, dass ein
  166. gebührenfreier Software-Standard eine weite Verbreitung haben
  167. und Innovation durch Wettbewerb fördern kann.</p>
  168. <h2 id="4">Die BSA repräsentiert nicht einmal ihre eigenen Mitglieder,
  169. geschweige denn die Software-Industrie als Ganzes</h2>
  170. <p>Die BSA argumentiert, „der EIF könnte dahingehend interpretiert
  171. werden, dass die Teilnahme der innovativsten europäischen und
  172. nicht-europäischen Unternehmen am Standardisierungsprozess
  173. nicht erwünscht ist, falls sie Patente in den relevanten
  174. Technologien besitzen und sie im Fall, dass diese
  175. Patente Teil eines Standards werden, eine Vergütung für ihre Erfindungen
  176. verlangen.“</p>
  177. <p>Weiter behauptet die BSA: „Die Beteiligten verstehen die wichtige
  178. Verbindung zwischen geistigem Eigentum und Standardisierung – und
  179. verstehen auch, dass FRAND-basierte Standards äußerst flexibel sind
  180. und in einem großen Bereich von Lösungen implementiert werden können,
  181. sowohl in Open-Source, als auch in proprietären.“</p>
  182. <p>Im Widerspruch zur Behauptung der BSA, eine einheitliche Position
  183. der Software-Industrie zu vertreten, möchten wir bemerken, dass die
  184. ECIS, die von wichtigen Beteiligten der Industrie gebildet wurde (von
  185. denen manche auch Mitglied der BSA sind), das Gegenteil
  186. behauptet<a class="fn" href="#refs">3</a>. Obwohl die Mitglieder der ECIS
  187. über große Patentportfolios verfügen, wollen sie, dass Standards zur
  188. Software-Interoperabilität frei von Lizenzgebühren sind. Um nur ein
  189. Beispiel zu nennen: Google hat in großem Maße zu gebührenfreien
  190. Standards beigetragen, indem es eine durch die Industrie unterstützte
  191. Alternative zu MPEG anbietet.</p>
  192. <h2 id="5">(F)RAND ist inkompatibel mit den meisten
  193. Freie-Software-Lizenzen</h2>
  194. <p>Die BSA behauptet, dass „die meisten Open-Source-Lizenzen vollständig
  195. kompatibel mit FRAND-basierter Lizenzierung sind.“</p>
  196. <p>Nach jeder vernünftigen Zählung (ob nach Menge des verfügbaren
  197. Source-Codes, dessen Wichtigkeit oder beidem) sind die relevantesten
  198. Freien (Open-Source) Software-Lizenzen:</p>
  199. <ol>
  200. <li>GNU GPL und LGPL</li>
  201. <li>Mozilla Public License</li>
  202. <li>Apache Public License</li>
  203. <li>BSD/MIT und andere ultra-freizügige Lizenzen</li>
  204. <li>EUPL</li>
  205. </ol>
  206. <p>Alle diese, eventuell mit Ausnahme der ultra-freizügigen Lizenzen,
  207. was aber nicht sicher ist, sind eindeutig inkompatibel mit
  208. gebührenpflichtigen Patentlizenzen. Gemäß Statistiken, die von
  209. <a href="http://www.blackducksoftware.com/oss/licenses#top20">Black Duck
  210. Software</a> veröffentlicht wurden, werden mehr als 85% der
  211. Freie-Software-Projekte unter Lizenzen vertrieben, die mit
  212. gebührenpflichtigen Patentlizenzen inkompatibel sind. Die GNU General
  213. Public License (GPL) ist als die weitaus am Häufigsten verwendete
  214. Freie-Software-Lizenz aufgelistet, sie wird von nahezu der Hälfte aller
  215. Projekte verwendet. Die Aufnahme von patentierten Technologien in
  216. auf Freier Software basierende Produkte verlangt von den
  217. Implementierern, falls überhaupt möglich, eine schwierige Vermischung
  218. von proprietären Teilen mit Freier Software. In solchen Fällen ist
  219. der resultierende Code zwangsläufig proprietäre
  220. Software<a class="fn" href="#refs">5</a>.</p>
  221. <h2 id="6">Eine Bevorzugung Offener Standards steht in keinerlei
  222. Zusammenhang mit der Verhandlungsposition der EU gegenüber China</h2>
  223. <p>Die BSA behauptet: „Die Mehrdeutigkeit der vorgeschlagenen
  224. Bevorzugung im EIF wird zweifelsohne
  225. die Fähigkeit der Kommission schwächen, die geistigen Eigentumsrechte
  226. der Europäer gegen eine Bedrohung aus China zu verteidigen.“</p>
  227. <p>Die Behauptung, dass die Empfehlung, offene
  228. Spezifikationen zu bevorzugen, die Verhandlungsposition der EU gegenüber China schwächen
  229. wird, ist schlicht und einfach falsch. Empfehlungen bezüglich der
  230. Nutzung offener Software-Spezifikationen im öffentlichen Sektor haben
  231. keinerlei Auswirkungen auf die Position der Kommission. Außerdem sollte
  232. noch einmal gesagt werden, dass gebührenfreie Standards nicht im
  233. Widerspruch zu einer „soliden Verteidigung“ von Patenten, Urheberrechten
  234. und Markenzeichen stehen.</p>
  235. <p>Wir möchten bemerken, dass in den Vereinigten Staaten im Zuge der
  236. Erstellung des „Special 301“ Berichts zu Handelshemmnissen von 2010
  237. dem US-Handelsbeauftragten ähnliche Bedenken übermittelt wurden. Der
  238. Handelsbeauftragte beschloss, diese Bedenken nicht mit in den Bericht
  239. aufzunehmen, was deutlich zeigt, dass dies für die Regierung der
  240. Vereinigten Staaten kein Thema ist. Während solche Bedenken oft
  241. bei Beeinflussungsversuchen öffentlicher Politik geäußert werden, gibt
  242. es eine augenfällige Abwesenheit von Versuchen, solche Bevorzugungen
  243. auf rechtlichem Weg zu entfernen – vermutlich weil die, die die
  244. Behauptungen aufstellen, sehr gut wissen, dass die Behauptungen nicht
  245. auf Fakten beruhen.</p>
  246. <h2 id="7">Spezifikationen ohne Beschränkungen werden Standardisierung,
  247. Wettbewerb und Interoperabilität fördern</h2>
  248. <p>Die BSA behauptet, dass „die vorgeschlagene Bevorzugung des EIF für
  249. Spezifikationen, die frei von geistigem Eigentum sind, langfristig
  250. Standardisierung, Wettbewerbsfähigkeit und Interoperabilität untergraben
  251. wird.“</p>
  252. <p>Wir sind nicht in der Lage, zu deuten, was die BSA mit
  253. „von geistigem Eigentum freien Spezifikationen“ meint, aber wir glauben,
  254. dass eine solche Wortwahl von einem ungenügenden Verständnis des
  255. Standardisierungsprozesses von Seiten der BSA zeugt.</p>
  256. <p>Die Behauptung, dass die aktuelle Version des EIF Interoperabilität
  257. untergraben könnte, ist einfach untragbar. Sie folgt aus unbewiesenen
  258. Annahmen, von denen wir in der obigen Diskussion gezeigt haben, dass
  259. sie falsch sind. Zum gegenwärtigen Zeitpunkt halten Lock-in-Effekte, die
  260. aus der Benutzung proprietärer Software und Dateiformate entstehen,
  261. die öffentliche Verwaltung häufig von einer freien Wahl ihrer
  262. IT-Lösungen ab. Stattdessen bleiben sie an einen bestimmten Anbieter
  263. gebunden.
  264. Der Stadtrat von Brighton und der Schweizer Kanton Solothurn sind zwei
  265. Beispiele der letzten Monate für die zahlreichen öffentlichen
  266. Einrichtungen, die von einer IT-Lösung zu einer anderen migrieren
  267. wollen und dabei durch patentgeschützte Software-Standards in einer
  268. suboptimalen Lösung festgehalten werden. Dieser Lock-in-Effekt führt zu
  269. Schwierigkeiten bei der Migration und zu hohen Kosten für die
  270. Steuerzahler.</p>
  271. <p>Im umgekehrten Fall erlauben Software-Standards, die ohne
  272. Beschränkungen implementiert werden könne, vielen konkurrierenden
  273. Implementierungen, miteinander zusammenzuarbeiten. In so einem Umfeld
  274. werden die Monopoleinnahmen einer kleinen Zahl von Großunternehmen
  275. durch einen lebhaften, innovativen Markt abgelöst, der sich durch
  276. einen harten Wettbewerb auszeichnet. Das Ergebnis sind bessere Lösungen
  277. und Dienstleistungen zu niedrigeren Preisen.</p>
  278. <h2 id="8">Empfehlungen</h2>
  279. <p>Im Licht der obigen Überlegungen fordern wir die Kommission
  280. eindringlich auf, Interoperabilität und Wettbewerb auf dem europäischen
  281. Software-Markt zu fördern, und nicht den etablierten, dominanten
  282. Unternehmen einen weiteren Hebel an die Hand zu geben, um ihre
  283. Kontrolle des Markts aufrechtzuerhalten. Daher fordern wir die
  284. Kommission auf, keine Billigung von (F)RAND-Lizenzierungen für
  285. Software-Standards in den EIF aufzunehmen. Stattdessen fordern wir
  286. die Kommission eindringlich auf, die Empfehlung beizubehalten, dass
  287. Spezifikationen nur als offen angesehen werden können, wenn sie unter
  288. unterschiedlichen Software-Linzenzierungsmodellen implementiert und
  289. verbreitet werden können, inklusive Freier
  290. Software<a class="fn" href="#refs">6</a> , die unter der GNU GPL
  291. lizenziert wird.</p>
  292. <p>Wir fordern die Kommission auch eindringlich auf, in die
  293. Revision des European Interoperability Framework eine starke
  294. Empfehlung an öffentliche Einrichtungen aufzunehmen, die Vorteile
  295. von Software, die auf Offenen Standards<a class="fn" href="#refs">7</a>
  296. basiert, im Hinblick auf freie Wahl, Wettbewerb, Vermeidung von
  297. Lock-in-Effekten und langfristiger Lesbarkeit von Daten zu nutzen.</p>
  298. <h2 id="fn">Fußnoten</h2>
  299. <ol id="refs">
  300. <li>Siehe z.B. Rishab Aiyer Ghosh, Philipp Schmidt (2006): United
  301. Nations University Policy Brief, Nr. 1, 2006: „Wohldefinierte
  302. Offene Standards können den einzigartigen ökonomischen Effekt haben,
  303. dass ‚natürliche‘ Monopole für eine bestimmte Technologie gebildet
  304. werden können, während sie einen vollen Wettbewerb zwischen
  305. Anbietern dieser Technologie gewährleisten.“ [Hervorhebung
  306. hinzugefügt]</li>
  307. <li>MPEG ist eigens dahingehend entwickelt, dass ausdrücklich der
  308. Einsatz patentierter Technologien vorgeschrieben wird, sogar wo diese
  309. größtenteils durch (nach Meinung von Experten) nicht patentgeschützte
  310. Alternativen ersetzt werden können. Es ist vorstellbar, dass der
  311. Grund dafür ist, dass so viel Profit wie möglich aus der Verwendung
  312. einer bestimmten Implementierung gewisser mathematischer Prinzipien
  313. erzielt werden soll, anstatt eine gemeinsame und standardisierte
  314. Plattform zum Zweck der Interoperabilität zu schaffen.
  315. <br />
  316. Darüber hinaus wurden die meisten MPEG-Standards zu einer Zeit
  317. etabliert, als Codecs noch in Hardware implementiert wurden, weil
  318. die verfügbare Bandbreite begrenzt und generische Hardware nicht
  319. ausreichend leistungsfähig war.</li>
  320. <li>Siehe
  321. <a href="http://www.ecis.eu/documents/ECISStatementreEIF13.10.10.pdf">die
  322. Reaktion der ECIS</a> vom 13. Oktober 2010 auf den Brief der BSA</li>
  323. <li>Für eine Diskussion hybrider Lösungen und Netzwerkprotokollen
  324. siehe die <a href="/activities/ms-vs-eu/fsfe_art18_reply_published_sourcecode.pdf">Antwort
  325. der FSFE und des Samba-Teams auf den Artikel 18</a>.</li>
  326. <li>Siehe die <a href="http://fsfe.org/about/basics/freesoftware.en.html">Definition Freier Software der FSFE</a></li>
  327. <li>Wie definiert in der <a href="/activities/os/def.html">Definition
  328. eines Offenen Standards der FSFE</a></li>
  329. </ol>
  330. </body>
  331. <timestamp>$Date: 2010-10-21 16:02:28 +0200 (Thu, 21 Oct 2010) $ $Author: guest-enz $</timestamp>
  332. <translator>Markus Enzenberger</translator>
  333. </html>