path: root/talermerchantdemos/blog/articles/nl/thegnuproject.html

<!--#set var="PO_FILE"
 value='<a href="/gnu/po/thegnuproject.nl.po">
 https://www.gnu.org/gnu/po/thegnuproject.nl.po</a>'
 --><!--#set var="ORIGINAL_FILE" value="/gnu/thegnuproject.html"
 --><!--#set var="DIFF_FILE" value="/gnu/po/thegnuproject.nl-diff.html"
 --><!--#set var="OUTDATED_SINCE" value="2018-01-01" -->

<!--#include virtual="/server/header.nl.html" -->
<!-- Parent-Version: 1.86 -->

<!-- This file is automatically generated by GNUnited Nations! -->
<title>Over het GNU-project - GNU-project - Free Software Foundation</title>
<meta http-equiv="Keywords" content="GNU, GNU-project, FSF, Vrije software, Free Software Foundation,
Geschiedenis" />

<!--#include virtual="/gnu/po/thegnuproject.translist" -->
<!--#include virtual="/server/banner.nl.html" -->
<!--#include virtual="/server/outdated.nl.html" -->
<h2>Het GNU-project</h2>

<p>
door <a href="http://www.stallman.org/"><strong>Richard
Stallman</strong></a></p>

<blockquote>
<p>
Gepubliceerd in het boek <em>Open Sources</em>.  Richard Stallman was <a
href="/philosophy/open-source-misses-the-point.html"> nooit een voorstander
van &ldquo;open source&rdquo;</a>, maar droeg bij met dit artikel zodat het
gedachtegoed van de vrije-softwarebeweging niet zouden ontbreken in dit
boek.
</p>
<p>
Waarom het belangrijker is dan ooit om <a
href="/philosophy/free-software-even-more-important.html">aan te dringen op
het gebruik van vrije software</a>.
</p>
</blockquote>

<h3>De eerste software-delende gemeenschap</h3>
<p>
Toen ik mijn loopbaan begon aan het Laboratorium van Kunstmatige
Intelligentie aan het <abbr title="Massachusetts Institute of
Technology">MIT</abbr> 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.</p>
<p>
Het Laboratorium voor Kunstmatige Intelligentie (KI lab.) gebruikte een
timesharing besturingssysteem met de naam <abbr title="Incompatible
Timesharing System">ITS</abbr> (het &lsquo;Incompatibele Timesharing
Systeem&rsquo;) dat hackers (1) onder het laboratoriumpersoneel hadden
ontworpen en geschreven in assembleer taal voor de <abbr title="Programmed
Data Processor">PDP</abbr>-10 van Digital, &eacute;&eacute;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.</p>
<p>
We noemden onze software geen &ldquo;vrije software&rdquo;, 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.</p>
<p>
(1) Het gebruik van het woord &ldquo;hacker&rdquo; in de betekenis van
&ldquo;digitale inbreker&rdquo; 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: <a
href="http://stallman.org/articles/on-hacking.html">On Hacking</a>.</p>

<h3>Het instorten van de gemeenschap</h3>
<p>
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.</p>
<p>
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.</p>
<p>
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.</p>
<p>
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,
&ldquo;Als u uw software deelt met uw buurman, bent u een piraat. Als u
veranderingen wilt in een programma, smeek ons er dan om.&rdquo;</p>
<p>
Het idee dat het systeem van private software&mdash;dat voorschrijft dat u
geen software mag veranderen of delen&mdash;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 &eacute;&eacute;n manier is
om naar deze zaak te kijken.</p>
<p>
Als software uitgevers praten over &ldquo;handhaving&rdquo; van hun
&ldquo;rechten&rdquo; of het &ldquo;stoppen van <a
href="/philosophy/words-to-avoid.html#Piracy">piraterij</a>&rdquo;; is wat
ze <em>zeggen</em> 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.</p>
<p>
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&euml;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&euml;ren aan banden legt.</p>
<p>
Een andere stilzwijgende aanname is dat het enige belangrijke aan software
is wat je er mee kunt doen&mdash;dat wij computergebruikers niet
maatschappelijk betrokken zouden mogen zijn.</p>
<p>
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.</p>
<p>
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.</p>
<p>
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: <a
href="/philosophy/why-free.html">
http://www.gnu.org/philosophy/why-free.html</a> en <a
href="/philosophy/free-software-even-more-important.html">
http://www.gnu.org/philosophy/free-software-even-more-important.html</a>.
</p>

<h3>Een duidelijke morele keuze</h3>
<p>
Nu mijn gemeenschap verdwenen was, kon ik niet op de oude voet doorgaan.  In
plaats daarvan werd ik geconfronteerd met een scherpe morele keuze.</p>
<p>
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.</p>
<p>
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.</p>
<p>
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.</p>
<p>
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.</p>
<p>
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?</p>
<p>
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&mdash;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.</p>
<p>
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: &ldquo;GNU's Not Unix&rdquo; (GNU is geen Unix). Het
wordt uitgesproken als <i>knoe</i>, als <a
href="/gnu/pronunciation.html">één lettergreep met een zachte k</a>.</p>
<p>
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.</p>
<p>
Later hoorde ik deze woorden, toegeschreven aan Hillel (1):</p>

<blockquote><p>
     Als ik niet voor mezelf ben, wie zal dan voor mij zijn?<br />
     Als ik alleen voor mezelf ben, wat ben ik dan?<br />
     Wanneer niet nu, wanneer dan?
</p></blockquote>
<p>
De beslissing om te starten met het GNU-project is hierop ge&iuml;nspireerd.</p>
<p>
(1) Als athe&iuml;st volg ik geen religieuze leiders, maar soms ontdek ik
dat ik iets bewonder wat sommige van ze hebben gezegd.</p>

<h3>Vrij als in vrijheid</h3>
<p>
De term &ldquo;vrije software&rdquo; wordt soms verkeerd opgevat&mdash;het
heeft niets met prijs te maken. Het gaat om vrijheid (het Engelse
&ldquo;free&rdquo; kan zowel <em>vrij</em> als <em>gratis</em> betekenen,
vandaar deze uitleg). Daarom hier de definitie van vrije software.</p>

<p>Een programma kun je vrije software noemen, voor jou als gebruiker, wanneer:</p>

<ul>
  <li>Je hebt de vrijheid het programma uit te voeren, voor welk doel dan ook.</li>

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

  <li>Je de vrijheid hebt om kopie&euml;n te verspreiden, gratis of tegen
betaling.</li>

  <li>Je de vrijheid hebt om aangepaste versies van het programma te verspreiden,
zodat je verbeteringen de gemeenschap ten goede komen.</li>
</ul>
<p>
Omdat &ldquo;vrij&rdquo; hier slaat op vrijheid, niet de prijs, is er geen
tegenstelling tussen het verkopen van kopie&euml;n en vrije software. In
feite is de vrijheid om kopie&euml;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.</p>
<p>
Vanwege de dubbelzinnigheid van &ldquo;free&rdquo;, 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 &ldquo;vrij&rdquo; betekent, als in
vrijheid&mdash;&ldquo;ongeketend&rdquo; is het woord dat er het dichtst bij
komt. Alternatieven als &ldquo;bevrijd&rdquo;, &ldquo;vrijheid&rdquo;, en
&ldquo;open&rdquo; hebben ofwel de verkeerde betekenis of een ander nadeel.</p>

<h3>GNU-software en het GNU-systeem</h3>
<p>
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.</p>
<p>
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.</p>

<h3>Start van het project</h3>
<p>
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&euml;ren van een nieuwe software-delende gemeenschap.</p>
<p>
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.</p>

<h3>De eerste stappen</h3>
<p>
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.</p>
<p>
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.</p>
<p>
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.</p>
<p>
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 &ldquo;instructies&rdquo;, 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 <abbr title="GNU Compiler
Collection">GCC</abbr>; 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.</p>

<h3>GNU Emacs</h3>
<p>
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.</p>
<p>
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&iuml;nteresseerden geen Internet toegang
en konden geen kopie per ftp krijgen. De vraag was dus, wat had ik ze te
vertellen?</p>
<p>
Ik zou hebben kunnen zeggen &ldquo;Zoek een kennis die op het net zit die
een kopie voor je kan maken.&rdquo; Of ik had hetzelfde kunnen doen als ik
heb gedaan met de originele PDP-10 Emacs: tegen ze zeggen, &ldquo;Stuur me
een tape en een aan jezelf geadresseerde envelop, dan stuur ik het terug met
Emacs erop.&rdquo; 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.</p>

<h3>Is een programma vrij voor iedere gebruiker?</h3>
<p>
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: <a
href="/philosophy/categories.html#PublicDomainSoftware"> publiek domein
software</a> (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.</p>
<p>
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&euml;n van X waren net zo min vrij als Unix was.</p>
<p>
De ontwikkelaars van het X Window systeem vonden dit geen probleem&mdash;ze
verwachten en wilden dat het gebeurde. Hun doel was niet vrijheid, enkel
&ldquo;succes&rdquo;, als in &ldquo;veel gebruikers&rdquo;. Het kon ze niet
schelen of de gebruikers vrijheid hadden, alleen dat het er veel zouden
zijn.</p>
<p>
Dit leidde tot de paradoxale situatie dat twee verschillende manieren om de
hoeveelheid vrijheid te meten, verschillende antwoorden gaven op de vaag
&ldquo;Is dit programma vrij?&rdquo;. 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.</p>

<h3>Auteursplicht en de GNU GPL</h3>
<p>
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 &ldquo;auteursplicht&rdquo;(1)  (of op zijn Engels:
&ldquo;copyleft&rdquo;)</p>
<p>
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.</p>
<p>
Het idee van auteursplicht is dat we iedereen toestaan het programma te
draaien, te kopi&euml;ren, aan te passen, en aangepaste versies te
distribueren&mdash;maar niet toestaan om eigen beperkingen toe te voegen.
De cruciale vrijheden die &ldquo;vrije software&rdquo; defini&euml;ren
worden daarom gegarandeerd aan iedereen die een kopie heeft; het worden
onvervreemdbare rechten.</p>
<p>
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, &ldquo;Jij kunt die veranderingen niet delen, omdat
we ze gaan gebruiken voor onze private versie van het programma.&rdquo;</p>
<p>
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.</p>
<p>
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.</p>
<p>
De specifieke implementatie van auteursplicht die we voor de meeste
GNU-software gebruiken is de GNU General Public License (&ldquo;GNU Algemene
Publieke Licentie&rdquo;, 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)</p>
<p>
(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: &ldquo;Copyleft&mdash;all rights reversed.&rdquo;
(&ldquo;Auteursplicht&mdash;alle rechten omgedraaid&rdquo;, nvdv). Ik
gebruikte het woord &ldquo;auteursplicht&rdquo; als werknaam voor het
distributieconcept dat ik op dat moment aan het ontwikkelen was.</p>

<p>
(2) We gebruiken nu de <a href="/licenses/fdl.html"> GNU Free Documentation
License </a> ("GNU Vrije Documentatie Licentie", nvdv) voor documentatie.</p>

<h3>De Free Software Foundation (Stichting voor Vrije Software)</h3>

<p>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 <a href="http://www.fsf.org/">Free Software
Foundation</a> op in 1985, een goed doel, belastingaftrekbaar, voor vrije
software ontwikkeling. De <abbr title="Free Software Foundation">FSF</abbr>
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.</p>

<p>De FSF accepteert donaties, maar het grootste deel van de inkomsten kwam
altijd uit de verkoop&mdash;kopie&euml;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 <a href="http://shop.fsf.org/">handleidingen en
aanverwante artikelen</a>, maar het meeste komt van bijdragen uit de
lidmaatschap.  Je kunt lid worden van de FSF bij <a
href="http://fsf.org/join">fsf.org</a>.</p>

<p>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 <abbr title="Bourne
Again Shell">BASH</abbr>, de Bourne Again Shell(1), die werd ontwikkeld door
FSF werknemer Brian Fox.</p>

<p>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.</p>

<p>(1) &ldquo;Bourne again Shell&rdquo; (<em>Opnieuw geboren Schil</em>, nvdv)
is een woordgrapje met de naam &ldquo;Bourne Shell&rdquo;, de meest
voorkomende shell op Unix.</p>

<h3>Ondersteuning voor vrije software</h3>

<p>De vrije-softwarefilosofie verwerpt een bepaalde veel voorkomende vorm van
commerci&euml;le activiteit, maar is niet vies van commercie. Als bedrijven
de vrijheid van gebruikers respecteren, wensen wij hen succes.</p>

<p>De verkoop van kopie&euml;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.</p>

<p>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.</p>

<p>Maar pas op: een aantal bedrijven die zichzelf associ&euml;ren met de term
&ldquo;open source&rdquo; (&ldquo;open broncode&rdquo;, 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
&ldquo;toegevoegde waarde&rdquo;, waarin ze andere normen aan ons op willen
dringen: gemak boven vrijheid. Als wij meer waarde hechten aan vrijheid,
zouden we ze &ldquo;minus vrijheid&rdquo; producten noemen.</p>

<h3>Technische doelen</h3>

<p>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.</p>

<p>Maar van nature pasten we de bekende standaarden voor goed werk
toe&mdash;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.</p>

<p>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&eacute; werken met hele grote bestanden, moedigden we programmeurs
aan om het invoer bestand in &eacute;&eacute;n keer in geheugen in te lezen,
en dan de inhoud te scannen zonder aandacht te besteden aan Invoer/Uitvoer.</p>

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

<h3>Gedoneerde computers</h3>

<p>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 &uuml;berhaupt een Unix kopie hadden.</p>

<p>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.</p>

<p>Maar, ook al was dit een noodzakelijk kwaad, het was nog altijd een
kwaad. Tegenwoordig hebben we geen Unix kopie&euml;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.</p>

<h3>De GNU-takenlijst</h3>

<p>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.</p>

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

<p>Zelfs spelletjes worden op de takenlijst gezet&mdash;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.</p>

<p>(1) Dit was geschreven in 1998. Sinds 2009 houden we geen lange takenlijst
meer bij. De gemeenschap ontwikkelt z&oacute; 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.</p>

<h3>De GNU Programmabibliotheek GPL</h3>

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

<p>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.</p>

<p>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&mdash;het zou alleen gebruik van onze bibliotheek hebben
ontmoedigd.</p>

<p>&Eacute;&eacute;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.</p>

<p>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.</p>

<p>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 &eacute;&eacute;n toepassing vrije software
geworden zodat het Readline kon gebruiken, dat is echte meerwaarde voor de
gemeenschap.</p>

<p>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.</p>

<p>(1) Deze licentie wordt nu de GNU Lesser General Public License (&ldquo;GNU
Verminderde Algemene Publieke Licentie&rdquo;) genoemd, om verwarring, dat
alle bibliotheken het zouden moeten gebruiken, te voorkomen.  <a
href="/philosophy/why-not-lgpl.html">Waarom je niet de Lesser GPL moet
gebruiken voor je volgende programmabibliotheek</a>.</p>

<h3>Krabben aan jeuk?</h3>
<p>
Eric Raymond zegt dat &ldquo;Ieder goed stuk software ontstaat door het
krabben aan de persoonlijke jeuk van een ontwikkelaar.&rdquo; Misschien
gebeurd dat wel eens, maar veel essenti&euml;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.</p>
<p>
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&mdash;de GNU C-compiler, GNU Emacs, GDB
en GNU Make.</p>
<p>
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 <abbr title="Lempel-Ziv-Welch">LZW</abbr>-patenten. We hebben
mensen gevonden om LessTif te maken, en recent startte <abbr title="GNU
Network Object Model Environment">GNOME</abbr> 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.</p>
<p>
Uiteraard raakten de mensen die deze programma's schrijven
ge&iuml;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.</p>

<h3>Onverwachte wendingen</h3>
<p>
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.</p>
<p>
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&mdash;naar de verschillende versies van Unix, en soms ook naar
andere systemen.</p>
<p>
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 &eacute;&eacute;n voor &eacute;&eacute;n
schrijven van de benodigde onderdelen.</p>

<h3>De GNU Hurd</h3>
<p>
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 &ldquo;herd of
gnus&rdquo; (&ldquo;kudde gnoes&rdquo;, 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.</p>
<p>
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.</p>

<h3>Alix</h3>
<p>
De GNU-kernel zou eerst niet de naam Hurd krijgen. De originele naam was
Alix&mdash;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
&ldquo;Iemand zou een kernel naar mij moeten noemen.&rdquo; Ik zei niets,
maar besloot haar te verassen met een kernel &ldquo;Alix&rdquo;.</p>
<p>
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&mdash;het deel dat systeemaanroepen
zou afvangen, en de aanvraag zou verwerken door berichten naar Hurd-servers
te zenden.</p>
<p>
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.</p>
<p>
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.</p>

<h3>Linux en GNU/Linux</h3>
<p>
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.</p>

<p>
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.</p>
<p>
Wij noemen deze versie <a href="/gnu/linux-and-gnu.html">GNU/Linux</a>, om
aan te geven dat het een combinatie betreft van het GNU-systeem met Linux
als kernel. Noem het hele systeem alsjeblief geen &ldquo;Linux&rdquo;, omdat
dat zou betekenen dat ons werk aan iemand anders wordt toegeschreven. Benoem
ons alsjeblieft <a href="/gnu/gnu-linux-faq.html">op een gelijkwaardige
manier</a>.</p>

<h3>Uitdagingen voor de toekomst</h3>
<p>
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.</p>
<p>
De volgende vier secties behandelen deze uitdagingen.</p>

<h3>Geheime hardware</h3>
<p>
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.</p>
<p>
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.</p>
<p>
Het ontrafelen van software is een zware taak; hebben we hier programmeurs
met voldoende doorzettingsvermogen voor? Ja&mdash;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.</p>
<p>
(2008 voetnoot: dit speelt ook in de BIOS. Er is een vrije BIOS, <a
href="http://www.libreboot.org/">LibreBoot</a> (een distributie van
coreboot); het probleem is het verkrijgen van specificaties van machines
zodat LibreBoot die kan ondersteunen zonder niet-vrije &ldquo;blobs&rdquo;.)</p>

<h3>Niet-vrije programmabibliotheken</h3>
<p>
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 <em>draaien</em> als de bibliotheek mist.)
Sterker nog, als een programma populair wordt dat private bibliotheken
gebruikt kan het andere nietsvermoedende programmeurs in de val lokken.</p>
<p>
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.</p>
<p>
Tussen 1996 en 1998 werd een andere niet-vrije <abbr title="Graphical User
Interface">GUI</abbr> toolkit (een programmabibliotheek met grafische
hulpmiddelen), Qt genoemd, gebruikt in een aanzienlijke hoeveelheid vrije
software, de bureaublad software <abbr title="K Desktop
Environment">KDE</abbr>.</p>
<p>
Vrije GNU/Linux-systemen konden KDE niet gebruiken omdat we de bibliotheek
niet konden inzetten. Sommige commerci&euml;le distributeurs van
GNU/Linux-systemen, die niet principieel waren met vrije software, voegden
KDE toe aan hun systemen&mdash;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 &ldquo;Linux gebruikers&rdquo;
wisten niet dat dit een probleem was. Het zag er moeilijk uit.</p>
<p>
De vrije software gemeenschap reageerde op twee manieren: GNOME en Harmony.</p>
<p>
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.</p>
<p>
Harmony is een vervanger voor Qt, met dezelfde interface, zodat KDE-software
kan draaien zonder Qt.</p>
<p>
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.)</p>
<p>
[Aanvullende noot: in september 2000 werd Qt opnieuw uitgebracht onder de
GNU GPL, dit probleem is nu in feite opgelost.]</p>
<p>
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.</p>

<h3>Softwarepatenten</h3>
<p>
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 <abbr
title="Graphics Interchange Format">GIF</abbr>s maakt [Sinds 2009 zijn ze
verlopen]. In 1998 kon een vrij programma dat <abbr title="MPEG-1 Audio
Layer 3">MP3</abbr> audiobestanden comprimeerde niet meer worden
uitgebracht, onder dreiging van een patent-rechtszaak.
</p>
<p>
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 terwijl gebruikers het willen. Na lang
wachten zullen de patenten verlopen (MP3-patenten zullen naar verwachting in
2018 verlopen zijn), maar wat doen we tot dan?</p>
<p>
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&euml;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.</p>

<h3>Vrije documentatie</h3>
<p>
Het grootste gebrek in onze vrije besturingssystemen ligt niet in de
software&mdash;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.</p>
<p>
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&euml;le handel) moet worden
toegestaan, elektronisch en op papier, zodat de handleiding met iedere kopie
van het programma kan worden geleverd.</p>
<p>
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.</p>
<p>
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&mdash;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.</p>
<p>
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.</p>
<p>
Het moet echter mogelijk blijven alle <em>technische</em> 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.</p>
<p>
Zullen vrije-software-ontwikkelaars de oplettendheid en het
doorzettingsvermogen hebben om een breed spectrum vrije handleidingen te
produceren? Onze filosofie bepaalt onze toekomst.</p>

<h3>We moeten het over vrijheid hebben</h3>
<p>
Er wordt heden ten dage geschat dat er tientallen miljoenen gebruikers van
GNU/Linux-systemen zoals Debian GNU/Linux en Red Hat &ldquo;Linux&rdquo;
zijn.  Vrije software heeft zoveel praktische voordelen ontwikkeld, dat
gebruikers alleen daar al massaal op af komen.</p>
<p>
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&euml;le vrije software
in plaats van private software te maken.</p>
<p>
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&euml;n te verspreiden naar nieuwe gebruikers,
als ze met de gemeenschap in aanraking komen.</p>
<p>
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.</p>

<h3>&ldquo;Open source&rdquo;</h3>
<p>
Aanleren van het basisprincipe vrijheid aan nieuwe gebruikers werd
moeilijker in 1998, toen een deel van de gemeenschap besloot te stoppen met
de term &ldquo;vrije software&rdquo;, en over &ldquo;open source
software&rdquo; (&ldquo;software met open broncode&rdquo;) begon te spreken.</p>
<p>
Er waren er die de voorkeur gaven aan de nieuwe term, omdat het
&ldquo;vrij&rdquo; niet met &ldquo;gratis&rdquo; kan worden verward&mdash;op
zich een goede reden. Anderen stelden zich echter ten doel om de
principi&euml;le inspiratie die de vrije-softwarebeweging en het GNU-project
gemotiveerd hadden, opzij te zetten, om in de gunst van bedrijfsleiders en
commerci&euml;le gebruikers te komen, waarvan velen een ideologie aanhangen
die winst boven vrijheid stelt, boven gemeenschap, boven principes. De
&ldquo;open source&rdquo;-retoriek richt zich op de mogelijkheid kwalitatief
hoogstaande en krachtige software te maken, maar schudt idee&euml;n als
vrijheid, gemeenschap en principes van zich af.</p>
<p>
De &ldquo;Linux&rdquo;-bladen zijn hier een duidelijk voorbeeld van&mdash;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?</p>
<p>
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.</p>
<p>
&ldquo;Vrije software&rdquo; en &ldquo;open source&rdquo; 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 &ldquo;vrije software&rdquo;, om duidelijk te maken dat het over
vrijheid gaat, meer dan slechts techniek.</p>

<h3>Proberen!</h3>
<p>
Yoda's aforisme (&ldquo;&lsquo;Proberen&rsquo; bestaat niet&rdquo;) 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.</p>
<p>
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.</p>
<p>
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&mdash;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.</p>

<div class="translators-notes">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
 </div>
</div>

<!-- for id="content", starts in the include above -->
<!--#include virtual="/server/footer.nl.html" -->
<div id="footer">
<div class="unprintable">

<p>Gelieve algemene vragen over FSF &amp; GNU te sturen naar <a
href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Er zijn ook nog <a
href="/contact/">andere manieren om in contact te komen</a> met de
FSF. Foute links en andere correcties graag sturen aan <a
href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>

<p>
<!-- TRANSLATORS: Ignore the original text in this paragraph,
        replace it with the translation of these two:

        We work hard and do our best to provide accurate, good quality
        translations.  However, we are not exempt from imperfection.
        Please send your comments and general suggestions in this regard
        to <a href="mailto:web-translators@gnu.org">

        &lt;web-translators@gnu.org&gt;</a>.</p>

        <p>For information on coordinating and submitting translations of
        our web pages, see <a
        href="/server/standards/README.translations.html">Translations
        README</a>. -->
We doen ons best om goede vertalingen te maken maar staan altijd open voor
verbeteringen. Suggesties, op- en aanmerkingen sturen aan: <a
href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>.</p>
<p>Zie <a href="/server/standards/README.translations.html"> Translations
README</a> voor informatie over het onderhoud van vertalingen op deze
website.</p>
</div>

<!-- Regarding copyright, in general, standalone pages (as opposed to
     files generated as part of manuals) on the GNU web server should
     be under CC BY-ND 4.0.  Please do NOT change or remove this
     without talking with the webmasters or licensing team first.
     Please make sure the copyright date is consistent with the
     document.  For web pages, it is ok to list just the latest year the
     document was modified, or published.
     If you wish to list earlier years, that is ok too.
     Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
     years, as long as each year in the range is in fact a copyrightable
     year, i.e., a year in which the document was published (including
     being publicly visible on the web or in a revision control system).
     There is more detail about copyright years in the GNU Maintainers
     Information document, www.gnu.org/prep/maintain. -->
<p>Copyright &copy; 1998, 2001, 2002, 2005, 2006, 2007, 2008, 2010, 2014, 2015,
2017 Richard Stallman</p>

<p>Deze pagina is uitgebracht onder een <a rel="license"
href="http://creativecommons.org/licenses/by-nd/4.0/">Creative Commons
Naamsvermelding-GeenAfgeleideWerken 4.0 Internationaal licentie</a>.</p>

<!--#include virtual="/server/bottom-notes.nl.html" -->
<div class="translators-credits">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
 <strong>Vertaling:</strong> <a
href="//savannah.gnu.org/projects/www-nl">www-nl</a></div>

<p class="unprintable"><!-- timestamp start -->
Bijgewerkt:

$Date: 2020/07/04 08:32:33 $

<!-- timestamp end -->
</p>
</div>
</div>
<!-- for class="inner", starts in the banner include -->
</body>
</html>