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.

bsa-letter-analysis.de.xhtml 20KB

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