diff options
Diffstat (limited to 'talermerchantdemos/blog/articles/de/thegnuproject.html')
-rw-r--r-- | talermerchantdemos/blog/articles/de/thegnuproject.html | 1226 |
1 files changed, 1226 insertions, 0 deletions
diff --git a/talermerchantdemos/blog/articles/de/thegnuproject.html b/talermerchantdemos/blog/articles/de/thegnuproject.html new file mode 100644 index 0000000..26d5d1c --- /dev/null +++ b/talermerchantdemos/blog/articles/de/thegnuproject.html @@ -0,0 +1,1226 @@ +<!--#set var="ENGLISH_PAGE" value="/gnu/thegnuproject.en.html" --> + +<!--#include virtual="/server/header.de.html" --> +<!-- Parent-Version: 1.86 --> + +<!-- This file is automatically generated by GNUnited Nations! --> +<title>Über das Projekt ‚GNU‘ - GNU-Projekt - Free Software Foundation</title> +<meta http-equiv="Keywords" content=" " /> + +<!--#include virtual="/gnu/po/thegnuproject.translist" --> +<!--#include virtual="/server/banner.de.html" --> +<h2>Über das Projekt ‚GNU‘</h2> + +<p> +von <strong><a href="//www.stallman.org/">Richard Stallman</a></strong></p> + +<blockquote> +<p> +<span class="intro">Die englische Originalausgabe wurde in dem Buch +<cite><span xml:lang="en" lang="en">Open Sources</span></cite> +veröffentlicht. Richard Stallman war <a +href="/philosophy/open-source-misses-the-point">nie ein Anhänger von <span +xml:lang="en" lang="en"><em>„Open Source“;</em></span></a>, trug aber diesen +Artikel bei, damit die Anschauungen der Freie-Software-Bewegung nicht völlig +fehlen würden.</span> +</p> +<p> +<ins>Bitte beachten Sie auch den Aufsatz</ins> <cite><a +href="/philosophy/free-software-even-more-important">Freie Software ist +jetzt sogar noch wichtiger</a></cite> denn je, denn wir sollten auf +Software ‑ Software die wir +nutzen! ‑ bestehen, die frei ist. +</p> +</blockquote> + +<h3>Die erste Software-teilende Gemeinschaft</h3> +<p> +Als ich 1971 am <span xml:lang="en" lang="en">Artificial Intelligence +Laboratory (AI Lab)</span> des <span xml:lang="en" lang="en">Massachusetts +Institute of Technology</span> anfing zu arbeiten, wurde ich Teil einer +Software-teilenden Gemeinschaft, die schon seit Jahren existierte. Die +gemeinsame Nutzung von Software war nicht nur auf unsere besondere +Gemeinschaft beschränkt; sie ist so alt wie Rechner selbst, genauso wie der +Austausch von Kochrezepten so alt wie das Kochen ist. Aber wir praktizierten +es mehr als die meisten.</p> +<p> +Das <span xml:lang="en" lang="en">AI Lab</span> verwendete ein +Mehrbenutzer-Betriebssystem namens <em><span xml:lang="en" +lang="en">Incompatible Timesharing System</span></em> (ITS), welches die +Hacker<a href="#fn1" id="fn1-ref" class="fnote">(1)</a> des Laborpersonals +in der Programmiersprache Assembler für den Digital <abbr title="Programmed +Data Processor">PDP</abbr>-10, einen der großen Rechner dieser Ära, +entworfen und geschrieben hatten. Als Mitglied dieser Gemeinschaft, ein +angestellter Systemhacker des <span xml:lang="en" lang="en">AI Labs</span>, +war es meine Aufgabe dieses System zu verbessern.</p> +<p> +Wir nannten unsere Software nicht <em>Freie Software</em>, da dieser +Ausdruck noch nicht geprägt war, aber das ist es, was sie war. Wann immer +jemand von einer anderen Universität oder einer Firma ein Programm portieren +und benutzen wollte, freute uns das und wir ließen sie gewähren. Wenn man +jemanden ein unbekanntes interessantes Programm benutzen sah, konnte man +immer den Quellcode bekommen, sodass man diesen lesen, verändern oder sogar +Teile davon für neue Programme ausschlachten konnte.</p> +<p> +<!-- see footer --></p> + +<h3>Der Zusammenbruch der Gemeinschaft</h3> +<p> +Die Situation änderte sich Anfang der 80er Jahre drastisch, als <span +xml:lang="en" lang="en">Digital</span> die PDP-10-Serie einstellte. Ihre +Architektur, elegant und leistungsfähig in den 60ern, konnte natürlich nicht +auf größere Adressräume erweitert werden, welche in den 80ern möglich +wurden. Das bedeutete, dass nahezu alle im ITS zusammengesetzten Programme +veraltet waren.</p> +<p> +Die Hacker-Gemeinschaft des <span xml:lang="en" lang="en">AI Labs</span> war +bereits kurz vorher zusammengebrochen. Im Jahr 1981 hatte das ausgegliederte +Unternehmen Symbolics fast alle Hacker aus dem <span xml:lang="en" +lang="en">AI Lab</span> abgeworben, und die entvölkerte Gemeinschaft war +außerstande, sich zu behaupten (das Buch <cite><span xml:lang="en" +lang="en">Hackers</span></cite> von Steve Levy beschreibt diese Ereignisse +sowie ein klares Bild dieser Gemeinschaft in ihrer Blütezeit). Als das <span +xml:lang="en" lang="en">AI Lab</span> 1982 einen neuen PDP-10 kaufte, +entschieden dessen Administratoren, <span xml:lang="en" +lang="en">Digitals</span> unfreies Mehrbenutzer-Betriebssystem anstatt ITS +zu benutzen.</p> +<p> +Die modernen Rechner dieser Ära, wie der VAX oder der 68020, hatten eigene +Betriebssysteme, aber keines war <em>freie</em> Software: man musste sogar +eine Vertraulichkeitsvereinbarung unterzeichnen, nur um eine ausführbare +Kopie zu erhalten.</p> +<p> +Das bedeutete, dass der erste Schritt zur Benutzung eines Rechners darin +bestand zu versprechen, seinen Nächsten nicht zu helfen. Eine +zusammenarbeitende Gemeinschaft war verboten. Die Vorschrift von Eigentümern +proprietärer Software war: „Wenn Sie mit ihrem Nächsten teilen, sind Sie ein +Softwarepirat. Möchten Sie irgendwelche Änderungen, bitten Sie uns, diese +vorzunehmen.“</p> +<p> +Die Idee, dass das proprietäre Software-Sozialsystem ‑ das +System, was besagt, man sei nicht berechtigt Software zu teilen oder zu +verändern ‑ unsozial, unethisch und einfach falsch ist, mag +einige überraschen. Aber was könnten wir sonst über ein System sagen, was +darauf basiert die Allgemeinheit zu spalten und Nutzer hilflos zu halten? +Leserinnen und Leser, die diesen Gedanken überraschend finden, haben das +proprietäre Software-Sozialsystem möglicherweise als gegeben angesehen oder +es unter den von den proprietären Softwareunternehmen vorgeschlagenen +Begriffen beurteilt. Softwarehersteller haben lange und hart daran +gearbeitet Menschen davon zu überzeugen, es gäbe nur einen Blickwinkel auf +dieses Problem.</p> +<p> +Wenn Softwarehersteller über <em>„Durchsetzung“</em> ihrer <em>„Rechte“</em> +oder <em>Verhinderung von <a +href="/philosophy/words-to-avoid.html#Piracy">„Softwarepiraterie“</a></em> +sprechen, ist das, was sie wirklich <em>meinen</em>, zweitrangig. Die +eigentliche Botschaft dieser Aussagen ist die unausgesprochene, für +selbstverständlich gehaltene Annahme, die Öffentlichkeit aufzufordern, diese +ungeprüft zu akzeptieren. Betrachten wir sie deshalb etwas näher.</p> +<p> +Eine Annahme ist, dass Softwareunternehmen ein unbestreitbares natürliches +Recht auf eigene Software und damit Macht über alle ihre Benutzer haben +(wenn dies ein natürliches Recht wäre, ganz gleich wie viel Schaden es für +die Öffentlichkeit bedeutet, könnten wir nichts dagegen +machen). Interessanterweise lehnen die US-Verfassung und rechtliche +Traditionen diese Auffassung ab. Urheberrecht ist kein natürliches Recht, +sondern ein vom Staat künstlich auferlegtes Monopol, das Benutzern das +natürliche Recht zu kopieren eingrenzt.</p> +<p> +Eine weitere unausgesprochene Annahme ist, dass es bei Software nur wichtig +ist, welche Aufgaben sie einem erlaubt auszuführen ‑ das wir +Rechnernutzer uns nicht darum kümmern sollten, was für eine Gesellschaft wir +haben dürfen.</p> +<p> +Eine dritte Annahme ist, dass wir keine brauchbare Software haben würden +(oder niemals ein Programm haben würden, um die eine oder andere Aufgabe zu +erledigen), wenn wir einem Unternehmen nicht die Macht über die Benutzer des +Programms geben würden. Diese Annahme mag ganz plausibel gewesen sein, bevor +die Freie-Software-Bewegung gezeigt hat, dass wir eine Menge nützlicher +Software entwickeln können, ohne sie an Ketten zu legen.</p> +<p> +Wenn wir diese Annahmen ablehnen zu akzeptieren und diese Probleme auf +Grundlage des gesunden Menschenverstandes +moralisch ‑ Benutzerinnen und Benutzer an erster +Stelle ‑ beurteilen, kommen wir zu ganz anderen +Schlussfolgerungen. Rechnernutzer sollten Programme entsprechend ihren +Bedürfnissen anpassen und mit anderen teilen können, denn anderen Menschen +zu helfen ist die Grundlage der Gesellschaft.</p> +<p> +Es würde den Rahmen dieses Dokuments sprengen, die Gründe für diese +Schlussfolgerung ausführlich darzulegen, möchte aber auf die Artikel +<cite><a href="/philosophy/why-free">Warum Software keine Eigentümer haben +sollte</a></cite> und <cite><a +href="/philosophy/free-software-even-more-important">Freie Software ist +jetzt sogar noch wichtiger</a></cite> verweisen. +</p> + +<h3>Eine gänzlich moralische Entscheidung</h3> +<p> +Mit dem Verlust meiner Gemeinschaft war es unmöglich weiterzumachen wie +zuvor. Stattdessen stand ich vor einer gänzlich moralischen Entscheidung.</p> +<p> +Die einfachste Entscheidung wäre wohl gewesen, der proprietären Softwarewelt +beizutreten, Vertraulichkeitsvereinbarungen zu unterzeichnen und zu +versprechen, meinen Mithackern nicht mehr zu helfen. Sehr wahrscheinlich +würde ich auch Software entwickeln, die unter Vertraulichkeitsvereinbarungen +freigegeben wäre und somit den Druck auf andere Menschen erhöhen, ihre +Mitmenschen auch zu verraten.</p> +<p> +Ich hätte auf diese Weise Geld gemacht und mich vielleicht mit dem Schreiben +von Quellcode vergnügen können. Aber ich wusste, dass ich am Ende meiner +Karriere auf Jahre des Mauerbauens, um Menschen zu spalten, zurückblicken +und das Gefühl haben würde, mein Leben damit verbracht zu haben, die Welt zu +einem noch schlimmeren Ort gemacht zu haben.</p> +<p> +Ich hatte bereits Erfahrung damit, am empfangenden Ende einer +Vertraulichkeitsvereinbarung zu sein, als sich jemand weigerte, mir und dem +<span xml:lang="en" lang="en">MIT AI Lab</span> den Quellcode für das +Steuerprogramm unseres Druckers zu geben (der Mangel bestimmter Fähigkeiten +in diesem Programm machte den Gebrauch des Druckers äußerst +frustrierend). Also konnte ich mir selbst nicht mehr sagen, dass +Vertraulichkeitsvereinbarungen unschuldig waren. Ich war sehr verärgert, als +er sich weigerte mit uns zu teilen. Ich konnte mich nicht einfach umdrehen +und dasselbe mit anderen machen.</p> +<p> +Eine andere Alternative, einfach aber unangenehm, war der Rechnerwelt den +Rücken zukehren. Auf diese Weise würden meine Kenntnisse nicht +missbräuchlich genutzt werden, aber dennoch verschwendet. Ich wäre zwar +nicht Schuld an der Spaltung und Beschränkung von Rechnernutzern, aber es +würde dennoch passieren.</p> +<p> +Also suchte ich nach einem Weg, auf dem ein Programmierer etwas Gutes +bewirken kann. Ich fragte mich, ob es ein Programm oder Programme gab, das +oder die ich schreiben könnte, um so noch einmal eine Gemeinschaft möglich +zu machen.</p> +<p> +Die Antwort war klar: was zuerst erforderlich war, war ein +Betriebssystem. Das ist die entscheidende Software, um anzufangen, einen +Rechner zu benutzen. Mit einem Betriebssystem kann man viele Dinge machen, +ohne kann man den Rechner überhaupt nicht benutzen. Mit einem freien +Betriebssystem könnten wir wieder eine Gemeinschaft von zusammenarbeitenden +Hackern haben ‑ und jeden einladen, sich uns +anzuschließen. Und jedermann wäre in der Lage einen Rechner zu benutzen, +ohne auf verschwörerische Weise zu beginnen seine oder ihre Freunde zu +benachteiligen.</p> +<p> +Als Betriebssystementwickler hatte ich die richtigen Kenntnisse für diese +Aufgabe. Auch wenn ich den Erfolg nicht als garantiert ansehen konnte, wurde +mir klar, dass ich auserwählt war diese Aufgabe zu übernehmen. Ich entschied +mich das System mit Unix kompatibel zu machen, damit es portabel wäre und +Unix-Benutzer somit leichter umsteigen könnten. Der Name <em>GNU</em> wurde, +einer Hacker-Tradition folgend, als ein rekursives Akronym für <em><span +xml:lang="en" lang="en">GNU’s Not Unix</span></em> (‚GNU ist nicht Unix‘) +gewählt und wird [<a title="Aussprache" href="/pronunciation/">ˈgnuː</a>] +ausgesprochen.</p> +<p> +Ein Betriebssystem bedeutet nicht nur einen +Betriebssystemkern ‑ kaum genug, um andere Programme +auszuführen. In den 1970ern umfasste jedes Betriebssystem, das diesen Namen +verdiente, Befehlsinterpreter, Assembler, Compiler, Interpreter, Debugger, +Texteditoren, E-Mail-Anwendungen und vieles mehr. ITS, Multics, VMS und Unix +hatten sie. Das GNU-Betriebssystem würde sie auch umfassen.</p> +<p> +Später hörte ich diese Wörter, zurückgeführt auf Hillel<a href="#fn2" +id="fn2-ref" class="fnote">[2]</a>:</p> + +<blockquote><p> + „Wenn ich nicht für mich bin, wer wird für mich sein?<br /> + Wenn ich nur für mich bin, was bin ich dann?<br /> + Wenn nicht jetzt, wann?“ +</p></blockquote> +<p> +Der Entschluss, mit dem GNU-Projekt zu beginnen, beruhte auf einem ähnlichen +Geist.</p> +<p> +<!--see footer--></p> + +<h3>Frei wie in Freiheit</h3> +<p> +Der Begriff <em>Freie Software</em> wird mitunter +missverstanden ‑ er hat nichts mit dem Preis zu tun. Es geht +um Freiheit. Hier deshalb die Freie-Software-Definition.</p> + +<p>Ein Programm ist Freie Software, für Sie, einem besonderen Benutzer, wenn:</p> + +<ul> + <li>Sie die Freiheit haben, das Programm auszuführen wie Sie möchten, für jeden +Zweck;</li> + + <li>Sie die Freiheit haben, das Programm an Ihre Bedürfnisse anzupassen (um +diese Freiheit in der Praxis umzusetzen, muss man Zugang zum Quellcode +haben, denn Programmänderungen ohne Quellcode sind außerordentlich +schwierig);</li> + + <li>Sie die Freiheit haben, Kopien weiterzuverbreiten, entweder gratis oder +gegen eine Gebühr;</li> + + <li>Sie die Freiheit haben, modifizierte Programmversionen zu distribuieren, +damit die Gemeinschaft von Ihren Verbesserungen profitieren kann.</li> +</ul> +<p> +Da sich <em>frei</em> auf Freiheit bezieht, nicht auf den Preis, gibt es +keinen Widerspruch zwischen Freie Software und dem Verkauf von +Kopien. Tatsächlich ist die Freiheit, Kopien zu verkaufen, entscheidend: +Sammlungen von auf CD-ROMs verkaufter freier Software sind für die +Gemeinschaft wichtig und der Verkauf ein wichtiger Weg, um mehr in die +Freie-Software-Entwicklung zu investieren. Daher ist ein Programm, das man +diesen Sammlungen nicht frei aufnehmen kann, keine <em>freie</em> Software.</p> +<p> +Aufgrund der Mehrdeutigkeit von <em>frei</em> hat man lange nach +Alternativen gesucht, aber niemand hat einen besseren Begriff gefunden. Die +englische Sprache hat mehr Wörter und Nuancen als jede andere, aber es fehlt +ein einfaches, eindeutiges Wort, das <em>frei</em> wie in Freiheit +bedeutet ‑ <em>uneingeschränkt</em> ist ein Wort, das dieser +Bedeutung am nächsten kommt. Derartige Alternativen wie <em>befreit</em>, +<em>Freiheit</em> und <em>offen</em> haben entweder die falsche Bedeutung +oder einen anderen Nachteil.</p> + +<h3>GNU-Software und das GNU-System</h3> +<p> +Die Entwicklung eines ganzen Systems ist ein sehr großes Projekt. Um es +erreichbar zu machen, beschloss ich, vorhandene Teile freier Software +anzupassen und zu nutzen, wo immer das möglich war. Beispielsweise entschied +ich mich gleich am Anfang hauptsächlich TeX als Textsatzsystem zu nutzen; +einige Jahre später beschloss ich, das <span xml:lang="en" lang="en">X +Window System (X11)</span> zu nutzen, anstatt ein anderes Fenstersystem für +GNU zu schreiben.</p> +<p> +Aufgrund dieser (und anderer ähnlicher) Entscheidungen ist das GNU-System +nicht das Gleiche wie die Sammlung aller GNU-Software. Das GNU-System +umfasst Programme, die nicht GNU-Software sind, Programme, die von anderen +Personen und Projekten für deren eigene Zwecke entwickelt +wurden ‑ aber die wir verwenden können, weil sie +<em>freie</em> Software sind.</p> + +<h3>Der Anfang des Projekts</h3> +<p> +Im Januar 1984 kündigte ich meinen Job am MIT und begann GNU-Software zu +schreiben. Das MIT zu verlassen war notwendig, damit es nicht in der Lage +gewesen wäre, sich in den Vertrieb von GNU als freie Software +einzumischen. Wäre ich als Mitarbeiter geblieben, hätte das MIT Anspruch auf +die Arbeit selbst erheben, eigene Vertriebsbedingungen festlegen oder die +Arbeit sogar in ein proprietäres Softwarepaket umwandeln können. Ich hatte +nicht die Absicht eine Menge Arbeit zu erledigen, um dann zu sehen, wie sie +für den eigentlichen Zweck nutzlos wird: das Schaffen einer neuen Software +teilenden Gemeinschaft.</p> +<p> +Allerdings lud mich Professor Winston, der damalige Leiter des <span +xml:lang="en" lang="en">MIT AI Lab</span>, freundlicherweise ein, weiterhin +die Einrichtung des Labors zu nutzen.</p> + +<h3>Die ersten Schritte</h3> +<p> +Kurz vor Beginn des GNU-Projekts hörte ich vom <em><span xml:lang="en" +lang="en">Free University Compiler Kit</span></em>, auch als VUCK bekannt +(das niederländische Wort für <em>frei</em> fängt mit einem <em>‚v‘</em>, +für <em><span xml:lang="nl" lang="nl">‚vrij‘</span></em>, an). Das war ein +Compiler, entwickelt, um mehrere Programmiersprachen, darunter C und Pascal, +zu verarbeiten und mehrere Zielplattformen zu unterstützten. Ich schrieb dem +Autor und fragte, ob das Programm für GNU genutzt werden könne.</p> +<p> +Er antwortete spöttisch und gab an, dass die Universität frei wäre, nicht +aber der Compiler. Ich beschloss daher, dass mein erstes Programm für das +GNU-Projekt ein mehrsprachiger, plattformübergreifender Compiler sein würde.</p> +<p> +In der Hoffnung, nicht notwendigerweise den ganzen Compiler selbst neu +schreiben zu müssen, erhielt ich schließlich den Quellcode des Pastel +Compilers, einem plattformübergreifenden Compiler, der am <span +xml:lang="en" lang="en">Lawrence Livermore Laboratory</span> entwickelt +wurde. Er unterstützte nicht nur eine erweiterte Version von Pascal, sondern +war auch in dieser als Systemprogrammiersprache geschrieben. Ich fügte ein +C-Frontend hinzu und begann die Portierung auf den Motorola +68000-Rechner. Als ich entdeckte, dass der Compiler mehrere Megabyte +Stack-Speicher benötigte und das verfügbare 68000 Unix-System nur 64k +erlauben würde, musste ich allerdings aufgeben.</p> +<p> +Dann fand ich heraus, dass der Pastel Compiler die gesamte Eingabedatei +durch Analyse in einen Syntaxbaum umwandelte, den gesamten Syntaxbaum in +eine Kette von <em>Anweisungen</em> umwandelte und dann die ganze +Ausgabedatei generierte, ohne jemals irgendwelchen Speicher wieder +freizugeben. An diesem Punkt entschloss ich mich, einen neuen Compiler von +Grund auf neu zu schreiben. Dieser neue Compiler ist heute als <em><span +xml:lang="en" lang="en">GNU Compiler Collection</span></em> (GCC) +bekannt. Nichts vom Pastel Compiler wurde darin genutzt, aber ich schaffte +es, das C-Frontend, welches ich geschrieben hatte, anzupassen und zu +nutzen. Aber das war erst einige Jahre später, zuerst arbeitete ich an GNU +Emacs.</p> + +<h3>GNU Emacs</h3> +<p> +Ich begann die Arbeit an <em>GNU Emacs</em> im September 1984, Anfang 1985 +fing er an brauchbar zu werden. Das ermöglichte mir für das weitere +Schreiben Unix-Systeme zu nutzen. Kein Interesse habend die Verwendung von +<em>Vi</em> oder <em>Ed</em> zu erlernen, hatte ich meine Bearbeitung bis +dahin auf anderen Rechnern erledigt.</p> +<p> +Zu diesem Zeitpunkt begann man GNU Emacs nutzen zu wollen, was die Frage +aufwarf, wie der Vertrieb aussehen sollte. Natürlich war er von einem +anonymen FTP-Server des MIT, den ich nutzte, abrufbar (dieser Rechner, +prep.ia.mit.edu, wurde daher zur wichtigsten FTP-Vertriebsseite von GNU. Als +er ein paar Jahre später stillgelegt wurde, transferierten wir den Namen auf +unseren neuen FTP-Server). Aber damals hatten viele Interessierte noch +keinen Internetzugang und konnten keine Kopie per FTP abrufen. Also stellte +sich die Frage, was ich ihnen sagen würde.</p> +<p> +Ich hätte sagen können: „Finden Sie einen Freund, der im Netz ist und eine +Kopie für Sie machen kann.“ Oder ich hätte gemacht, was ich mit dem +ursprünglichen PDP-10 Emacs praktizierte: „Übersenden Sie mir ein Magnetband +mit einem adressierten und frankierten Rückumschlag, und ich sende es mit +Emacs darauf zurück.“ Aber ich hatte keine Anstellung und suchte nach Wegen, +mit freier Software Geld zu verdienen. Also kündigte ich an, jedem gegen +eine Gebühr von 150 US-Dollar ein Magnetband zu senden. Auf diese Weise +begann ich einen geschäftlichen Vertrieb mit freier Software, dem Vorläufer +der Unternehmen, die heute ganze GNU/Linux-Distributionen verbreiten.</p> + +<h3>Ist ein Programm für jeden Benutzer frei?</h3> +<p> +Wenn ein Programm, wenn es die Hände des Autors verlässt, Freie Software +ist, bedeutet dies nicht notwendigerweise, dass es für jedermann +<em>freie</em> Software sein wird, die eine Kopie davon +besitzen. Beispielsweise ist <a +href="/philosophy/categories.html#PublicDomainSoftware">Public-Domain-Software</a> +(Software, die nicht dem Urheberrecht unterliegt)<a href="#tn1" id="tn1-ref" +class="tnote">[*]</a> Freie Software, aber jeder kann eine proprietäre +modifizierte Version davon erstellen. Ebenfalls sind viele freie Programme +mit einem Copyright versehen, aber unter einfachen freizügigen Lizenzen, die +proprietäre modifizierte Versionen ermöglichen.</p> +<p> +Das paradigmatische Beispiel dieses Problems ist das <span xml:lang="en" +lang="en">X Window System</span> (X11). Am MIT entwickelt und als Freie +Software mit einer freizügigen Lizenz freigegeben, wurde es bald von +verschiedenen Rechnerfirmen adaptiert. Sie fügten X11 nur in binärer Form +ihren proprietären Unix-Systemen hinzu ‑ mit einer +Vertraulichkeitsvereinbarung. Diese X11-Kopien waren wie Unix keine +<em>freie</em> Software mehr.</p> +<p> +Die Entwickler von X11 betrachteten dies nicht als ein +Problem ‑ sie erwarteten und beabsichtigten es sogar. Ziel +war nicht Freiheit, nur <em>Erfolg</em>, definiert als <em>viele Benutzer +habend</em>. Es kümmerte nicht, ob diese Freiheit hatten, sie sollten nur +zahlreich sein.</p> +<p> +Das führte zu einer paradoxen Situation, in der zwei unterschiedliche +Sichtweisen, das Maß an Freiheit zu messen, verschiedene Antworten auf die +Frage ergaben, <em>„Ist das Programm frei?“</em> Würde man Freiheit nach den +Vertriebsbedingungen des MIT beurteilen, würde man sagen, dass X11 freie +Software war. Aber gemessen an der Freiheit des durchschnittlichen +X11-Benutzer müsste man sagen, es war proprietäre Software. Die meisten +X11-Benutzer führten die proprietären Versionen aus, die mit unfreien +Unix-Systemen kamen, nicht die freie Version.</p> + +<h3>Copyleft und die GNU GPL</h3> +<p> +Das Ziel von GNU war den Benutzern Freiheit zu geben, nicht nur beliebt zu +sein. Also mussten wir Vertriebsbedingungen verwenden, die verhindern +würden, GNU-Software in proprietäre Software umzuwandeln. Die Methode, die +wir verwenden, wird <em>Copyleft</em> genannt.<a href="#fn3" id="fn3-ref" +class="fnote">(3)</a></p> +<p> +Copyleft nutzt das Urheberrecht, aber wendet es auf gegenteilige Weise des +üblichen Zwecks an: statt einem Mittel zur Beschränkung eines Programms wird +es zu einem Mittel, damit das Programm frei bleibt.</p> +<p> +Der Kerngedanke von Copyleft ist, jedem die Berechtigung zu geben, das +Programm ausführen, kopieren, modifizieren und modifizierte Versionen +verbreiten zu dürfen ‑ aber nicht die Berechtigung +Beschränkungen hinzuzufügen. Damit werden entscheidende Freiheiten, die +<em>Freie Software</em> definieren, an jedermann garantiert, wer eine Kopie +besitzt. Sie werden unveräußerliche Rechte.</p> +<p> +Für ein effektives Copyleft müssen modifizierte Versionen ebenfalls frei +sein. Dadurch wird sichergestellt, dass das abgeleitete Werk unserer +Gemeinschaft verfügbar wird, wenn es veröffentlicht wird. Wenn +Programmierer, die als solche arbeiten, freiwillig GNU-Software verbessern, +ist es das Copyleft, was ihre Arbeitgeber davon abhält zu sagen: <em>„Sie +können diese Änderungen nicht mit anderen austauschen, weil wir sie nutzen +werden, um unsere proprietäre Version des Programms daraus zu machen.“</em></p> +<p> +Die Anforderung, das Änderungen frei sein müssen, ist unerlässlich, wenn wir +Freiheit für jeden Programmnutzer gewähren wollen. Die Unternehmen, die X11 +privatisiert haben, machten für gewöhnlich einige Änderungen, um es auf ihre +Systeme und ihre Hardware zu portieren. Diese Änderungen waren im Vergleich +mit dem großen Umfang von X11 gering, aber sie waren nicht trivial. Wenn +gemachte Änderungen Vorwand wären, um den Nutzern Freiheit zu versagen, wäre +es für jedermann einfach, die Vorteile als Vorwand auszunutzen.</p> +<p> +Ein ähnliches Problem betrifft die Kombination eines freien Programms mit +unfreiem Quellcode. Solch eine Kombination wäre zwangsläufig unfrei! Welche +Freiheiten auch immer dem unfreien Teil fehlt, würde dem Ganzen auch +fehlen. Solche Kombinationen zu erlauben, würde ein Loch öffnen, groß genug, +um ein Schiff darin zu versenken. Daher ist eine unabdingbare Anforderung +für Copyleft, dieses Loch zu stopfen: etwas einem mit Copyleft versehenem +Programm hinzuzufügen oder zu kombinieren muss so erfolgen, dass die daraus +größere kombinierte Version ebenfalls frei und mit Copyleft ist.</p> +<p> +Die konkrete Umsetzung des Copyleft, die wir für die meiste GNU-Software +verwenden, ist die <cite><span xml:lang="en" lang="en">GNU General Public +License</span></cite>, kurz <em>GNU GPL</em>. Wir haben auch noch andere +Arten des Copyleft, die unter bestimmten Umständen verwendet +werden. GNU-Handbücher sind ebenfalls mit Copyleft versehen, verwenden aber +ein viel einfacheres Copyleft, weil die Komplexität der GNU GPL für +Handbücher nicht notwendig ist.<a href="#fn4" id="fn4-ref" +class="fnote">(4)</a></p> +<p> +<!--see footer--></p> + +<p> +<!--see footer--></p> + +<h3><span xml:lang="en" lang="en">Free Software Foundation</span></h3> + +<p>Da das Interesse an der Nutzung von Emacs wuchs, andere Personen am +GNU-Projekt beteiligt wurden und wir beschlossen, dass es Zeit war erneut +nach finanziellen Mitteln zu suchen, schufen wir 1985 die <a +href="http://www.fsf.org/" xml:lang="en" lang="en">Free Software +Foundation</a> (FSF), eine gemeinnützige Stiftung für die +Freie-Software-Förderung und -Entwicklung. Die FSF übernahm auch das +Vertriebsgeschäft der Emacs-Magnetbänder. Später wurde dies durch Hinzufügen +weiterer freier Software zum Magnetband (sowohl GNU als auch GNU-fremder) +und natürlich durch den Verkauf freier Handbücher erweitert.</p> + +<p>Der größte Teil der Einnahmen der FSF kam aus den Verkäufen von Kopien +freier Software und anderen damit zusammenhängenden Diensten (CD-ROMs mit +Quellcode oder Binärdateien, schön gedruckten Handbüchern, alle mit der +Freiheit weitergegeben und modifiziert zu werden) und Deluxe-Distributionen +(in denen wir eine ganze Softwaresammlung nach Wahl des Kunden je nach +Plattform zusammenstellten). Noch heute vertreibt die FSF <a +href="http://shop.fsf.org/">Handbücher und andere Utensilien</a>, erhält +aber den Großteil ihrer Mittel aus Mitgliedsbeiträgen. Sie können der FSF +unter <a href="http://fsf.org/join">FSF.org</a> beitreten.</p> + +<p>Mitarbeiter der <span xml:lang="en" lang="en">Free Software +Foundation</span> haben eine Reihe von GNU-Softwarepaketen geschrieben und +betreut. Zwei beachtenswerte sind die C-Bibliothek und die +Eingabeaufforderung. Die GNU C-Bibliothek wird von jedem auf einem +GNU/Linux-System ausgeführten Programm genutzt, um mit Linux zu +kommunizieren. Sie wurde von einem Mitarbeiter der <span xml:lang="en" +lang="en">Free Software Foundation</span>, Roland McGrath, entwickelt. Der +auf den meisten GNU/Linux-Systemen genutzte Befehlszeileninterpreter ist +<em><span xml:lang="en">Bourne Again Shell</span></em> (BASH)<a href="#fn5" +id="fn5-ref" class="fnote">[5]</a>, entwickelt von Brian Fox, einem +FSF-Mitarbeiter.</p> + +<p>Wir finanzierten die Entwicklung dieser Programme, weil es beim GNU-Projekt +nicht nur um Dienstprogramme oder eine Entwicklungsumgebung ging. Unser Ziel +war ein vollständiges Betriebssystem, und diese Programme waren für dieses +Ziel erforderlich.</p> + +<p><!--see footer--></p> + +<h3>Freie-Software-Unterstützung</h3> + +<p>Die Freie-Software-Philosophie lehnt eine bestimmte weitverbreitete +Geschäftspraxis ab, aber ist nicht gegen das Geschäft. Wenn Geschäfte die +Freiheit der Nutzer respektieren, wünschen wir ihnen Erfolg.</p> + +<p>Der Verkauf von Emacs-Kopien veranschaulicht eine Art von +Freie-Software-Geschäft. Als die FSF dieses Geschäft übernahm, brauchte ich +einen anderen Weg, um meinen Lebensunterhalt zu bestreiten. Ich fand ihn im +Anbieten von Dienstleistungen in Zusammenhang mit der freien Software, die +ich entwickelt hatte. Dies beinhaltete die Unterweisung zu Themen wie man +beispielsweise GNU Emacs programmiert und GCC anpasst und +Softwareentwicklung, hauptsächlich das Portieren von GCC auf neue +Plattformen.</p> + +<p>Heutzutage wird jede Art von Freie-Software-Geschäft von einer Reihe von +Unternehmen praktiziert. Einige vertreiben Freie-Software-Sammlungen auf +CD-ROM. Andere bieten Unterstützung, angefangen mit der Beantwortung von +Benutzerfragen, Beseitigung von Programmfehlern, Hinzufügen neuer +Programmfunktionen. Wir fangen sogar an Freie-Software-Unternehmen zu sehen, +die aufgrund neuer Freie-Software-Produkte gegründet werden.</p> + +<p>Passen Sie dennoch auf: Obwohl es eine Reihe von Unternehmen gibt, die sich +dem Begriff <em>„Open Source“</em> verbunden fühlen, basiert ihr Geschäft +tatsächlich auf unfreier Software, die mit freier Software arbeitet. Das +sind keine Freie-Software-Unternehmen, sondern proprietäre +Softwareunternehmen, deren Produkte Benutzer von Freiheit weg in Versuchung +führen. Sie nennen diese Programme <em>Mehrwertpakete</em>, die die Werte +widerspiegeln, die sie gerne als von uns adaptiert sehen würden: Nutzen über +Freiheit. Wenn wir Freiheit höher schätzen, sollten sie +<em>freiheitsentziehende</em> Pakete genannt werden.</p> + +<h3>Technische Ziele</h3> + +<p>Das primäre Ziel von GNU soll Freie Software sein. Selbst wenn GNU keinen +technischen Vorteil gegenüber Unix hätte, gäbe es einen sozialen Vorteil, +der Nutzern erlaubt zusammenzuarbeiten, und einen ethischen Vorteil, der die +Freiheit des Nutzers respektiert.</p> + +<p>Aber es war selbstverständlich, die bekannten Standards guter Praxis auf die +Arbeit anzuwenden ‑ etwa die dynamische Zuweisung von +Datenstrukturen, um willkürliche feste Größenbegrenzungen zu vermeiden, und +die Handhabung aller möglichen 8-Bit-Codes, wann immer das Sinn macht.</p> + +<p>Darüber hinaus lehnten wir den Unix-Fokus auf kleine Speichergrößen ab und +entschieden, 16-Bit-Rechner nicht zu unterstützen (es war klar, dass +32-Bit-Rechner Standard sind, wenn das GNU-System fertig wäre) und keine +Anstrengungen zu machen die Speichernutzung zu verringern, wenn es einen +Megabyte überstieg. In Programmen, für die die Behandlung von großen Dateien +nicht entscheidend war, ermutigten wir Programmierer die gesamte +Eingabedatei in den Prozessorkern einzulesen, dann seinen Inhalt zu +überprüfen, ohne sich um Ein- und Ausgabe kümmern zu müssen.</p> + +<p>Diese Entscheidungen ermöglichten vielen GNU-Programmen, ihre +Unix-Gegenstücke in Zuverlässigkeit und Geschwindigkeit zu übertreffen.</p> + +<h3>Gespendete Rechner</h3> + +<p>Als der Ruf des GNU-Projekts wuchs, begann man Rechner als Spende für das +Projekt anzubieten, die unter Unix liefen. Diese waren sehr nützlich, weil +der einfachste Weg, die Entwicklung von GNU-Komponenten auf einem +Unix-System zu tun, und dessen Komponenten eins nach dem anderen zu +ersetzen ‑ eine nach der anderen. Aber das löste eine +ethische Frage aus: ob es für uns richtig war, überhaupt eine Kopie von Unix +zu besitzen.</p> + +<p>Unix war (und ist) proprietäre Software, und die Philosophie des +GNU-Projekts besagt, dass wir keine proprietäre Software nutzen +sollten. Aber die gleiche Argumentation anwendend, die zu der +Schlussfolgerung führt, dass Gewalt als Selbstverteidigung gerechtfertigt +sei, schloss ich, dass es legitim wäre, ein proprietäres Paket zu nutzen, +wenn das für die Entwicklung eines freien Ersatzes entscheidend war, der +anderen helfen würde, das proprietäre Paket nicht mehr zu verwenden.</p> + +<p>Aber selbst wenn dies ein gerechtfertigtes Übel war, war es immer noch ein +Übel. Heute haben wir nicht mehr irgendwelche Kopien von Unix, weil wir sie +durch freie Betriebssysteme ersetzten. Konnten wir das Betriebssystem eines +Rechners nicht ersetzen, ersetzten wir stattdessen den Rechner.</p> + +<h3>GNU-Aufgabenliste</h3> + +<p>Mit Fortschreiten des GNU-Projekts und immer mehr gefundenen oder +entwickelten Systemkomponenten wurde schließlich eine Liste der +verbleibenden Lücken notwendig. Wir verwendeten sie, um Entwickler zu +rekrutieren, fehlende Teile zu schreiben. Diese Liste wurde als +GNU-Aufgabenliste bekannt. Zusätzlich zu fehlenden Unix-Komponenten führten +wir verschiedene andere nützliche Software- und Dokumentationsprojekte auf, +die unserer Meinung nach ein Gesamtsystem haben sollte.</p> + +<p>Heute sind kaum noch Unix-Komponenten in der <cite xml:lang="en" +lang="en">GNU Task List</cite><a href="#fn6" id="fn6-ref" +class="fnote">[6]</a> vorhanden ‑ diese sind, abgesehen von +ein paar unwichtigen, abgearbeitet. Aber die Liste ist voll von Projekten, +die manche <em>„Anwendungen“</em> nennen mögen. Jedes Programm, das mehr als +nur eine kleine Benutzergruppe anspricht, wäre sinnvoll, um es einem +Betriebssystem hinzuzufügen.</p> + +<p>Sogar Spiele sind in der Aufgabenliste enthalten ‑ und sind +von Anfang an dabei. Unix enthielt Spiele, also sollte GNU natürlich auch +welche enthalten. Da aber Kompatibilität kein Problem für Spiele war, +mussten wir der Liste der Spiele nicht folgen, die Unix hatte. Stattdessen +führten wir ein Spektrum verschiedener möglicher Spiele auf, die Benutzer +mögen würden.</p> + +<p><!--see footer--></p> + +<h3>GNU Library GPL</h3> + +<p>Die GNU C-Bibliothek nutzt eine spezielle Art des Copyleft namens <em><span +xml:lang="en" lang="en">GNU Library General Public License</span></em> +(LGPL), die die Berechtigung erteilt, proprietäre Software mit der +Bibliothek zu verbinden.<a href="#fn7" id="fn7-ref" class="fnote">(7)</a> +Warum diese Ausnahme?</p> + +<p>Es ist keine Frage des Prinzips. Es gibt kein Prinzip, das proprietäre +Softwareprodukte berechtigt unseren Quellcode einzubinden (warum zu einem +Projekt beitragen, welches sich weigert, sich mit uns auszutauschen?). Die +LGPL für die C-Bibliothek (oder für jedwede Bibliothek) zu verwenden, ist +eine Frage der Strategie.</p> + +<p>Die C-Bibliothek erfüllt eine allgemeine Aufgabe. Jedes proprietäre System +oder jeder Compiler kommt mit einer C-Bibliothek. Deshalb hätte, wäre unsere +C-Bibliothek ausschließlich für Freie Software verfügbar, dieser keinen +Vorteil bringen ‑ es hätte nur von der Nutzung unserer +Bibliothek abgehalten.</p> + +<p>Ein System ist eine Ausnahme: in einem GNU-System (und dies schließt +GNU/Linux ein) ist die GNU C-Bibliothek die einzige C-Bibliothek. Die +Vertriebsbedingungen der GNU C-Bibliothek bestimmen, ob es möglich ist, ein +proprietäres Programm für das GNU-System zu kompilieren. Es gibt keinen +ethischen Grund, proprietäre Anwendungen auf einem GNU-System zu +ermöglichen, aber strategisch gesehen scheint es, dass das Verbieten eher +von der Nutzung des GNU-Systems abhält, als die Entwicklung freier +Anwendungen zu fördern. Deshalb ist die Verwendung der Library GPL eine +gute Strategie für die C-Bibliothek.</p> + +<p>Für andere Bibliotheken muss die strategische Entscheidung individuell +getroffen werden. Wenn eine Bibliothek bei einer speziellen Aufgabe helfen +kann, bestimmte Arten von Programmen zu schreiben und dann unter der GPL +freizugeben ‑ auf lediglich freie Programme +begrenzt ‑ ist das ein Weg, anderen +Freie-Software-Entwicklern zu helfen und einen Vorteil gegenüber proprietäre +Software zu geben.</p> + +<p>Betrachten wir GNU Readline, eine Bibliothek, die entwickelt wurde, um für +BASH die Befehlszeilenbearbeitung zu ermöglichen. Readline wird unter der +gewöhnlichen GNU GPL vertrieben, nicht unter der Library GPL. Das reduziert +möglicherweise die Häufigkeit, mit der Readline benutzt wird, aber das ist +kein Verlust für uns. Inzwischen wurde mindestens eine nützliche Anwendung +ausdrücklich zu freier Software gemacht, damit sie Readline nutzen kann, und +das ist ein echter Gewinn für die Gemeinschaft.</p> + +<p>Entwickler proprietärer Software haben die Vorteile, die Geld ermöglicht; +Entwickler freier Software müssen sich gegenseitig Vorteile für einander +verschaffen. Ich hoffe, wir haben eines Tages eine große Sammlung +GPL-lizenzierter Bibliotheken, die keine Parallelen zu verfügbarer +proprietärer Software bilden, nützliche Module liefern, die als Bausteine in +neuer freier Software dienen und sich zu einem größeren Vorteil für die +weitere Freie-Software-Entwicklung summieren.</p> + +<p><!--see footer--></p> + +<h3>Einen Juckreiz löschen?</h3> +<p> +Eric Raymond sagt: <cite><q>Jedes gute Werk von Software fängt mit dem +Kratzen eines persönlichen Juckreizes des Entwicklers an.</q></cite> +Vielleicht passiert das manchmal, aber viele wesentliche Teile der +GNU-Software wurden entwickelt um ein vollständig freies Betriebssystem zu +haben. Sie stammen aus einer Vision und einem Plan, nicht aus einem Impuls +heraus.</p> +<p> +Beispielsweise wurde die C-Bibliothek entwickelt, weil ein unixartiges +System eine C-Bibliothek braucht, BASH, weil ein unixoides System einen +Befehlszeileninterpreter braucht, und GNU Tar, weil ein unixoides System ein +Archivierungsprogramm braucht. Gleiches gilt für die von mir geschriebenen +Programme ‑ den GNU C-Compiler, GNU Emacs, GDB und GNU Make.</p> +<p> +Einige GNU-Programme wurden entwickelt, um bestimmte Bedrohungen unserer +Freiheit zu bewältigen. So entwickelten wir GZIP, um das +Komprimierungsprogramm zu ersetzen, das der Gemeinschaft wegen der Patente +auf <abbr title="Lempel-Ziv-Welch-Algorithmus">LZW</abbr>-verloren gegangen +war. Wir fanden Menschen um LessTif zu entwickeln und begannen vor kurzem +mit der Entwicklung von <abbr title="GNU Network Object Model +Environment">GNOME</abbr> und Harmony, um die durch bestimmte proprietäre +Bibliotheken verursachten Probleme anzugehen (siehe unten). Wir entwickelten +den GNU Privacy Guard, um eine beliebte unfreie Verschlüsselungssoftware zu +ersetzen, weil Benutzer nicht zwischen Privatsphäre und Freiheit sollten +wählen müssen.</p> +<p> +Die Personen, die diese Programme schrieben, interessierten sich natürlich +für die Arbeit, und viele Funktionen wurden von verschiedenen Personen +aufgrund eigener Anforderungen und Interessen hinzugefügt. Doch darum +existieren die Programme nicht.</p> + +<h3>Unerwartete Entwicklungen</h3> +<p> +Zu Beginn des GNU-Projekts stellte ich mir vor, wir würden das gesamte +GNU-System entwickeln und dann als Ganzes freigeben. So ist es nicht +gekommen.</p> +<p> +Da jede Komponente des GNU-Systems auf einem Unix-System umgesetzt wurde, +konnte jede auf einem Unix-System ausgeführt werden, lange bevor ein +komplettes GNU-System existierte. Einige dieser Programme wurden populär und +Benutzer begannen sie zu erweitern und zu portieren ‑ auf +die verschiedenen inkompatiblen Versionen von Unix und manchmal auch auf +andere Systeme.</p> +<p> +Dieser Vorgang machte diese Programme sehr viel mächtiger und zog sowohl +Gelder als auch Mitwirkende zum GNU-Projekt. Aber er verzögerte +möglicherweise auch die Fertigstellung eines minimal funktionierenden +Systems um mehrere Jahre, da GNU-Entwickler Zeit in die Betreuung dieser +Schnittstellen und zusätzliche Funktionen zu bestehenden Komponenten +aufbrachten, anstatt eine fehlende Komponente nach der anderen zu schreiben.</p> + +<h3>GNU Hurd</h3> +<p> +Um 1990 war das GNU-System fast fertig. Die einzige größere fehlende +Komponente war der Betriebssystemkern. Wir hatten beschlossen, unseren +Systemkern als eine Sammlung von Serverprozessen zu implementieren, die auf +dem Mach laufen. Mach ist ein an der <span xml:lang="en" lang="en">Carnegie +Mellon</span>-Universität und dann an der Universität von Utah entwickelter +Mikrokern. GNU HURD ist eine Sammlung von Servern (d. h. eine Herde +GNUs), die auf dem Mach laufen und verschiedene Aufgaben des +Unix-Betriebssystemkerns erledigen. Der Beginn der Entwicklung wurde +verzögert, da wir, wie versprochen wurde, auf die Freigabe von Mach als +Freie Software warteten.</p> +<p> +Ein Grund für die Wahl dieses Designs war zu vermeiden, was, wie es schien, +der schwierigste Teil der Aufgabe war: Ein Systemkernprogramm ohne einen +Source-Level-Debugger zu debuggen [Diagnose auf Quelltextebene]. Dieser Teil +der Aufgabe war bereits im Mach erledigt, und wir erwarteten die HURD-Server +als Benutzerprogramme mit GDB zu debuggen. Aber es brauchte lange Zeit, um +dies zu ermöglichen und die Multithread-Server, die sich gegenseitig +Nachrichten senden, sich als sehr schwierig zu debuggen erwiesen haben. Den +HURD zum soliden Arbeiten zu bringen, zog sich über mehrere Jahre hin.</p> + +<h3>Alix</h3> +<p> +Der GNU-Betriebssystemkern sollte ursprünglich nicht HURD genannt +werden. Sein ursprünglicher Name war Alix ‑ benannt nach der +Frau, die damals mein Schatz war. Sie, eine Unix-Systemadministratorin, +hatte darauf hingewiesen wie ihr Name in ein allgemeines Namensmuster für +Unix-Systemversionen passen würde. <cite><q>Jemand sollte einen Systemkern +nach mir benennen</q></cite> witzelte sie unter Freunden. Ich sagte nichts +dazu, aber beschloss sie mit einem Systemkern namens <em>Alix</em> zu +überraschen.</p> +<p> +Es blieb nicht dabei. Michael Bushnell (heute Thomas Bushnell), der +Hauptentwickler des Systemkerns, bevorzugte den Namen HURD und definierte +Alix neu, um auf einen bestimmen Teil des Systemkerns zu +verweisen ‑ den Teil, der Systemaufrufe abfangen und diese +durch Senden von Nachrichten an die Hurd-Server behandeln würde.</p> +<p> +Später trennten sich unsere Wege und Alix änderte ihren Nachnamen; +unabhängig davon wurde das HURD-Design geändert, damit die C-Bibliothek +Nachrichten direkt an die Server senden würde, und das ließ die +Alix-Komponente aus dem Design verschwinden.</p> +<p> +Doch bevor diese Dinge passierten, stieß ein Freund von ihr auf den Namen +Alix im HURD-Quellcode und erwähnte es ihr gegenüber. Sie hatte also die +Chance, einen nach ihr benannten Systemkern zu finden.</p> + +<h3>Linux und GNU/Linux</h3> +<p> +GNU Hurd ist nicht für den produktiven Einsatz geeignet und wir wissen +nicht, ob es jemals so sein wird. Das fähigkeitsbasierte Konzept hat +Probleme, die sich direkt aus der Flexibilität des Konzepts ergeben und es +ist nicht klar, ob Lösungen existieren.</p> + +<p> +Glücklicherweise ist ein anderer Betriebssystemkern verfügbar. Im Jahr 1991 +entwickelte Linus Torvalds einen Unix-kompatiblen Systemkern und nannte ihn +Linux. Es war zunächst proprietär, aber im Jahr 1992 machte er es zu Freie +Software. Die Kombination von Linux mit dem noch nicht ganz fertigen +GNU-System führte zu einem vollständig freien Betriebssystem (die +Kombination war natürlich eine erhebliche Aufgabe an sich). Es ist Linux zu +verdanken, dass wir heute tatsächlich eine Version des GNU-Systems verwenden +können. </p> +<p> +Wir nennen diese Version des Systems <a +href="/gnu/linux-and-gnu">GNU/Linux</a>, um dessen Zusammensetzung als +Kombination aus dem GNU-System mit Linux als Systemkern auszudrücken. Bitte +verfallen Sie nicht der Praxis, das Gesamtsystem „Linux“ zu nennen, da +das<ins> fälschlicherweise</ins> unsere Arbeit auf jemand anderen +zurückführt. Bitte geben Sie uns eine <a +href="/gnu/gnu-linux-faq">ebensolche Erwähnung</a>.</p> + +<h3>Herausforderungen in der Zukunft</h3> +<p> +Wir haben unsere Fähigkeit, ein breites Spektrum an freier Software zu +entwickeln, bewiesen. Das bedeutet nicht, wir seien unbesiegbar und +unaufhaltsam. Verschiedene Herausforderungen machen die Zukunft von freier +Software unsicher; sie zu erfüllen, erfordert unerschütterliche +Anstrengungen und Durchhaltevermögen, manchmal für Jahre. Es ist die Art von +Entschlossenheit erforderlich, die Menschen zeigen, wenn sie ihre Freiheit +schätzen und sich von niemanden wegnehmen lassen.</p> +<p> +Die folgenden vier Abschnitte erörtern diese Herausforderungen.</p> + +<h3>Geheime Hardware</h3> +<p> +Hardwarehersteller tendieren zunehmend dazu, Hardwarespezifikationen geheim +zu halten. Das macht es schwierig, freie Treiber zu schreiben, damit Linux +und XFree86 neue Hardware unterstützen können. Wir haben heute vollständig +freie Systeme, aber wir werden sie morgen nicht mehr haben, wenn wir die +Rechner von morgen nicht unterstützen können.</p> +<p> +Es gibt zwei Wege, um mit diesem Problem fertig zu werden. Die Programmierer +können mit <span xml:lang="en" lang="en"><em>Reverse Engineering</em></span> +‚Nachkonstruktion‘ herausfinden, wie man die Hardware +unterstützen kann. Der Rest von uns kann die Hardware wählen, die von freier +Software unterstützt wird; bei steigender Nutzerzahl wird das Geheimhalten +der Spezifikationen eine selbstzerstörerische Politik.</p> +<p> +<span xml:lang="en" lang="en">Reverse Engineering</span> ist eine äußerst +umfangreiche Aufgabe. Werden wir Programmierer mit ausreichender +Entschlossenheit haben, dies zu übernehmen? <em>Ja</em>, wenn wir ein +starkes Gefühl aufgebaut haben, dass freie Software eine Frage des Prinzips +ist und unfreie Treiber unerträglich sind. Und werden viele zusätzliches +Geld spenden oder sogar ein wenig mehr Zeit, damit wir freie Treiber nutzen +können? <em>Ja</em>, wenn die Entschlossenheit, Freiheit zu haben, weit +verbreitet ist.</p> +<p> +(Anmerkung: Dieses Problem erstreckt sich auch auf das BIOS. Es gibt ein +freies BIOS namens <cite><a href="http://www.libreboot.org/" xml:lang="en" +lang="en">LibreBoot</a></cite>. Das Problem ist Spezifikationen für Rechner +zu erhalten, damit <span xml:lang="en" lang="en">LibreBoot</span> sie ohne +unfreie <em><span xml:lang="en" lang="en">Binary Large Objects</span></em> +‚BLOBs‘ unterstützen kann. Stand: 2008)</p> + +<h3>Unfreie Bibliotheken</h3> +<p> +Eine unfreie Bibliothek, die auf einem freien Betriebssystem ausgeführt +wird, verhält sich für Freie-Software-Entwickler wie ein Falle. Die +attraktiven Funktionen der Bibliothek sind der Köder, und wenn man sie +nutzt, schnappt die Falle zu, weil das Programm nicht nutzbringend Teil +eines freien Betriebssystems sein kann (streng genommen könnte man das +Programm einbinden, aber es würde mit fehlender Bibliothek unmöglich +<em>ausgeführt</em> werden können). Noch schlimmer ist, wenn ein Programm, +das die proprietäre Bibliothek nutzt, immer beliebter wird und so andere +ahnungslose Programmierer in die Falle lockt.</p> +<p> +Der erste Fall dieses Problems war der Motif-Werkzeugsatz, damals in den +80ern. Obwohl es noch keine freien Betriebssysteme gab, war klar, welche +Probleme Motif später verursachen würde. Das GNU-Projekt reagierte auf +zweierlei Weise: indem einzelne Freie-Software-Projekte gebeten wurden, die +freien Steuerelemente des X-Werkzeugsatzes als auch Motif zu unterstützen +und indem nach jemand gesucht wurde, einen freien Ersatz für Motif zu +schreiben. Diese Aufgabe dauerte viele Jahre; LessTif, von ungarischen +Programmierern entwickelt, unterstütze erst ab 1997 die meisten +Motif-Anwendungen.</p> +<p> +Zwischen 1996 und 1998 wurde eine andere Bibliothek namens Qt als unfreie +<em>grafische Benutzerschnittstelle</em> ‚<abbr title="Graphical User +Interface">GUI</abbr>‘ in einer umfangreichen Freie-Software-Sammlung, +der <abbr title="K Desktop Environment">KDE</abbr>-Arbeitsumgebung, genutzt.</p> +<p> +Freie GNU/Linux-Systeme waren außerstande KDE zu verwenden, denn die +Bibliothek konnte nicht genutzt werden. Allerdings fügten einige +kommerzielle Distributoren von GNU/Linux-Systemen, die nicht streng an +freier Software festhielten, KDE ihren Systemen +hinzu ‑ produzierten so ein System mit mehr Möglichkeiten, +aber weniger Freiheit. Die KDE-Gruppe ermutigte aktiv mehr Programmierer Qt +zu benutzen, und Millionen von neuen „Linux-Nutzern“ waren nie der Idee +ausgesetzt worden, dass es damit ein Problem gab. Die Situation war makaber.</p> +<p> +Die Freie-Software-Gemeinschaft reagierte auf das Problem in zweierlei +Weise: GNOME und Harmony.</p> +<p> +GNOME, das <span xml:lang="en" lang="en">GNU Network Object Model +Environment</span>, ist GNUs Projekt einer grafischen +Benutzeroberflächen-Umgebung. 1997 von <span xml:lang="es" lang="es">Miguel +de Icaza</span> gestartet und entwickelt mit der Unterstützung von <span +xml:lang="en" lang="en">Red Hat Software</span>, machte sich GNOME auf den +Weg, mit ausschließlich freier Software eine ähnliche Ausstattung der +Arbeitsumgebung zu schaffen. Es hat auch technische Vorteile wie die +Unterstützung einer Vielzahl von Programmiersprachen, nicht nur C++. Aber +das wichtigste Ziel war Freiheit: keine unfreie Software erforderlich.</p> +<p> +Harmony ist eine kompatible Ersatzbibliothek, entworfen, um zu ermöglichen, +KDE-Software ohne Qt zu nutzen.</p> +<p> +Im November 1998 kündigten die Entwickler von Qt eine Änderung der Lizenz +an, die, wenn in die Tat umgesetzt, Qt zu freier Software machen sollte. Es +gibt keine Möglichkeit um sicher zu sein, aber ich denke, dass dies zum Teil +durch die entschiedene Reaktion der Gemeinschaft auf das Problem, das Qt +darstellte als es unfrei war, verursacht war (die neue Lizenz ist ungeeignet +und ungerecht, so bleibt es wünschenswert, die Nutzung von Qt zu vermeiden).</p> +<p> +(Nachträgliche Anmerkung: Im September 2000 wurde Qt unter der GNU GPL neu +freigegeben, was dieses Problem im Grunde löste.)</p> +<p> +Wie antworten wir auf die nächste verlockende unfreie Bibliothek? Versteht +die gesamte Gemeinschaft die Notwendigkeit, nicht in die Falle zu tappen? +Oder geben viele von uns Freiheit zugunsten Bequemlichkeit auf und erzeugen +so ein größeres Problem? Unsere Zukunft hängt von unserer Philosophie ab.</p> + +<h3>Softwarepatente</h3> +<p> +Die schlimmste Bedrohung mit der wir uns konfrontiert sehen stammt von +Softwarepatenten, die für bis zu zwanzig Jahre Algorithmen und Funktionen +für Freie Software tabu setzen können. Die Patente für das +LZW-Komprimierungsverfahren wurden 1983 beantragt, und wir können noch immer +keine Freie Software freigeben, um ordnungsgemäß komprimierte +<em>GIF</em>-Dateien (Graphics Interchange Format) zu erzeugen.<a +href="#up1" id="up1-ref" class="fnote">(*)</a> 1998 wurde ein freies +Programm zur Produktion von komprimiertem <em>MP3</em>-Audio (MPEG-1 Audio +Layer 3) unter Androhung einer Patentklage aus der Distribution +herausgenommen.<a href="#up2" id="up2-ref" class="fnote">(**)</a> +</p> +<p> +Es gibt Möglichkeiten, Patente zu bewältigen: man kann nach Beweisen suchen, +ob ein Patent ungültig ist und nach alternativen Wegen suchen um eine +Aufgabe zu lösen. Aber jede dieser Methoden funktioniert nur +manchmal. schlagen beide fehl, kann ein Patent jegliche Freie Software dazu +zwingen, dass eine Eigenschaft fehlt, die Benutzer wollen. Nach einer langen +Wartezeit erlöschen Patente, aber was machen wir bis dahin?</p> +<p> +Diejenigen von uns, die freie Software der Freiheit wegen schätzen, bleiben +sowieso bei freier Software. Wir schaffen es, Aufgaben ohne patentierte +Funktionen zu erledigen. Aber diejenigen, die freie Software schätzen, weil +sie sie als technisch überlegen erwarten, werden es wahrscheinlich einen +Misserfolg nennen, wenn ein Patent davon abhält. Daher, obwohl es sinnvoll +ist, über die praktische Wirksamkeit des <em>Bazaar</em>-Entwicklungsmodells +sowie der Zuverlässigkeit und Macht irgendeiner freien Software zu sprechen, +dürfen wir dort nicht anhalten. Wir müssen über Freiheit und Prinzipien +sprechen.</p> + +<h3>Freie Dokumentation</h3> +<p> +Der größte Mangel an unseren freien Betriebssystemen ist nicht die +Software ‑ es ist der Mangel an guten freien Handbüchern, +die wir in unsere Systeme integrieren können. Dokumentation ist ein +wesentlicher Bestandteil jedes Softwarepakets; wenn ein wichtiges freies +Softwarepaket nicht mit einem guten freien Handbuch erhältlich ist, ist das +eine große Lücke. Wir haben heute viele solcher Lücken.</p> +<p> +Freie Dokumentation, wie freie Software, ist eine Frage der Freiheit, nicht +des Preises. Das Kriterium eines freien Handbuchs ist dem freier Software +ziemlich ähnlich: es geht darum, allen Benutzern bestimmte Freiheiten zu +gewähren. Weitervertrieb (einschließlich kommerziellen Verkaufs) muss online +und auf Papier erlaubt sein, damit das Handbuch jede Programmkopie begleiten +kann.</p> +<p> +Die Berechtigung zur Modifikation ist ebenfalls von entscheidender +Bedeutung. Im Allgemeinen glaube ich nicht, dass die Berechtigung notwendig +ist, alle möglichen Artikel und Bücher modifizieren zu +dürfen. Beispielsweise denke ich nicht, dass Sie oder ich verpflichtet sind +die Berechtigung zu erteilen, Artikel wie diesen zu modifizieren, der unsere +Handlungen und Ansichten beschreibt.</p> +<p> +Es gibt aber einen bestimmten Grund, warum die Freiheit zur Modifizierung +für Dokumentation von freier Software entscheidend ist. Wenn die Menschen +ihr Recht ausüben, Software zu modifizieren und Funktionen zu ändern oder +hinzuzufügen, wenn sie gewissenhaft sind, ändern sie das Handbuch +auch ‑ damit eine genaue und nutzbare Dokumentation mit dem +modifizierten Programm angeboten werden kann. Ein unfreies Handbuch, dass +gewissenhaften Programmierern nicht erlaubt die Aufgabe zu beenden, erfüllt +nicht den Bedarf unserer Gemeinschaft.</p> +<p> +Einige Einschränkungen, wie Modifikationen vorgenommen werden können, werfen +keine Probleme auf. Beispielsweise sind Anforderungen, den Copyright-Hinweis +des Originalautors, die Vertriebsbedingungen oder die Autorenliste +anzugeben, in Ordnung. Es ist auch kein Problem zu verlangen, dass +modifizierte Versionen einen Hinweis enthalten, dass sie modifiziert wurden, +ebenso wie ganze Abschnitte vor dem Löschen oder Verändern zu schützen, +solange diese Abschnitte nichttechnische Themen behandeln. Diese +Beschränkungen sind kein Problem, weil sie den gewissenhaften Programmierer +nicht davon abhalten, das Handbuch dem modifizierten Programm +anzupassen. Mit anderen Worten halten sie die Freie-Software-Gemeinschaft +nicht davon ab, vollen Gebrauch vom Handbuch zu machen.</p> +<p> +Jedoch muss es möglich sein, den ganzen <em>technischen</em> Inhalt des +Handbuchs zu modifizieren und das Ergebnis mit allen gängigen Medien und +üblichen Kanälen zu verbreiten; andernfalls behindern die Beschränkungen die +Gemeinschaft, das Handbuch ist unfrei und wir brauchen ein anderes.</p> +<p> +Haben Freie-Software-Entwickler das Bewusstsein und die Entschlossenheit, +ein breites Spektrum von freien Handbüchern zu schreiben? Noch einmal hängt +unsere Zukunft von Philosophie ab. </p> + +<h3>Wir müssen über Freiheit sprechen</h3> +<p> +Nach heutigen Schätzungen gibt es zehn Millionen Nutzer von +GNU/Linux-Systemen wie Debian GNU/Linux und Red Hat „Linux“. Freie Software +hat solche praktische Vorteile entwickelt, dass Nutzer aus rein praktischen +Erwägungen zuströmen.</p> +<p> +Die guten Konsequenzen daraus sind offensichtlich: mehr Interesse an der +Entwicklung freier Software, mehr Kunden für Geschäfte mit freier Software +und mehr Möglichkeiten, Unternehmen zu ermutigen, kommerzielle freie +Software anstelle proprietärer Softwareprodukte zu entwickeln.</p> +<p> +Aber das Interesse an der Software wächst schneller als das Bewusstsein der +Philosophie, auf der sie basiert, und das führt zu Problemen. Unsere +Möglichkeiten, den o. a. Herausforderungen und Bedrohungen zu entsprechen, +hängt vom Willen ab, eine feste Haltung für Freiheit einzunehmen. Um +sicherzugehen, dass unsere Gemeinschaft diesen Willen hat, müssen wir den +Gedanken an neue Nutzer verbreiten, wenn sie in die Gemeinschaft kommen.</p> +<p> +Aber wir versagen dabei: die Bemühungen, neue Benutzer für unsere +Gemeinschaft zu gewinnen, übersteigen bei weitem die Bemühungen, ihnen die +Pflichten unserer Gemeinschaft zu lehren. Wir müssen beides machen, und wir +müssen beide Bemühungen im Gleichgewicht halten.</p> + +<h3>„Open Source“</h3> +<p> +Neuen Benutzern etwas über Freiheit zu lehren wurde 1998 schwieriger, als +ein Teil der Gemeinschaft beschloss, nicht mehr den Begriff <em>Freie +Software</em> zu verwenden, sondern stattdessen +<em>„Open-Source“</em>-Software.</p> +<p> +Einige, die diesen Begriff bevorzugten, hatten zum Ziel, die Verwechslung +von <em>frei</em> mit <em>gratis</em> zu vermeiden ‑ ein +zulässiges Ziel. Andere hatten jedoch zum Ziel, den Geist des Prinzips ins +Abseits zu drängen, der die Freie-Software-Bewegung und das GNU-Projekt +motivierte, und stattdessen an Führungskräfte und Geschäftskunden zu +appellieren, von denen viele eine Ideologie haben, die Gewinn über Freiheit, +über Gemeinschaft und über Prinzipien stellt. So konzentriert sich die +Rhetorik von <em>„Open Source“</em> auf das Potenzial, qualitativ +hochwertige und leistungsfähige Software herzustellen, aber die Ideen von +Freiheit, Gemeinschaft und Prinzip meidet.</p> +<p> +Die <em>„Linux“</em>-Fachzeitschriften sind ein eindeutiges Beispiel +dafür ‑ sie sind mit Werbung für proprietäre Software +gefüllt, die mit GNU/Linux funktioniert. Wenn das nächste Motif oder Qt +erscheint, werden diese Magazine Programmierer warnen sich davon +fernzuhalten oder werden sie dafür werben?</p> +<p> +Die Unterstützung des Geschäfts kann in vielerlei Hinsicht zur Gemeinschaft +beitragen; <em>unter sonst gleichen Bedingungen</em> <span xml:lang="la" +lang="la">‚Ceteris Paribus‘</span> ist es nützlich. Aber ihre Unterstützung +zu gewinnen, indem man noch weniger über Freiheit und Prinzipien spricht, +kann katastrophal sein; es macht das vorherige Ungleichgewicht zwischen +sozialem Engagement und politischer Bildung noch schlimmer.</p> +<p> +<em>Freie Software</em> und <em>Open Source</em> beschreiben mehr oder +weniger die gleiche Softwarekategorie, aber sagen verschiedene Dinge über +Software und Werte. Das GNU-Projekt verwendet weiterhin den Begriff +<em>Freie Software</em> um die Idee zum Ausdruck zu bringen, dass Freiheit, +nicht nur Technik, wichtig ist.</p> + +<h3>Testen Sie!</h3> +<p> +Yodas Aphorismus (<em><q>Es gibt kein <q>Versuchen</q></q></em>) klingt +nett, aber funktioniert nicht für mich. Ich habe die meisten meiner Aufgaben +geleistet, während ich besorgt war, ob ich sie erledigen kann und unsicher +war, ob es ausreichen würde um das Ziel zu erreichen. Aber ich versuchte es +trotzdem, denn es gab niemand außer mir zwischen dem Feind und meiner +Stadt. Selbst überrascht, ist es manchmal gelungen.</p> +<p> +Manchmal habe ich versagt; einige meiner Städte sind gefallen. Dann fand ich +eine andere bedrohte Stadt und machte mich für eine andere Schlacht +bereit. Im Laufe der Zeit habe ich gelernt, nach Bedrohungen Ausschau zu +halten und mich selbst zwischen sie und meine Stadt zu stellen, und rief +andere Hacker auf, zu kommen und sich mir anzuschließen.</p> +<p> +Heutzutage bin ich oft nicht der einzige. Es ist eine Erleichterung und +Freude, wenn ich sehe wie sich ein Regiment von Hackern eingräbt, um die +Stellung zu halten, und weiß, diese Stadt kann +überleben ‑ im Moment. Aber die Gefahren werden jedes Jahr +größer, und nun hat sich Microsoft klar gegen unsere Gemeinschaft +ausgerichtet. Wir können die zukünftige Freiheit nicht für +selbstverständlich halten. Halten Sie sie nicht für selbstverständlich! Wenn +Sie Ihre Freiheit behalten möchten, müssen Sie bereit sein sie zu +verteidigen.</p> + +<div class="translators-notes"> + +<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.--> +<ol id="fnote"> +<li id="fn1"><a href="#fn1-ref">1.</a> Die Verwendung von <em>Hacker</em> im +Sinne von <em>Sicherheitsbrecher</em> ist eine Irreführung seitens der +Massenmedien. Wir Hacker weigern uns diese Bedeutung anzuerkennen und +verwenden dieses Wort weiterhin in seiner Bedeutung dahingehend für jemanden +der es liebt zu programmieren, jemanden der sich spielerischer Klugheit +erfreut oder die Kombination von beiden. Siehe auch meinen Artikel <cite><a +href="https://stallman.org/articles/on-hacking.html" title="On Hacking">Auf +das Hacken</a></cite> (engl.).</li> +<li id="fn2"><a href="#fn2-ref">2.</a> Als Atheist folge ich keinen +Religionsführern, stelle aber manchmal fest, dass ich etwas bewundere, was +einer von ihnen gesagt hat.</li> +<li id="fn3"><a href="#fn3-ref">3.</a> 1984 oder 1985 schickte mir Don +Hopkins (ein sehr einfallsreicher Bursche) einen Brief. Auf den Umschlag +hatte er etliche amüsante Sprüche geschrieben, unter anderen diesen: +<em>Copyleft ‑ All Rights Reversed.</em> +(‚Copyleft ‑ Alle Rechte vertauscht.‘). Ich nutzte das Wort +<em>Copyleft</em>, um das Vertriebskonzept zu benennen, welches ich gerade +entwickelte.</li> +<li id="fn4"><a href="#fn4-ref">4.</a> Wir verwenden nun die <em><a +href="/licenses/fdl" xml:lang="en" lang="en">GNU Free Documentation +License</a></em> für die Dokumentation.</li> +<li id="fn5"><a href="#fn5-ref">5.</a> <em>Bourne Again Shell</em> ist ein +Wortspiel mit dem Namen <em>Bourne Shell</em>, welche die übliche Shell +unter Unix war.</li> +<li id="fn6"><a href="#fn6-ref">6.</a> Diese wurde in 1998 geschrieben. Im +Jahr 2009 pflegen wir keine lange Aufgabenliste mehr. Die Gemeinschaft +entwickelt Freie Software so schnell, dass wir nicht einmal jede im Auge +behalten können. Stattdessen haben wir <a +href="https://www.fsf.org/campaigns/priority-projects/" title="High Priority +Free Software Projects">Projekte mit hoher Priorität</a>, eine viel kürzere +Projektliste, mit der wir Menschen wirklich ermutigen möchten zu +schreiben. [Siehe auch die <a +href="https://web.archive.org/web/19981201065412/http://www.gnu.org/prep/tasks.html">ursprüngliche +GNU Task List</a> von 1998, A. d. Ü.].</li> +<li id="fn7"><a href="#fn7-ref">7.</a> Diese Lizenz wird heute <em>GNU +Lesser General Public License</em> (LGPL) genannt, um die Idee zu vermeiden, +sie für alle Bibliotheken zu verwenden. Siehe <cite><a +href="/philosophy/why-not-lgpl">Warum man die Lesser GPL nicht für die +nächste Bibliothek verwenden sollte</a></cite>.</li> +</ol><br /> +<p><strong>Anmerkungen des Autors:</strong></p> +<ol> +<li id="up1"><a href="#up1-ref">(*)</a> Patente auf den +LZW-Komprimierungsalgorithmus sind seit 2009 erloschen.</li> +<li id="up2"><a href="#up2-ref">(**)</a> Patente auf komprimiertes MP3-Audio +sind seit 2017 erloschen. Beachte, wie lange wir warten mussten.</li> +</ol><br /> + +<p><strong>Anmerkungen des Übersetzungsteams:</strong></p> +<ol id="transnote"> +<li id="tn1"><a href="#tn1-ref">[*]</a> Software, die in die Gemeinfreiheit +entlassen ist, bezieht sich immer auf die jeweilige nationale Rechtsordnung +(der des Urhebers und der des Nutzers). Nach US-Recht können dem +Urheberrecht unterliegende Werke diesem nicht unterliegen und es kann sogar +auf alle Rechte verzichtet werden. Nach deutschem Recht wird der Begriff +häufig für Werke (auch amtliche) genutzt, die von vornherein nicht bzw. nur +eingeschränkt dem Urheberrecht unterliegen. Ein völliger +Verzicht ‑ etwa zugunsten der +Allgemeinheit ‑ ist nicht möglich (es kann allerdings mit +dem Nutzungsrecht zur Verfügung gestellt werden, von jedermann frei +veränderbar zu sein).</li> +</ol></div> +</div> + +<!-- for id="content", starts in the include above --> +<!--#include virtual="/server/footer.de.html" --> +<div id="footer"> +<div class="unprintable"> + +<p>Bitte senden Sie allgemeine Fragen zur FSF & GNU an <a +href="mailto:gnu@gnu.org"><gnu@gnu.org></a>. Sie können auch die <a +href="/contact/"><span xml:lang="en" lang="en">Free Software +Foundation</span> kontaktieren</a>. Ungültige Verweise und andere +Korrekturen oder Vorschläge können an <a +href="mailto:webmasters@gnu.org"><webmasters@gnu.org></a> gesendet +werden.</p> + +<p> +<!-- TRANSLATORS: Ignore the original text in this paragraph, + replace it with the translation of these two: + + We work hard and do our best to provide accurate, good quality + translations. However, we are not exempt from imperfection. + Please send your comments and general suggestions in this regard + to <a href="mailto:web-translators@gnu.org"> + + <web-translators@gnu.org></a>.</p> + + <p>For information on coordinating and submitting translations of + our web pages, see <a + href="/server/standards/README.translations.html">Translations + README</a>. --> +Bei der Übersetzung dieses Werkes wurde mit größter Sorgfalt +vorgegangen. Trotzdem können Fehler nicht völlig ausgeschlossen +werden. Sollten Sie Fehler bemerken oder Vorschläge, Kommentare oder Fragen +zu diesem Dokument haben, wenden Sie sich bitte an unser Übersetzungsteam <a +href="mailto:web-translators@gnu.org?cc=www-de-translators@gnu.org"><web-translators@gnu.org></a>.</p> +<p>Weitere Informationen über die Koordinierung und Einsendung von +Übersetzungen unserer Internetpräsenz finden Sie in der <a +href="/server/standards/README.translations">LIESMICH für Übersetzungen</a>.</p> +</div> + +<!-- Regarding copyright, in general, standalone pages (as opposed to + files generated as part of manuals) on the GNU web server should + be under CC BY-ND 4.0. Please do NOT change or remove this + without talking with the webmasters or licensing team first. + Please make sure the copyright date is consistent with the + document. For web pages, it is ok to list just the latest year the + document was modified, or published. + + If you wish to list earlier years, that is ok too. + Either "2001, 2002, 2003" or "2001-2003" are ok for specifying + years, as long as each year in the range is in fact a copyrightable + year, i.e., a year in which the document was published (including + being publicly visible on the web or in a revision control system). + + There is more detail about copyright years in the GNU Maintainers + Information document, www.gnu.org/prep/maintain. --> +<p>Copyright © 1998, 2001, 2002, 2005, 2006, 2007, 2008, 2010, 2014, 2015, +2017, 2018, 2020 Richard Stallman.</p> + +<p>Dieses Werk ist lizenziert unter einer <a +rel="license" +href="//creativecommons.org/licenses/by-nd/4.0/deed.de">Creative Commons +Namensnennung-Keine Bearbeitungen 4.0 International</a>-Lizenz.</p> + +<!--#include virtual="/server/bottom-notes.de.html" --> +<div class="translators-credits"> + +<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.--> +<strong>Übersetzung:</strong> Stephan Knuth, 2003. Jоегg Kоhпе <a +href="//savannah.gnu.org/projects/www-de"><www-de></a>, 2011-2015, +2017, 2018.</div> + +<p class="unprintable"><!-- timestamp start --> +Letzte Änderung: + +$Date: 2020/07/25 20:00:28 $ + +<!-- timestamp end --> +</p> +</div> +</div> +<!-- for class="inner", starts in the banner include --> +</body> +</html> |