![[image of What's GNU]](/graphics/whats-gnu-sm.jpg)
[
deutsch
| englisch
| französisch
| indonesisch
| italienisch
| koreanisch
| russisch
| spanisch
| tschechisch
]
von Richard Stallman
Originalveröffentlichung in dem Buch "Open Sources"
[
deutsch
| englisch
| französisch
| indonesisch
| italienisch
| koreanisch
| russisch
| spanisch
| tschechisch
]
Als ich 1971 anfing, im Labor für Künstliche Intelligenz des MIT zu arbeiten, wurde ich Teil einer gemeinschaftlich Software nutzenden Gesellschaft, die seit vielen Jahren existiert hatte. Das miteinander Teilen von Software war nicht auf unsere einzelne Gruppe beschränkt; es ist so alt, wie die Computer selbst, genauso wie das Weitergeben von Rezepten so alt, wie das Kochen ist. Aber wir taten es öfter, als die meisten.
Das KI-Labor nutzte ein Mehrbenutzer-Betriebssystem, genannt ITS (the Incompatible Timesharing System) welches die Hacker (1) des Laborpersonals in Assemblersprache für den Digital PDP-10, einen der großen Computer dieser Ära, designed und geschrieben hatten. Als ein Mitglied dieser Gemeinschaft, als ein KI-Laborpersonal-Systemhacker, war es meine Aufgabe, dieses System zu verbessern.
Wir nannten unsere Software nicht "freie Software", weil dieser Term noch nicht existierte, aber das ist es, was sie war. 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 ungewohntes und interessantes Programm nutzen 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.
(1) Der Gebrauch von "Hacker" in der Bedeutung als jemand, der Sicherheitssysteme bricht, ist eine Verwirrung seitens der Massenmedien. Wir Hacker lehnen es ab, diese Bedeutung anzuerkennen und fahren fort, dieses Wort in seiner Bedeutung für jemanden zu nutzen, der es liebt, zu programmieren und raffiniert darin ist.
Die Situation änderte sich drastisch in den frühen 1980ern, als Digital die PDP-10 Serie einstellte. Ihre Architektur, elegant und leistungsfähig in den 60er Jahren, konnte nicht auf die größeren Adressräume erweitert werden, welche in den 80ern möglich wurden. Das bedeutete, dass nahezu alle im ITS zusammengesetzten Programme veraltet waren.
Die KI-Labor Hacker-Gesellschaft war nicht lange davor bereits 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 fähig, sich zu behaupten. (Das Buch "Hackers", von Steve Levy, beschreibt diese Ereignisse und gibt ein klares Bild von dieser Gemeinschaft in ihren besten Jahren.) Als das KI-Labor 1982 einen neuen PDP-10 kaufte, entschieden seine Administratoren, Digitals' nicht-freies Mehrbenutzer-Betriebssystem anstatt ITS zu benutzen.
Die modernen Computer dieser Ära, solche wie der VAX oder der 68020, hatten ihre eigenen Betriebssysteme, aber keines von ihnen war freie Software: Man musste eine Vertraulichkeitsvereinbarung unterzeichen, sogar um nur eine ausführbare Kopie zu erhalten.
Das bedeutete, dass der erste Schritt beim Nutzen eines Computers darin bestand, zu versprechen, seinem Nachbarn nicht zu helfen. Eine kooperierende Gemeinschaft war verboten. Die Regel des Besitzers der proprietären Software war, "Wenn du mit deinem Nachbar teilst, bist du ein Software-Pirat. Wenn du irgendwelche Änderungen haben möchtest, bitte uns, diese zu machen."
Die Idee, welche das proprietäre Software-Sozialsystem -- das System, was besagte, man sei nicht berechtigt, Software zu teilen oder zu verändern -- gesellschaftsfeindlich ist, dass es nicht ethisch ist, dass es einfach falsch ist, mag einigen Lesern wie eine Überraschung vorkommen. Aber was sollten wir sonst über ein System sagen, welches auf der Teilung der Allgemeinheit und dem Hilflos-Lassen des Anwenders basiert? Leser, welche diese Idee überraschend finden, haben möglicherweise das proprietäre Software-Sozialsystem als gegeben angesehen oder es unter den von den proprietären Software-Gesellschaften vorgeschlagenen Begriffen betrachtet. Software-Herausgeber haben lange und hart daran gearbeitet, die Menschen zu überzeugen, dass es nur einen Blickwinkel auf diese Sache gibt.
Wenn Software-Herausgeber über das "Erzwingen" ihrer "Rechte" oder das "Stoppen von Software-Piraterie" sprechen, ist es sekundär, was sie wirklich *sagen*. Die wahre Aussage ihrer Äußerungen ist die nicht ausgesprochene Annahme, die sie als garantiert ansehen; der Öffentlichkeit wird unterstellt, diese unkritisch zu akzeptieren. Lasst uns diese nun prüfen.
Eine Annahme ist, dass Software Firmen fraglos natürliches Recht haben, Software zu besitzen, und so die Macht über alle ihre Anwender. (Wenn das naturgemäßes Recht wäre, ganz gleich wieviel Schaden es der Öffentlichkeit bringt, könnten wir keinen Einspruch erheben.) Interessanterweise lehnen die US Verfassung und rechtliche Traditionen diese Sichtweise ab; Copyright ist kein natürliches Recht, sondern ein von der Regierung verhängtes Monopol, welches das Recht des Nutzers zu kopieren, begrenzt.
Eine andere nicht ausgesprochene Annahme ist die, dass die einzig wichtige Sache an Software ist, welche Aufgaben sie einem erlaubt, zu tun -- dass wir Computer-Nutzer uns nicht darum kümmern sollten, welche Art von Gesellschaft wir erlaubt sind zu haben.
Eine dritte Annahme ist die, dass wir keine nutzbare Software haben würden (oder niemals ein Programm, um diesen oder jenen bestimmten Job zu erledigen), wenn wir keiner Firma Macht über die Benutzer des Programms geben würden. Diese Annahme mag ganz plausibel ausgesehen haben, bevor die freie Software Bewegung demonstriert hat, dass wir eine Fülle an brauchbarer Software machen können, ohne Ketten an sie zu legen.
Wenn wir es ablehnen, diese Annahmen zu akzeptieren und diese Dinge auf der moralischen Basis des gewöhnlichen Menschenverstandes beurteilen, während wir den Nutzer an erste Stelle setzen, kommen wir zu ganz anderen Schlussfolgerungen. Computer-Nutzern sollte erlaubt sein, Software ihren Bedürfnissen entsprechend anzupassen und Software mit anderen zu teilen, denn anderen Menschen zu helfen, ist die Basis unserer Gesellschaft.
Hier ist kein Platz, um ausführlich die Gründe für diese Schlussfolgerung darzulegen, so möchte ich den Leser auf die Website http://www.gnu.org/philosophy/why-free.de.html hinweisen.
Mit dem Verlust meiner Gemeinschaft war es unmöglich, weiterzumachen wie zuvor. Stattdessen stand ich vor einer gänzlich moralischen Entscheidung.
Die einfache Wahl wäre gewesen, der proprietären Software-Welt beizutreten, Vertraulichkeitsvereinbarungen zu unterzeichnen und zu versprechen, meinen Mit-Hackern nicht zu helfen. Sehr wahrscheinlich würde ich auch Software entwickeln, die unter Vertraulichkeitsvereinbarungen ausgegeben würde und so den Druck auf andere Leute erhöhen, ihre Kameraden auch zu verraten.
Ich hätte auf diese Art Geld machen und mich vielleicht mit dem Schreiben von Code vergnügen können. Aber ich wusste, dass ich am Ende meiner Karriere auf Jahre des Bauens von Wänden, um die Menschen zu teilen, zurückblicken würde und ich würde das Gefühl haben, dass ich mein Leben damit verbracht hatte, die Welt zu einen schlechteren Ort zu machen.
Ich hatte bereits Erfahrung damit, am empfangenden Ende einer Vertraulichkeitsvereinbarung zu sein, als sich jemand weigerte, mir und dem MIT KI-Labor den Quellcode für das Kontrollprogramm 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 umdrehen und dasselbe mit jemand anderem machen.
Eine andere Wahl, direkt aber unerfreulich, war, das Gebiet der Computer zu verlassen. Auf diese Art würden meine Fähigkeiten nicht missbraucht, aber sie würden dennoch verschwendet werden. Ich wäre nicht Schuld, Computer-Nutzer zu trennen und zu begrenzen, aber es würde trotzdem passieren.
Also suchte ich nach einem Weg, auf dem ein Programmierer etwas Gutes tun kann. Ich fragte mich selbst: Gibt es ein Programm oder Programme, die ich schreiben könnte, um wieder eine Gemeinschaft möglich zu machen?
Die Antwort war klar: zuerst wurde ein Betriebssystem gebraucht. Das war der entscheidende Punkt um anzufangen, einen Computer zu nutzen. Mit einem Betriebssystem kann man viele Dinge machen; ohne kann man den Computer überhaupt nicht nutzen. Mit einem freien Betriebssystem könnten wir wieder eine neue Gemeinschaft von zusammenarbeitenden Hackern haben -- und jeden einladen, sich uns anzuschließen. Und jeder würde fähig sein, einen Computer zu nutzen, ohne anzufangen, sich auf verschwörerische Weise seinen oder ihren Freunden zu entziehen.
Als ein Betriebssystem-Entwickler hatte ich die richtigen Fähigkeiten für diesen Job. 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, dieses System mit Unix kompatibel zu machen, so dass es portierbar wäre und dass Unix Nutzer leicht zu ihm wechseln könnten. Der Name GNU wurde entsprechend einer Hacker-Tradition gewählt, als eine rekursive Abkürzung für "GNU's Not Unix." (GNU ist nicht Unix)
Ein Betriebssystem bedeutet nicht einfach nur ein Kernel, gerade mal genug, um andere Programme laufen zu lassen. In den 1970ern enthielt jedes Betriebssystem, welches diesen Namens wert war, Kommando-Prozessoren, Assembler, Compiler, Interpreter, Debugger, Text-Editoren, Mailer und viel mehr. ITS hatte sie, Multics hatte sie, VMS hatte sie und Unix hatte sie. Das GNU Betriebssystem würde sie auch enthalten.
Später hörte ich diese Worte, Hillel (1) zugeschrieben:
If I am not for myself, who will be for me?
If I am only for myself, what am I?
If not now, when?
Wenn nicht ich für mich bin, wer wird sein für mich?
Wenn einzig ich für mich bin, was bin ich?
Wenn nicht jetzt, wann?
Die Entscheidung, das GNU-Projekt zu starten, basierte auf einer ähnlichen Einstellung.
(1) Als Atheist folge ich keinem religiösen Anführer, aber manchmal stelle ich fest, dass ich einiges bewundere, was einer von ihnen gesagt hat.
Der Term "freie Software" wird manchmal falsch verstanden -- er hat nichts mit dem Preis zu tun. Es geht dabei um Freiheit. Hier ist deswegen die Definition von freier Software: Ein Programm ist freie Software, für dich, einen bestimmten Anwender, wenn:
Da sich "frei" auf Freiheit bezieht, nicht auf den Preis, gibt es keinen Widerspruch zwischen dem Verkaufen von Kopien und freier Software. Tatsächlich ist die Freiheit entscheidend, Kopien zu verkaufen: Sammlungen von freier Software, verkauft auf CD-ROMs, sind wichtig für die Gemeinschaft und diese zu verkaufen ist eine wichtige Methode, Geld für die Entwicklung freier Software zu beschaffen. Daher ist ein Programm keine freie Software, bei dem man nicht frei ist, es in solche Sammlungen aufzunehmen.
Aufgrund der Mehrdeutigkeit von "free" ("frei") hat man lange nach Alternativen gesucht, aber niemand hat eine passende Alternative gefunden. Die Englische Sprache hat mehr Wörter und Nuancen als jede andere, aber ihr fehlt ein einfaches, eindeutiges Wort, das "frei" bedeutet, so wie in Freiheit -- "unfettered" (frei, uneingeschränkt) ist das Wort, was dieser Bedeutung am nächsten kommt. Solche Alternativen wie "liberated" (befreit), "freedom" (Freiheit) und "open" (offen) haben entweder die falsche Bedeutung oder einige andere Nachteile.
Ein ganzes System zu entwickeln, ist ein sehr großes Projekt. Um es erreichbar zu machen, entschied ich mich, existierende Teile von freier Software anzupassen und zu nutzen, wann immer das möglich war. Zum Beispiel entschied ich mich ganz am Anfang, hauptsächlich TeX als Text-Formatierer zu nutzen; einige Jahre später entschied ich mich, das X Window-System zu benutzen, anstatt ein anderes Window-System für GNU zu schreiben.
Aufgrund dieser Entscheidung ist das GNU System nicht dasselbe wie die Sammlung aller GNU Software. Das GNU System enthält Programme, die nicht GNU Software sind, Programme, die von anderen Menschen und für andere Projekte und für ihre eigene Zwecke entwickelt wurden, aber wir können sie nutzen, weil sie freie Software sind.
Im Januar 1984 quittierte ich meinen Job am MIT und begann, GNU Software zu schreiben. Das MIT zu verlassen, war nötig, damit es nicht in der Lage war, sich bezüglich der Verbreitung von GNU als freie Software einzumischen. Wenn ich ihr Mitarbeiter geblieben wäre, hätte das MIT Anspruch auf den Besitz meiner Arbeit erheben können und seine eigenen Richtlinien bei der Verbreitung verhängen können, oder die Arbeit sogar in ein proprietäres Software-Paket verwandeln können. Ich hatte nicht die Absicht, eine Menge Arbeit zu erledigen, um dann zu sehen, dass es für seinen eigentlichen Zweck nutzlos wird: Das Erschaffen einer neuen Software teilenden Gemeinschaft.
Wie auch immer, Professor Winston, der Leiter des MIT-KI-Labors, lud mich freundlich ein, weiterhin die Einrichtungen des Labors zu nutzen.
Kurz vor Anfang des GNU Projektes hörte ich vom Free University Compiler Kit (freier Universitäts Compiler-Satz), auch bekannt als VUCK. (Das niederländische Wort für frei wird mit einem V geschrieben.) Es ist ein Compiler, entworfen um verschiedene Sprachen handhaben zu können, inklusive C und Pascal, und um vielfältige Ziel-Plattformen zu unterstützen. 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, aber der Compiler nicht. Ich entschied mich daher, dass mein erstes Programm für das GNU Projekt ein Compiler für viele Sprachen und Plattformen sein würde.
In der Hoffnung, die Notwendigkeit zu vermeiden, den ganzen Compiler selbst zu schreiben, besorgte ich den Quellcode für den Pastel Compiler, welcher ein Multi-Plattform Compiler war, entwickelt in den Lawrence Livermore Laboren. Er unterstützte und war in einer erweiterten Pascal-Version geschrieben, entworfen um eine System-Programmiersprache zu sein. Ich fügte ein C-Front-End hinzu und begann ihn auf den Motorola 68000 Computer zu portieren. Aber ich musste das aufgeben, als ich herausfand, dass der Compiler mehrere Megabyte Stack-Speicher benötigte und das verfügbare 68000 Unix System nur 64k erlauben würde.
Ich fand dann heraus, dass der Pastel Compiler so funktionierte, dass er die ganze Eingabedatei in einen Syntax-Baum umwandelte, diesen dann in eine Kette von "Instruktionen" und dann die ganze Ausgabedatei generierte, ohne jemals irgendwelche Speicher wieder freizugeben. An diesem Punkt zog ich den Schluss, dass ich einen neuen Compiler von Grund auf schreiben muss. Dieser neue Compiler ist nun bekannt als GCC; nichts aus dem Pastel Compiler ist in ihm genutzt worden, aber ich schaffte es, das C Front-End, welches ich geschrieben hatte, anzupassen und zu nutzen. Aber das kam erst einige Jahre später, zuerst arbeitete ich an GNU Emacs.
Ich fing im September 1984 mit der Arbeit am GNU Emacs an und im frühen 1985 begann er, nutzbar zu werden. Das erlaubte mir, Unix Systeme zum Editieren zu nutzen, ich hatte kein Interesse daran, vi oder ed zu lernen, bis dahin hatte ich auf anderen Maschinen editiert.
Zu diesem Zeitpunkt begannen die Menschen, sich für den GNU Emacs zu interessieren, was die Frage aufwarf, wie ich ihn vertreiben sollte. Natürlich legte ich ihn auf den anonymen FTP Server des MIT Computers, den ich nutzte. (Dieser Computer, prep.ia.mit.edu, wurde daher zur hauptsächlichen GNU-FTP-Vertriebsseite, als er ein paar Jahre später stillgelegt wurde, transferierten wir seinen Namen zu unserem neuen FTP-Server.) Zu dieser Zeit aber waren viele der interessierten Leute nicht im Internet und konnten keine Kopie per FTP bekommen. Nun also war die Frage, was würde ich zu ihnen sagen?
Ich hätte sagen können, "Finde einen Freund, der im Netz ist und der eine Kopie für dich machen wird." Oder ich hätte das tun können, was ich mit dem originalen PDP-10 Emacs tat: Ich sagte ihnen: "Schicke mir ein Band und einen frankierten Rückumschlag, und ich werde es mit Emacs darauf zurücksenden." Aber ich hatte keinen Job und war auf der Suche nach Wegen, Geld mit freier Software zu verdienen. So kündigte ich an, dass ich für eine Gebühr von $150 ein Band zu jedem, der eins wolle, senden würde. Auf diese Art begann ich, ein freie Software vertreibendes Unternehmen zu starten, der Vorläufer der Unternehmen, die heute ganze Linux-basierte GNU-Systeme vertreiben.
Wenn ein Programm freie Software ist, wenn es die Hände seines Autors verlässt, bedeutet das nicht notwendigerweise, dass es freie Software für jeden ist, der eine Kopie davon hat. Zum Beispiel Public Domain Software (Software, die kein Copyright hat) ist freie Software; aber jeder kann eine modifizierte proprietäre Version davon erstellen. Ebenfalls werden viele freie Programme mit einem Copyright versehen, aber unter einfachen, freizügigen Lizenzen vertrieben, die proprietäre modifizierte Versionen erlauben.
Das paradigmatische Beispiel dieses Problems ist das X Window-System. Am MIT entwickelt und als freie Software mit einer freizügigen Lizenz vertrieben, wurde es bald von verschiedenen Computerfirmen adaptiert. Sie fügten X zu ihren proprietären Unix Systemen hinzu, nur in binärer Form, abgedeckt durch eine Vertraulichkeitsvereinbarung. Diese Kopien von X waren keine freie Software mehr wie Unix.
Die Entwickler des X Window-Systems sahen das nicht als ein Problem -- sie erwarteten und beabsichtigten, dass es passieren würde. Ihr Ziel war nicht Freiheit, einfach "Erfolg", definiert darin, "viele Anwender zu haben." Sie kümmerten sich nicht darum, ob diese Freiheit hatten, sie sollten nur zahlreich sein.
Das führte zu einer paradoxen Situation, an der zwei verschiedene Wege, das Maß der Freiheit zu bestimmen, verschiedene Antworten auf die Frage, "Ist das Programm frei?", gab. Wenn man Freiheit nach den Vertriebstermen, die das MIT seinem Vertrieb zu Grund legte, beurteilte, würde man sagen, dass X freie Software war. Aber wenn man die Freiheit des durchschnittlichen Nutzers von X maß, würde man sagen, dass es proprietäre Software sei. Die meisten X Anwender benutzten die proprietären Versionen, die mit ihren Unix Systemen kamen, nicht die freie Version.
Das Ziel von GNU war, den Anwendern Freiheit zu geben, nicht einfach bloß bekannt zu sein. So brauchten wir Vertriebsbedingungen, die es verhindern würden, dass GNU Software zu proprietärer Software gemacht werden würde. Die Methode, die wir nutzen, wird "Copyleft" genannt.(1)
Copyleft nutzt Copyright-Gesetze, aber dreht sie um, um auf gegenteilige Weise zu wirken, als deren gewöhnliche Anwendung: anstatt als ein Mittel um Software zu privatisieren, wird es ein Mittel um Software frei zu halten.
Die zentrale Idee vom Copyleft ist, dass wir jedem die Erlaubnis geben, das Programm laufen zu lassen, es zu kopieren, zu modifizieren und modifizierte Versionen zu vertreiben -- aber nicht die Erlaubnis, eigene Begrenzungen hinzuzufügen. Daher sind die entscheidenden Freiheiten, die "Freie Software" definieren, jedem garantiert, der eine Kopie hat; sie werden unverkäufliche Rechte.
Für ein effektives Copyleft müssen modifizierte Versionen auch frei sein. Das garantiert, dass Arbeit, die auf unserer basiert, für die Gemeinschaft bei Veröffentlichung verfügbar wird. Wenn Programmierer, die Arbeit als solche haben, freiwillig GNU Software verbessern, dann ist es das Copyleft, was ihre Chefs davon abhält, zu sagen, "Du kannst diese Änderungen nicht mit anderen teilen, weil wir sie zu unserer proprietären Version dieses Programms machen werden."
Die Anforderung, dass Änderungen auch frei sind, ist essentiell, wenn wir Freiheit für jeden Nutzer des Programms garantieren wollen. Die Firmen, die das X Window-System privatisiert haben, machten für gewöhnlich einige Änderungen, um es auf ihre Systeme und ihre Hardware zu portieren. Diese Änderungen waren klein, verglichen mit der Größe von X, aber sie waren nicht trivial. Wenn Änderungen zu machen eine Entschuldigung dafür wäre, den Nutzern die Freiheit zu verweigern, wäre es leicht für jeden, seinen Vorteil aus dieser Ausrede zu ziehen.
Ein ähnliches Problem betrifft die Kombination eines freien Programms mit nicht-freiem Code. Solch eine Kombination würde unumgänglich nicht-frei sein; welche Freiheiten auch immer im nicht-freien Teil fehlen würden, würden den Ganzen fehlen. Solche Kombinationen zu erlauben, würde ein Loch öffnen, groß genug um ein Schiff darin zu versenken. Daher ist eine zentrale Anforderung an das Copyleft, dieses Loch zu stopfen: alles hinzugefügt oder kombiniert mit einem Copyleft-geschützten Programm muss auf eine Art erfolgen, dass die große kombinierte Version auch frei und Copyleft-geschützt ist.
Die spezifische Implementation des Copyleft, die wir für die meiste GNU Software nutzen, ist die GNU General Public License, oder die GNU GPL, abgekürzt. Wir haben viele andere Arten von Copylefts, die in speziellen Situationen genutzt werden. GNU Anleitungen sind auch Copyleft-geschützt, aber nutzen eine viel einfachere Version des Copyleft, weil die Komplexität der GNU GPL nicht für Anleitungen nötig ist.
(1) 1984 oder 1985, schicke Don Hopkins (ein sehr einfallsreicher Bursche) mir einen Brief. Auf den Umschlag hatte er etliche amüsante Sprüche geschrieben, unter anderen diesen: "Copyleft--all rights reversed." (Copyleft -- alle Rechte umgedreht) Ich nutzte das Wort "Copyleft" um das Vertriebskonzept zu benennen, welches ich zu dieser Zeit entwickelte.
Als das Interesse am Gebrauch 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, einen steuerfreien Wohlfahrtsverband für die Entwicklung freier Software. Die FSF übernahm das Emacs-Bänder Vertriebssystem; später erweiterte sie es durch Hinzufügen anderer freier Software (sowohl GNU und nicht-GNU) zu dem Band, und auch durch den Verkauf freier Anleitungen.
Die FSF akzeptiert Spenden, aber der größte Teil ihres Einkommens kommt von Verkäufen -- von Kopien freier Software und anderen damit zusammenhängenden Diensten. Heutzutage verkauft sie CD-ROMs mit Quellcode, CD-ROMs mit Binaries, hübsch gedruckte Anleitungen (alle mit der Freiheit, sie zu verteilen und zu verändern), und Deluxe Distributionen (in denen wir die ganze Sammlung von Software für ihre gewählte Plattform zusammenstellen).
Free Software Foundation - Angestellte haben eine Menge von GNU Software Paketen geschrieben und gewartet. Zwei beachtenswerte sind die C Bibliothek und die Shell. Die GNU C Bibliothek ist, was jedes auf einem GNU/Linux System laufende Programm nutzt, um mit Linux zu kommunizieren. Sie wurde von einem Mitglied des Free Software Foundation Personals, Roland McGrath, entwickelt. Die auf den meisten GNU/Linux Systemen benutzte Shell ist BASH, die Bourne again Shell(1), welche von Brian Fox, einem FSF Beschäftigten, entwickelt wurde.
Wir finanzierten die Entwicklung von diesen Programmen, weil es im GNU Projekt nicht nur um Tools oder eine Entwicklungsumgebung ging. Unser Ziel war ein komplettes Betriebssystem und diese Programme wurden für dieses Ziel gebraucht.
(1) "Bourne again Shell" ist ein Witz über den Namen "Bourne Shell", welche die gewöhnliche Shell in Unix war.
Die freie Software Philosophie lehnt eine bestimmte, weitverbreitete Geschäftspraxis ab, aber ist nicht gegen das Geschäft an sich. Wenn es die Freiheit des Nutzers respektiert, wünschen wir Erfolg.
Kopien von Emacs zu verkaufen, demonstriert eine Art von Geschäften mit freier Software. Als die FSF diese Angelegenheit übernahm, brauchte ich eine andere Lösung, um mein Auskommen zu haben. Ich fand sie, indem ich Service zu der von mir entwickelten Software anbot. Das enthielt Unterricht über Themen, wie man GNU Emacs programmiert und wie man GCC anpasst und Software-Entwicklung, hauptsächlich das Portieren von GCC auf neue Plattformen.
Heute wird jede Art dieses Geschäftes mit freier Software von einer Anzahl von Beteiligten praktiziert. Einige verteilen Sammlungen freier Software auf CD-ROM; andere verkaufen Support auf Ebenen angefangen vom Beantworten von Nutzer-Fragen, über Fehlerbeseitigung, bis hin zum Hinzufügen bedeutender neuer Features. Wir fangen sogar an, freie Software-Firmen zu sehen, die auf dem Einführen neuer freier Software Produkte basieren.
Aufgepasst, obgleich es eine Anzahl von Firmen gibt, die sich mit dem Term "open source" assoziieren, basiert ihr Geschäft auf nicht-freier Software, die mit freier Software arbeitet. Das sind keine freie Software Firmen, es sind proprietäre Software-Firmen, deren Produkte die Nutzer aus der Freiheit heraus verführen. Sie nennen diese "wertgesteigert", was die Werte wiederspiegelt, die sie gerne als von uns adaptiert sehen würden: Bequemlichkeit bezüglich Freiheit. Wenn wir Freiheit höher bewerten, sollten wir diese "freedom subtracted" (freiheitsentzogene) Produkte nennen.
Das hauptsächliche Ziel von GNU war, freie Software zu sein. Sogar wenn GNU keine technischen Vorteile gegenüber Unix hätte, hätte es einen sozialen Vorteil gehabt, der Nutzern erlaubt, zu kooperieren, und einen ethischen Vorteil, die Freiheit des User zu respektieren.
Aber es war natürlich, die bekannten Standards guter Praxis auf die Arbeit anzuwenden -- zum Beispiel, dynamisch Datenstrukturen anzulegen, um eigenmächtige feste Größenbegrenzungen zu vermeiden und alle möglichen 8-Bit Codes zu bearbeiten, wann immer das Sinn machte.
Zusätzlich lehnten wir die Unix-Konzentration auf kleine Speichergrößen ab, indem wir entschieden, 16-Bit Maschinen nicht zu unterstützen (es war klar, dass 32-Bit Maschinen die Norm sein würden, wenn das GNU System fertiggestellt war), und keine Bestrebungen zu machen, die Speichernutzung zu verringern, wenn es nicht einen Megabyte überstieg. In Programmen, für die das Handhaben von großen Dateien nicht entscheidend war, ermutigten wir die Programmierer, die gesamte Eingabedatei in den Kern einzulesen, dann seinen Inhalt zu scannen, ohne sich über Ein- und Ausgabe Sorgen machen zu müssen.
Diese Entscheidungen erlaubten es vielen GNU Programmen, ihre Unix Gegenstücke in Verlässlichkeit und Geschwindigkeit zu übertreffen.
Als die Anerkennung des GNU Projektes wuchs, begannen die Menschen, uns Maschinen als Spenden für das Projekt anzubieten, auf denen Unix lief. Diese waren sehr nützlich, weil es der einfachste Weg, GNU Komponenten zu entwickeln, war, dieses auf einem Unix zu tun und dessen Komponenten Stück für Stück auszutauschen. Aber das erhob eine ethische Frage: Ob es für uns richtig war, überhaupt eine Unix-Kopie zu haben.
Unix war (und ist) proprietäre Software und die Philosophie des GNU Projekts sagt, dass wir keine proprietäre Software nutzen sollten. 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, das Nutzen der proprietären Anwendung zu beenden.
Aber sogar wenn es ein gerechtfertigtes Übel war, es war noch immer ein Übel. Heutzutage haben wir keine Kopien von Unix mehr, weil wir sie mit freien Betriebssystemen ersetzt haben. Wenn wir das Betriebssystem einer Maschine nicht ersetzen konnten, haben wir stattdessen die Maschine ersetzt.
Mit dem Fortschreiten des GNU Projektes und einer wachsenden Anzahl von neu entwickelten Systemkomponenten wurde es nützlich, eine Liste von den verbleibenden Lücken anzufertigen. Wir nutzten diese, um Entwickler einzustellen, um die fehlenden Teile zu schreiben. Diese Liste wurde unter dem Namen Unix Task List bekannt. Zusätzlich zu den fehlenden Unix Komponenten listeten wir verschiedene andere nützliche Software und Dokumentationsprojekte auf, die unserer Meinung nach ein komplettes System haben sollte.
Heute sind kaum noch irgendwelche Unix Komponenten in der GNU Task List übrig -- diese Aufgaben wurden erledigt, außer einigen unwichtigen. Aber die Liste ist voll von Projekten, die man "Applikationen" nennen könnte. Jedes Programm, welches bei mehr als nur einer kleinen Klasse von Benutzern Anklang zu haben scheint, würde ein nützliches Ding zum Hinzufügen zu einem Betriebssystem sein.
Sogar Spiele sind in der Task List enthalten -- und waren es auch schon von Anfang an. Unix enthielt Spiele, also sollte GNU natürlich auch welche enthalten. Kompatibilität war aber kein Kernpunkt bei Spielen, so folgten wir nicht der Liste von Spielen, die Unix hat. Stattdessen listeten wir ein Spektrum von verschiedenen Typen von Spielen auf, welche User mögen könnten.
Die GNU C-Bibliothek nutzt eine spezielle Art von Copyleft, genannt die GNU Library General Public License, welche die Erlaubnis gibt, proprietäre Software gegen die Bibliothek zu linken. Warum machen wir diese Ausnahme?
Es ist keine Sache des Prinzips; es gibt kein Prinzip, welches besagt, dass proprietäre Software berechtigt ist, unseren Code zu enthalten. (Warum zu einem Projekt beisteuern, welches mit uns zu teilen ablehnt?) Die LGPL für die C Bibliothek zu nutzen, oder für jede Bibliothek, ist eine strategische Sache.
Die C-Bibliothek erfüllt eine allgemeine Aufgabe; jedes proprietäre System oder jeder Compiler kommt mit einer C Bibliothek. Daher würde das Verfügbarmachen unserer C-Bibliothek nur für freie Software dieser keine Vorteile bringen -- es würde nur vom Gebrauch unserer Bibliothek abschrecken.
Ein System ist da eine Ausnahme: Im GNU System (und das beinhaltet GNU/Linux) ist die GNU C-Bibliothek die einzige C-Bibliothek. So bestimmen die Bedingungen ihrer Verbreitung, ob es möglich ist, proprietäre Programm für das GNU System zu kompilieren. Es gibt keine ethischen Gründe, proprietäre Applikationen auf einem GNU System zu erlauben, aber strategisch gesehen scheint es, dass das Verbieten dieser eher von der Nutzung des GNU Systems abschrecken würde, als freie Applikationen zu entwickeln.
Darum ist das Benutzen der Library GPL (LGPL, Bibliotheks GPL) eine gute Strategie für die C-Bibliothek. Für andere Bibliotheken muss die strategische Entscheidung individuell getroffen werden. Wenn eine Bibliothek, die eine bestimmte Aufgabe erfüllt und beim Schreiben von bestimmten Typen von Programmen helfen kann, unter der GPL vertrieben wird, ist das ein Weg, anderen Entwicklern freier Software zu helfen, ihnen so eine Vorteil gegenüber proprietärer Software zu geben.
Ziehen wir GNU Readline in Betracht, eine Bibliothek, die entwickelt wurde, um Kommandozeilen-Bearbeitung für die BASH zu ermöglichen. Readline wird unter der gewöhnlichen GNU GPL vertrieben, nicht unter der Bibliotheks-GPL. Das reduziert möglicherweise die Häufigkeit, mit der Readline benutzt wird, aber das ist kein Verlust für uns. In der Zwischenzeit wurde zumindest eine nützliche Applikation zu freier Software gemacht, damit sie Readline nutzen kann und das ist ein wahrer Gewinn für die Gemeinschaft.
Entwickler proprietärer Software haben die Vorteile, die Geld bringt; Entwickler freier Software müssen sich gegenseitig Vorteile verschaffen. Ich hoffe, dass wir eines Tages eine große Sammlung GPL-abgedeckter Bibliotheken haben werden, ohne Parallelen bei proprietärer Software, die nützliche Module bieten und als Bauteile in neuer freier Software dienen und sich zu einem großen Vorteil für zukünftige Entwicklung freier Software summieren.
"Jedes gute Stück Software beginnt damit, dass es ein Entwickler persönlich benötigt", sagt Eric Raymond. Vielleicht passiert das manchmal, aber viele essentielle Stücke der GNU Software wurden entwickelt, um ein komplettes, freies Betriebssystem zu haben. Sie entstanden aus einer Vision und einem Plan, nicht aus einem Impuls heraus.
Wir entwickelten die C-Bibliothek zu Beispiel, weil ein Unix-ähnliches System eine C-Bibliothek braucht, die Bourne-Again Shell (bash), weil ein Unix-ähnliches System eine Shell braucht und GNU tar, weil ein Unix-ähnliches System ein tar Programm braucht. Dasselbe trifft für meine eigenen Programme zu -- den GNU C-Compiler, GNU Emacs, GDB und GNU Make.
Einige GNU Programme wurden entwickelt, um mit spezifischen Bedrohungen unserer Freiheit fertig zu werden. So entwickelten wir gzip, um das Kompressionsprogramm zu ersetzen, welches durch die LZW Patente der Gemeinschaft verloren ging. Wir fanden Leute, um LessTif zu entwickeln und vor kürzerer Zeit starteten wir GNOME und Harmony, um die Probleme bestimmter proprietärer Bibliotheken (siehe unten) anzugehen. Wir entwickeln den GNU Privacy Guard, um beliebte nicht-freie Verschlüsselungs-Software zu ersetzen, denn Nutzer sollten nicht zwischen Datenschutz und Freiheit entscheiden müssen.
Natürlich fing die Arbeit an, für die Leute interessant zu werden, die diese Programme schrieben und viele Features wurden den Programmen von verschiedenen anderen Menschen entsprechend ihren eigenen Bedürfnissen und Interessen hinzugefügt. Aber das ist nicht, weswegen die Programme existieren.
Am Beginn den GNU Projekts stellte ich mir vor, dass wir das ganze GNU System entwickeln und es dann als ganzes freigeben würden. So ist es nicht passiert
Weil jeder Bestandteil des GNU Systems in einem Unix System implementiert wurde, konnte jeder Bestandteil in einem Unix System laufen, lange bevor ein komplettes GNU System existierte. Einige von diesen Programmen wurden beliebt und Nutzer begannen, sie zu erweitern und zu portieren -- auf die verschiedensten inkompatiblen Versionen von Unix und manchmal auch auf andere Systeme.
Dieser Prozess machte diese Programme sehr viel mächtiger und zog sowohl Gelder als auch Mitarbeiter zum GNU Projekt hin. Aber er verzögerte möglicherweise auch die Fertigstellung eines minimalen, arbeitenden Systems um mehrere Jahre, da die Zeit der GNU Entwickler in das Pflegen dieser Portierungen und Hinzufügen neuer Features zu den bestehenden Komponenten hineinfloss, vielmehr als in das Fortsetzen des Schreibens von einer fehlenden Komponente nach der anderen.
Um 1990 war das GNU System fast komplett; die einzige große fehlende Komponente war der Kernel. Wie hatten uns entschieden, unseren Kernel als eine Sammlung von Server-Prozessen zu implementieren, welche über dem Mach laufen. Mach ist ein erst an der Carnegie Mellon Universität und dann an der Universität von Utah entwickelter Mikrokernel. Das GNU HURD ist eine Sammlung von Servern (oder ``herd of gnus'', Herde von Gnus), die über dem Mach laufen und verschiedene Jobs des Unix-Kernels erledigen. Der Start der Entwicklung wurde verschoben, als wir darauf warteten, dass Mach als freie Software herausgegeben werden würde, so wie es versprochen wurde.
Ein Grund, dieses Design auszuwählen, war um zu vermeiden, was als der schwierigste Teil der Arbeit erschien: Ein Kernel-Programm zu debuggen, ohne einen Source-Level-Debugger zu haben, mit dem man es tun konnte. Dieser Teil der Arbeit war bereits erledigt, in Mach, und wir erwarteten die HURD Server als User-Programme zu debuggen, mit GDB. Aber es brauchte lange Zeit, das möglich zu machen und die multi-threaded Server, die sich gegenseitig Nachrichten schicken, erwiesen sich als sehr schwierig zu debuggen. Den HURD zum soliden Arbeiten zu bringen, zog sich über mehrere Jahre hin.
Der GNU Kernel war ursprünglich nicht dazu gedacht, HURD genannt zu werden. Sein ursprünglicher Name war Alix -- genannt nach der Frau, die zu dieser Zeit mein Liebling war. Sie, eine Unix System-Administratorin, wies darauf hin, dass ihr Name in ein verbreitetes Unix-Namensmuster für Systemversionen passen würde. Als ein Witz erzählte sie ihren Freunden, "Jemand sollte einen Kernel nach mir benennen." Ich sagte nichts, aber entschied sie mit einem Kernel namens Alix zu überraschen.
Es blieb nicht dabei. Michael Bushnell (nun Thomas), der Hauptentwickler des Kernels, zog den Namen HURD vor und definierte Alix um als einen speziellen Teil des Kernels, den Teil, der System Calls abfangen und sie durch das Senden von Nachrichten an den Hurd Server handhaben würde.
Letztendlich trennten sich Alix und ich und sie änderte ihren Namen; unabhängig davon wurde das HURD Design geändert, so dass die C-Bibliothek Nachrichten direkt zu den Servern senden würde und das ließ die Alix Komponente aus dem Design verschwinden.
Bevor jedoch diese Dinge passierten, fand ein Freund von ihr den Namen Alix in dem HURD-Quellcode und erwähnte es ihr gegenüber. So erfüllte der Namen seine Aufgabe.
Der GNU Hurd ist nicht bereit für den produktiven Einsatz. Glücklicherweise ist ein anderer Kernel verfügbar. Im Jahr 1991 entwickelte Linus Torvalds einen Unix-kompatiblen Kernel und nannte ihn Linux. Um 1992 resultierte das Kombinieren von Linux mit dem noch nicht ganz fertigen GNU System in einem komplett freien Betriebssystem. (Sie zu kombinieren war natürlich ein beträchtlicher Job für sich.) Es ist Linux zu verdanken, dass wir tatsächlich eine Version des GNU System heutzutage laufen lassen können.
Wir nennen diese Systemversion GNU/Linux, um seine Zusammenstellung als eine Kombination von dem GNU System mit Linux als Kernel auszudrücken.
Wir haben unsere Fähigkeit bewiesen, ein breites Spektrum von freier Software zu entwickeln. Das bedeutet nicht, dass wir unbesiegbar und nicht zu stoppen sind. Verschiedene Herausforderungen machen die Zukunft von freier Software unsicher. Sie anzunehmen wird unerschütterliche Anstrengungen und Ausdauer nötig machen, manchmal für Jahre. Es wird die Art von Entschlossenheit brauchen, die Menschen zeigen, wenn sie ihre Freiheit schätzen und sie sich von niemanden wegnehmen lassen wollen.
Die folgenden vier Abschnitte diskutieren diese Herausforderungen.
Hardware-Hersteller tendieren zunehmend dazu, Hardware-Spezifikationen geheim zu halten. Das macht es schwierig, freie Treiber zu schreiben, so dass Linux und XFree86 neue Hardware unterstützen können. Wir haben heute komplette, freie Systeme, aber wir werden sie morgen nicht mehr haben, wenn wir Computer von morgen nicht unterstützen können.
Es gibt zwei Wege mit diesem Problem fertig zu werden. Programmierer können reverse engineering betreiben, um herauszufinden, wie die Hardware zu unterstützen ist. Der Rest von uns kann die Hardware wählen, die von freier Software unterstützt wird; mit der steigenden Anzahl von uns wird das Geheimhalten der Spezifikationen eine sich selbst begrenzende Politik.
Reverse Engineering ist eine große Aufgabe; werden wir Programmierer mit ausreichend Entschlossenheit haben, um es zu übernehmen? Ja -- wenn wir ein starkes Gefühl dafür entwickeln, das freie Software eine Sache von Prinzipien ist und nicht-freie Treiber unerträglich sind. Und wird ein großer Teil von uns extra Geld oder sogar ein wenig extra Zeit aufwenden, so dass wir freie Treiber nutzen können? Ja, wenn die Entschlossenheit, Freiheit zu haben, sich verbreitet.
Eine nicht-freie Bibliothek, die auf einem freien Betriebssystem läuft, verhält sich wie ein Falle für Entwickler freier Software. Die attraktiven Features der Bibliothek sind der Köder, wenn man die Bibliothek nutzt, fällt man in die Falle, weil das Programm nicht Teil eines freien Betriebssystems sein kann. (Strenggenommen könnten wir unser Programm einschließen, aber es würde nicht laufen ohne die Bibliothek.) Noch schlimmer wäre es, wenn ein die Bibliothek nutzendes Programm sehr beliebt würde, es kann andere ahnungslose Programmierer in die Falle ködern.
Das erste Beispiel dieses Problems war das Motif Toolkit, damals in den 80ern. Obwohl es bis dahin kein freies Betriebssystem gab, war klar, welche Probleme Motif für ein solches später verursachen würde. Das GNU Projekt antwortete auf zwei Arten: es fragte bei individuellen Projekten freier Software nach der Unterstützung von freien X Toolkit Widgets ebenso wie die von Motif und indem es nach jemandem suchte, der einen freien Ersatz für Motif schreiben würde. Diese Aufgabe brauchte mehrere Jahre; LessTif, entwickelt von den ungarischen Programmierern, wurde erst 1997 mächtig genug, um die meisten Motif Applikationen zu unterstützen.
Zwischen 1996 und 1998 wurde eine andere nicht freie GUI Toolkit Bibliothek, genannt Qt, in einer umfangreichen Sammlung freier Software, KDE genannt, genutzt.
Freie GNU/Linux Systeme waren nicht in der Lage, KDE zu nutzen, weil wir die Bibliothek nicht nutzen konnten. Wie auch immer, einige kommerzielle Distributoren von GNU/Linux Systemen, die nicht so streng bei ausschließlich freier Software blieben, nahmen KDE zu ihren Systemen hinzu -- produzierten so ein System mit mehr Möglichkeiten, aber weniger Freiheit. Die KDE Gruppe ermutigte aktiv mehr Programmierer, Qt zu nutzen, und Millionen von "Linux Nutzern" wurde niemals die Idee enthüllt, das es dabei ein Problem gab. Die Situation war makaber.
Die freie Software Gemeinschaft reagierte auf das Problem auf zwei Arten: GNOME und Harmony
GNOME, die GNU Netzwerk Objekt Modell Umgebung (GNU Network Object Model Environment), ist GNUs Desktop Projekt. Gestartet 1997 von Miguel de Icaza und mit der Unterstützung von Red Hat Software, machte sich GNOME auf den Weg, ähnliche Desktop Möglichkeiten exklusiv für die freie Software Gemeinschaft anzubieten. Es hat auch technische Vorteile, wie die Unterstützung von einer Vielzahl von Sprachen, nicht nur C++. Aber sein Hauptzweck war Freiheit: Nicht zu erfordern, dass man irgendwelche unfreie Software nutzt.
Harmony ist eine kompatible Ersatzbibliothek, entwickelt um es möglich zu machen, KDE Software ohne Qt zu nutzen.
Im November 1998 kündigten die Entwickler von Qt eine Änderung der Lizenz an, welche, wenn durchgesetzt, Qt zu freier Software machen sollte. Es gibt keine Möglichkeit, da sicher zu sein, aber ich denke, dass das zum Teil auch durch die standhafte Reaktion der Gemeinschaft auf das Problem durch das Nicht-Frei-Sein von Qt verursacht wurde. (Die neue Lizenz ist ungeeignet und ungerecht, so bleibt es wünschenswert, den Gebrauch 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 werden wir auf die nächste verführerische unfreie Bibliothek reagieren? Wird die gesamte Gemeinschaft die Notwendigkeit, nicht in die Falle zu gehen, verstehen? Oder werden viele von uns die Freiheit für Bequemlichkeit aufgeben und so ein großes Problem erschaffen? Unsere Zukunft hängt von unserer Philosophie ab.
Die schlimmste Bedrohung, der wir uns gegenübergestellt sehen, kommt von Software-Patenten, welche Algorithmen und Features der freien Software Gemeinschaft für bis zu zwanzig Jahre entziehen. Das LZW Kompressionsverfahren Algorithmus - Patent wurde 1983 beantragt und wir können noch immer keine freie Software herausgeben, um korrekt komprimierte GIFs zu erzeugen. Ein Programm, um MP3 komprimierten Ton zu produzieren, wurde 1998 von unserer Distribution unter Androhung eines Rechtsstreites entfernt.
Es gibt Wege, mit Patenten fertig zu werden: Wir können nach Beispielen suchen, dass ein Patent ungültig ist und wir können nach alternativen Möglichkeiten suchen, eine Aufgabe zu lösen. Beide Möglichkeiten funktionieren aber nur manchmal; wenn beide versagen, kann ein Software Patent freie Software zu einem Mangel einiger Features zwingen, welche die Nutzer aber wollen. Was werden wir tun, wenn das passiert?
Jene von uns, die freie Software der Freiheit wegen schätzen, werde so oder so bei freier Software bleiben. Wir werden es hinbekommen, Arbeit auch ohne die patentierten Features zu erledigen. Aber jene, die freie Software schätzen, weil sie diese als technisch überlegen erwarten, werden es als ein Versagen betrachten, wenn ein Patent es verhindert. Daher, während es nützlich ist, über die praktische Effektivität des "Dom" Modells ("cathedral" model) der Entwicklung (1) und die Verlässlichkeit und Macht freier Software zu reden, dürfen wir nicht dort anhalten. Wir müssen über Freiheit und Prinzipien sprechen.
Das größte Defizit in unserem freien Betriebssystem ist nicht in der Software -- es ist der Mangel von guten freien Anleitungen, die wir in unsere Systeme einschließen können. Dokumentation ist ein essentieller Teil jedes Software-Paketes; wenn ein wichtiges freies Softwarepaket nicht mit einer guten freien Anleitung kommt, dann ist das eine große Lücke. Wir haben heute viele solcher Lücken.
Freie Dokumentation, wie freie Software, ist eine Sache der Freiheit, nicht des Preises. Die Kriterien für eine freie Anleitung sind so ziemlich die gleichen wie für freie Software: Es ist die Angelegenheit, allen Nutzern gewisse Freiheiten zu geben. Neue Verteilung (einschließlich kommerziellem Verkaufs) muss erlaubt sein, online und auf Papier, so dass die Anleitung jede Kopie des Programms begleiten kann.
Die Erlaubnis für Modifikationen ist auch entscheidend. Als einen generellen Maßstab, glaube ich nicht, dass es für die Leute wichtig ist, jede Art von Artikeln und Büchern modifizieren zu dürfen. Zum Beispiel denke ich nicht, dass du oder ich gezwungen sind, die Erlaubnis zu geben, Artikel wie diesen zu modifizieren, welcher unsere Handlungen und Sichtweisen beschreibt.
Es gibt aber einen bestimmten Grund, warum die Freiheit zur Veränderung entscheidend für die Dokumentation freier Software ist. Wenn Leute ihre Rechte zur Veränderung der Software wahrnehmen, und Features ändern oder hinzufügen und wenn sie gewissenhaft sind, werden sie auch die Anleitung ändern -- so dass sie eine akkurate und nutzbare Dokumentation mit dem veränderten Programm bieten können. Eine Anleitung, die Programmierern nicht erlaubt, gewissenhaft zu sein und den Job zu beenden, erfüllt nicht den Bedarf der Gemeinschaft.
Einige Arten von Grenzen, wie Modifikationen gemacht werden können, werden festgelegt und werfen keine Probleme auf. Zum Beispiel die Anforderung, die originale Copyright-Notiz des Autors zu erhalten, die Vertriebsbedingungen, oder die Liste von Autoren, sind okay. Es ist auch kein Problem, in modifizierten Versionen einen Hinweis zu erzwingen, dass sie modifiziert wurden, ebenso wie ganze Abschnitte vor dem Löschen oder Verändern zu schützen, solange es sich um nicht-technische Dinge handelt. Diese Begrenzungen sind kein Problem, weil sie den gewissenhaften Programmierer nicht davon abhalten, die Anleitung an das veränderte Programm anzupassen. In anderen Worten, sie verhindern nicht, dass die freie Software Gemeinschaft vollen Nutzen aus den Anleitungen zieht.
Es muss jedoch möglich sein, all die *technischen* Inhalte der Anleitung zu ändern und dann das Ergebnis mit allen gebräuchlichen Medien zu vertreiben, durch die gewöhnlichen Kanäle; andernfalls sperren die Begrenzungen die Gemeinschaft aus, die Anleitung ist nicht frei und wir brauchen eine andere.
Werden freie Software Entwickler das Bewusstsein und die Entschlossenheit haben, um ein volles Spektrum an freien Anleitungen zu produzieren? Einmal mehr hängt die Zukunft von unserer Philosophie ab.
Heutige Schätzungen sind, dass es zehn Millionen Nutzer von GNU/Linux Systemen wie Debian GNU/Linux und Red Hat Linux gibt. Freie Software hat so einen praktischen Vorteil entwickelt, das die Nutzer ihr nur der rein praktischen Gründe wegen zuströmen.
Die guten Konsequenzen daraus sind klar ersichtlich: Mehr Interesse an der Entwicklung freier Software, mehr Kunden für das Geschäft mit freier Software und mehr Fähigkeiten, Firmen zu ermutigen, kommerzielle, freie Software zu entwickeln, anstatt proprietärer Software Produkte.
Das Interesse an der Software aber wächst schneller als das Bewusstsein der Philosophie, auf der sie basiert und das führt zu Problemen. Unsere Möglichkeiten, den weiter oben beschriebenen Herausforderungen und Bedrohungen zu entsprechen, hängen vom Willen, fest für Freiheit zu stehen, ab. Um sicher zu machen, dass unsere Gemeinschaft diesen Willen hat, ist es nötig, die Idee unter den neuen Nutzern zu verbreiten, wenn sie in die Gemeinschaft kommen.
Wir aber versagen dabei: Die Anstrengungen, neue Nutzer in unsere Gemeinschaft zu holen, überflügeln bei weitem die Anstrengungen, ihnen die Pflichten unserer Gemeinschaft zu lehren. Wir müssen beides machen und wir müssen beide Anstrengungen im Gleichgewicht halten.
Neuen Nutzern etwas über Freiheit beizubringen wurde 1998 schwieriger, als ein Teil der Gemeinschaft aufhörte, den Term "freie Software" zu nutzen und stattdessen "Open Source Software" (Quelloffene Software) sagte.
Einige, die diesen Ausdruck bevorzugten, zielten darauf ab, die Verwirrung von "frei" mit "gratis" zu vermeiden -- ein zulässiges Ziel. Andere jedoch zielten darauf ab, den Geist der Prinzipien ins Abseits zu drängen, welcher die freie Software Bewegung motiviert hatte und stattdessen eine Anziehungskraft auf Führungskräfte und geschäftliche Nutzer zu bewirken. Viele von ihnen haben eine Ideologie, welche Profit über Freiheit, über die Gemeinschaft, über Prinzipien stellt. Daher fokussiert die Rhetorik von "Open Source" auf das Potenzial, hoch qualitative, mächtige Software zu machen, aber weicht den Ideen von Freiheit, Gemeinschaft und Prinzipien aus.
Die "Linux" Magazine 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 werden sie Werbung dafür machen?
Die Unterstützung des Geschäfts kann zur Gemeinschaft auf viele Arten etwas beitragen; alle sind gleichwertig, es ist nützlich. Aber ihre Unterstützung zu gewinnen, indem man schlecht über Freiheit und Prinzipien spricht, kann katastrophal sein; es macht das vorherige Ungleichgewicht zwischen Hinausragen und der Aufklärung über gemeinschaftliche Pflichten noch schlimmer.
"Freie Software" und "Open Source" beschreiben dieselbe Kategorie von Software, mehr oder weniger, aber sagen verschiedene Dinge über die Software und über Werte. Das GNU Projekt fährt fort, den Term "freie Software" zu nutzen, um die Idee auszudrücken, dass Freiheit, nicht bloß Technologie, wichtig ist.
Yoda's Philosophie ("Es gibt kein `Versuchen'") klingt nett, aber für mich funktioniert es nicht. Ich habe das meiste meiner Arbeit gemacht, während ich besorgt war, ob ich den Job erledigen kann und unsicher war, dass es genug wäre, wenn ich das Ziel erreiche. Aber ich habe es trotzdem versucht, weil keiner außer mir zwischen dem Feind und meiner Stadt war. Mich selbst überraschend, habe ich es manchmal geschafft.
Manchmal habe ich versagt; einige meiner Städte sind gefallen. Dann habe ich eine andere bedrohte Stadt gefunden und machte mich für eine weitere Schlacht bereit. Im Laufe der Zeit lernte ich, nach Bedrohungen Ausschau zu halten und mich selbst zwischen sie und meine Stadt zu stellen, andere Hacker rufend, dass sie kommen und sich mir anschließen.
Heutzutage bin ich oft nicht der einzige. Es ist eine Erleichterung und eine Freude, wenn ich ein Regiment von Hackern sehe, die sich eingraben, um die Stellung zu halten und ich erkenne, diese Stadt kann überleben -- im Moment. Aber die Gefahren werden jedes Jahr größer und nun hat Microsoft ausdrücklich auf unsere Gemeinschaft gezielt. Wir können die Zukunft der Freiheit nicht als garantiert ansehen. Nimm es nicht als garantiert an! Wenn du deine Freiheit behalten willst, musst du darauf vorbereitet sein, sie zu verteidigen.
Zurück zu GNU's Home Page.
Bitte senden Sie FSF & GNU & Fragen an gnu@gnu.org. Es gibt auch andere Kontaktmöglichkeiten zur FSF.
Bitte senden Sie Kommentare zu diesen Web-Seiten an webmasters@gnu.org, senden Sie andere Fragen an gnu@gnu.org.
Copyright (C) 1998, 2001 Richard Stallman.
Übersetzt 2003 von Stephan Knuth (sknu(bitte nicht zuspammen)[at]gmx.de)
Wörtliches Kopieren und Verbreiten des ganzen Artikels ist auf jedem Medium erlaubt, solange diese Notiz enthalten ist.
Aktualisiert: $Date: 2007/02/07 02:35:10 $ $Author: mattl $