taler-merchant-demos

thegnuproject.html (60021B)

---

 <!--#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="2021-10-24" -->
 
 <!--#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. [Sinds 2017 zijn deze
 patenten verlopen, <strong>zo</strong> lang moesten we wachten.]
 </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 die gebruikers wel willen. Na lang wachten
 zullen de patenten verlopen, maar wat doen we zolang?</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, 2018, 2020 Richard Stallman</p>
 
 <p>Deze pagina is uitgebracht onder de <a rel="license"
 href="http://creativecommons.org/licenses/by-nd/4.0/deed.nl">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: 2021/12/25 21:34:16 $
 
 <!-- timestamp end -->
 </p>
 </div>
 </div>
 <!-- for class="inner", starts in the banner include -->
 </body>
 </html>