path: root/talermerchantdemos/blog/articles/de/thegnuproject.html

<!--#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&#160;&#8209;&#160;Software die wir
nutzen!&#160;&#8209;&#160;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.&#8220;</p>
<p>
Die Idee, dass das proprietäre Software-Sozialsystem&#160;&#8209;&#160;das
System, was besagt, man sei nicht berechtigt Software zu teilen oder zu
verändern&#160;&#8209;&#160;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&#160;&#8209;&#160;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&#160;&#8209;&#160;Benutzerinnen und Benutzer an erster
Stelle&#160;&#8209;&#160;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&#160;&#8209;&#160;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&#160;&#8209;&#160;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&#160;&#8209;&#160;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&#160;&#8209;&#160;<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&#160;&#8209;&#160;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&#160;&#8209;&#160;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&#160;&#8209;&#160;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&#160;&#8209;&#160;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&#160;&#8209;&#160;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&#160;&#8209;&#160;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&#160;&#8209;&#160;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&#160;&#8209;&#160;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&#160;&#8209;&#160;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&#160;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&#160;&#8209;&#160;auf lediglich freie Programme
begrenzt&#160;&#8209;&#160;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&#160;&#8209;&#160;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&#160;&#8209;&#160;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.&nbsp;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&#160;&#8209;&#160;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&#160;&#8209;&#160;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>
&#8218;Nachkonstruktion&#8216; 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> &#8218;<abbr title="Graphical User
Interface">GUI</abbr>&#8216; 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&#160;&#8209;&#160;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&#160;&#8209;&#160;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&#160;&#8209;&#160;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&#160;&#8209;&#160;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&#160;&#8209;&#160;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&#160;&#8209;&#160;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&#160;&#8209;&#160;All Rights Reversed.</em>
(‚Copyleft&#160;&#8209;&#160;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&#160;&#8209;&#160;etwa zugunsten der
Allgemeinheit&#160;&#8209;&#160;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 &amp; GNU an <a
href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</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">&lt;webmasters@gnu.org&gt;</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">

        &lt;web-translators@gnu.org&gt;</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">&lt;web-translators@gnu.org&gt;</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 &copy; 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">&lt;www-de&gt;</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>