Het GNU-project

door Richard Stallman

Gepubliceerd in het boek Open Sources. Richard Stallman was nooit een voorstander van “open source”, maar droeg bij met dit artikel zodat het gedachtegoed van de vrije-softwarebeweging niet zouden ontbreken in dit boek.

Waarom het belangrijker is dan ooit om aan te dringen op het gebruik van vrije software.

De eerste software-delende gemeenschap

Toen ik mijn loopbaan begon aan het Laboratorium van Kunstmatige Intelligentie aan het MIT in 1971, werd ik opgenomen in een software-delende gemeenschap die al jaren bestond. Het delen van software was niet voorbehouden aan onze eigen gemeenschap; het is al zo oud als de computer, net als het uitwisselen van recepten zo oud is als koken. Maar wij deden het meer dan de meesten.

Het Laboratorium voor Kunstmatige Intelligentie (KI lab.) gebruikte een timesharing besturingssysteem met de naam ITS (het ‘Incompatibele Timesharing Systeem’) dat hackers (1) onder het laboratoriumpersoneel hadden ontworpen en geschreven in assembleer taal voor de PDP-10 van Digital, één van de grote computers uit die tijd. Als lid van deze gemeenschap, een hacker van het KI lab., was het mijn taak dit systeem te verbeteren.

We noemden onze software geen “vrije software”, omdat die term nog niet bestond; maar dat was het. Telkens wanneer mensen van een andere universiteit of bedrijf een programma wilde vertalen en gebruiken voor een ander platform, lieten we ze met plezier hun gang gaan. Als je iemand een onbekend en interessant programma zag gebruiken, kon je altijd vragen om de bron code zodat je het kon lezen, veranderen, en er stukken uit slopen om een nieuw programma te maken.

(1) Het gebruik van het woord “hacker” in de betekenis van “digitale inbreker” is een fout van de media. Wij hackers weigeren deze betekenis te accepteren, en gaan door met de originele betekenis “Iemand die van programmeren houdt en/of er plezier in heeft er goed in te zijn”. Zie ook mijn artikel: On Hacking.

Het instorten van de gemeenschap

De situatie veranderde drastisch aan het begin van de jaren 80 toen Digital stopte met de PDP-10 serie. Deze architectuur, elegant en krachtig in de jaren zestig kon niet meekomen met de grotere adres ruimtes die mogelijk werden in de tachtiger jaren. Dit betekende dat bijna alle programma's voor ITS verouderd waren.

De gemeenschap van KI Lab hackers was kort daarvoor al ingestort. In 1981 had het spin-off bedrijf Symbolics bijna alle hackers van het KI lab. ingehuurd, en de uitgedunde gemeenschap kon zichzelf niet in stand houden. (Het boek Hackers, van Steve Levy, beschrijft deze gebeurtenissen, en geeft een helder beeld van deze gemeenschap op haar hoogtepunt). Toen het KI lab. de nieuwe PDP-10 kocht in 1982 besloten de beheerders om het private timesharing systeem van Digital te gebruiken, in plaats van ITS.

De moderne computers uit die tijd, zoals de VAX of de 68020 hadden hun eigen besturingssystemen, maar geen van deze was vrije software: je moest een geheimhoudingsplicht ondertekenen om zelfs maar een gecompileerde kopie te krijgen.

Dit betekende dat de eerste stap om een computer te kunnen gebruiken was, om te beloven dat je je buurman niet zou helpen. Een samenwerkende gemeenschap werd verboden. De regel, opgesteld door eigenaren van private software was, “Als u uw software deelt met uw buurman, bent u een piraat. Als u veranderingen wilt in een programma, smeek ons er dan om.”

Het idee dat het systeem van private software—dat voorschrijft dat u geen software mag veranderen of delen—asociaal is, of onethisch, of zelfs simpelweg fout, kan als een verassing komen voor sommige lezers. Maar welk ander oordeel kunnen we vellen over een systeem gebaseerd op het verdeel- en heers-principe waarbij gebruikers machteloos worden gemaakt? Lezers die dit idee verbaast, hebben misschien het systeem van private software als een gegeven beschouwd, of klakkeloos de zienswijze van private softwarebedrijven overgenomen. Softwarebedrijven hebben tenslotte lang en hard gewerkt om mensen te overtuigen dat er maar één manier is om naar deze zaak te kijken.

Als software uitgevers praten over “handhaving” van hun “rechten” of het “stoppen van piraterij”; is wat ze zeggen maar bijzaak. De echte boodschap in deze uitspraken zijn de impliciete aannames die ze maken, en van de maatschappij wordt verwacht dat ze dit klakkeloos overnemen. Laten we die aannames eens aan een onderzoek onderwerpen.

Aangenomen wordt dat softwarebedrijven een onaantastbaar natuurlijk recht hebben om software te bezitten, en daarmee macht te hebben over alle gebruikers. (Als dit daadwerkelijk zo was, dan zouden we hier geen bezwaar tegen kunnen maken, hoe schadelijk die situatie ook is voor de maatschappij.) Opvallend is dat de Grondwet en justitiële traditie van de VS deze uitleg verwerpen; auteursrecht is geen natuurlijk recht, maar een kunstmatig door de overheid in stand gehouden monopolie, dat het natuurlijk gebruikersrecht om te kopiëren aan banden legt.

Een andere stilzwijgende aanname is dat het enige belangrijke aan software is wat je er mee kunt doen—dat wij computergebruikers niet maatschappelijk betrokken zouden mogen zijn.

Een derde aanname is dat wij geen bruikbare software zouden hebben (of nooit een programma zouden hebben dat deze of gene bepaalde taak doet) als we een bedrijf geen macht over de gebruikers van het programma zouden geven. Dit leek een geloofwaardige aanname, voordat de vrije-softwarebeweging aantoonde dat wij meer dan genoeg bruikbare software kunnen maken, zonder het aan de ketting te leggen.

Wanneer wij deze aannames verwerpen, en de zaak beoordelen met ons gezond -moreel- verstand en we plaatsen de gebruikers op de eerste plaats, dan komen we tot hele andere conclusies. Computergebruikers zouden vrij moeten zijn om programma's aan te passen aan hun behoeften, om de software vrij met elkaar te delen, omdat andere mensen helpen de basis van een maatschappij is.

Dit stuk wordt te lang met een uitgebreide verhandeling over de motivatie achter deze conclusie, dus ik verwijs de lezer door naar deze pagina's: http://www.gnu.org/philosophy/why-free.html en http://www.gnu.org/philosophy/free-software-even-more-important.html.

Een duidelijke morele keuze

Nu mijn gemeenschap verdwenen was, kon ik niet op de oude voet doorgaan. In plaats daarvan werd ik geconfronteerd met een scherpe morele keuze.

De makkelijke weg was om me aan te sluiten bij de private software wereld, geheimhoudingsplichten te ondertekenen en te beloven mijn mede-hacker niet te helpen. Hoogstwaarschijnlijk zou ik dan ook software gaan ontwikkelen die onder geheimhoudingsplicht zou worden gepubliceerd, en zo de druk verhogen op andere mensen om ook hun medemens te verraden.

Ik had op deze manier geld kunnen verdienen, en wellicht mezelf kunnen amuseren met het schrijven van code. Maar ik wist dat ik aan het einde van mijn loopbaan zou terugkijken op een leven waarin ik muren tussen mensen had opgebouwd die mensen verdelen, en het gevoel zou hebben dat ik mijn leven in dienst gesteld zou hebben van het verergeren van de toestand in de wereld.

Ik had al ervaring opgedaan aan de verkeerde kant van een geheimhoudingsplicht, toen iemand mij en het MIT KI Lab weigerde ons de broncode van het stuurprogramma voor onze printer te geven. (Het gebrek aan bepaalde mogelijkheden van dit programma maakte het gebruik van de printer uitermate frustrerend.) Dus ik kon mezelf niet wijsmaken dat geheimhoudingsplichten onschuldig waren. Ik werd erg kwaad toen hij weigerde met ons te delen; ik kon mezelf niet verloochenen en anderen hetzelfde aandoen.

Een andere keuze, simpel maar onprettig, was om de computer wereld vaarwel te zeggen. Op die manier zouden mijn vaardigheden niet worden misbruikt, maar ze zouden wel weggegooid worden. Ik zou niet aangeklaagd kunnen worden voor het verdelen en beperken van computergebruikers, maar dat zou zonder mij toch wel gebeuren.

Dus ik zocht naar een manier waarop een programmeur toch iets goeds kon doen. Ik vroeg mezelf af of er een programma was dat ik zou kunnen schrijven, zodat een gemeenschap weer opnieuw mogelijk werd?

Het antwoord was duidelijk: ten eerste was er een besturingssysteem nodig. Dit is cruciale software voor het gebruik van een computer. Met een besturingssysteem worden vele mogelijkheden gerealiseerd; zonder is een computer volkomen onbruikbaar. Met een vrij besturingssysteem zouden we opnieuw een gemeenschap van samenwerkende hackers hebben—en iedereen kunnen uitnodigen om zich aan te sluiten. En iedereen zou een computer kunnen gebruiken, zonder mee te hoeven doen aan een samenzwering die haar of zijn vrienden uitsluit.

Als ontwikkelaar van besturingssystemen had ik de juiste vaardigheden. Dus hoewel succes niet verzekerd was realiseerde ik me dat ik dit werk zou moeten doen. Ik koos ervoor om het systeem uitwisselbaar te maken met Unix, zodat het overgezet kon worden naar andere computers en Unix gebruikers makkelijk over konden stappen. De naam GNU volgde uit de hackertraditie van recursieve afkortingen: “GNU's Not Unix” (GNU is geen Unix). Het wordt uitgesproken als knoe, als één lettergreep met een zachte k.

Een besturingssysteem bestaat niet alleen uit een kernel, net genoeg om andere programma's te draaien. In de jaren zeventig bevatte ieder zichzelf respecterend besturingssysteem commando-uitvoerprogramma's, assembleerders, compilers, interpreters, debuggers, tekstverwerkers, emailprogramma's, en nog veel meer. ITS had ze, Multics had ze, VMS had ze, en Unix had ze. Het GNU-besturingssysteem zou ze ook hebben.

Later hoorde ik deze woorden, toegeschreven aan Hillel (1):

Als ik niet voor mezelf ben, wie zal dan voor mij zijn?
Als ik alleen voor mezelf ben, wat ben ik dan?
Wanneer niet nu, wanneer dan?

De beslissing om te starten met het GNU-project is hierop geïnspireerd.

(1) Als atheïst volg ik geen religieuze leiders, maar soms ontdek ik dat ik iets bewonder wat sommige van ze hebben gezegd.

Vrij als in vrijheid

De term “vrije software” wordt soms verkeerd opgevat—het heeft niets met prijs te maken. Het gaat om vrijheid (het Engelse “free” kan zowel vrij als gratis betekenen, vandaar deze uitleg). Daarom hier de definitie van vrije software.

Een programma kun je vrije software noemen, voor jou als gebruiker, wanneer:

• Je hebt de vrijheid het programma uit te voeren, voor welk doel dan ook.
• Je de vrijheid hebt het programma aan te passen aan je behoeften. (Om deze vrijheid effectief te laten zijn moet je toegang hebben tot de broncode, omdat veranderingen aanbrengen in een programma zonder broncode bijzonder moeilijk is.)
• Je de vrijheid hebt om kopieën te verspreiden, gratis of tegen betaling.
• Je de vrijheid hebt om aangepaste versies van het programma te verspreiden, zodat je verbeteringen de gemeenschap ten goede komen.

Omdat “vrij” hier slaat op vrijheid, niet de prijs, is er geen tegenstelling tussen het verkopen van kopieën en vrije software. In feite is de vrijheid om kopieën te verkopen cruciaal: een verzameling vrije software, verkocht op CD-ROMs, zijn belangrijk voor de gemeenschap, en de verkoop is een belangrijke manier om geld in te zamelen voor vrije software ontwikkeling. Daarom is een programma dat mensen niet bij zo'n verzameling kunnen voegen geen vrije software.

Vanwege de dubbelzinnigheid van “free”, zijn mensen al lang op zoek naar alternatieven, maar niemand heeft er nog een gevonden. De Engelse taal heeft meer woorden en nuances dan iedere andere taal, maar het mist een simpel ondubbelzinnig wordt dat “vrij” betekent, als in vrijheid—“ongeketend” is het woord dat er het dichtst bij komt. Alternatieven als “bevrijd”, “vrijheid”, en “open” hebben ofwel de verkeerde betekenis of een ander nadeel.

GNU-software en het GNU-systeem

Het bouwen van een heel systeem is een groot project. Om het haalbaar te maken besloot ik bestaande vrije software in te passen waar mogelijk. Voorbeeld: ik besloot helemaal aan het begin om TeX als belangrijkste tekstzetter te gebruiken; een paar jaar later besloot ik het X Window Systeem te gaan gebruiken in plaats van opnieuw een venstersysteem te schrijven voor GNU.

Vanwege deze en andere beslissingen is het GNU-systeem niet hetzelfde als de collectie van alle GNU-software. Het GNU-systeem omvat programma's die geen GNU-software zijn: programma's die werden ontwikkeld door anderen - projecten met hun eigen drijfveren - maar die we kunnen gebruiken omdat ze vrije software zijn.

Start van het project

In januari 1984 nam ik ontslag bij MIT en begon GNU-software te schrijven. MIT verlaten was nodig zodat MIT geen vinger achter de distributie van GNU als vrije software kon krijgen. Als ik daar was gebleven als staflid, zou MIT het eigendom van het werk kunnen opeisen, en haar eigen voorwaarden voor distributie kunnen opdringen, of het werk zelfs in private software kunnen veranderen. Ik had geen zin om een grote hoeveelheid werk te verzetten, alleen maar om het te zien veranderen in iets tegengesteld aan het doel: het creëren van een nieuwe software-delende gemeenschap.

Professor Winston echter, destijds hoofd van het MIT KI Lab, was zo vriendelijk me uit te nodigen om gebruik te blijven maken van de faciliteiten van het lab.

De eerste stappen

Kort voor aanvang van het GNU-project hoorde ik over de Vrije Universiteit Compiler Kit, ook wel bekend als VUCK. Dit was een compiler geschreven voor meerdere programmeertalen, zoals C en Pascal, en ondersteunde meerdere machines. Ik schreef naar de auteur met de vraag of GNU het mocht gebruiken.

Hij antwoordde bot met de mededeling dat de universiteit vrij was, maar niet de compiler. Daarom besloot ik dat mijn eerste programma voor het GNU-project een compiler voor meerdere talen en platformen zou worden.

In de hoop niet de hele compiler zelf te hoeven schrijven kwam ik in het bezit van de bron code voor de Pastel-compiler, een compiler voor meerdere platformen, ontwikkeld bij het Lawrence Livermore Laboratorium. Het ondersteunde en was geschreven in een uitgebreide versie van Pascal, ontwikkeld als systeem-programmeertaal. Ik voegde er een C front-end aan toe, en begon het aan te passen aan de Motorola 68000 computer. Maar dit moest ik opgeven toen ik ontdekte dat de compiler vele megabytes aan stackruimte nodig had, en het 68000 Unix systeem maar 64k had.

Ik realiseerde me toen dat de Pastel-compiler functioneerde door het hele invoer bestand om te zetten in een syntax-boom, dan de hele syntax-boom omzette in een lijst “instructies”, om daarna het hele uitvoerbestand te genereren, zonder ooit geheugenruimte vrij te geven. Op dat moment besefte ik dat ik een nieuwe compiler vanaf de grond zou moeten opbouwen. Die nieuwe compiler staat nu bekend als GCC; niets van de Pastel compiler is er voor gebruikt, maar ik was in staat het eerder geschreven C front-end aan te passen en erin te verwerken. Maar dat was enkele jaren later; eerst werkte ik aan GNU Emacs.

GNU Emacs

I begon het werk aan GNU Emacs in September 1984, begin 1985 begon het bruikbaar te worden. Hierdoor werd het mogelijk voor mij om bestanden te schrijven op Unix systemen; ik had geen zin om het gebruik van vi of ed te leren, en had mijn schrijfwerk tot nog toe op andere machines gedaan.

Op dat punt wilden mensen GNU Emacs gaan gebruiken, hierdoor kwam de vraag op hoe te distribueren. Uiteraard zette ik het op de anonieme ftp server van de MIT computer die ik gebruikte. (Deze computer, prep.ai.mit.edu werd zodoende de hoofd GNU ftp distributiewebsite; toen het na enkele jaren buiten gebruik werd gesteld, namen we de naam over naar onze nieuwe ftp server.) Maar toentertijd hadden geïnteresseerden geen Internet toegang en konden geen kopie per ftp krijgen. De vraag was dus, wat had ik ze te vertellen?

Ik zou hebben kunnen zeggen “Zoek een kennis die op het net zit die een kopie voor je kan maken.” Of ik had hetzelfde kunnen doen als ik heb gedaan met de originele PDP-10 Emacs: tegen ze zeggen, “Stuur me een tape en een aan jezelf geadresseerde envelop, dan stuur ik het terug met Emacs erop.” Maar ik had geen werk, en zocht manieren om geld te verdienen met vrije software. Daarom verklaarde ik dat ik een tape met Emacs voor een vergoeding van $150 op zou sturen naar wie het maar wilde hebben. Op deze manier begon ik de vrije-software-business, een voorloper van de bedrijven die vandaag de dag hele GNU/Linux-systemen distribueren.

Is een programma vrij voor iedere gebruiker?

Wanneer een programma vrije software is als het de handen van de auteur verlaat wil dat nog niet zeggen dat het vrije software is voor iedereen die er een kopie van heeft. Voorbeeld: publiek domein software (software zonder auteursrecht) is vrije software; maar iedereen kan er een private, aangepaste versie van maken. Ook hebben veel programma's een auteursrecht, maar worden ze onder een simpele licentie verspreidt, die veel toestaat, waaronder private, aangepaste versies.

Het archetypische voorbeeld van dit probleem is het X Window systeem. Ontwikkeld door MIT, en vrijgegeven als vrije software met een licentie die veel toelaat, werd het snel overgenomen door verschillende computerbedrijven. Zij voegden X toe aan hun private Unix systemen, exclusief in binaire vorm en onder dezelfde geheimhoudingsplicht. Deze kopieën van X waren net zo min vrij als Unix was.

De ontwikkelaars van het X Window systeem vonden dit geen probleem—ze verwachten en wilden dat het gebeurde. Hun doel was niet vrijheid, enkel “succes”, als in “veel gebruikers”. Het kon ze niet schelen of de gebruikers vrijheid hadden, alleen dat het er veel zouden zijn.

Dit leidde tot de paradoxale situatie dat twee verschillende manieren om de hoeveelheid vrijheid te meten, verschillende antwoorden gaven op de vaag “Is dit programma vrij?”. Als je het beoordeelde op basis van de vrijheden die de MIT publicatie toeliet, zou je zeggen dat X vrije software was. Maar als je het zou meten aan de vrijheid van de gemiddelde gebruiker van X, zou je zeggen dat het private software was. De meeste X gebruikers gebruikten de private versie die gebundeld was met Unix systemen, niet de vrije versie.

Auteursplicht en de GNU GPL

Het doel van GNU was om gebruikers vrijheid te geven, niet om slechts populair te zijn. We hadden dus distributievoorwaarden nodig die zouden voorkomen dat GNU software in private software zou veranderen. De methode die we gebruiken heet “auteursplicht”(1) (of op zijn Engels: “copyleft”)

Auteursplicht gebruikt het auteursrecht, maar draait het om zodat het tegendeel van het gewoonlijke doel wordt gediend: in plaats van een methode om software te privatiseren, wordt het een middel om software vrij te houden.

Het idee van auteursplicht is dat we iedereen toestaan het programma te draaien, te kopiëren, aan te passen, en aangepaste versies te distribueren—maar niet toestaan om eigen beperkingen toe te voegen. De cruciale vrijheden die “vrije software” definiëren worden daarom gegarandeerd aan iedereen die een kopie heeft; het worden onvervreemdbare rechten.

Voor een effectieve auteursplicht moeten aangepaste versies ook vrij zijn. Zo wordt werk gebaseerd op dat van ons toegankelijk voor onze gemeenschap als het wordt gepubliceerd. Wanneer programmeurs, die banen hebben als programmeur vrijwillig GNU software verbeteren, voorkomt de auteursplicht dat hun werkgever zegt, “Jij kunt die veranderingen niet delen, omdat we ze gaan gebruiken voor onze private versie van het programma.”

De eis dat veranderingen vrij moeten zijn, is essentieel als we de vrijheid van iedere gebruiker willen beschermen. De bedrijven die het X Window systeem privatiseerden pasten het gewoonlijk aan aan hun systemen en hardware. Deze veranderingen waren klein vergeleken met het grote X project, maar ze waren niet triviaal. Als het aanbrengen van veranderingen als excuus kan gelden om gebruikers van hun vrijheid te beroven, zou het voor iedereen makkelijk zijn met dit excuus hun eigen voordeel te doen.

Een aanverwant probleem is het combineren van een vrij programma met niet vrije code. Zo'n combinatie is onvermijdelijk niet vrij; de vrijheden die ontbreken in het niet vrije gedeelte zouden in het geheel ook ontbreken. Dergelijke combinaties toestaan zou een gat openen, groot genoeg om een schip in te zinken. Daarom is het een cruciale eis voor auteursplicht dit gat te dichten: wat aan het auteursplichtige programma wordt toegevoegd of er mee wordt gecombineerd, moet zorgen dat de grotere gecombineerde versie ook vrij en auteursplichtig is.

De specifieke implementatie van auteursplicht die we voor de meeste GNU-software gebruiken is de GNU General Public License (“GNU Algemene Publieke Licentie”, nvdv). We hebben andere soorten auteursplicht die worden gebruikt in speciale omstandigheden. GNU handleidingen worden ook auteursplichtig, maar gebruiken een veel eenvoudiger vorm, omdat de gecompliceerdheid van de GNU GPL onnodig is voor handleidingen.(2)

(1) In 1984 of 1985 stuurde Don Hopkins (een erg fantasievolle kerel) me een brief. Op de enveloppe had hij wat grappige gezegden geschreven, waaronder deze: “Copyleft—all rights reversed.” (“Auteursplicht—alle rechten omgedraaid”, nvdv). Ik gebruikte het woord “auteursplicht” als werknaam voor het distributieconcept dat ik op dat moment aan het ontwikkelen was.

(2) We gebruiken nu de GNU Free Documentation License ("GNU Vrije Documentatie Licentie", nvdv) voor documentatie.

De Free Software Foundation (Stichting voor Vrije Software)

Toen de interesse in Emacs groeide gingen meer mensen zich bezig houden met het GNU project, en we besloten dat het tijd werd om weer fondsen te werven. Dus we richten de Free Software Foundation op in 1985, een goed doel, belastingaftrekbaar, voor vrije software ontwikkeling. De FSF nam ook de Emacs tape distributie activiteit over; later groeide dit door andere vrije software (GNU en niet-GNU) toe te voegen aan de tape, en met de verkoop van vrije handleidingen.

De FSF accepteert donaties, maar het grootste deel van de inkomsten kwam altijd uit de verkoop—kopieën van vrije software, en aanverwante diensten. Vandaag de dag verkoopt het CD-ROMs met broncode, CD-ROMs met binaire bestanden, mooi gedrukte handleidingen (allemaal met de vrijheden om verder te distribueren en aan te passen), en Luxe Distributies (waar we de hele softwarecollectie op maat maken voor het door u gekozen platform). De FSF verkoopt nog steeds handleidingen en aanverwante artikelen, maar het meeste komt van bijdragen uit de lidmaatschap. Je kunt lid worden van de FSF bij fsf.org.

Free Software Foundation werknemers hebben een aantal GNU-software pakketten geschreven en onderhouden. Twee opmerkelijke zijn de C bibliotheek en de shell. De GNU C-bibliotheek is wat ieder programma dat draait op een GNU/Linux systeem gebruikt om met Linux te communiceren. Het werd ontwikkeld door een staflid van de Free Software Foundation, Roland McGrath. De shell die wordt gebruikt op de meeste GNU/Linux-systemen is BASH, de Bourne Again Shell(1), die werd ontwikkeld door FSF werknemer Brian Fox.

We financierden de ontwikkeling van deze programma's omdat het GNU-project niet slechts ging over een software-ontwikkelomgeving. Ons doel was een compleet besturingssysteem, en deze programma's waren daarvoor nodig.

(1) “Bourne again Shell” (Opnieuw geboren Schil, nvdv) is een woordgrapje met de naam “Bourne Shell”, de meest voorkomende shell op Unix.

Ondersteuning voor vrije software

De vrije-softwarefilosofie verwerpt een bepaalde veel voorkomende vorm van commerciële activiteit, maar is niet vies van commercie. Als bedrijven de vrijheid van gebruikers respecteren, wensen wij hen succes.

De verkoop van kopieën van Emacs is een voorbeeld van zaken doen met vrije software. Toen de FSF die handel overnam, moest ik op een andere manier brood op de plank krijgen. Ik vond een manier om diensten te verkopen die verband hielden met de door mij ontwikkelde software. Onder meer les geven in hoe GNU Emacs te programmeren, het aanpassen van GCC, softwareontwikkeling; vooral het aanpassen van GCC aan nieuwe platformen.

Tegenwoordig wordt elk van deze manieren van vrije software handel uitgevoerd door een aantal bedrijven. Sommige distribueren vrije software collecties op CD-ROM, anderen verkopen ondersteuning op verschillende niveaus, van het beantwoorden van gebruikersvragen, het corrigeren van fouten, tot het toevoegen van compleet nieuwe mogelijkheden. We zien nu zelfs vrije software bedrijven gebaseerd op het lanceren van nieuwe vrije software producten.

Maar pas op: een aantal bedrijven die zichzelf associëren met de term “open source” (“open broncode”, nvdv), baseren hun handel op niet-vrije software die werkt met vrije software. Dit zijn geen vrije software bedrijven, het zijn private software bedrijven wiens producten gebruikers wegleiden van vrijheid. Ze noemen het “toegevoegde waarde”, waarin ze andere normen aan ons op willen dringen: gemak boven vrijheid. Als wij meer waarde hechten aan vrijheid, zouden we ze “minus vrijheid” producten noemen.

Technische doelen

Het hoofddoel van GNU is om vrije software te zijn. Zelfs als GNU geen technische voordelen boven Unix had, zou het een sociaal voordeel hebben dat gebruikers toestaat om samen te werken, en een ethisch voordeel, respect voor de vrijheid van de gebruikers.

Maar van nature pasten we de bekende standaarden voor goed werk toe—bijvoorbeeld: dynamisch toewijzen van data structuren om vaststaande limieten van willekeurige grootte te omzeilen, en het correct afhandelen van alle mogelijke 8-bit codes waar dat zinnig was.

Daarbij kwam dat we de Unix focus op weinig geheugen gebruik verwierpen met de beslissing dat we de 16-bit machines niet zouden ondersteunen (het was duidelijk dat 32-bit machines de norm zouden zijn op het moment dat het GNU-systeem klaar zou zijn), en geheugen gebruik niet zouden proberen te verminderen tenzij het meer dan een megabyte zou zijn. In programma's die niet persé werken met hele grote bestanden, moedigden we programmeurs aan om het invoer bestand in één keer in geheugen in te lezen, en dan de inhoud te scannen zonder aandacht te besteden aan Invoer/Uitvoer.

Deze beslissingen maakten het mogelijk voor veel GNU-programma's om hun Unix equivalent voorbij te streven in betrouwbaarheid en snelheid.

Gedoneerde computers

Terwijl de reputatie van het GNU-project groeide, begonnen mensen computers te doneren waarop Unix draaide. Deze waren heel bruikbaar, omdat de makkelijkste manier om onderdelen voor GNU te ontwikkelen op een Unix-systeem was, en de onderdelen van dat systeem stuk voor stuk te vervangen. Maar we werden geconfronteerd met een ethisch probleem: was het wel terecht dat we überhaupt een Unix kopie hadden.

Unix was (en is) private software, en de filosofie van het GNU-project zegt dat we geen private software zullen gebruiken. Maar, gebruikmakend van dezelfde logica die zegt dat geweld ter zelfverdediging gerechtvaardigd is, concludeerde ik dat het legitiem was om een privaat pakket toe te passen als het noodzakelijk was in de ontwikkeling van een vrije vervanging, die gebruikers in staat zou stellen met het private pakket te stoppen.

Maar, ook al was dit een noodzakelijk kwaad, het was nog altijd een kwaad. Tegenwoordig hebben we geen Unix kopieën meer, omdat we ze hebben vervangen met vrije besturingssystemen. Als we het besturingssysteem van een machine niet konden vervangen met een vrije versie, vervingen we in plaats daarvan de machine.

De GNU-takenlijst

Op een gegeven moment, terwijl het GNU-project verder ging en steeds meer systeem componenten werden gevonden of ontwikkeld, werd het zinnig om een lijst met missende onderdelen te maken. Normaal gesproken namen we ontwikkelaars aan om deze missende delen te schrijven. Deze lijst is bekend geworden als de GNU-takenlijst. Hier bovenop voegden we andere software en documentatie projecten toe die, zo dachten wij, een echt compleet systeem zou moeten hebben.

Vandaag de dag (1) zijn er vrijwel geen Unix componenten over op de GNU-takenlijst—dat werk is gedaan, op een paar minder belangrijke dingen na. Maar de lijst staat vol met projecten die door sommigen “toepassingen” genoemd zouden worden. Elk programma dat aantrekkelijk is voor meer dan een hele speciale klasse gebruikers zou een goede toevoeging aan een besturingssysteem zijn.

Zelfs spelletjes worden op de takenlijst gezet—dit was al zo vanaf het begin. Unix had spelletjes, dus GNU natuurlijk ook. Maar samen kunnen werken met Unix op dit gebied was niet belangrijk voor spelletjes, dus we volgden niet de Unix lijst met spelletjes. In plaats daarvan maakten we een spectrum van verschillende soorten spelletjes die gebruikers wellicht leuk zouden vinden.

(1) Dit was geschreven in 1998. Sinds 2009 houden we geen lange takenlijst meer bij. De gemeenschap ontwikkelt zó snel vrije software dat we dit niet allemaal meer bij kunnen houden. In plaats daarvan hebben we nu een lijst met Belangrijkste Projecten, een lijst met projecten waarvan we echt graag willen dat ze uit worden gevoerd.

De GNU Programmabibliotheek GPL

De GNU C-bibliotheek gebruikt een speciaal soort auteursplicht met de naam de GNU Library General Public License(1) (GNU LGPL—GNU Bibliotheek Algemene Publieke Licentie), die toestaat dat private software de bibliotheek mag gebruiken. Waarom deze uitzondering?

Dit is geen principieel punt; er is geen principe dat zegt dat private softwareproducten het recht hebben om onze code in zich op te nemen. (Waarom meewerken aan een project dat noodzakelijkerwijs niets met ons zal delen?) Het gebruik van de LGPL voor de C bibliotheek, en voor iedere andere bibliotheek, is strategisch.

De C-bibliotheek doet een algemene taak; ieder privaat systeem of compiler heeft een C-bibliotheek. Daarom zou als we de C-bibliotheek alleen toegankelijk maakten voor vrije software dit vrije software geen voordeel hebben opgeleverd—het zou alleen gebruik van onze bibliotheek hebben ontmoedigd.

Één systeem vormt hierop een uitzondering: op het GNU-systeem (en ook GNU/Linux), is de GNU C-bibliotheek de enige C-bibliotheek. Dus de distributie voorwaarden voor de GNU C-bibliotheek bepalen of het mogelijk is om private programma's voor het GNU-systeem te compileren. Er is geen ethische reden om private toepassingen toe te staan op het GNU-systeem, maar strategisch gezien lijkt het weren ervan eerder het gebruik van het GNU-systeem af te remmen, dan dat het ontwikkelen van vrije toepassingen wordt gestimuleerd. Daarom is het gebruik van de Library GPL een goede strategie voor de C-bibliotheek.

Daarom is het toepassen van de LGPL een goede strategie voor de C-bibliotheek. Voor andere programmabibliotheken moet de strategische beslissing per geval worden bekeken. Als de bibliotheek een speciale taak heeft die bepaalde soorten programma's mogelijk maken, dan is het vrijgeven onder de GPL, zodat alleen vrije programma's het kunnen aanroepen, een manier om vrije software ontwikkelaars te helpen, zodat ze een voordeel over private software hebben.

Kijk eens naar GNU Readline, een bibliotheek die werd ontwikkeld om commando-regel redigeren makkelijk te maken voor BASH. Readline wordt gepubliceerd onder de gewone GNU GPL, niet de LGPL. Dit vermindert waarschijnlijk het gebruik van Readline, maar dat is geen probleem voor ons. Tegelijkertijd is tenminste één toepassing vrije software geworden zodat het Readline kon gebruiken, dat is echte meerwaarde voor de gemeenschap.

Private software-ontwikkelaars hebben het voordeel dat geld hen geeft; vrije-software-ontwikkelaars moeten voor elkaar voordelen scheppen. Ik hoop dat we op een dag een grote collectie onder de GPL uitgegeven bibliotheken hebben, waarvan geen gelijke voor private programma's bestaat, die bruikbare modules leveren als bouwstenen voor nieuwe vrije software, zodat er een groot voordeel ontstaat voor verdere vrije software ontwikkeling.

(1) Deze licentie wordt nu de GNU Lesser General Public License (“GNU Verminderde Algemene Publieke Licentie”) genoemd, om verwarring, dat alle bibliotheken het zouden moeten gebruiken, te voorkomen. Waarom je niet de Lesser GPL moet gebruiken voor je volgende programmabibliotheek.

Krabben aan jeuk?

Eric Raymond zegt dat “Ieder goed stuk software ontstaat door het krabben aan de persoonlijke jeuk van een ontwikkelaar.” Misschien gebeurd dat wel eens, maar veel essentiële stukken GNU-software werden ontwikkeld om een compleet vrij besturingssysteem te hebben. Ze komen voort uit een visie, een plan, niet uit een impuls.

Bijvoorbeeld, we ontwikkelen de GNU C-bibliotheek omdat een Unix-achtig systeem een C-bibliotheek nodig heeft, de Bourne-Again Shell (BASH) omdat een Unix-achtig systeem een shell moet hebben, en GNU tar omdat een Unix-achtig systeem een archiveringsprogramma nodig heeft. Hetzelfde geldt voor veel van mijn eigen programma's—de GNU C-compiler, GNU Emacs, GDB en GNU Make.

Sommige GNU-programma's werden ontwikkeld om specifieke bedreigingen voor onze vrijheid het hoofd te bieden. Daarom ontwikkelden we gzip om het Compress-programma te vervangen, omdat we dit als gemeenschap kwijt waren vanwege de LZW-patenten. We hebben mensen gevonden om LessTif te maken, en recent startte GNOME en Harmony, om bepaalde private bibliotheken (zie onder) te omzeilen. We ontwikkelen de GNU Privacy Guard om populaire onvrije encryptie software te vervangen, zodat gebruikers niet noodgedwongen tussen privacy en vrijheid hoeven te kiezen.

Uiteraard raakten de mensen die deze programma's schrijven geïnteresseerd in het werk, en veel mogelijkheden werden toegevoegd omdat ze het zelf nodig hadden, of het hun boeide. Maar dat is niet de reden dat deze programma's bestaan.

Onverwachte wendingen

Aan het begin van het GNU-project zag ik voor me dat we het hele GNU-systeem zouden ontwikkelen, en het dan als geheel publiceren. Zo is het dus niet gegaan.

Omdat elk onderdeel van het GNU-systeem werd gemaakt op een Unix-systeem, kon elk onderdeel dus draaien op Unix-systemen, lang voordat er een compleet GNU-systeem bestond. Sommige van deze programma's werden populair, en gebruikers begonnen ze uit te breiden en aan te passen aan andere platform—naar de verschillende versies van Unix, en soms ook naar andere systemen.

Dit proces maakte de programma's vele malen krachtiger, en trok geld en medewerkers naar het GNU-project. Maar het heeft waarschijnlijk ook tot vertraging geleidt van een paar jaar voordat een minimaal werkend systeem af was, aangezien GNU-ontwikkelaars nu tijd staken in het onderhouden van deze aanpassingen, en zelf mogelijkheden aan bestaande onderdelen toevoegden, in plaats van door te gaan met het één voor één schrijven van de benodigde onderdelen.

De GNU Hurd

Tegen 1990 was het GNU-systeem bijna compleet; het enige missende onderdeel was de kernel. We hadden besloten om onze kernel als een collectie van server processen bovenop Mach te schrijven. Mach is een microkernel ontwikkeld aan de Carnegie Mellon Universiteit en daarna aan de Universiteit van Utah; de GNU HURD is een verzameling servers (een “herd of gnus” (“kudde gnoes”, nvdv)) die bovenop Mach draaien, en die de verschillende taken van de Unixkernel uitvoeren. De start van de ontwikkeling werd vertraagd terwijl we wachtten tot Mach als vrije software werd vrijgegeven, zoals was beloofd.

Het moeilijkste onderdeel van het schrijven van de kernel leek ons het debuggen van een kernelprogramma zonder een gelijktijdig draaiende debugger, dat was een reden voor dit ontwerp. Die taak was al gedaan, in Mach, en we verwachtten Hurd-servers te kunnen debuggen als gebruiker programma's, met GDB. Maar het heeft lang geduurd om dat mogelijk te maken, en de multi-executie-pad servers die berichten naar elkaar sturen bleken heel moeilijk te debuggen. Hurd stabiel te laten werken duurde steeds langer, jaren.

Alix

De GNU-kernel zou eerst niet de naam Hurd krijgen. De originele naam was Alix—vernoemd naar de vrouw die ik toen liefhad. Zij, een Unix systeembeheerder, wees op het feit dat haar naam een algemeen patroon van Unix-systeem versies volgde; als grap vertelde ze haar vrienden “Iemand zou een kernel naar mij moeten noemen.” Ik zei niets, maar besloot haar te verassen met een kernel “Alix”.

Maar het hield geen stand. Michael Bushnell (nu Thomas), hoofdontwikkelaar van de kernel gaf de voorkeur aan Hurd, en bepaalde dat een bepaald onderdeel van de kernel Alix zou heten—het deel dat systeemaanroepen zou afvangen, en de aanvraag zou verwerken door berichten naar Hurd-servers te zenden.

Uiteindelijk ging het uit tussen mij en Alix, en ze veranderde haar naam; onafhankelijk hiervan werd het Hurd ontwerp veranderd zodat de C-bibliotheek de berichten direct naar de servers zou zenden, het Alix-onderdeel verdween uit het ontwerp.

Voordat dit echter gebeurde zag een vriend van haar de naam Alix in de Hurd broncode en vertelde het tegen haar. Ze heeft dus de kans gehad een kernel naar haar vernoemd te hebben.

Linux en GNU/Linux

GNU Hurd is nog niet productierijp en we weten niet of dit ooit het geval zal zijn. Het toepassingsgerichte ontwerp heeft problemen die een direct gevolg zijn van het flexibele ontwerp. Het is niet duidelijk of er een oplossing is.

Gelukkig is een andere kernel voorhanden. In 1991 ontwikkelde Linus Torvalds een Unix-achtige kernel, en noemde het Linux. Die was eerst privaat, maar in 1992 maakte hij het vrije software; het combineren van Linux met het nog-niet-helemaal-complete GNU-systeem resulteerde in een compleet vrij besturingssysteem. (Het combineren zelf was een flinke taak, uiteraard.) Dankzij Linux kunnen we daadwerkelijk vandaag de dag een versie van het GNU systeem draaien.

Wij noemen deze versie GNU/Linux, om aan te geven dat het een combinatie betreft van het GNU-systeem met Linux als kernel. Noem het hele systeem alsjeblief geen “Linux”, omdat dat zou betekenen dat ons werk aan iemand anders wordt toegeschreven. Benoem ons alsjeblieft op een gelijkwaardige manier.

Uitdagingen voor de toekomst

Wij hebben bewezen dat we een breed spectrum vrije software kunnen ontwikkelen. Dit betekent niet dat we onoverwinnelijk en niet te stoppen zijn. Verschillende uitdagingen maken de toekomst van vrije software onzeker; die het hoofd bieden zal standvastigheid en volhouden vergen, soms jarenlang. Het zal het soort doorzettingsvermogen vergen die mensen laten zien als ze vrij willen zijn, en niet toelaten dat die afgenomen wordt.

De volgende vier secties behandelen deze uitdagingen.

Geheime hardware

Hardwarefabrikanten houden steeds vaker hun hardwarespecificaties geheim. Dit maakt het moeilijk om vrije stuurprogramma's te schrijven zodat Linux en XFree86 de nieuwe hardware kunnen ondersteunen. We hebben nu compleet vrije systemen, maar dat geldt niet voor de toekomst als we de computers van morgen niet kunnen ondersteunen.

Er zijn twee manieren om met dit probleem om te gaan. Programmeurs kunnen de hardware van buiten benaderen om uit te vinden hoe het werkt. De rest kan hardware kiezen die wordt ondersteund door vrije software; als we dit massaal doen wordt geheimhouding van specificaties een doodlopende weg.

Het ontrafelen van software is een zware taak; hebben we hier programmeurs met voldoende doorzettingsvermogen voor? Ja—als we ons sterk maken voor vrije software als principe, en onvrije stuurprogramma's niet tolereren. En zullen velen van ons extra geld uitgeven, of zelfs een beetje meer tijd, zodat we vrije stuurprogramma's kunnen gebruiken? Zeker als de vastberadenheid voor vrijheid breed wordt gedragen.

(2008 voetnoot: dit speelt ook in de BIOS. Er is een vrije BIOS, LibreBoot (een distributie van coreboot); het probleem is het verkrijgen van specificaties van machines zodat LibreBoot die kan ondersteunen zonder niet-vrije “blobs”.)

Niet-vrije programmabibliotheken

Een niet-vrije programmabibliotheek die draait op een vrij besturingssysteem werkt als een hinderlaag voor vrije-software-ontwikkelaars. De bibliotheek heeft aantrekkelijke mogelijkheden, het aas; als je de bibliotheek gebruikt val je in de val, omdat je programma geen bruikbaar onderdeel van een vrij besturingssysteem kan worden. (Strikt gesproken kunnen we je programma opnemen, maar het zal niet draaien als de bibliotheek mist.) Sterker nog, als een programma populair wordt dat private bibliotheken gebruikt kan het andere nietsvermoedende programmeurs in de val lokken.

De eerste keer dat dit een probleem werd was met de Motif-toolkit, al weer lang geleden in de tachtiger jaren. Alhoewel er toen nog geen vrije besturingssystemen waren, was duidelijk welk probleem Motif zou gaan opleveren voor vrije software programma's. Het GNU-project reageerde op twee manieren: door individuele vrije software projecten te vragen om de vrije X Toolkit widgets naast die van Motif te ondersteunen, en om te vragen om iemand die een vrije vervanging voor Motif kon schrijven. Dit kostte vele jaren; LessTif, ontwikkeld door de Hungry Programmers, werd pas in 1997 krachtig genoeg om de meeste Motif toepassingen te ondersteunen.

Tussen 1996 en 1998 werd een andere niet-vrije GUI toolkit (een programmabibliotheek met grafische hulpmiddelen), Qt genoemd, gebruikt in een aanzienlijke hoeveelheid vrije software, de bureaublad software KDE.

Vrije GNU/Linux-systemen konden KDE niet gebruiken omdat we de bibliotheek niet konden inzetten. Sommige commerciële distributeurs van GNU/Linux-systemen, die niet principieel waren met vrije software, voegden KDE toe aan hun systemen—waardoor hun producten meer konden, maar met minder vrijheid. De KDE-groep probeerde meer programmeurs over te halen om Qt te gaan gebruiken, en miljoenen nieuwe “Linux gebruikers” wisten niet dat dit een probleem was. Het zag er moeilijk uit.

De vrije software gemeenschap reageerde op twee manieren: GNOME en Harmony.

GNOME, de GNU Network Object Model Environment, is GNU's desktopproject. Het werd gestart in 1997 door Miguel de Icaza, en ontwikkelde zich, ondersteund door Red Hat Software; GNOME had als doel gelijkwaardige desktop faciliteiten te bieden, maar exclusief met vrije software. Het heeft ook technische voordelen, zoals het ondersteunen van vele verschillende talen, niet alleen C++. Maar het belangrijkste doel was vrijheid: onafhankelijkheid van onvrije software.

Harmony is een vervanger voor Qt, met dezelfde interface, zodat KDE-software kan draaien zonder Qt.

In november 1998 kondigden de Qt-ontwikkelaars aan dat ze hun licentie gingen veranderen, zodat - als ze dit echt gingen doen - Qt vrije software zou worden. We weten het niet zeker, maar ik denk dat dit gedeeltelijk een reactie was op het krachtige weerwoord van de gemeenschap op het Qt probleem, toen het nog onvrij was. (De nieuwe licentie is onhandig en ongelijkwaardig, het blijft dus aan te raden om Qt niet te gebruiken.)

[Aanvullende noot: in september 2000 werd Qt opnieuw uitgebracht onder de GNU GPL, dit probleem is nu in feite opgelost.]

Wat zal ons antwoord zijn op de volgende aantrekkelijke onvrije bibliotheek? Zal de hele gemeenschap de noodzaak inzien van het ontwijken van de val? Of zullen velen van ons vrijheid opgeven voor het gemak, en grote problemen gaan opleveren? Onze toekomst hangt af van onze filosofie.

Softwarepatenten

De grootste dreiging komt van softwarepatenten, die kunnen algoritmes en mogelijkheden voor maximaal twintig jaar verboden gebied verklaren. Het LZW-compressie-algoritme-patent werd aangevraagd in 1983, en we kunnen nog altijd geen vrije software produceren die correct gecomprimeerde GIFs maakt [Sinds 2009 zijn ze verlopen]. In 1998 kon een vrij programma dat MP3 audiobestanden comprimeerde niet meer worden uitgebracht, onder dreiging van een patent-rechtszaak. [Sinds 2017 zijn deze patenten verlopen, zo lang moesten we wachten.]

Er zijn manieren om ons tegen patenten te verweren: we kunnen zoeken naar bewijs dat een patent ongeldig is, en we kunnen zoeken naar alternatieve manieren om het werk te doen. Maar deze oplossingen werken niet altijd; als beide falen kan het patent alle vrije software dwingen bepaalde functionaliteit niet te hebben die gebruikers wel willen. Na lang wachten zullen de patenten verlopen, maar wat doen we zolang?

Diegenen van ons die vrije software waarderen om zijn vrijheid, zullen altijd bij de vrije software blijven. We zullen ons werk doen zonder de gepatenteerde functionaliteit. Maar degenen die van vrije software houden omdat ze ervan verwachten dat het technisch superieur is, zullen het waarschijnlijk een mislukking vinden als het door een patent wordt tegengehouden. Dus, hoewel het zinnig is te discussiëren over het praktische effect van het “bazaar”-model voor ontwikkeling, en de betrouwbaarheid en kracht van vrije software, moeten we daar niet ophouden. We moeten het hebben over vrijheid en principes.

Vrije documentatie

Het grootste gebrek in onze vrije besturingssystemen ligt niet in de software—er is een tekort aan goede vrije handleidingen die we met onze systemen kunnen bundelen. Documentatie is een essentieel onderdeel van ieder softwarepakket; als een belangrijk vrij softwarepakket geen goede vrije handleiding heeft, is dat een groot gemis. We hebben veel van zulke gaten momenteel.

Vrije documentatie is, net als vrije software, een kwestie van vrijheid, niet van prijs. Het criterium voor een vrije handleiding is min of meer gelijk aan dat van vrije software: alle gebruikers krijgen bepaalde vrijheden. Verspreiding (inclusief commerciële handel) moet worden toegestaan, elektronisch en op papier, zodat de handleiding met iedere kopie van het programma kan worden geleverd.

Toestaan van aanpassingen is ook belangrijk. In het algemeen geloof ik niet dat het essentieel is dat mensen toestemming hebben om allerlei artikelen en boeken aan te passen. Het lijkt me bijvoorbeeld niet nodig dat jij of ik toestemming geven om een artikel als dit te veranderen, iets dat onze activiteiten en meningen beschrijft.

Maar er is een speciale reden waarom de vrijheid van aanpassen essentieel is voor documentatie van vrije software. Als mensen van hun recht om software aan te passen gebruik maken, zoals het toevoegen of veranderen van dingen, dan zullen ze als ze verantwoordelijk bezig willen zijn, ook de handleiding aan willen passen—zodat ze correcte en bruikbare informatie met het aangepaste programma kunnen leveren. Een handleiding die programmeurs niet toelaat een taak verantwoordelijk af te ronden, voorziet niet in de behoeften van de gemeenschap.

Bepaalde grenzen aan wat veranderd mag worden zijn geen probleem. Bijvoorbeeld: de eis dat het auteursrecht van de originele auteur, de voorwaarden voor distributie, en de lijst van auteurs gehandhaafd blijven, daar is niets mis mee. Het is ook geen probleem te eisen dat veranderde versies een notitie bevatten dat ze veranderd werden, of zelfs het hebben van hele onderdelen die niet veranderd of verwijderd mogen worden, zolang die onderdelen maar niet over de techniek gaan. Dit soort beperkingen zijn geen probleem omdat ze een verantwoordelijke programmeur niet in de weg zitten bij het aanpassen van een handleiding aan een veranderd programma. Met andere woorden: ze verhinderen niet het gebruik van de handleiding door de software gemeenschap.

Het moet echter mogelijk blijven alle technische inhoud van een handleiding te redigeren, en het resultaat te kunnen distribueren via de gebruikelijke wegen en kanalen; anders zitten de beperkingen de gemeenschap in de weg; de handleiding is niet vrij, we hebben dan een andere handleiding nodig.

Zullen vrije-software-ontwikkelaars de oplettendheid en het doorzettingsvermogen hebben om een breed spectrum vrije handleidingen te produceren? Onze filosofie bepaalt onze toekomst.

We moeten het over vrijheid hebben

Er wordt heden ten dage geschat dat er tientallen miljoenen gebruikers van GNU/Linux-systemen zoals Debian GNU/Linux en Red Hat “Linux” zijn. Vrije software heeft zoveel praktische voordelen ontwikkeld, dat gebruikers alleen daar al massaal op af komen.

De goede gevolgen hiervan zijn duidelijk: meer interesse in het ontwikkelen van vrije software, meer klanten voor vrijesoftwarebedrijven, meer mogelijkheden om bedrijven aan te moedigen commerciële vrije software in plaats van private software te maken.

Maar de interesse voor de software groeit sneller dan de bekendheid van de achterliggende filosofie, dit geeft problemen. Onze kracht om de boven beschreven uitdagingen aan te gaan hangt af van de wil om achter onze vrijheid te gaan staan. Om zeker te zijn dat onze gemeenschap deze wil heeft, is het nodig deze ideeën te verspreiden naar nieuwe gebruikers, als ze met de gemeenschap in aanraking komen.

Maar dit is aan het mislukken: er wordt veel meer moeite gestoken in het aantrekken van nieuwe gebruikers, dan in het aanleren van de basisvoorwaarden van onze gemeenschap. Het is nodig beide te doen, en te zorgen dat deze twee doelen in evenwicht blijven.

“Open source”

Aanleren van het basisprincipe vrijheid aan nieuwe gebruikers werd moeilijker in 1998, toen een deel van de gemeenschap besloot te stoppen met de term “vrije software”, en over “open source software” (“software met open broncode”) begon te spreken.

Er waren er die de voorkeur gaven aan de nieuwe term, omdat het “vrij” niet met “gratis” kan worden verward—op zich een goede reden. Anderen stelden zich echter ten doel om de principiële inspiratie die de vrije-softwarebeweging en het GNU-project gemotiveerd hadden, opzij te zetten, om in de gunst van bedrijfsleiders en commerciële gebruikers te komen, waarvan velen een ideologie aanhangen die winst boven vrijheid stelt, boven gemeenschap, boven principes. De “open source”-retoriek richt zich op de mogelijkheid kwalitatief hoogstaande en krachtige software te maken, maar schudt ideeën als vrijheid, gemeenschap en principes van zich af.

De “Linux”-bladen zijn hier een duidelijk voorbeeld van—ze staan vol advertenties voor private software die met GNU/Linux werkt. Als de volgende Motif of Qt verschijnt, zullen deze bladen dan de programmeurs waarschuwen zich er niet mee in te laten, of zullen ze er advertenties voor plaatsen?

De steun van bedrijven kan bijdragen aan de gemeenschap, op veel manieren; op die manier is het nuttig. Maar hen overhalen door nog minder over vrijheid en principes te praten kan rampzalig zijn; het uit evenwicht zijn van het aantrekken van gebruikers en het aanleren van onze cultuur wordt nog erger.

“Vrije software” en “open source” beschrijven min of meer dezelfde software-categorie, maar ze zeggen verschillende dingen over deze software, en over normen en waarden. Het GNU-project gaat door met de term “vrije software”, om duidelijk te maken dat het over vrijheid gaat, meer dan slechts techniek.

Proberen!

Yoda's aforisme (“‘Proberen’ bestaat niet”) klinkt leuk, maar is niks voor mij. Meestal ben ik tijdens het werk in de stress of ik het eigenlijk wel kan. Maar ik probeerde het toch, omdat er niemand anders tussen de vijand en mijn stad stond. Tot mijn eigen verbazing is het soms toch gelukt.

Soms is het mis gegaan; een paar van mijn steden zijn gevallen. Dan vond ik een andere bedreigde stad, en maakte me klaar voor nieuwe strijd. Ik leerde uit te kijken naar gevaren, en plaatste mijzelf tussen hen en mijn stad, hulp in roepend van andere hackers om zich bij mij aan te sluiten.

Tegenwoordig ben ik vaak niet de enige. Het is een opluchting en een feest wanneer ik een regiment hackers zich zie ingraven om het front te verdedigen, en ik realiseer me, deze stad kan overleven—voor even. Maar de gevaren zijn elk jaar groter, en nu neemt Microsoft expliciet onze gemeenschap op de korrel. Wij kunnen de toekomst van vrijheid niet voor lief nemen. Neem het niet voor lief! Als je je vrijheid wilt, moet je bereid zijn het te verdedigen.