Über das Projekt ‚GNU‘

von Richard Stallman

Die englische Originalausgabe wurde in dem Buch Open Sources veröffentlicht. Richard Stallman war nie ein Anhänger von „Open Source“;, trug aber diesen Artikel bei, damit die Anschauungen der Freie-Software-Bewegung nicht völlig fehlen würden.

Bitte beachten Sie auch den Aufsatz Freie Software ist jetzt sogar noch wichtiger denn je, denn wir sollten auf Software ‑ Software die wir nutzen! ‑ bestehen, die frei ist.

Die erste Software-teilende Gemeinschaft

Als ich 1971 am Artificial Intelligence Laboratory (AI Lab) des Massachusetts Institute of Technology 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.

Das AI Lab verwendete ein Mehrbenutzer-Betriebssystem namens Incompatible Timesharing System (ITS), welches die Hacker(1) des Laborpersonals in der Programmiersprache Assembler für den Digital PDP-10, einen der großen Rechner dieser Ära, entworfen und geschrieben hatten. Als Mitglied dieser Gemeinschaft, ein angestellter Systemhacker des AI Labs, war es meine Aufgabe dieses System zu verbessern.

Wir nannten unsere Software nicht Freie Software, 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.

Der Zusammenbruch der Gemeinschaft

Die Situation änderte sich Anfang der 80er Jahre drastisch, 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 AI Labs war bereits kurz vorher zusammengebrochen. Im Jahr 1981 hatte das ausgegliederte Unternehmen Symbolics fast alle Hacker aus dem AI Lab abgeworben, und die entvölkerte Gemeinschaft war außerstande, sich zu behaupten (das Buch Hackers von Steve Levy beschreibt diese Ereignisse sowie ein klares Bild dieser Gemeinschaft in ihrer Blütezeit). Als das AI Lab 1982 einen neuen PDP-10 kaufte, entschieden dessen Administratoren, Digitals unfreies Mehrbenutzer-Betriebssystem anstatt ITS zu benutzen.

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

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.“

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

Wenn Softwarehersteller über „Durchsetzung“ ihrer „Rechte“ oder Verhinderung von „Softwarepiraterie“ sprechen, ist das, was sie wirklich meinen, 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.

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.

Eine weitere unausgesprochene Annahme ist, dass es bei Software nur wichtig ist, welche Aufgaben sie einem erlaubt auszuführen ‑ das wir Rechnernutzer uns nicht darum kümmern sollten, was für eine Gesellschaft wir haben dürfen.

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.

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

Es würde den Rahmen dieses Dokuments sprengen, die Gründe für diese Schlussfolgerung ausführlich darzulegen, möchte aber auf die Artikel Warum Software keine Eigentümer haben sollte und Freie Software ist jetzt sogar noch wichtiger verweisen.

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

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.

Ich hatte bereits Erfahrung damit, am empfangenden Ende einer Vertraulichkeitsvereinbarung zu sein, als sich jemand weigerte, mir und dem MIT AI Lab 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.

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.

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.

Die Antwort war klar: was zuerst erforderlich war, war ein Betriebssystem. Das ist die entscheidende Software, um anzufangen, einen Rechner zu benutzen. Mit einem Betriebssystem kann man viele Dinge machen, ohne kann man den Rechner überhaupt nicht benutzen. Mit einem freien Betriebssystem könnten wir wieder eine Gemeinschaft von zusammenarbeitenden Hackern haben ‑ und jeden einladen, sich uns anzuschließen. Und jedermann wäre in der Lage einen Rechner zu benutzen, ohne auf verschwörerische Weise zu beginnen seine oder ihre Freunde zu benachteiligen.

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 GNU wurde, einer Hacker-Tradition folgend, als ein rekursives Akronym für GNU’s Not Unix (‚GNU ist nicht Unix‘) gewählt und wird [ˈgnuː] ausgesprochen.

Ein Betriebssystem bedeutet nicht nur einen Betriebssystemkern ‑ kaum genug, um andere Programme auszuführen. In den 1970ern umfasste jedes Betriebssystem, das diesen Namen verdiente, Befehlsinterpreter, Assembler, Compiler, Interpreter, Debugger, Texteditoren, E-Mail-Anwendungen und vieles mehr. ITS, Multics, VMS und Unix hatten sie. Das GNU-Betriebssystem würde sie auch umfassen.

Später hörte ich diese Wörter, zurückgeführt auf Hillel[2]:

„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?“

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

Frei wie in Freiheit

Der Begriff Freie Software wird mitunter missverstanden ‑ er hat nichts mit dem Preis zu tun. Es geht um Freiheit. Hier deshalb die Freie-Software-Definition.

Ein Programm ist Freie Software, für Sie, einem besonderen Benutzer, wenn:

• Sie die Freiheit haben, das Programm auszuführen wie Sie möchten, für jeden Zweck;
• 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);
• Sie die Freiheit haben, Kopien weiterzuverbreiten, entweder gratis oder gegen eine Gebühr;
• Sie die Freiheit haben, modifizierte Programmversionen zu distribuieren, damit die Gemeinschaft von Ihren Verbesserungen profitieren kann.

Da sich frei 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 freie Software.

Aufgrund der Mehrdeutigkeit von frei 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 frei wie in Freiheit bedeutet ‑ uneingeschränkt ist ein Wort, das dieser Bedeutung am nächsten kommt. Derartige Alternativen wie befreit, Freiheit und offen haben entweder die falsche Bedeutung oder einen anderen Nachteil.

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. Beispielsweise entschied ich mich gleich am Anfang hauptsächlich TeX als Textsatzsystem zu nutzen; einige Jahre später beschloss ich, das X Window System (X11) zu nutzen, anstatt ein anderes Fenstersystem für GNU zu schreiben.

Aufgrund dieser (und anderer ähnlicher) Entscheidungen ist das GNU-System nicht das Gleiche wie die Sammlung aller GNU-Software. Das GNU-System umfasst Programme, die nicht GNU-Software sind, Programme, die von anderen Personen und Projekten für deren eigene Zwecke entwickelt wurden ‑ aber die wir verwenden können, weil sie 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 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.

Allerdings lud mich Professor Winston, der damalige Leiter des MIT AI Lab, freundlicherweise ein, weiterhin die Einrichtung des Labors zu nutzen.

Die ersten Schritte

Kurz vor Beginn des GNU-Projekts hörte ich vom Free University Compiler Kit, auch als VUCK bekannt (das niederländische Wort für frei fängt mit einem ‚v‘, für ‚vrij‘, 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.

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.

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 Lawrence Livermore Laboratory 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.

Dann fand ich heraus, dass der Pastel Compiler die gesamte Eingabedatei durch 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 zu schreiben. Dieser neue Compiler ist heute als GNU Compiler Collection (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.

GNU Emacs

Ich begann die Arbeit an GNU Emacs 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 Vi oder Ed zu erlernen, hatte ich meine Bearbeitung bis dahin auf anderen Rechnern erledigt.

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.

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.

Ist ein Programm für jeden Benutzer frei?

Wenn ein Programm, wenn es die Hände des Autors verlässt, Freie Software ist, bedeutet dies nicht notwendigerweise, dass es für jedermann freie Software sein wird, die eine Kopie davon besitzen. Beispielsweise ist Public-Domain-Software (Software, die nicht dem Urheberrecht unterliegt)[*] 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.

Das paradigmatische Beispiel dieses Problems ist das X Window System (X11). Am MIT entwickelt und als Freie Software mit einer freizügigen Lizenz freigegeben, wurde es bald von verschiedenen Rechnerfirmen adaptiert. Sie fügten X11 nur in binärer Form ihren proprietären Unix-Systemen hinzu ‑ mit einer Vertraulichkeitsvereinbarung. Diese X11-Kopien waren wie Unix keine freie Software mehr.

Die Entwickler von X11 betrachteten dies nicht als ein Problem ‑ sie erwarteten und beabsichtigten es sogar. Ziel war nicht Freiheit, nur Erfolg, definiert als viele Benutzer habend. Es kümmerte nicht, ob diese Freiheit hatten, sie sollten nur zahlreich sein.

Das führte zu einer paradoxen Situation, in der zwei unterschiedliche Sichtweisen, das Maß an Freiheit zu messen, verschiedene Antworten auf die Frage ergaben, „Ist das Programm frei?“ 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.

Copyleft und die GNU GPL

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 Copyleft genannt.(3)

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.

Der Kerngedanke von Copyleft ist, jedem die Berechtigung zu geben, das Programm ausführen, kopieren, modifizieren und modifizierte Versionen verbreiten zu dürfen ‑ aber nicht die Berechtigung Beschränkungen hinzuzufügen. Damit werden entscheidende Freiheiten, die Freie Software definieren, an jedermann garantiert, wer eine Kopie besitzt. Sie werden unveräußerliche Rechte.

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: „Sie können diese Änderungen nicht mit anderen austauschen, weil wir sie nutzen werden, um unsere proprietäre Version des Programms daraus zu machen.“

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.

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.

Die konkrete Umsetzung des Copyleft, die wir für die meiste GNU-Software verwenden, ist die GNU General Public License, kurz GNU GPL. 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.(4)

Free Software Foundation

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 Free Software Foundation (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.

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 Handbücher und andere Utensilien, erhält aber den Großteil ihrer Mittel aus Mitgliedsbeiträgen. Sie können der FSF unter FSF.org beitreten.

Mitarbeiter der Free Software Foundation 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 Free Software Foundation, Roland McGrath, entwickelt. Der auf den meisten GNU/Linux-Systemen genutzte Befehlszeileninterpreter ist Bourne Again Shell (BASH)[5], entwickelt von Brian Fox, einem FSF-Mitarbeiter.

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.

Freie-Software-Unterstützung

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.

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.

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.

Passen Sie dennoch auf: 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-Software-Unternehmen, sondern proprietäre Softwareunternehmen, deren Produkte Benutzer von Freiheit weg in Versuchung führen. Sie nennen diese Programme Mehrwertpakete, 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 freiheitsentziehende 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, gäbe es einen sozialen Vorteil, der Nutzern erlaubt zusammenzuarbeiten, und einen ethischen Vorteil, der die Freiheit des Nutzers respektiert.

Aber es war selbstverständlich, die bekannten Standards guter Praxis auf die Arbeit anzuwenden ‑ etwa die dynamische Zuweisung von Datenstrukturen, um willkürliche feste Größenbegrenzungen zu vermeiden, und die Handhabung aller möglichen 8-Bit-Codes, wann immer das Sinn macht.

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.

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

Gespendete Rechner

Als der Ruf des GNU-Projekts wuchs, begann man Rechner als Spende für das Projekt anzubieten, die unter Unix liefen. Diese waren sehr nützlich, weil der einfachste Weg, die Entwicklung von GNU-Komponenten auf einem Unix-System zu tun, und dessen Komponenten eins nach dem anderen zu ersetzen ‑ eine nach der anderen. Aber das löste eine ethische Frage aus: ob es für uns richtig war, überhaupt eine Kopie von Unix zu besitzen.

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.

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.

GNU-Aufgabenliste

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.

Heute sind kaum noch Unix-Komponenten in der GNU Task List[6] vorhanden ‑ diese sind, abgesehen von ein paar unwichtigen, abgearbeitet. Aber die Liste ist voll von Projekten, die manche „Anwendungen“ nennen mögen. Jedes Programm, das mehr als nur eine kleine Benutzergruppe anspricht, wäre sinnvoll, um es einem Betriebssystem hinzuzufügen.

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

GNU Library GPL

Die GNU C-Bibliothek nutzt eine spezielle Art des Copyleft namens GNU Library General Public License (LGPL), die die Berechtigung erteilt, proprietäre Software mit der Bibliothek zu verbinden.(7) Warum diese Ausnahme?

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.

Die C-Bibliothek erfüllt eine allgemeine Aufgabe. Jedes proprietäre System oder jeder Compiler kommt mit einer C-Bibliothek. Deshalb hätte, wäre unsere C-Bibliothek ausschließlich für Freie Software verfügbar, dieser keinen Vorteil bringen ‑ es hätte nur von der Nutzung unserer Bibliothek abgehalten.

Ein System ist eine Ausnahme: in einem GNU-System (und dies schließt GNU/Linux ein) ist die GNU C-Bibliothek die einzige C-Bibliothek. Die Vertriebsbedingungen der GNU C-Bibliothek bestimmen, ob es möglich ist, ein proprietäres Programm für das GNU-System zu kompilieren. Es gibt keinen ethischen Grund, proprietäre Anwendungen auf einem GNU-System zu ermöglichen, aber strategisch gesehen scheint es, dass das Verbieten eher von der Nutzung des GNU-Systems abhält, als die Entwicklung freier Anwendungen zu fördern. Deshalb ist die Verwendung der Library GPL eine gute Strategie für die C-Bibliothek.

Für andere Bibliotheken muss die strategische Entscheidung individuell getroffen werden. Wenn eine Bibliothek bei einer speziellen Aufgabe helfen kann, bestimmte Arten von Programmen zu schreiben und dann unter der GPL freizugeben ‑ auf lediglich freie Programme begrenzt ‑ ist das ein Weg, anderen Freie-Software-Entwicklern zu helfen und einen Vorteil gegenüber proprietäre Software zu geben.

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.

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.

Einen Juckreiz löschen?

Eric Raymond sagt: Jedes gute Werk von Software fängt mit dem Kratzen eines persönlichen Juckreizes des Entwicklers an. 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.

Beispielsweise wurde die C-Bibliothek entwickelt, weil ein unixartiges System eine C-Bibliothek braucht, BASH, weil ein unixoides System einen Befehlszeileninterpreter braucht, und GNU Tar, weil ein unixoides System ein Archivierungsprogramm braucht. Gleiches gilt für die von mir geschriebenen Programme ‑ den GNU C-Compiler, GNU Emacs, GDB und GNU Make.

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 LZW-verloren gegangen war. Wir fanden Menschen um LessTif zu entwickeln und begannen vor kurzem mit der Entwicklung von GNOME 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.

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.

Unerwartete Entwicklungen

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.

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

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.

GNU Hurd

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 Carnegie Mellon-Universität und dann an der Universität von Utah entwickelter Mikrokern. GNU HURD ist eine Sammlung von Servern (d. h. eine Herde GNUs), die auf dem Mach laufen und verschiedene Aufgaben des Unix-Betriebssystemkerns erledigen. Der Beginn der Entwicklung wurde verzögert, da wir, wie versprochen wurde, auf die Freigabe von Mach als Freie Software warteten.

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.

Alix

Der GNU-Betriebssystemkern sollte ursprünglich nicht HURD genannt werden. Sein ursprünglicher Name war Alix ‑ benannt nach der Frau, die damals mein Schatz war. Sie, eine Unix-Systemadministratorin, hatte darauf hingewiesen wie ihr Name in ein allgemeines Namensmuster für Unix-Systemversionen passen würde. Jemand sollte einen Systemkern nach mir benennen witzelte sie unter Freunden. Ich sagte nichts dazu, aber beschloss sie mit einem Systemkern namens Alix zu überraschen.

Es blieb nicht dabei. Michael Bushnell (heute Thomas Bushnell), der Hauptentwickler des Systemkerns, bevorzugte den Namen HURD und definierte Alix neu, um auf einen bestimmen Teil des Systemkerns zu verweisen ‑ den Teil, der Systemaufrufe abfangen und diese durch Senden von Nachrichten an die Hurd-Server behandeln würde.

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.

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.

Linux und GNU/Linux

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.

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.

Wir nennen diese Version des Systems GNU/Linux, 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 fälschlicherweise unsere Arbeit auf jemand anderen zurückführt. Bitte geben Sie uns eine ebensolche Erwähnung.

Herausforderungen in der Zukunft

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.

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

Es gibt zwei Wege, um mit diesem Problem fertig zu werden. Die Programmierer können mit Reverse Engineering ‚Nachkonstruktion‘ herausfinden, wie man die Hardware unterstützen kann. Der Rest von uns kann die Hardware wählen, die von freier Software unterstützt wird; bei steigender Nutzerzahl wird das Geheimhalten der Spezifikationen eine selbstzerstörerische Politik.

Reverse Engineering ist eine äußerst umfangreiche Aufgabe. Werden wir Programmierer mit ausreichender Entschlossenheit haben, dies 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 zusätzliches Geld spenden oder sogar ein wenig mehr Zeit, damit wir freie Treiber nutzen können? Ja, wenn die Entschlossenheit, Freiheit zu haben, weit verbreitet ist.

(Anmerkung: Dieses Problem erstreckt sich auch auf das BIOS. Es gibt ein freies BIOS namens LibreBoot. Das Problem ist Spezifikationen für Rechner zu erhalten, damit LibreBoot sie ohne unfreie Binary Large Objects ‚BLOBs‘ unterstützen kann. Stand: 2008)

Unfreie Bibliotheken

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 ausgeführt 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.

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.

Zwischen 1996 und 1998 wurde eine andere Bibliothek namens Qt als unfreie grafische Benutzerschnittstelle ‚GUI‘ in einer umfangreichen Freie-Software-Sammlung, der KDE-Arbeitsumgebung, genutzt.

Freie GNU/Linux-Systeme waren außerstande KDE zu verwenden, denn die Bibliothek konnte nicht genutzt werden. Allerdings fügten einige kommerzielle Distributoren von GNU/Linux-Systemen, die nicht streng an freier Software festhielten, KDE ihren Systemen hinzu ‑ produzierten so ein System mit mehr Möglichkeiten, aber weniger Freiheit. Die KDE-Gruppe ermutigte aktiv mehr Programmierer Qt zu benutzen, und Millionen von neuen „Linux-Nutzern“ waren nie der Idee ausgesetzt worden, dass es damit ein Problem gab. Die Situation war makaber.

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

GNOME, das GNU Network Object Model Environment, ist GNUs Projekt einer grafischen Benutzeroberflächen-Umgebung. 1997 von Miguel de Icaza gestartet und entwickelt mit der Unterstützung von Red Hat Software, 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.

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

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).

(Nachträgliche Anmerkung: Im September 2000 wurde Qt unter der GNU GPL neu freigegeben, was dieses Problem im Grunde löste.)

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.

Softwarepatente

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 GIF-Dateien (Graphics Interchange Format) zu erzeugen.(*) 1998 wurde ein freies Programm zur Produktion von komprimiertem MP3-Audio (MPEG-1 Audio Layer 3) unter Androhung einer Patentklage aus der Distribution herausgenommen.(**)

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?

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 Bazaar-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.

Freie Dokumentation

Der größte Mangel an unseren freien Betriebssystemen ist nicht die Software ‑ es ist der Mangel an guten freien Handbüchern, die wir in unsere Systeme integrieren können. Dokumentation ist ein wesentlicher Bestandteil jedes Softwarepakets; wenn ein wichtiges freies Softwarepaket nicht mit einem guten freien Handbuch erhältlich ist, ist das eine große Lücke. Wir haben heute viele solcher Lücken.

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.

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.

Es gibt aber einen bestimmten Grund, warum die Freiheit zur Modifizierung für Dokumentation von freier Software entscheidend ist. Wenn die Menschen ihr Recht ausüben, Software zu modifizieren und Funktionen zu ändern oder hinzuzufügen, wenn sie gewissenhaft sind, ändern sie das Handbuch auch ‑ damit eine genaue und nutzbare Dokumentation mit dem modifizierten Programm angeboten werden kann. Ein unfreies Handbuch, dass gewissenhaften Programmierern nicht erlaubt die Aufgabe zu beenden, erfüllt nicht den Bedarf unserer Gemeinschaft.

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.

Jedoch muss es möglich sein, den ganzen technischen 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.

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.

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 praktische Vorteile entwickelt, dass Nutzer aus rein praktischen Erwägungen zuströmen.

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.

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.

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.

„Open Source“

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

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

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

Die Unterstützung des Geschäfts kann in vielerlei Hinsicht zur Gemeinschaft beitragen; unter sonst gleichen Bedingungen ‚Ceteris Paribus‘ 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.

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, nicht nur Technik, 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 versuchte es trotzdem, denn es gab niemand außer mir zwischen dem Feind und meiner Stadt. Selbst überrascht, 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.

Heutzutage bin ich oft nicht der einzige. Es ist eine Erleichterung und Freude, wenn ich sehe wie sich ein Regiment von Hackern eingräbt, um die Stellung zu halten, und weiß, diese Stadt kann überleben ‑ im Moment. Aber die Gefahren werden jedes Jahr größer, und nun hat sich Microsoft klar gegen unsere Gemeinschaft ausgerichtet. Wir können die zukünftige Freiheit nicht für selbstverständlich halten. Halten Sie sie nicht für selbstverständlich! Wenn Sie Ihre Freiheit behalten möchten, müssen Sie bereit sein sie zu verteidigen.