GNU Betriebssystem

Das GNU Projekt

von Richard Stallman

Die ursprüngliche Version wurde in dem Buch „Open Sources“ veröffentlicht

Die erste Software-teilende Gemeinschaft

Als ich 1971 am Fachbereich für künstliche Intelligenz des Massachusetts Institute of Technology (MIT-AI) anfing zu arbeiten, wurde ich Teil einer Software-teilenden Gemeinschaft, die schon seit vielen Jahren existierte. Der gemeinsame Dateizugriff auf Software war nicht auf unsere besondere Gemeinschaft begrenzt; er ist so alt wie die Computer selbst, genauso wie der Austausch von Kochrezepten so alt wie das Kochen selbst ist. Aber wir taten es öfter als andere.

Das MIT-AI verwendete ein Mehrbenutzersystem namens Incompatible Timesharing System (ITS), welches Hacker⁽¹⁾ des Fachbereichs in Assemblersprache für den Digital PDP-10, einen der großen Rechner dieser Ära, entworfen und geschrieben hatten. Als Mitglied dieser Gemeinschaft, ein AI-Labor-Systemhacker, war es meine Aufgabe, dieses System zu verbessern.

Wir nannten unsere Software nicht „freie Software“, weil dieser Ausdruck noch nicht existierte – aber das war sie. Wann immer Leute einer anderen Universität oder eines Unternehmens ein Programm portieren und nutzen wollten, erlaubten wir es ihnen gern. Wenn man jemanden ein unbekanntes und interessantes Programm verwenden sah, konnte man immer fragen, ob man den Quellcode bekam, man konnte ihn lesen, ändern, ihn ausschlachten und Teile davon nutzen, um ein neues Programm zu schreiben.

Der Zusammenbruch der Gemeinschaft

Die Situation änderte sich drastisch Anfang der 80er Jahre, als Digital 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.

Die Hacker-Gemeinschaft des KI-Labors war bereits kurz vorher zusammengebrochen. Im Jahr 1981 hatte das sich abspaltende Unternehmen Symbolics fast alle Hacker aus dem KI-Labor abgeworben, und die entvölkerte Gemeinschaft war nicht in der Lage, sich selber aufrechtzuerhalten (das Buch „Hackers“, von Steve Levy, beschreibt diese Ereignisse sowie ein deutliches Bild dieser Gemeinschaft in ihrer Blütezeit). Als das KI-Labor 1982 einen neuen PDP-10 kaufte, entschieden seine Administratoren, Digitals unfreies Mehrbenutzersystem statt ITS zu nutzen.

Die modernen Rechner dieser Ära, wie der VAX oder der 68020, hatten ihre eigenen Betriebssysteme, aber keiner war freie Software: Man musste sogar eine Vertraulichkeitsvereinbarung unterzeichnen, nur um eine ausführbare Kopie zu erhalten.

Das bedeutete, dass der erste Schritt zur Nutzung eines Rechners darin bestand zu versprechen, nicht seinen Nächsten 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 zu machen“.

Die Idee, dass das proprietäre Softwaresozialsystem – das System, was besagt, man sei nicht berechtigt Software zu teilen oder zu verändern – unsozial, unethisch und einfach falsch ist, mag einige Leser überraschen. Aber was könnten wir sonst über ein System sagen, was darauf basiert, die Allgemeinheit zu spalten und Nutzer hilflos zu halten? Leser, die diese Idee überraschend finden, haben möglicherweise das proprietäre Softwaresozialsystem als gegeben angesehen oder es unter den von den proprietären Softwareunternehmen vorgeschlagenen Begriffen betrachtet. Softwarehersteller haben lange und hart daran gearbeitet Menschen davon zu überzeugen, es gäbe nur einen Blickwinkel auf dieses Problem.

Wenn Softwarehersteller über „Durchsetzung“ ihrer „Rechte“ oder „Verhinderung“ von Softwarepiraterie sprechen, ist das, was sie wirklich sagen zweitrangig. Die eigentliche Botschaft dieser Aussagen ist die unausgesprochene Annahme – die für selbstverständlich gehalten wird – die Öffentlichkeit aufzufordern, diese ungeprüft zu akzeptieren. Lassen Sie sie uns deshalb überprüfen.

Eine Annahme ist, dass Softwareunternehmen ein unbestreitbares natürliches Recht auf eigene Software und damit Macht über alle ihre Nutzer 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; Copyright ist kein natürliches Recht, sondern ein künstlich von der Regierung auferlegtes Monopol, das Nutzern das natürliche Recht zum Kopieren einschränkt.

Eine weitere unausgesprochene Annahme ist, dass es bei Software nur wichtig ist, welche Aufgaben sie einem erlaubt auszuführen – dass wir Computernutzer uns nicht darum kümmern sollten, welche Art von Gesellschaft wir haben dürfen.

Eine dritte Annahme ist, dass wir keine nutzbare Software haben (oder niemals ein Programm haben würden, um die eine oder andere Aufgabe zu erledigen), wenn wir einem Unternehmen nicht die Macht über die Programmnutzer 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 Nutzer anzuketten.

Wenn wir es ablehnen, diese Annahmen zu akzeptieren und diese Dinge auf Basis des gesunden Menschenverstandes moralisch, den Nutzer an erste Stelle, beurteilen, kommen wir zu ganz anderen Schlussfolgerungen. Rechnernutzer sollten Programme entsprechend ihren Bedürfnissen anpassen und mit anderen teilen können, denn die Grundlage der Gesellschaft ist Menschen zu helfen.

Es würde den Rahmen dieser Seite sprengen, um die Gründe für diese Schlussfolgerung ausführlich darzulegen, möchte aber an dieser Stelle auf die Webseite Warum Software keine Eigentümer haben sollte hinweisen.

Eine gänzlich moralische Entscheidung.

Mit dem Verlust meiner Gemeinschaft war es unmöglich, weiterzumachen wie zuvor. Stattdessen stand ich vor einer gänzlich moralischen Entscheidung.

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ürde und so den Druck auf andere Menschen erhöhen, ihre Mitmenschen auch zu verraten.

Ich hätte auf diese Weise Geld machen und mich vielleicht mit dem Schreiben von Code amüsiert. 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.

Ich hatte bereits Erfahrung damit, am empfangenden Ende einer Vertraulichkeitsvereinbarung zu sein, als sich jemand weigerte, mir und dem MIT-AI 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 sind. Ich war sehr verärgert, als er sich weigerte, mit uns zu teilen; ich konnte mich nicht einfach umdrehen und dasselbe mit anderen machen.

Eine andere Wahl – einfach, aber unangenehm – war, die Welt der Rechner zu verlassen. Auf diese Weise würden meine Fähigkeiten nicht missbräuchlich genutzt werden, aber immer noch verschwendet. Ich wäre zwar nicht Schuld an der Spaltung und Beschränkung von Rechnernutzern, würde aber dennoch passieren.

Also suchte ich nach einem Weg, auf dem ein Programmierer etwas Gutes tun kann. Ich fragte mich, ob es ein Programm oder Programme gab, die ich schreiben konnte, um noch einmal so eine Gemeinschaft möglich werden zu lassen?

Die Antwort war klar: Was zuerst erforderlich war, war ein Betriebssystem. Das ist die entscheidende Software zum Starten und Nutzung eines Rechners. Mit einem Betriebssystem kann man viele Dinge machen; ohne kann man den Rechner überhaupt nicht nutzen. Mit einem freien Betriebssystem könnte es wieder eine Gemeinschaft von zusammenarbeitenden Hackern geben – und jeden einladen, sich uns anzuschließen. Und jeder wäre in der Lage, einen Rechner zu nutzen, ohne eine Verschwörung anzufangen, um seine oder ihre Freunde zu benachteiligen.

Als Betriebssystementwickler hatte ich die richtigen Qualifikationen für diese Aufgabe. Auch wenn ich den Erfolg nicht als garantiert ansehen konnte, wurde mit klar, dass ich auserwählt war, diese Aufgabe zu übernehmen. Ich entschied mich, das System mit Unix kompatibel zu machen, um es portabel und somit Unix-Nutzer leichter umsteigen können. Der Name GNU wurde, einer Hacker-Tradition folgend, als ein rekursives Akronym für „GNU’s Nicht Unix“ (engl. GNU’s Not Unix) gewählt.

Ein Betriebssystem bedeutet nicht nur ein Betriebssystemkern (engl. Kernel) – kaum genug, um andere Programme auszuführen. In den siebzigern umfasste jedes Betriebssystem, das diesen Namen verdient, Eingabeaufforderungen, 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.

Später hörte ich diese Worte, zurückzuführen auf Rabbi Hillel⁽²⁾:

Wenn ich nicht für mich bin, wer wird für mich sein?
Wenn ich nur für mich bin, was bin ich dann?
Wenn nicht jetzt, wann sonst?

Der Entschluss, mit dem GNU Projekt zu beginnen, beruhte auf einem ähnlichen Geist.

Frei wie in Freiheit

Der Begriff „Freie Software“ wird manchmal falsch verstanden – und hat nichts mit dem Preis zu tun. Es geht um Freiheit. Weitere Informationen hierzu finden Sie unter Definition von Freie Software.

Ein Programm ist Freie Software, für Sie, einen besonderen Nutzer, wenn

• Sie die Freiheit haben, das Programm auszuführen wie Sie wollen, für jeden Zweck.
• Sie die Freiheit haben, das Programm an Ihre Bedürfnisse anzupassen. (Um diese Freiheit in der Praxis umzusetzen, müssen Sie Zugriff auf den Quellcode haben, denn Programmänderungen ohne Quellcode sind außerordentlich schwierig.)
• Sie die Freiheit haben, Vervielfältigungen zu verbreiten, entweder kostenlos oder gegen eine Gebühr.
• Sie die Freiheit haben, modifizierte Programmversionen zu verbreiten, damit die Gemeinschaft von Ihren Verbesserungen profitieren kann.

Da sich „frei“ auf Freiheit, nicht den Preis, bezieht, gibt es keinen Widerspruch zwischen dem Verkauf von Vervielfältigungen und Freie Software. Tatsächlich ist die Freiheit Vervielfältigungen zu verkaufen entscheidend: Zusammenstellungen von auf CD-ROMs verkaufter freier Software sind für die Gemeinschaft wichtig und der Verkauf ein wichtiger Weg, um mehr in die Entwicklung von Freie Software zu investieren. Deshalb wird ein Programm, das den Nutzer einschränkt, in diesen Sammlungen nicht aufgenommen.

Aufgrund der Mehrdeutigkeit von „frei“ hat man lange nach Alternativen gesucht, aber niemand hat eine passende gefunden. Die Englische Sprache hat mehr Wörter und Nuancen als jede andere, aber es fehlt ein einfaches, eindeutiges Wort, das „Frei“, wie in Freiheit, bedeutet – „uneingeschränkt“ ist das Wort, das dieser Bedeutung am nächsten kommt. Derartige Alternativen wie „befreit“, „Freiheit“ und „offen“ haben entweder die falsche Bedeutung oder einige andere Nachteile.

GNU Software und das GNU System

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. Zum Beispiel entschied ich mich gleich am Anfang hauptsächlich TeX als Textformatierer zu nutzen; einige Jahre später entschloss ich mich, das X Window System (u. a. kurz „X11“) zu nutzen, anstatt ein weiteres Fenster-System für GNU zu schreiben.

Aufgrund dieser Entscheidung ist das GNU System nicht identisch mit der Sammlung aller GNU Software. Das GNU System enthält Programme, die keine GNU Software sind, Programme, die von anderen Menschen und Projekten für eigene Zwecke entwickelt wurden – können sie aber nutzen, weil sie Freie Software sind.

Der Anfang des Projekts

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 bezüglich der Verbreitung von GNU als Freie Software einzumischen. Wäre ich als Mitarbeiter geblieben, hätte das MIT Anspruch auf die Arbeit selbst erheben und eigene Vertriebsbedingungen festlegen, oder die Arbeit sogar in ein proprietäres Softwarepaket verwandeln können. Ich hatte nicht die Absicht, eine Menge Arbeit zu erledigen, um dann zu sehen, dass es für den eigentlichen Zweck nutzlos wird: Die Schaffung einer neuen Software-teilenden Gemeinschaft.

Allerdings hat mich Professor Winston, der Leiter des MIT-AI, freundlich eingeladen, weiterhin die Einrichtungen des Labors zu nutzen.

Die ersten Schritte

Kurz vor Start des GNU Projekt hörte ich vom Free University Compiler Kit (auch als VUCK bekannt; das niederländische Wort für „frei“ wird mit einem „V“ geschrieben). Das war ein Compiler, der entwickelt wurde, um mehrere Programmiersprachen, darunter C und Pascal, zu behandeln und mehrere Zielrechner unterstützte. Ich schrieb dem Autor und fragte, ob GNU ihn nutzen könne.

Er antwortete spöttisch, 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.

In der Hoffnung, nicht notwendigerweise den ganzen Compiler selbst neu schreiben zu müssen, erhielt ich schließlich den Quellcode des Pastel Compilers, ein plattformübergreifender Compiler, der im Lawrence Livermore Lab 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. Aber ich musste aufgeben, als ich entdeckte, dass der Compiler mehrere Megabyte Stack-Speicherplatz benötigte, und das verfügbare 68000 Unix System nur 64k erlauben würde.

Dann fand ich heraus, dass der Pastel Compiler die gesamte Eingabedatei durch die Analyse in einen Syntaxbaum umwandelte, den gesamten Syntaxbaum in eine Kette von „Anweisungen“ 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 schreiben. Dieser neue Compiler ist heute als GCC bekannt; nichts aus dem 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.

GNU Emacs

Ich begann die Arbeit am GNU Emacs im September 1984, und Anfang 1985 begann er brauchbar zu werden. Dies ermöglichte nun, für die weitere Bearbeitung Unix-Systeme zu nutzen; ohne Interesse am Erlernen von vi oder ed, hatte ich bis dahin meine Bearbeitung auf anderen Rechnern gemacht.

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 abrufbar, den ich nutzte (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 war die Frage, was würde ich ihnen sagen?

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 tun können, was ich mit dem ursprünglichen PDP-10 Emacs tat: Ihnen sagen: „Übersenden Sie mir ein Magnetband mit einem frankierten Rückumschlag, und ich sende es mit Emacs darauf zurück.“ Aber ich hatte keinen Job, und suchte nach Wegen, um Geld mit freier Software 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 den geschäftlichen Vertrieb von freier Software, dem Vorläufer der Unternehmen, die heute ganze Linux-basierte GNU Systeme vertreiben.

Ist ein Programm für jeden Nutzer frei?

Wenn ein Programm Freie Software ist, wenn es die Hände seines Autors verlässt, bedeutet dies nicht notwendigerweise, dass es Freie Software für jeden ist, der eine Kopie davon hat. Beispielsweise ist Public Domain Software (gemeinfreie Software, die keinem Copyright unterliegt)¹ Freie Software; aber jeder kann eine modifizierte proprietäre 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.

Das paradigmatische Beispiel dieses Problems ist das X Window System (u. a. kurz „X11“). Am MIT entwickelt und als Freie Software mit freizügiger Lizenz veröffentlicht, wurde es bald von verschiedenen Computerfirmen 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 freie Software mehr.

Die Entwickler des X11 sahen das nicht als ein Problem – sie erwarteten und beabsichtigten es sogar. Ihr Ziel war nicht die Freiheit zu erhalten, nur der „Erfolg“, definiert nach „viele Nutzer zu haben“. Es kümmerte nicht, ob diese Freiheit hatten, sie sollten nur zahlreich sein.

Das führte zu einer paradoxen Situation, wo zwei unterschiedliche Sichtweisen das Maß der Freiheit zu bestimmen, verschiedene Antworten auf die Frage, „Ist das Programm frei?“, ergaben. 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-Nutzers müsste man sagen, es war proprietäre Software. Die meisten X11-Nutzer führten proprietäre Versionen aus, die mit unfreien Unix-Systemen kamen.

Copyleft und die GNU GPL

Das Ziel von GNU war, den Nutzern Freiheit zu geben, nicht nur weit verbreitet zu sein. Also mussten wir Vertriebsbedingungen verwenden, die verhindern würde, dass GNU Software zu proprietärer Software gemacht werden würde. Die Methode, die wir nutzen, wird „Copyleft“ genannt.⁽³⁾

Copyleft nutzt das Urheberrecht, aber wendet es auf gegenteilige Weise des üblichen Zwecks an: Statt einem Mittel zur Programmbeschränkung, wird es zu einem Mittel, ein Programm frei zu halten.

Die Kerngedanke vom Copyleft ist, jedem die Berechtigung zu geben, das Programm ausführen, kopieren, modifizieren und modifizierte Versionen vertreiben zu dürfen – aber nicht die Berechtigung zum Hinzufügen von Einschränkungen. Damit werden entscheidende Freiheiten, die Definition von „Freie Software“, allen garantiert, die eine Kopie besitzen; sie werden unveräußerlichen Rechte.

Für ein effektives Copyleft müssen modifizierte Versionen auch 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 Chefs davon abhält zu sagen: „Sie können diese Änderungen nicht mit anderen teilen, weil wir sie nutzen werden, um unsere eigene (proprietäre) Version des Programms daraus zu machen.“

Die Anforderung, dass Änderungen frei sein müssen ist unerlässlich, wenn wir Freiheit für jeden Nutzer des Programms zu gewährleisten 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 Änderungen eine Entschuldigung wäre Nutzern die Freiheit zu verweigern, wäre es für jedermann einfach, dies als Ausrede zu verwenden.

Ein ähnliches Problem betrifft die Kombination eines freien Programms mit unfreiem Code. Solch eine Kombination würde zwangsläufig unfrei sein; welche Freiheiten auch immer dem unfreien Teil fehlt, würde es dem Ganzen auch fehlen. Solche Kombinationen zu erlauben, würde ein Loch öffnen, groß genug, um ein Schiff darin zu versenken. Daher ist eine entscheidende Voraussetzung für das Copyleft, dieses Loch zu stopfen: Einem Copyleft-geschützten Programm hinzugefügtes oder kombiniertes muss so gestellt werden, dass die daraus größere abgeleitete Version auch frei und Copyleft-geschützt ist.

Die konkrete Umsetzung des Copyleft, die wir für die meiste GNU Software nutzen, ist die GNU General Public License, kurz GNU GPL. Wir haben andere Arten des Copyleft, die unter bestimmten Umständen verwendet werden. GNU Handbücher stehen auch unter Copyleft, aber nutzen ein viel einfacheres Copyleft, weil die Komplexität der GNU GPL nicht für Handbücher notwendig ist.⁽⁴⁾

Free Software Foundation

Als das Interesse an der Nutzung von Emacs wuchs, beteiligten sich andere Leute am GNU Projekt und wir entschieden, dass es Zeit wurde, erneut nach finanziellen Mitteln zu suchen. So schufen wir 1985 die Free Software Foundation (FSF), eine gemeinnützige Organisation zur Förderung und Entwicklung von freier Software. 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 und nonGNU) und natürlich durch den Verkauf freier Handbücher erweitert.

Der größte Teil der Einnahmen kommt von Verkäufen von Kopien freier Software und anderen damit zusammenhängenden Diensten (CD-ROMs mit Quellcodes oder Binärdateien, schön gedruckten Handbüchern, alle mit der Freiheit der Weitergabe und Modifizierung) und Deluxe Distributionen (in denen wir ein ganzes Softwarearchiv nach Wahl des Kunden je nach Plattform zusammenstellten). Heute verkauft die FSF Handbücher und andere Ausrüstung, aber den Großteil ihrer Mittel aus Mitgliedsbeiträgen. Sie können der FSF unter fsf.org beitreten.

Beschäftigte der Free Software Foundation haben eine Reihe von GNU Softwarepaketen geschrieben und gewartet. Zwei beachtenswerte sind die C-Bibliothek und die Shell. 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 Free Software Foundation, Roland McGrath, entwickelt. Die auf den meisten GNU/Linux-Systemen genutzte Eingabeaufforderung ist Bourne Again Shell (BASH)⁽⁵⁾, die von Brian Fox, einem FSF-Mitarbeiter, entwickelt wurde.

Wir finanzierten die Entwicklung dieser Programme, weil es beim GNU Projekt nicht nur um Extras oder einer Entwicklungsumgebung ging. Ziel war ein vollständiges Betriebssystem, und diese Programme wurden für dieses Ziel gebraucht.

Freie Software-Unterstützung

Die Freie-Software-Philosophie lehnt eine bestimmte, weitverbreitete Geschäftspraxis ab, aber ist nicht gegen das Geschäft. Wenn Unternehmen die Freiheit der Nutzer respektieren, wünschen wir ihnen viel Erfolg.

Der Verkauf von Emacs-Kopien veranschaulicht eine Art des freien Softwaregeschäfts. Als die FSF dieses Geschäft übernahm, brauchte ich eine andere Lösung, um meinen Lebensunterhalt zu bestreiten. Ich fand sie im Verkauf von Dienstleistungen in Zusammenhang mit der freien Software, die ich entwickelt hatte. Dies beinhaltete Unterricht über Themen wie GNU Emacs und GCC, Softwareentwicklung und hauptsächlich das Portieren von GCC auf neue Plattformen.

Inzwischen wird jede Art dieser Geschäfte mit freier Software durch eine Reihe von Unternehmen praktiziert. Einige verbreiten Freie Software auf CD-ROM; andere verkaufen Unterstützung durch Beantwortung von Anwenderfragen, Beseitigung von Programmfehlern, bis hin zum Hinzufügen neuer Programmfunktionen. Wir fangen sogar an, freie Softwareunternehmen zu sehen, die aufgrund neuer freier Softwareprodukte gegründet werden.

Achtung, obwohl es eine Reihe von Unternehmen gibt, die sich dem Begriff „Open Source“ verbunden fühlen, basiert ihr Geschäft tatsächlich auf unfreier Software, die mit freier Software arbeitet. Das sind keine freie, sondern proprietäre Softwareunternehmen, deren Produkte Nutzer aus der Freiheit weg in Versuchung führen sollen. Sie nennen diese Programme „Mehrwertpakete“, die die Werte widerspiegeln, die sie gerne als von uns adaptiert sehen würden: Bequemlichkeit über Freiheit. Wenn wir Freiheit höher schätzen, sollten sie „Wenigwert“pakete genannt werden.

Technische Ziele

Das primäre Ziel von GNU soll Freie Software sein. Selbst wenn GNU keinen technischen Vorteil gegenüber Unix hätte, hat es einen sozialen Vorteil, der Nutzern erlaubt zusammenzuarbeiten, und einen ethischen Vorteil, der die Freiheit des Nutzers respektiert.

Aber es war natürlich, bekannte Standards guter Praxis auf die Arbeit anzuwenden – etwa die dynamische Zuweisung von Datenstrukturen, um willkürliche feste Größenbeschränkungen zu vermeiden, und die Behandlung aller möglichen 8-Bit-Codes, wann immer das Sinn macht.

Darüber hinaus lehnten wir die Unix-Konzentration 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 machen, die Speichernutzung zu verringern, wenn es einen Megabyte nicht überstieg. In Programmen, für die die Behandlung von großen Dateien nicht entscheidend war, ermutigten wir Programmierer, die gesamte Eingabedatei in den Kern einzulesen, dann seinen Inhalt zu überprüfen, ohne sich über Ein- und Ausgabe kümmern zu müssen.

Diese Entscheidungen ermöglichten vielen GNU Programmen, ihre Unix-Gegenstücke in Zuverlässigkeit und Geschwindigkeit zu übertreffen.

Gespendete Rechner

Als die Anerkennung des GNU Projekt wuchs, wurden Rechner als Spende für das Projekt angeboten, die unter Unix liefen. Diese waren sehr nützlich, weil es der einfachste Weg war, um GNU-Komponenten zu entwickeln, diese auf einem Unix-System zu packen, und dessen Komponenten - eins nach dem anderen - zu ersetzen. Aber das löste eine ethische Frage aus: Ob für uns überhaupt eine Kopie von Unix richtig war…

Unix war (und ist) proprietäre Software und die Philosophie des GNU Projekt sagte, keine proprietäre Software zu nutzen. Aber die gleiche Argumentation anwendend, die zu der Schlussfolgerung führt, dass Gewalt als Selbstverteidigung gerechtfertigt ist, schloss ich, dass es legitim wäre, ein proprietäres Paket zu nutzen, wenn es entscheidend ist für die Entwicklung eines freien Ersatzes, der anderen helfen würde, die Nutzung der proprietären Anwendung zu beenden.

Aber sogar wenn es ein gerechtfertigtes Übel war, es war noch immer ein Übel. Heute haben wir keine Kopien mehr von Unix, weil wir sie durch freie Betriebssysteme ersetzt haben. Wenn wir das Betriebssystem eines Rechners nicht ersetzen konnten, haben wir stattdessen den Rechner ersetzt.

GNUs Aufgabenliste

Mit Fortschreiten des GNU Projekt und immer mehr gefundenen oder entwickelten Systemkomponenten wurde schließlich eine Liste der verbleibenden Lücken notwendig. Wir verwendeten sie, um Entwickler zu rekrutieren, um die fehlenden Teile zu schreiben. Diese Liste wurde als GNU Task List bekannt. Zusätzlich zu den fehlenden Unix-Komponenten listeten wir verschiedene andere nützliche Projekte für Software und Dokumentationen auf, die unserer Meinung nach ein komplettes System haben sollte.

Heute⁽⁶⁾ sind kaum noch Unix-Komponenten in der GNU Aufgabenliste vorhanden – diese wurden abgearbeitet, abgesehen von ein paar unwichtigen. Aber die Liste ist voll von Projekten, die manche „Anwendungen“ nennen. Jedes Programm, das mehr als nur bei einer kleinen Nutzergruppe Anklang findet, wäre Sinnvoll, um es einem Betriebssystem hinzuzufügen.

Sogar Spiele sind in der Aufgabenliste enthalten – und seit Anfang an dabei. Unix enthielt Spiele, also sollte natürlich auch GNU welche enthalten. Da aber Kompatibilität kein Problem für Spiele war, mussten wir der Liste von Spielen nicht folgen, die Unix hatte. Stattdessen listeten wir ein Spektrum verschiedener Arten von Spielen auf, die Nutzer mögen würden.

GNU Library GPL

Die GNU C-Bibliothek nutzt eine spezielle Art des Copyleft namens GNU Library General Public License⁽⁷⁾, die die Berechtigung erteilt, proprietäre Software mit der Bibliothek zu verknüpfen. Warum machen wir diese Ausnahme?

Es ist keine Frage des Prinzips; es gibt kein Prinzip, das proprietäre Softwareprodukte berechtigt, unseren Code zu enthalten. (Warum zu einem Projekt beitragen, welches sich weigert, mit uns zu teilen?) Die LGPL für die C-Bibliothek, oder irgendeine andere Bibliothek, ist eine Frage der Strategie.

Die C-Bibliothek erfüllt eine allgemeine Aufgabe; jedes proprietäre System oder Compiler kommt mit einer C-Bibliothek. Deshalb würde die Verfügbarkeit unserer C-Bibliothek ausschließlich für Freie Software dieser keinen Vorteil bringen – es würde nur von der Nutzung unserer Bibliothek abhalten.

Ein System ist eine Ausnahme: Auf dem GNU System (und dazu gehört auch GNU/Linux) ist die GNU C-Bibliothek die einzige C-Bibliothek. Die Vertriebsbedingungen bestimmen, ob es möglich ist, proprietäre Anwendungen für das GNU System zu kompilieren. Es gibt keine ethischen Gründe, 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.

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, es dann unter der GPL freizugeben –  beschränkt auf freie Programme – ist das ein Weg, anderen Entwicklern freier Software zu helfen, einen Vorteil gegenüber proprietärer Software zu haben.

Die GNU Readline-Bibliothek wurde entwickelt, um die Bearbeitung der Eingabeaufforderung für BASH 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, um Readline zu nutzen, und das ist ein wirklicher Gewinn für die Gemeinschaft.

Entwickler proprietärer Software haben die Vorteile Geld zu bieten; Entwickler freier Software müssen sich gegenseitig Vorteile verschaffen. Ich hoffe, dass wir eines Tages eine große Sammlung GPL-abgedeckter Bibliotheken haben werden, die keine Parallelen zu proprietärer Software haben, nützliche Module bereitstellen, die als Bausteine in neuer freier Software dienen und die mind. einen großen Vorteil für die weitere Entwicklung freier Software hinzufügt.

Einen Juckreiz löschen?

Eric Raymond sagt: „Jede gute Software wird von einem Entwickler geschrieben, der ein persönliches Problem lösen will." Vielleicht passiert das manchmal, aber viele wesentliche Teile der GNU Software wurden entwickelt, um ein komplettes freies Betriebssystem zu haben. Sie stammen aus einer Vision und einem Plan, nicht aus einem Impuls heraus.

Beispielsweise wurde die C-Bibliothek entwickelt, weil ein unixartiges System eine C-Bibliothek braucht, BASH, weil ein unixartiges System eine Eingabeaufforderung braucht, und GNU tar, weil ein unixartiges System ein tar-Programm braucht. Gleiches gilt für die von mir geschriebenen Programme – den GNU C-Compiler, GNU Emacs, GDB und GNU Make.

Einige GNU Programme wurden entwickelt, um mit bestimmten Bedrohungen unserer Freiheit zurechtzukommen. So entwickelten wir gzip, um das Komprimierungsprogramm zu ersetzen, das der Gemeinschaft wegen LZW-Patente verloren ging. Wir fanden Leute, um LessTif zu entwickeln, und begannen vor kurzem mit der Entwicklung von GNOME und Harmony, um die durch bestimmte proprietäre Bibliotheken (siehe unten) verursachten Probleme anzugehen. Wir entwickelten den GNU Privacy Guard, um eine beliebte unfreie Verschlüsselungssoftware zu ersetzen, denn Nutzer sollten nicht zwischen Privatsphäre und Freiheit entscheiden müssen.

Die Leute, 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.

Unerwartete Entwicklungen

Zu Beginn des GNU Projekt stellte ich mir vor, dass wir das ganze GNU System entwickeln und dann als Ganzes freigeben. So ist es nicht gekommen.

Da jede Komponente des GNU Systems auf einem Unix-System implementiert wurde, konnte jede auf einem Unix-System ausgeführt werden, lange bevor ein komplettes GNU System vorhanden war. Einige dieser Programme wurden populär und Nutzer begannen sie zu erweitern und zu portieren – auf die verschiedensten inkompatiblen Versionen von Unix, und manchmal auch auf andere Systeme.

Dieser Vorgang machte diese Programme sehr viel mächtiger und zog sowohl Gelder als auch Mitwirkende dem GNU Projekt hinzu. Aber er verzögerte möglicherweise auch die Fertigstellung eines minimal-arbeitenden Systems um mehrere Jahre, da die Entwickler von GNU Zeit in die Pflege dieser Portierungen und Hinzufügen neuer Funktionen zu bestehenden Komponenten aufbrachten, statt sich dem Schreiben fehlender Komponenten, eine nach der anderen, zu widmen.

GNU Hurd

Um 1990 war das GNU System fast fertig; die einzige große fehlende Komponente war der Betriebssystemkern. Wir hatten beschlossen, unseren Betriebssystemkern als eine Sammlung von Server-Prozessen zu implementieren, die auf dem Mach laufen. Mach ist ein an der Carnegie Mellon University und dann an der University of Utah entwickelter Mikrokernel. GNU HURD ist eine Sammlung von Servern (d. h. eine Herde von 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 Veröffentlichung von Mach als freie Software warteten.

Ein Grund für die Wahl dieses Designs war zu vermeiden, was, wie es schien der schwierigste Teil der Aufgabe war: Ein Betriebssystemkernprogramm ohne einen Source-Level-Debugger zu debuggen (Diagnose auf Quelltextebene). Dieser Teil der Aufgabe war bereits im Mach getan, und wir erwarteten die HURD-Server als Anwenderprogramme mit GDB zu debuggen. Aber es brauchte lange Zeit, um dies zu ermöglichen, und die Multithread-Server, die sich gegenseitig Nachrichten senden, haben sich als sehr schwierig zu debuggen erwiesen. Den HURD zum soliden Arbeiten zu bringen, zog sich über mehrere Jahre hin.

Alix

Der GNU-Betriebssystemkern sollte ursprünglich nicht HURD genannt werden. Sein ursprünglicher Name war Alix – benannt nach der Frau, die damals meine Geliebte war. Sie, eine Unix Systemadministratorin, wies darauf hin, wie ihr Name in ein allgemeines Namensschema für Unix-Systemversionen passen würde. „Jemand sollte einen Betriebssystemkern nach mir benennen“, witzelte sie unter Freunden. Ich sagte nichts, aber beschloss, sie mit einem Betriebssystemkern namens Alix zu überraschen.

Es blieb nicht dabei. Michael Bushnell (heute Thomas Bushnell), der Hauptentwickler des Betriebssystemkerns, bevorzugte den Namen HURD und definierte Alix als einen bestimmen Teil des Betriebssystemkerns um – den Teil, der Systemaufrufe abfängt und durch Senden von Nachrichten an Hurd Server behandeln würde.

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 sendet, und das ließ die Alix Komponente aus dem Design verschwinden.

Aber vorher stieß ein Freund von ihr auf den Namen Alix im Quellcode von HURD, und erwähnte es ihr gegenüber. So erfüllte der Name seine Aufgabe.

Linux und GNU/Linux

GNU Hurd ist nicht für den produktiven Einsatz geeignet – und wissen nicht, ob es jemals so sein wird. Das fähigkeitsbasierte Design hat Probleme, die sich direkt aus der Flexibilität des Designs ergeben, und es ist nicht klar, ob Lösungen existieren.

Glücklicherweise ist ein anderer Betriebssystemkern verfügbar. 1991 entwickelte Linus Torvalds einen Unix-kompatiblen Betriebssystemkern und nannte ihn Linux. Im Jahr 1992 gab er Linux als Freie Software frei; die Kombination von Linux mit dem noch nicht ganz fertigen GNU System führte zu einem komplett freien Betriebssystem (die Kombination war natürlich eine erhebliche Aufgabe an sich). Es ist Linux zu verdanken, dass heute tatsächlich eine Version des GNU Systems ausführbar ist.

Wir nennen diese Systemversion GNU/Linux, um die Zusammensetzung als eine Kombination des GNU Systems mit Linux als Betriebssystemkern auszudrücken.

Herausforderungen in der Zukunft

Wir haben unsere Fähigkeit, ein breites Spektrum an freier Software zu entwickeln. Dies bedeutet nicht, dass wir unbesiegbar und unaufhaltsam sind. Verschiedene Herausforderungen machen die Zukunft von freier Software unsicher; ihnen zu entsprechen, erfordert unerschütterliche Anstrengungen und Durchhaltevermögen, manchmal für Jahre. Es erfordert die Art von Entschlossenheit, die Menschen zeigen, wenn sie ihre Freiheit schätzen und sich von niemanden wegnehmen lassen.

Die folgenden vier Abschnitte erörtern diese Herausforderungen.

Geheime Hardware

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 Rechner von morgen nicht unterstützen können.

Es gibt zwei Wege, um mit diesem Problem fertig zu werden. Programmierer können mit Reverse Engineering („umgekehrt entwickeln“) herauszufinden, 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.

Reverse Engineering ist eine große Aufgabe; haben wir Programmierer mit ausreichender Entschlossenheit, es zu übernehmen? Ja, 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 von uns extra Geld spenden oder sogar etwas mehr Zeit, damit wir freie Treiber nutzen können? Ja, wenn die Entschlossenheit, Freiheit zu haben, weit verbreitet ist.

(Hinweis: Dieses Problem erstreckt sich auch auf das BIOS. Es gibt ein freies BIOS namens „Coreboot“; das Problem ist, Spezifikationen für Rechner zu erhalten, damit Coreboot sie unterstützt. Stand: 2008)

Unfreie Bibliotheken

Eine unfreie Bibliothek, die auf einem freien Betriebssystem ausgeführt wird, verhält sich für Entwickler von freier Software wie ein Falle. Die attraktiven Funktionen der Bibliothek sind der Köder, und wenn man sie nutzt, schnappt die Falle zu, weil das Programm kein sinnvoller Bestandteil eines freien Betriebssystems sein kann (streng genommen könnte das Programm eingebunden werden, aber die Ausführung mit fehlender Bibliothek unmöglich). Noch schlimmer ist, wenn ein Programm, das eine proprietäre Bibliothek verwendet, populär wird, und so andere ahnungslose Programmierer in die Falle lockt.

Der erste Fall dieses Problems war in den Achtzigern das Motif-Toolkit. Obwohl es noch keine freien Betriebssysteme gab, war klar, welche Probleme Motif später verursachen würde. Das GNU Projekt antwortete auf zwei Arten:

1. indem bei einzelnen freien Softwareprojekten um Unterstützung von freien X-Toolkit-Widgets sowie Motif gebeten wurde, und
2. indem nach jemandem gesucht wurde, der einen freien Ersatz für Motif schreibt.

Diese Aufgabe dauerte viele Jahre; LessTif, von ungarischen Programmierern entwickelt, unterstütze erst ab 1997 die meisten Motif-Anwendungen.

Zwischen 1996 und 1998 wurde eine weitere unfreie grafische Benutzeroberflächen-Bibliothek (GUI) namens Qt in eine umfangreiche Sammlung freier Software, dem KDE-Desktop, genutzt.

Freie GNU/Linux-Systeme konnten KDE nicht verwenden, denn die Bibliothek wurde nicht genutzt. Jedoch fügten einige kommerzielle GNU/Linux-Distributoren, die keine strenge Richtlinie hatten, ausschließlich Freie Software aufzunehmen, KDE hinzu – produzierten so ein System mit mehr Möglichkeiten, aber weniger Freiheit. Die KDE-Gruppe ermutigte aktiv mehr Programmierer Qt zu nutzen, und Millionen neuer „Linux-Anwender“ hatten noch nie von dem Problem gehört, dem sie ausgesetzt waren. Die Situation war makaber.

Die Freie-Software-Gemeinschaft antwortete auf das Problem auf zweierlei Weise: GNOME und Harmony.

GNOME ist GNUs Benutzeroberflächen-Projekt. 1997 von Miguel de Icaza gestartet, und entwickelt mit Unterstützung von Red Hat Software, machte sich GNOME auf den Weg, mit ausschließlich freier Software eine ähnliche Ausstattung der Arbeitsoberfläche anzubieten. Es hat auch technische Vorteile, wie die Unterstützung einer Vielzahl von Programmiersprachen, nicht nur C++. Aber das wichtigste Ziel war die Freiheit: Keine unfreie Software erforderlich.

Harmony ist eine kompatible Ersatzbibliothek, entworfen, um KDE-Software ohne Verwendung von Qt zu ermöglichen.

Im November 1998 kündigten die Entwickler von Qt eine Änderung der Lizenz an, die, wenn durchgesetzt, Qt zu freier Software machen sollte. Es gibt keine Möglichkeit, sicher zu sein, aber ich denke, dass das zum Teil auch durch die standhafte Reaktion der Gemeinschaft auf das Problem, vor dem Qt stand, als es unfrei war, verursacht war. (Die neue Lizenz ist ungeeignet und ungerecht, so bleibt es wünschenswert, die Nutzung von Qt zu vermeiden.)

[Nachträgliche Notiz: Im September 2000 wurde Qt unter der GNU GPL freigegeben, was das Problem im Wesentlichen gelöst hat.]

Wie antworten wir auf die nächste verlockende unfreie Bibliothek? Wird die gesamte Gemeinschaft die Notwendigkeit verstehen, nicht in die Falle zu tappen? Oder werden viele von uns die Freiheit zugunsten der Bequemlichkeit aufgeben und so ein großes Problem erzeugen? Unsere Zukunft hängt von unserer Philosophie ab.

Softwarepatente

Die schlimmste Bedrohung, mit der wir uns konfrontiert sehen, kommt 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 veröffentlichen, um ordnungsgemäße komprimierte GIFs zu produzieren. [Seit 2009 abgelaufen.] Im Jahr 1998 wurde ein freies Programm, um MP3 komprimiertes Audio zu produzieren, aus der Distribution unter Androhung eines Rechtsstreites entfernt.

Es gibt Möglichkeiten, mit Patenten zurechtzukommen: Man kann nach Beweisen suchen, ob ein Patent ungültig ist, und nach Alternativen suchen, um eine Aufgabe zu lösen. Aber jede dieser Methoden funktioniert nur manchmal; scheitern beide, kann ein Patent von jeder freien Software erzwingen, eine Eigenschaft, die Anwender benötigen, fehlt. Was werden wir tun, wenn das geschieht?

Diejenigen von uns, die Freie Software um der Freiheit wegen schätzen, werden so oder so bei freier Software bleiben. Wir werden es schaffen, Aufgaben ohne patentierte Funktionen zu erledigen. Aber diejenigen, die Freie Software schätzen, weil sie sie als technisch überlegen erwarten, werden es wahrscheinlich einen Fehler nennen, wenn ein Patent davon abhält. Daher – obwohl es sinnvoll ist, über die praktische Wirksamkeit des „Bazaar“-Entwicklungsmodells sowie der Zuverlässigkeit und Macht irgendeiner freien Software zu sprechen – dürfen wir nicht dort stoppen. Wir müssen über Freiheit und Prinzipien sprechen.

Freie Dokumentation

Das größte Defizit in unserem freien Betriebssystem ist nicht in der Software – es ist der Mangel an guten freien Anleitungen, die wir in unsere Systeme integrieren können. Dokumentation ist ein wesentlicher Bestandteil jedes Softwarepaketes; wenn ein wichtiges freies Softwarepaket nicht mit einer guten freien Anleitung kommt, ist das eine große Lücke. Wir haben heute viele solcher Lücken.

Freie Dokumentation, wie Freie Software, ist eine Frage der Freiheit, nicht des Preises. Das Kriterium einer freien Anleitung ist so ziemlich das gleiche wie für Freie Software: Es geht darum, allen Nutzern bestimmte Freiheiten zu geben. Weitervertrieb (einschließlich kommerzieller Verkauf) muss online und auf Papier zulässig sein, damit die Anleitung jede Programmkopie begleiten kann.

Die Berechtigung zur Modifikation ist auch entscheidend. Im Allgemeinen glaube ich nicht, dass die Berechtigung wichtig ist, alle Arten von Artikel und Bücher zu modifizieren. Ich glaube nicht, dass Sie, oder ich, beispielsweise verpflichtet sind, die Berechtigung zur Modifikation für Artikel wie diesen zu erteilen, der unsere Handlungen und Ansichten beschreibt.

Es gibt aber einen bestimmten Grund, warum die Freiheit zur Veränderung entscheidend für die Dokumentation freier Software ist. Wenn die Menschen ihr Recht, Software zu ändern oder Funktionen zu ändern oder hinzuzufügen, ausüben und gewissenhaft sind, werden sie auch die Anleitung ändern – damit eine genaue und brauchbare Dokumentation mit dem modifizierten Programm angeboten werden kann. Eine unfreie Anleitung, die gewissenhaften Programmierern nicht erlaubt die Aufgabe zu beenden, erfüllt nicht den Bedarf der Gemeinschaft.

Einige Beschränkungen, wie Modifikationen gemacht werden können, werfen keine Probleme auf. Anforderungen, wie den ursprünglichen Copyright-Hinweis des Autors, Vertriebsbedingungen oder die Autorenliste anzugeben, sind beispielsweise okay. 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 es sich um nichttechnische Themen handelt. Diese Beschränkungen sind kein Problem, weil sie den gewissenhaften Programmierer nicht davon abhalten, die Anleitung an das modifizierte Programm anzupassen. Mit anderen Worten blockieren sie die Freie-Software-Gemeinschaft nicht, die Anleitungen voll zu nutzen.

Es Jedoch muss es möglich sein, den ganzen technischen Inhalt der Anleitung zu modifizieren und das Ergebnis mit allen gängigen Medien und üblichen Vertriebskanälen zu verbreiten; andernfalls behindern die Einschränkungen die Gemeinschaft, die Anleitung ist nicht frei, und wir brauchen eine andere.

Werden freie Softwareentwickler das Bewusstsein und die Entschlossenheit haben, das volle Spektrum freier Anleitungen zu produzieren? Wieder einmal hängt unsere Zukunft von der Philosophie ab.

Wir müssen über Freiheit sprechen

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 praktischen Vorteile entwickelt, dass Nutzer aus rein praktischen Gründen zuströmen.

Die guten Konsequenzen daraus sind offensichtlich: Mehr Interesse an der Entwicklung von Freie Software, mehr Kunden für das Geschäft mit Freie Software und mehr Möglichkeiten zur Förderung von Unternehmen, kommerzielle Freie Software anstelle proprietärer Software zu entwickeln.

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 erfüllen, hängt vom Willen ab, für Freiheit zustehen. Um sicherzustellen, dass unsere Gemeinschaft diesen Willen hat, müssen an jeden neuen Nutzer zu verbreiten, wenn sie in die Gemeinschaft kommen.

Wir aber versagen: Die Bemühungen, um neue Nutzer für unsere Gemeinschaft zu gewinnen, übersteigt bei weitem die Bemühungen, ihnen die Pflichten unserer Gemeinschaft zu lehren. Wir müssen beides tun und im Gleichgewicht halten.

„Open Source“

Neuen Nutzern etwas über Freiheit zu lehren, wurde im Jahr 1998 schwieriger, als ein Teil der Gemeinschaft beschloss, nicht mehr den Begriff „Freie Software“ zu verwenden, sondern stattdessen „Open-Source“-Software (quelloffene Software).

Einige, die diesen Begriff bevorzugten, hatten die Verwechslung von „frei“ mit „gratis“ zum Ziel – ein zulässiges Ziel. Andere hatten jedoch zum Ziel, den Geist des Grundsatzes ins Abseits zu drängen, der die Freie-Software-Bewegung und das GNU Projekt motivierte, und stattdessen an Führungskräfte und Geschäftskunden appellierte, viele von ihnen haben eine Ideologie, die Gewinn vor Freiheit, vor Gemeinschaft und vor Prinzipien stellt. So konzentriert sich die Rhetorik von „Open Source“ auf das Potenzial, hochwertige und leistungsfähige Software zu herzustellen, aber die Ideen der Freiheit, Gemeinschaft und Prinzip vermeidet.

Die „Linux“-Fachzeitschriften sind ein klares Beispiel dafür – sie sind gefüllt mit Werbung für proprietäre Software, die mit GNU/Linux funktioniert. Wenn das nächste Motif oder Qt erscheint, werden diese Magazine Programmierer warnen davon fern zu bleiben, oder dafür werben?

Die Unterstützung von Unternehmen kann in vielerlei Hinsicht zur Gemeinschaft beitragen; Ceteris paribus - wobei die übrigen Dinge gleich sind - ist sinnvoll. Aber ihre Unterstützung zu gewinnen, indem man noch weniger über Freiheit und Prinzipien spricht, kann katastrophal sein; es macht das vorherige Ungleichgewicht zwischen Reichweite und Sozialer Bildung noch schlimmer.

„Freie Software“ und „Open Source“ beschreiben mehr oder weniger die gleiche Softwarekategorie, aber sagen verschiedene Dinge über Software und Werte. Das GNU Projekt verwendet weiterhin den Begriff „Freie Software“, um die Idee zum Ausdruck zu bringen, dass Freiheit, und nicht nur Technk wichtig ist.

Testen Sie!

Yodas Aphorismus („Es gibt kein ‚Versuchen‘“) 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 habe es trotzdem versucht, denn es war niemand außer mir zwischen dem Feind und meiner Stadt. Überraschend ist es manchmal gelungen.

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.

Heute bin ich oft nicht der einzige. Es ist eine Erleichterung und Freude, wenn ich ein Regiment von Hackern eingraben sehe, 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 darauf vorbereitet sein, sie zu verteidigen.