diff options
Diffstat (limited to 'talermerchantdemos/blog/articles/nl/thegnuproject.html')
| -rw-r--r-- | talermerchantdemos/blog/articles/nl/thegnuproject.html | 1115 |
1 files changed, 1115 insertions, 0 deletions
diff --git a/talermerchantdemos/blog/articles/nl/thegnuproject.html b/talermerchantdemos/blog/articles/nl/thegnuproject.html new file mode 100644 index 0000000..1f0413d --- /dev/null +++ b/talermerchantdemos/blog/articles/nl/thegnuproject.html @@ -0,0 +1,1115 @@ +<!--#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 “open source”</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 ‘Incompatibele Timesharing +Systeem’) 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, éé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 “vrije software”, omdat die term +nog niet bestond; maar dat was het. Telkens wanneer mensen van een andere +universiteit of bedrijf een programma wilde vertalen en gebruiken voor een +ander platform, lieten we ze met plezier hun gang gaan. Als je iemand een +onbekend en interessant programma zag gebruiken, kon je altijd vragen om de +bron code zodat je het kon lezen, veranderen, en er stukken uit slopen om +een nieuw programma te maken.</p> +<p> +(1) Het gebruik van het woord “hacker” in de betekenis van +“digitale inbreker” is een fout van de media. Wij hackers +weigeren deze betekenis te accepteren, en gaan door met de originele +betekenis “Iemand die van programmeren houdt en/of er plezier in heeft er +goed in te zijn”. Zie ook mijn artikel: <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, +“Als u uw software deelt met uw buurman, bent u een piraat. Als u +veranderingen wilt in een programma, smeek ons er dan om.”</p> +<p> +Het idee dat het systeem van private software—dat voorschrijft dat u +geen software mag veranderen of delen—asociaal is, of onethisch, of +zelfs simpelweg fout, kan als een verassing komen voor sommige lezers. Maar +welk ander oordeel kunnen we vellen over een systeem gebaseerd op het +verdeel- en heers-principe waarbij gebruikers machteloos worden gemaakt? +Lezers die dit idee verbaast, hebben misschien het systeem van private +software als een gegeven beschouwd, of klakkeloos de zienswijze van private +softwarebedrijven overgenomen. Softwarebedrijven hebben tenslotte lang en +hard gewerkt om mensen te overtuigen dat er maar één manier is +om naar deze zaak te kijken.</p> +<p> +Als software uitgevers praten over “handhaving” van hun +“rechten” of het “stoppen van <a +href="/philosophy/words-to-avoid.html#Piracy">piraterij</a>”; 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ële traditie van +de VS deze uitleg verwerpen; auteursrecht is geen natuurlijk recht, maar een +kunstmatig door de overheid in stand gehouden monopolie, dat het natuurlijk +gebruikersrecht om te kopiëren aan banden legt.</p> +<p> +Een andere stilzwijgende aanname is dat het enige belangrijke aan software +is wat je er mee kunt doen—dat wij computergebruikers niet +maatschappelijk betrokken zouden mogen zijn.</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—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: “GNU's Not Unix” (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ïnspireerd.</p> +<p> +(1) Als atheï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 “vrije software” wordt soms verkeerd opgevat—het +heeft niets met prijs te maken. Het gaat om vrijheid (het Engelse +“free” 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ë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 “vrij” hier slaat op vrijheid, niet de prijs, is er geen +tegenstelling tussen het verkopen van kopieën en vrije software. In +feite is de vrijheid om kopieën te verkopen cruciaal: een verzameling +vrije software, verkocht op CD-ROMs, zijn belangrijk voor de gemeenschap, en +de verkoop is een belangrijke manier om geld in te zamelen voor vrije +software ontwikkeling. Daarom is een programma dat mensen niet bij zo'n +verzameling kunnen voegen geen vrije software.</p> +<p> +Vanwege de dubbelzinnigheid van “free”, zijn mensen al lang op +zoek naar alternatieven, maar niemand heeft er nog een gevonden. De Engelse +taal heeft meer woorden en nuances dan iedere andere taal, maar het mist een +simpel ondubbelzinnig wordt dat “vrij” betekent, als in +vrijheid—“ongeketend” is het woord dat er het dichtst bij +komt. Alternatieven als “bevrijd”, “vrijheid”, en +“open” hebben ofwel de verkeerde betekenis of een ander nadeel.</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ë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 “instructies”, om daarna het hele +uitvoerbestand te genereren, zonder ooit geheugenruimte vrij te geven. Op +dat moment besefte ik dat ik een nieuwe compiler vanaf de grond zou moeten +opbouwen. Die nieuwe compiler staat nu bekend als <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ï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 “Zoek een kennis die op het net zit die +een kopie voor je kan maken.” Of ik had hetzelfde kunnen doen als ik +heb gedaan met de originele PDP-10 Emacs: tegen ze zeggen, “Stuur me +een tape en een aan jezelf geadresseerde envelop, dan stuur ik het terug met +Emacs erop.” Maar ik had geen werk, en zocht manieren om geld te +verdienen met vrije software. Daarom verklaarde ik dat ik een tape met Emacs +voor een vergoeding van $150 op zou sturen naar wie het maar wilde hebben. +Op deze manier begon ik de vrije-software-business, een voorloper van de +bedrijven die vandaag de dag hele GNU/Linux-systemen distribueren.</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ën van X waren net zo min vrij als Unix was.</p> +<p> +De ontwikkelaars van het X Window systeem vonden dit geen probleem—ze +verwachten en wilden dat het gebeurde. Hun doel was niet vrijheid, enkel +“succes”, als in “veel gebruikers”. Het kon ze niet +schelen of de gebruikers vrijheid hadden, alleen dat het er veel zouden +zijn.</p> +<p> +Dit leidde tot de paradoxale situatie dat twee verschillende manieren om de +hoeveelheid vrijheid te meten, verschillende antwoorden gaven op de vaag +“Is dit programma vrij?”. Als je het beoordeelde op basis van de +vrijheden die de MIT publicatie toeliet, zou je zeggen dat X vrije software +was. Maar als je het zou meten aan de vrijheid van de gemiddelde gebruiker +van X, zou je zeggen dat het private software was. De meeste X gebruikers +gebruikten de private versie die gebundeld was met Unix systemen, niet de +vrije versie.</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 “auteursplicht”(1) (of op zijn Engels: +“copyleft”)</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ëren, aan te passen, en aangepaste versies te +distribueren—maar niet toestaan om eigen beperkingen toe te voegen. +De cruciale vrijheden die “vrije software” definiëren +worden daarom gegarandeerd aan iedereen die een kopie heeft; het worden +onvervreemdbare rechten.</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, “Jij kunt die veranderingen niet delen, omdat +we ze gaan gebruiken voor onze private versie van het programma.”</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 (“GNU Algemene +Publieke Licentie”, nvdv). We hebben andere soorten auteursplicht die +worden gebruikt in speciale omstandigheden. GNU handleidingen worden ook +auteursplichtig, maar gebruiken een veel eenvoudiger vorm, omdat de +gecompliceerdheid van de GNU GPL onnodig is voor handleidingen.(2)</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: “Copyleft—all rights reversed.” +(“Auteursplicht—alle rechten omgedraaid”, nvdv). Ik +gebruikte het woord “auteursplicht” als werknaam voor het +distributieconcept dat ik op dat moment aan het ontwikkelen was.</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—kopieën van vrije software, en aanverwante +diensten. Vandaag de dag verkoopt het CD-ROMs met broncode, CD-ROMs met +binaire bestanden, mooi gedrukte handleidingen (allemaal met de vrijheden om +verder te distribueren en aan te passen), en Luxe Distributies (waar we de +hele softwarecollectie op maat maken voor het door u gekozen platform). De +FSF verkoopt nog steeds <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) “Bourne again Shell” (<em>Opnieuw geboren Schil</em>, nvdv) +is een woordgrapje met de naam “Bourne Shell”, 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ë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ë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ëren met de term +“open source” (“open broncode”, nvdv), baseren hun +handel op niet-vrije software die werkt met vrije software. Dit zijn geen +vrije software bedrijven, het zijn private software bedrijven wiens +producten gebruikers wegleiden van vrijheid. Ze noemen het +“toegevoegde waarde”, waarin ze andere normen aan ons op willen +dringen: gemak boven vrijheid. Als wij meer waarde hechten aan vrijheid, +zouden we ze “minus vrijheid” producten noemen.</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—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é werken met hele grote bestanden, moedigden we programmeurs +aan om het invoer bestand in één keer in geheugen in te lezen, +en dan de inhoud te scannen zonder aandacht te besteden aan Invoer/Uitvoer.</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 ü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ë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—dat werk is gedaan, op een paar minder belangrijke +dingen na. Maar de lijst staat vol met projecten die door sommigen +“toepassingen” genoemd zouden worden. Elk programma dat +aantrekkelijk is voor meer dan een hele speciale klasse gebruikers zou een +goede toevoeging aan een besturingssysteem zijn.</p> + +<p>Zelfs spelletjes worden op de takenlijst gezet—dit was al zo vanaf het +begin. Unix had spelletjes, dus GNU natuurlijk ook. Maar samen kunnen werken +met Unix op dit gebied was niet belangrijk voor spelletjes, dus we volgden +niet de Unix lijst met spelletjes. In plaats daarvan maakten we een +spectrum van verschillende soorten spelletjes die gebruikers wellicht leuk +zouden vinden.</p> + +<p>(1) Dit was geschreven in 1998. Sinds 2009 houden we geen lange takenlijst +meer bij. De gemeenschap ontwikkelt zó snel vrije software dat we dit +niet allemaal meer bij kunnen houden. In plaats daarvan hebben we nu een +lijst met Belangrijkste Projecten, een lijst met projecten waarvan we echt +graag willen dat ze uit worden gevoerd.</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—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—het zou alleen gebruik van onze bibliotheek hebben +ontmoedigd.</p> + +<p>Éé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 éé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 (“GNU +Verminderde Algemene Publieke Licentie”) 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 “Ieder goed stuk software ontstaat door het +krabben aan de persoonlijke jeuk van een ontwikkelaar.” Misschien +gebeurd dat wel eens, maar veel essentiële stukken GNU-software werden +ontwikkeld om een compleet vrij besturingssysteem te hebben. Ze komen voort +uit een visie, een plan, niet uit een impuls.</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—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ï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—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 één voor éé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 “herd of +gnus” (“kudde gnoes”, nvdv)) die bovenop Mach draaien, en +die de verschillende taken van de Unixkernel uitvoeren. De start van de +ontwikkeling werd vertraagd terwijl we wachtten tot Mach als vrije software +werd vrijgegeven, zoals was beloofd.</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—vernoemd naar de vrouw die ik toen liefhad. Zij, een Unix +systeembeheerder, wees op het feit dat haar naam een algemeen patroon van +Unix-systeem versies volgde; als grap vertelde ze haar vrienden +“Iemand zou een kernel naar mij moeten noemen.” Ik zei niets, +maar besloot haar te verassen met een kernel “Alix”.</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—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 “Linux”, 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—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 “blobs”.)</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ële distributeurs van +GNU/Linux-systemen, die niet principieel waren met vrije software, voegden +KDE toe aan hun systemen—waardoor hun producten meer konden, maar met +minder vrijheid. De KDE-groep probeerde meer programmeurs over te halen om +Qt te gaan gebruiken, en miljoenen nieuwe “Linux gebruikers” +wisten niet dat dit een probleem was. Het zag er moeilijk uit.</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ë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—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ë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—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 “Linux” +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ë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ë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>“Open source”</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 “vrije software”, en over “open source +software” (“software met open broncode”) begon te spreken.</p> +<p> +Er waren er die de voorkeur gaven aan de nieuwe term, omdat het +“vrij” niet met “gratis” kan worden verward—op +zich een goede reden. Anderen stelden zich echter ten doel om de +principiële inspiratie die de vrije-softwarebeweging en het GNU-project +gemotiveerd hadden, opzij te zetten, om in de gunst van bedrijfsleiders en +commerciële gebruikers te komen, waarvan velen een ideologie aanhangen +die winst boven vrijheid stelt, boven gemeenschap, boven principes. De +“open source”-retoriek richt zich op de mogelijkheid kwalitatief +hoogstaande en krachtige software te maken, maar schudt ideeën als +vrijheid, gemeenschap en principes van zich af.</p> +<p> +De “Linux”-bladen zijn hier een duidelijk voorbeeld van—ze +staan vol advertenties voor private software die met GNU/Linux werkt. Als +de volgende Motif of Qt verschijnt, zullen deze bladen dan de programmeurs +waarschuwen zich er niet mee in te laten, of zullen ze er advertenties voor +plaatsen?</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> +“Vrije software” en “open source” beschrijven min of +meer dezelfde software-categorie, maar ze zeggen verschillende dingen over +deze software, en over normen en waarden. Het GNU-project gaat door met de +term “vrije software”, om duidelijk te maken dat het over +vrijheid gaat, meer dan slechts techniek.</p> + +<h3>Proberen!</h3> +<p> +Yoda's aforisme (“‘Proberen’ bestaat niet”) klinkt +leuk, maar is niks voor mij. Meestal ben ik tijdens het werk in de stress of +ik het eigenlijk wel kan. Maar ik probeerde het toch, omdat er niemand +anders tussen de vijand en mijn stad stond. Tot mijn eigen verbazing is het +soms toch gelukt.</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—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 & GNU te sturen naar <a +href="mailto:gnu@gnu.org"><gnu@gnu.org></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"><webmasters@gnu.org></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"> + + <web-translators@gnu.org></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"><web-translators@gnu.org></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 © 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> |