Het GNU Project

door Richard Stallman

voor het eerst gepubliceerd in het boek "Open Sources"

 [image of What's GNU]

Vertalingen van deze pagina


De eerste software-delende gemeenschap

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

Het Kunstmatige Intelligentie Laboratorium (AI lab.) gebruikte een timesharing besturingssysteem met de naam ITS (het `Incompatible Timesharing System') dat de laboratoriums staf hackers (1) hadden ontworpen en geschreven in assembleer taal voor de Digitale PDP-10, een van de grote computers uit die tijd. Als een lid van deze gemeenschap, een AI lab. staf systeem hacker, was mijn taak dit systeem te verbeteren.

We noemden onze software geen "vrije software" (`free software'), omdat die term nog niet bestond; maar dat is wat het was. Telkens wanneer mensen van een andere universiteit of bedrijf een programma wilde vertalen voor een ander platform en gebruiken, 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 "computer inbreker" is een verwarring van de hand van de massa media. Wij hackers weigeren deze betekenis te accepteren, en wij gaan door met de betekenis "Iemand die van programmeren houdt en plezier heeft er goed in te zijn".

Het instorten van de gemeenschap

De situatie veranderde drastisch aan het begin van de jaren 1980 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 AI lab. hacker gemeenschap was al eerder ingestort, kort daarvoor. In 1981 had het spin-off bedrijf Symbolics bijna alle hackers van het AI lab. over gekocht, en de uitgedunde gemeenschap kon zichzelf niet in stand houden. (Het boek Hackers, door Steve Levy, beschrijft deze gebeurtenissen, en geeft een helder beeld van deze gemeenschap op haar hoogtepunt). Toen het AI lab. de nieuwe PDP-10 kocht in 1982 besloten de administrateurs om het onvrije 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 werden 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 gaan gebruiken was, om te beloven dat je je buurman niet zou helpen. Een samenwerkende gemeenschap werd verboden. De regel gemaakt door de eigenaars van private software was, "Als u uw software deelt met uw buurman, bent u een piraat. Als u veranderingen wilt in een programma, bedel ons er dan om."

Het idee dat het private-software sociale systeem--het systeem dat zegt dat het u niet is toegestaan software te veranderen of te delen--anti sociaal is, on ethisch is, dat het eenvoudigweg fout is, kan als een verassing komen voor sommige lezers. Maar wat anders kunnen we zeggen over een systeem gebaseerd op het verdelen van het publiek, gebruikers hulpeloos makend? Lezers die dit idee verrassend vinden hebben wellicht het private-software sociale systeem als vaststaand aangenomen, of hebben het beoordeeld binnen een kader gesuggereerd door private software bedrijven. Software uitgevers hebben lang en hard gewerkt om mensen te overtuigen dat er maar één manier is naar deze zaak te kijken.

Als software uitgevers praten over "handhaving" van hun "rechten" of "stoppen van piraterij"; wat ze zeggen is maar bijzaak. De echte boodschap van de stellingen zijn de impliciete aannames die ze voor lief nemen, en het publiek wordt verwacht ze zonder kritiek te accepteren. Laten we ze aan een onderzoek onderwerpen.

Aangenomen wordt dat software bedrijven een onaantastbaar natuurlijk recht hebben om software te bezitten, en daarmee macht te hebben over alle gebruikers. (Als dit een natuurlijk recht was, dan hoezeer dit het publiek ook zou schaden, we zouden er niet tegenin kunnen gaan.) Interessant genoeg verwerpen de Grondwet en de justitiële traditie van de VS deze uitleg; copyright is geen natuurlijk recht, maar een kunstmatig door de overheid opgelegd monopolie, dat het natuurlijke recht van gebruikers om te kopiëren verkort.

Een andere stilzwijgende aanname is dat het enige belangrijke aan software is welke taken je er mee kunt uitvoeren--dat wij computer gebruikers niet zouden moeten geven om welke maatschappij ons toegestaan wordt.

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 aanbieden. Deze aanname mag geloofwaardig geleken hebben, voordat de vrije software beweging aantoonde dat wij meer dan genoeg bruikbare software kunnen maken, zonder het aan de ketting te leggen.

Als wij bedanken voor deze aannames, en de zaak beoordelen met een gewoon gezond verstand moreel besef terwijl we de gebruikers op de eerste plaats stellen, dan komen we tot hele andere conclusies. Computer gebruikers 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.

Er is hier geen ruimte voor een uitgebreide ontwikkeling van de redenering achter deze conclusie, dus ik verwijs de lezer door naar deze web pagina, http://www.gnu.org/philosophy/why-free.nl.html.

Een duidelijke morele keuze.

Nu mij gemeenschap verdwenen was, werd doorgaan als eerder onmogelijk. In plaats daarvan werd ik geconfronteerd met een scherpe morele keuze.

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

Ik had op deze manier geld kunnen verdienen, en wellicht mezelf kunnen amuseren met het schrijven van code. Maar ik wist dat aan het einde van mijn carrière ik 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 ervaring met aan de verkeerde kant van een geheimhoudingsplicht staan, toen iemand mij en het MIT AI lab. weigerde om ons de bron code van het aanstuur programma 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 om met ons te delen; ik kon niet mezelf verloochenen en hetzelfde met andere mensen doen.

Een andere keuze, eenvoudig 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. I zou niet aangeklaagd kunnen worden voor het verdelen en aan banden leggen van computer gebruikers, maar het zou niettemin gebeuren.

Dus ik zocht naar een weg zodat een programmeur iets ten goede kon doen. Ik vroeg mezelf, was er een programma of programma's die ik zou kunnen schrijven, zodat een gemeenschap weer opnieuw mogelijk werd ?

Het antwoord was duidelijk: ten eerste was een een besturingssysteem nodig. Dit is de cruciale software om een computer te gebruiken. 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 in staat gesteld worden een computer te gebruiken, zonder om te beginnen mee te doen in een samenzwering die haar of zijn vrienden uitsluit.

Als besturingssysteem ontwikkelaar had ik hier de juiste vaardigheden voor. Dus alhoewel succes niet verzekerd was realiseerde ik me dat ik was uitverkoren voor dit werk. Ik koos ervoor om het systeem compatibel te maken met Unix, zodat het overgezet kon worden naar andere platforms en Unix gebruikers makkelijk over konden stappen. De naam GNU volgde uit de hacker traditie van recursieve afkortingen: "GNU's Not Unix".

Een besturingssysteem betekend niet alleen een kernel, net genoeg om andere programma's te draaien. In de jaren zeventig bevatte ieder besturingssysteem de naam waardig commando uitvoerders, assembleerders, compilers, interpreters, debuggers, tekst bewerkers, mail programma's, en 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 ben voor mijzelf, wie zal zijn voor mij?
Als ik alleen voor mijzelf ben, wat ben ik?
Als niet nu, wanneer?

De beslissing om te starten met het GNU project werd in deze geest genomen.

(1) Zijnde een 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" (`free software') wordt soms verkeerd opgevat--het heeft niets met prijs te maken. Het gaat om vrijheid. Daarom hier de definitie van vrije software: een programma is vrije software, voor u, een bepaalde gebruiker, als:

Omdat "vrij" refereerd aan vrijheid, niet de prijs, is er geen tegenstelling tussen het verkopen van kopieën vrije software. In feite is de vrijheid om kopieën te verkopen cruciaal: collecties 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 collectie kunnen voegen geen vrije software.

Vanwege de dubbelzinnigheid van "vrij", zijn mensen al lang op zoek naar alternatieven, maar niemand heeft een zinnig alternatief. De Engelse taal heeft meer woorden en nuances dan iedere andere taal, maar het mist een simpele ondubbelzinnig wordt dat "vrij" betekend, als in vrijheid--"on-geketend" is het woord dat er het dichtst bij komt. Alternatieven als "bevrijdt", "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 erg 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 tekst formatter te gebruiken; een paar jaar later besloot ik het X Window Systeem te gaan gebruiken in plaats van opnieuw een window systeem te schrijven voor GNU.

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

Start van het project

In Januari 1984 nam ik ontslag bij MIT en begon met GNU software schrijven. MIT verlaten was nodig zodat MIT geen vinger achter de distributie van GNU als vrije software kon krijgen. Als ik aan was gebleven als staf lid, zou MIT het eigendom van het werk kunnen claimen, 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.

Echter, Professor Winston, toen het hoofd van het MIT AI lab., nodigde me vriendelijk uit 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. (Het Nederlandse woord voor "free" wordt geschreven met een V.) Dit was een compiler geschreven voor meerdere talen, inclusief C en Pascal, en ondersteunde meerdere doel 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 meerdere-talen/meerdere-platforms compiler 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 meerdere-platforms compiler ontwikkeld bij het Lawrence Livermore Laboratorium. Het ondersteunde en was geschreven in een uitgebreide versie van Pascal, ontwikkeld als systeem programmeer taal. Ik voegde een C front-end toe 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 stack ruimte 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 om zette in een lijst "instructies", om daarna het hele uitvoer bestand te genereren, zonder ooit geheugen ruimte 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 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; geen interesse hebbende in het leren van vi of ed, had ik mijn schrijfwerk tot nog toe op andere soorten machines gedaan.

Op dat moment wilden mensen voor het eerste GNU Emacs, hierdoor kwam de vraag van hoe te distribueren op. 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 distributie site; toen het buiten gebruik werd gesteld na enkele jaren, namen we de naam mee naar onze nieuwe ftp server.) Maar toendertijd hadden geïnteresseerden geen Internet toegang en konden geen kopie per ftp krijgen. De vraag was dus, wat zou ik tegen ze zeggen ?

Ik zou hebben kunnen zeggen "Zoek een vriend die op het net zit die een kopie voor je kan maken." Of ik had hetzelfde kunnen doen als ik had gedaan met de originele PDP-10 Emacs: tegen ze zeggen, "Stuur me een tap en een SASE, 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 op Linux gebaseerde GNU systemen distribueren.

Is een programma vrij voor iedere gebruiker?

Of een programma vrije software is als het de handen van de auteur verlaat wil nog niet zeggen dat het vrije software is voor iedereen die er een kopie van heeft. Voorbeeld: publiek domein software (software zonder copyright) is vrije software; maar iedereen kan er een private aangepaste versie van maken. Net zo hebben veel programma's een copyright, 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 aangenomen door verschillende computer bedrijven. 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 te 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.

Copyleft en de GNU GPL

Het doel van GNU was om gebruikers vrijheid te geven, niet om slechts populair te zijn. We hadden dus distributie voorwaarden nodig die zouden voorkomen dat GNU software in private software zou veranderen. De methode die we gebruiken heet "copyleft".(1)

Copyleft gebruikt copyright wetten, 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 kern idee van copyleft 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 restricties 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 effectief copyleft moeten aangepaste versies ook vrij zijn. Zo wordt werk gebaseerd op dat van ons toegankelijk voor onze gemeenschap als het wordt gepubliceerd. Als programmeurs die banen hebben als programmeur vrijwillig GNU software verbeteren, voorkomt het copyleft 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 programma 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 ontdoen, zou het voor wie dan ook makkelijk zijn dit excuus ter eigen voordeel te gebruiken.

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 toe staan zou een gat openen, groot genoeg om een schip in te zinken. Daarom is het een cruciale eis voor copyleft dit gat te dichten: wat aan het copyleft programma wordt toegevoegd of er mee wordt gecombineerd, moet zorgen dat de grotere gecombineerde versie ook vrij en copyleft is.

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

(1) In 1984 of 1985 stuurde Don Hopkins (een erg fantasie volle kerel) me een brief. Op de enveloppe had hij wat grappige gezegden geschreven, waaronder deze: "Copyleft--all rights reversed." ("Copyleft--alle rechten omgedraaid", nvdv). Ik gebruikte het woord "copyleft" als naam voor het distributie concept 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 (De Vrije Software Stichting)

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 belastingvrij goed doel voor vrije software ontwikkeling. De FSF nam ook de Emacs tape distributie bedrijvigheid over; later groeide dit uit door andere vrije software (tegelijkertijd 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 andere aanverwante diensten. Vandaag de dag verkoopt het CD-ROMs met bron code, 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 collectie software klaar maken voor het door u gekozen platform).

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 lid van de Free Software Foundation staf, Roland McGrath. De shell in gebruik op de meeste GNU/Linux systemen is BASH, de Bourne Again Shell(1), die werd ontwikkeld door een FSF werknemer Brian Fox.

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

(1) "Bourne again Shell" ("Opnieuw geboren Shell", nvdv) is een woordspelletje met de naam ``Bourne Shell'', de meest voorkomende shell op Unix.

Vrije software ondersteuning

De vrije software filosofie verwerpt een bepaalde veel voorkomende vorm van bedrijvigheid, maar is niet tegen bedrijven. Als bedrijven de vrijheid van gebruikers respecteert, wensen wij hen succes.

De verkoop van kopieën van Emacs demonstreert één vorm van vrije software bedrijvigheid. 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, software ontwikkeling; vooral het aanpassen van GCC aan nieuwe platforms.

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 gebruiker vragen, 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 bron code", 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 de normen die aan ons suggereren weerspiegeld worden: gemak boven vrijheid. Als wij meer waarde hechten aan vrijheid, zouden we ze "minus vrijheid" producten noemen.

Technische doelen

Het principe doel van GNU was om vrije software te zijn. Zelfs als GNU geen technische voordelen boven Unix had, zou het een sociaal voordeel hebben dat gebruikers samenwerking toestaat, 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 perse 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, gebruik makend van dezelfde logica die zegt dat geweld ter zelf verdediging 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 Taken Lijst

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 taken lijst ("GNU task list", nvdv). Hier bovenop voegden we andere software en documentatie projecten toe die, zo dachten wij, een echt compleet systeem zou moeten hebben.

Vandaag de dag zijn er vrijwel geen Unix componenten over op de GNU taken lijst--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 taken lijst 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.

De GNU Bibliotheek GPL

De GNU C bibliotheek gebruikt een speciale soort copyleft met de naam de GNU Library General Public License(1) (GNU Bibliotheek Algemene Publieke Licentie, nvdv), die toestaat dat private software naar de bibliotheek mag verwijzen. Waarom deze uitzondering ?

Dit is geen principieel punt; er is geen principe dat zegt dat private software producten 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 een punt van strategie.

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

Één systeem vormt hierop een uitzondering: op het GNU systeem (en dat is inclusief 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 toepassen van de Bibliotheek GPL een goede strategie voor de C bibliotheek. Voor andere bibliotheken moet de strategische beslissing per keer 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 krijgen.

Kijk eens naar GNU Readline, een bibliotheek die werd ontwikkeld om commando-regel editen makkelijk te maken voor BASH. Readline wordt gepubliceerd onder de gewone GNU GPL, niet de bibliotheek GPL. Dit verminderd 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 echt meerwaarde voor de gemeenschap.

Private software ontwikkelaars hebben het voordeel van geld; 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", nvdv) genoemd, om verwarring dat alle bibliotheken het zouden moeten gebruiken te voorkomen. .

Krabben aan jeuk?

Eric Raymond zegt dat "Ieder goed stuk software start door het krabben van een 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 archivering programma 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 programma mee te vervangen, omdat we dit als gemeenschap kwijt waren vanwege de LZW patenten. We hebben mensen gevonden om LessTif te maken, en recenter startte GNOME en Harmony, in verdediging tegen bepaalde private bibliotheken (zie onder). 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 platforms--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 toe voegden, 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 collectie servers (een ``herd of gnus'' ("kudde gnoes", nvdv)) die bovenop Mach draaien, en die de verschillende taken van de Unix kernel uitvoeren. De start van de ontwikkeling werd vertraagd terwijl we wachtten tot Mach als vrije software werd gepubliceerd, zoals was beloofd.

Het moeilijkste onderdeel van het schrijven van de kernel leek ons het debuggen van een kernel programma 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 mijn liefje op dat moment was. Zij, een Unix systeem administrateuze, 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), de hoofd ontwikkelaar van de kernel gaf de voorkeur aan HURD, en bepaalde dat een bepaald onderdeel van de kernel Alix zou heten--het deel dat systeem aanroepen 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.

Maar voor deze dingen gebeurden zag een vriend van haar de naam Alix in de HURD bron code, en vertelde het tegen haar. De naam had zijn werk gedaan.

Linux en GNU/Linux

GNU Hurd is niet klaar voor productief gebruik. Gelukkig is een andere kernel voorhanden. In 1991 ontwikkelde Linus Torvalds een Unix-achtige kernel, en noemde het Linux. Rond 1992 resulteerde de combinatie Linux met het nog-niet-helemaal-complete GNU systeem 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 systeem versie GNU/Linux, om aan te geven dat het een combinatie betreft van het GNU systeem met Linux als de kernel.

Uitdagingen voor de toekomst

Wij hebben bewezen dat we een breed spectrum vrije software kunnen ontwikkelen. Dit betekend 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 voor jaren. 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

Hardware fabrikanten houden steeds vaker hun hardware specificaties geheim. Dit maakt het moeilijk om vrije aanstuur programma's te schrijven zo dat Linux en XFree86 de nieuwe hardware ondersteunen. We hebben nu compleet vrije systemen, maar dat geldt niet voor later 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 met meer zijn wordt geheimhouding van specificaties een doodlopende weg.

Dit van buitenaf de hardware uitpluizen 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 stuur programma's niet tolereren. En zullen velen van ons extra geld uitgeven, of zelfs een beetje meer tijd, zodat we vrije stuur programma's kunnen gebruiken ? Ja, als de vastberadenheid voor vrijheid breed wordt gedragen.

Onvrije bibliotheken

Een onvrije bibliotheek 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 onvrije GUI toolkit bibliotheek, Qt genoemd, gebruikt in een aanzienlijke hoeveelheid vrije software, de desk-top KDE.

Vrije GNU/Linux systemen waren niet in staat KDE te gebruiken omdat we de bibliotheek niet konden inzetten. Sommige commerciële distributeurs van GNU/Linux systemen, die niet principieel vast hielden aan 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" waren onbekend met het idee 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 desk top project. Het startte in 1997 van de hand van Miguel de Icaza, en ontwikkelde zich ondersteund door Red Hat Software; GNOME had als doel gelijkwaardige desk top 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 vervangende bibliotheek 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. Het is niet zeker te weten, maar ik denk dat dit gedeeltelijk door het krachtige weerwoord van de gemeenschap op het Qt probleem was, toen het nog onvrij was. (De nieuwe licentie is onhandig en ongelijkwaardig, het blijft dus aangeraden om Qt te ontwijken.)

[Aanvullende noot: in September 2000 werd Qt opnieuw gepubliceerd 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.

Software patents

De grootste dreiging komt van software patenten, die kunnen algoritmes en mogelijkheden voor maximaal twintig jaar verboden gebied verklaren. Het LZW compressie ("compressie": meestal: inkorten met behoudt van informatie, nvdv) algoritme patent werd aangevraagd in 1983, en we kunnen nog altijd geen vrije software produceren die correct gecompresseerde GIFs maakt. In 1998 kon een vrij programma dat MP3 audio bestanden compresseerde niet meer worden gepubliceerd, onder dreiging van een patent recht zaak.

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 een bepaalde mogelijkheid niet te hebben terwijl gebruikers het willen hebben. Wat doen we als dit gebeurd ?

Degenen van ons die vrije software waarderen voor de vrijheid ervan, zullen altijd bij de vrije software blijven. We zullen ons werk doen zonder de mogelijkheden die onder het patent liggen. 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, alhoewel het zinnig is over de praktische effectiviteit van het "cathedraal" model van ontwikkeling(1), en de betrouwbaarheid en kracht van vrije software te praten, moeten we daar niet stoppen. We moeten het hebben over vrijheid en principes.

(1) Het zou duidelijker zijn om te schrijven `van het "bazar" model', omdat dat het nieuwe en eerst controversiële alternatief was.

Free documentation

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 software pakket; als een belangrijk vrij software pakket 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. Her distributie (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 cruciaal. 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 copyright 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 inperkingen van rechten 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 blokkeren niet het volledig gebruik van de handleiding door de software gemeenschap.

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

Zullen vrije software ontwikkelaars de oplettendheid en het doorzettingsvermogen aan de dag leggen, om een breed spectrum vrije handleidingen te produceren ? Onze filosofie bepaald 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 er massaal op af komen voor alleen al praktische redenen.

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

Maar de interesse in de software groeit sneller dan de bekendheid van de filosofie waarop het is gebaseerd, dit leidt tot moeilijkheden. 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 mislukt: 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 zorgen dat deze twee doelen in evenwicht blijven.

"Open Source"

Aanleren van vrijheid aan nieuwe gebruikers werd moeilijker in 1998, toen een deel van de gemeenschap besloot te stoppen met de term "free software", en van "open source software" ("open bron code", nvdv) begon te spreken.

Er waren er die de voorkeur gaven aan de nieuwe term, omdat het "vrij" niet met "gratis" verward--op zich een goede reden. Anderen stelden zich echter ten doel om de principiële inspiratie die de vrije software beweging en het GNU project gemotiveerd hadden, opzij te zetten, om in de gunst van bedrijfsleiders en bedrijfsgebruikers 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 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; al het andere gelijkblijvend 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 dezelfde categorie software, min of meer, maar ze zeggen verschillende dingen over deze software, en over gedragsnormen. Het GNU Project gaat door met de term "free software" ("vrije software", nvdv), om duidelijk te maken dat het over vrijheid gaat, meer dan slechts techniek.

Proberen!

Yoda's filosofie ("`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 groter elk jaar, 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, wees bereid het te verdedigen.


Meer over het GNU Project


Vertalingen van deze pagina:
[ Català | 简体中文 | 繁體中文 | Česky | Deutsch | Nederlands | English | Ελληνικά | Español | Français | Suomi | Bahasa Indonesia | Italiano | 한국어 | Polski | Русский ]