diff options
Diffstat (limited to 'talermerchantdemos/blog/articles/nl/shouldbefree.html')
| -rw-r--r-- | talermerchantdemos/blog/articles/nl/shouldbefree.html | 951 |
1 files changed, 951 insertions, 0 deletions
diff --git a/talermerchantdemos/blog/articles/nl/shouldbefree.html b/talermerchantdemos/blog/articles/nl/shouldbefree.html new file mode 100644 index 0000000..5f808c5 --- /dev/null +++ b/talermerchantdemos/blog/articles/nl/shouldbefree.html @@ -0,0 +1,951 @@ +<!--#set var="ENGLISH_PAGE" value="/philosophy/shouldbefree.en.html" --> + +<!--#include virtual="/server/header.nl.html" --> +<!-- Parent-Version: 1.86 --> + +<!-- This file is automatically generated by GNUnited Nations! --> +<title>Waarom software vrij zou moeten zijn - GNU-project - Free Software +Foundation</title> + +<!--#include virtual="/philosophy/po/shouldbefree.translist" --> +<!--#include virtual="/server/banner.nl.html" --> +<h2>Waarom software vrij zou moeten zijn</h2> + +<p> +door <a href="http://www.stallman.org/"><strong>Richard +Stallman</strong></a></p> +<h3 id="introduction">Introductie</h3> +<p> +Het bestaan van software leidt onherroepelijk tot de vraag hoe men beslist +over het gebruik ervan. Een individu bijvoorbeeld, met een kopie van een +programma, loopt iemand anders tegen het lijf die ook een kopie zou willen +hebben. Het is mogelijk om hiervan een kopie te maken; wie zou mogen +beslissen of dit ook gebeurt? De betreffende personen? Of een andere partij, +te weten de “eigenaar”?</p> +<p> + Softwareontwikkelaars gaan er doorgaans vanuit dat een beslissing gebaseerd +zal zijn op het maximaliseren van de winst voor de ontwikkelaar. De +politieke kracht van bedrijven heeft ertoe geleid dat de regering dit +criterium heeft overgenomen en ook het antwoord wat daarop gegeven wordt +door de ontwikkelaars: dat een programma een eigenaar heeft, meestal een +bedrijf wat betrokken was bij de ontwikkeling.</p> +<p> + Ik zou graag diezelfde vraag in overweging willen nemen maar dan met een +ander uitgangspunt: de voorspoed en vrijheid van mensen in het algemeen.</p> +<p> + De beslissing kan niet genomen worden door huidige wetgeving—de wet +dient de ethiek te volgen, niet andersom. De huidige manier van werken kan +dit ook niet beslissen, maar wel een mogelijke richting aangeven. De enige +manier om dit goed te kunnen beoordelen is door te kijken wie er mee is +geholpen (en waarom en hoeveel) en wie niet wanneer we erkennen dat software +in eigendom kan zijn. Oftewel, een kosten-batenanalyse voor de maatschappij +als geheel, rekening houdend met individuele vrijheid alsook de productie +van materiële goederen.</p> +<p> + In dit artikel zal ik de gevolgen beschrijven wanneer software in eigendom +wordt genomen en aantonen dat dit schadelijk is. Mijn conclusie is dat +programmeurs de plicht hebben om iedereen aan te moedigen de software die ze +maken te delen, te kopiëren, te bestuderen en te verbeteren: oftewel om +<a href= "/philosophy/free-sw.html">“vrije” software</a> te +maken.<a href= "#f1">(1)</a></p> + +<h3 id="owner-justification">Hoe eigenaren hun macht rechtvaardigen</h3> +<p> + Degenen die baat hebben bij de huidige praktijk van programma's die bezit +vormen, komen met twee rechtvaardigingen hiervoor: een emotionele en een +economische.</p> +<p> + Het emotionele argument gaat als volgt: “Ik heb mijn bloed, zweet en +tranen in dit programma zitten. <em>Ik</em> heb het gemaakt, het is van +<em>mij</em>!”</p> +<p> + Dit argument hoeven we amper te weerleggen. De gehechtheid aan een programma +is iets wat programmeurs kunnen veinzen wanneer het ze uit komt; het is niet +onontkoombaar. Ga bijvoorbeeld maar eens na hoe makkelijk diezelfde +programmeurs al hun rechten inleveren bij een bedrijf in ruil voor een +salaris; de emotionele band met de programmatuur verdwijnt als sneeuw voor +de zon. Zet daar de grote kunstenaars en ambachtslieden uit de Middeleeuwen +tegenover, die hun werk niet eens signeerden. Voor hen was de naam van de +kunstenaar niet belangrijk. Wat van belang was was het werk dat gedaan moest +worden—en het doel dat dit diende. Zo heeft men er eeuwen tegenaan +gekeken.</p> +<p> + Het economische argument gaat als volgt: “Ik wil rijk worden (vaak wat +slordig omschreven als 'je brood verdienen'), en als je mij niet toestaat +rijk te worden door te programmeren dan ga ik niet programmeren. Iedereen +denkt er zo over dus niemand zal dan ooit programmeren. En dan zul je dus +geen programma's meer hebben!” Dit wordt meestal gebracht als een +vriendelijk advies van hen die het weten kunnen.</p> +<p> + Ik zal later uitleggen waarom dit dreigement bluf is. Eerst wil ik het +hebben over een stille aanname die duidelijk wordt in een andere versie van +datzelfde argument.</p> +<p> + Daarbij begint men het sociale nut van een privaat programma te vergelijken +met de situatie dat er geen programma is, waarbij men de conclusie trekt +dat, door de bank genomen, private software dus nut heeft en moet worden +gestimuleerd. De fout in deze redenering is dat men slechts twee +mogelijkheden vergelijkt— private software of geen software—en +aanneemt dat er geen andere alternatieven zijn.</p> +<p> + Door het systeem van auteursrechten is de ontwikkeling van software meestal +geassocieerd met een eigenaar die bepaalt hoe de software wordt gebruikt. +Zolang deze associatie bestaat hebben we dus meestal de keus tussen private +software of geen software. Deze associatie is echter geen wetmatigheid of +onontkoombaar: het is slechts het gevolg van onze sociale en juridische +beleidskeuze die we hier aan de tand voelen: de beslissing om eigenaren te +hebben. Door het neer te zetten als een keuze tussen private software of +geen software wordt de vraag ontweken.</p> + +<h3 id="against-having-owners">Argumenten tegen het eigenaarschap</h3> +<p> + De vraag is dus, “moet het ontwikkelen van software gebonden zijn aan +het hebben van eigenaren die het gebruik ervan kunnen limiteren?”.</p> +<p> + Om dit te kunnen beoordelen moeten we het effect van beide activiteiten op +de maatschappij <em>afzonderlijk</em> bekijken: het effect van het +ontwikkelen van software (ongeacht hoe dit gedistribueerd wordt) en het +effect van het beperken van het gebruikersrecht (aannemende dat de software +al ontwikkeld is). Als één ervan ons verder helpt en een ander +ons schaadt dan zijn we beter af wanneer we de schadelijke activiteit +stoppen.</p> +<p> + Anders gezegd, als het beperken van het gebruikersrecht van een programma +dat al is ontwikkeld schadelijk is voor de gemeenschap dan zal een +gewetensvolle programmeur geen beperkingen in dat recht aanbrengen.</p> +<p> + Om het effect van het beperken van het delen van programma's vast te kunnen +stellen moeten we vaststellen wat de waarde voor de gemeenschap is van een +programma met gebruikersbeperkingen (oftewel privaat) en dat van een +programma wat voor iedereen toegankelijk is. De twee mogelijkheden +vergelijken dus.</p> +<p> + Deze analyse weerlegt ook een tegenargument wat soms wordt gebruikt dat +“het voordeel dat men heeft door je buurman een kopie van het +programma te geven teniet wordt gedaan door het nadeel dat je de eigenaar +berokkent”. Dit tegenargument veronderstelt dat de berokkende schade +en het verkregen voordeel even groot zijn. De analyse vergelijkt dus ook de +ernst van de gevolgen en zal aantonen dat het verkregen voordeel veel groter +is dan de berokkende schade.</p> +<p> + Laten we de discussie ter verheldering eens toepassen op het bouwen van +wegen.</p> +<p> + Het is mogelijk om het bouwen van wegen te financieren met +tolheffing. Hiervoor heb je tolhuisjes nodig op iedere kruising. Een +dergelijk systeem bevat een grote prikkel om wegen te verbeteren. Bijkomend +voordeel is dat alleen gebruikers van die weg ervoor hoeven te betalen. Een +tolhuisje is echter een kunstmatig obstakel op de weg—kunstmatig +doordat het niets te maken heeft met hoe wegen of auto's werken.</p> +<p> + Wanneer we vervolgens het nut van tolwegen met vrije wegen vergelijken zien +we dat (over het geheel genomen) wegen zonder tolhuisjes goedkoper zijn om +te bouwen en te exploiteren, veiliger zijn en efficiënter in gebruik <a +href= "#f2">(2)</a>. In arme landen zal tolheffing bepaalde +bevolkingsgroepen uitsluiten van het gebruik van deze wegen. Wegen zonder +tolheffing geven dus een groter voordeel voor de maatschappij tegen minder +kosten; maatschappelijk gezien verdient dit dus de voorkeur. Dus dient de +maatschappij een andere manier dan tolheffing te vinden voor het financieren +van wegen. Het gebruik van wegen zou, wanneer ze eenmaal gebouwd zijn, vrij +moeten zijn.</p> +<p> + Wanneer voorstanders van tolhuisjes dit voorstellen als <em>slechts</em> een +manier om de financiering rond te krijgen dan is dat niet de hele waarheid. +Tolhuisjes brengen wel geld op maar ze doen ook nog iets anders: in feite +verslechteren ze de weg. Een tolweg is niet zo goed als een vrije weg; het +bouwen van meer- of technisch betere wegen zou wel eens geen vooruitgang +kunnen zijn wanneer dit betekent dat vrije wegen worden vervangen door +tolwegen.</p> +<p> + Uiteraard is het bouwen van een weg niet gratis en zullen we die met z'n +allen moeten financieren. Dit betekent echter niet automatisch dat we +tolhuisjes moeten inzetten. Wij, die in beide gevallen voor de kosten moeten +opdraaien krijgen meer waar voor ons geld wanneer we een vrije weg kopen.</p> +<p> + Ik beweer hier niet dat een tolweg nog slechter is dan helemaal geen +weg. Dat zou alleen opgaan wanneer de tol zo hoog is dat bijna niemand hem +zal gebruiken —iets wat niet snel voor zal komen doordat het niet in +het voordeel is van de tolheffer. Zolang tolhuisjes echter voor oponthoud en +verspilling blijven zorgen is het raadzaam om wegen op een minder +hinderlijke manier te financieren.</p> +<p> + Om deze redenering nu door te zetten naar software ontwikkeling zal ik laten +zien dat het de maatschappij behoorlijk wat schade berokkent wanneer we +dergelijke “tolhuisjes” opzetten voor nuttige programmatuur: het +maakt programma's duurder om te maken, duurder om te verspreiden en minder +bruikbaar en efficiënt. Hieruit zal blijken dat het maken van +programma's beter op een andere manier gestimuleerd kan worden. Daarna zal +ik andere methoden behandelen om softwareontwikkeling te stimuleren en (voor +zover nodig) te financieren.</p> + +<h4 id="harm-done">De schade van software met beperkingen</h4> +<p> + Neem even aan dat een nieuw programma is gemaakt en alle rekeningen voor de +ontwikkeling ervan zijn voldaan; nu moet de maatschappij een keuze maken +tussen het privaat (niet-vrij) maken van het programma of toestaan dat het +vrijelijk wordt gekopieerd en gebruikt. Laten we verder aannemen dat het +bestaan van het programma en de verkrijgbaarheid ervan wenselijk is <a +href="#f3" >(3)</a>.</p> +<p> + Beperkingen met betrekking tot de verspreiding of het veranderen van het +programma helpen niet in de verspreiding van het gebruik ervan. Het staat +dit maar in de weg. Het effect kan dus alleen maar negatief zijn. Maar hoe +erg? En op wat voor manier?</p> +<p> + Drie verschillende niveaus van materiële schade volgen uit dergelijke +beperkingen:</p> + +<ul> +<li>Minder mensen zullen het programma gebruiken.</li> + +<li>Geen enkele gebruiker kan het programma aanpassen of repareren.</li> + +<li>Andere ontwikkelaars kunnen niets leren van dit programma of het gebruiken +als basis voor nieuwe ontwikkelingen.</li> +</ul> + +<p> + Ieder niveau van materiële schade gaat ook gepaard met een zekere +psychosociale schade. Dit gaat om het fenomeen dat beslissingen van mensen +gevolgen hebben voor hun gevoelens, houding en gemoedstoestand. Dit soort +veranderingen in het denken van mensen zal op zijn beurt weer gevolgen +hebben op hun onderlinge relaties met anderen, wat weer tot materiële +gevolgen kan leiden.</p> +<p> + De drie niveaus van materiële schade doen afbreuk aan de bijdrage van +een programma maar niet zozeer dat er helemaal geen sprake meer is van een +bijdrage. Wanneer de afbreuk de bijdrage zou neutraliseren dan is de +maximale schade voor de gemeenschap gelijk aan de inspanning die het gekost +heeft om het programma te maken. Verder is aan te voeren dat een programma +dat winst maakt kennelijk iets toevoegt wat direct materieel resultaat +oplevert.</p> +<p> + Rekening houdend met de bijkomende psychosociale nadelen, is er geen grens +aan de mate waarin private software schade kan aanrichten.</p> + +<h4 id="obstructing-use">Gebruiksbeperkingen van programma's</h4> +<p> + Het eerste nadelige niveau heeft betrekking op het directe gebruik van een +programma. Een kopie van een programma kost bijna niets (en je kunt die +kosten nog drukken door zelf te kopiëren) dus in een vrije markt zou de +prijs bijna nul zijn. Een licentiebijdrage is een groot obstakel wanneer je +het programma wilt gebruiken. Wanneer een breed toepasbaar programma privaat +is zullen veel minder mensen het gebruiken.</p> +<p> + Het is eenvoudig aan te tonen dat de totale bijdrage van een programma aan +de gemeenschap wordt verminderd wanneer een programma een eigenaar +krijgt. Iedere potentiële gebruiker van het programma die wordt +geconfronteerd met de eis te betalen als ze het willen gebruiken zal een +keuze maken: gebruiken of niet. Wanneer de gebruiker beslist het te +gebruiken en dus te betalen vindt er een neutrale overdracht van welvaart +plaats tussen gebruiker en eigenaar. Iedere keer echter dat een gebruiker +het verkiest om niet te betalen en het dus niet te gebruiken berokkent het +die potentiële gebruiker schade zonder dat iemand er ook profijt van +heeft. De som van deze negatieve gevolgen en de neutrale transacties kan dus +alleen maar negatief zijn.</p> +<p> + Dit vermindert echter niet de hoeveelheid werk die erin gaat zitten om het +programma te <em>ontwikkelen</em>. Resultaat hiervan is dus dat de mate van +efficiëntie achteruit gaat wanneer we kijken naar mate van gebruikers +tevredenheid per gewerkt uur.</p> +<p> + Dit is een belangrijk verschil tussen kopieën van programma's en +auto's, stoelen of broodjes. Er bestaat geen kopieermachine voor +gebruiksvoorwerpen, behalve in science fiction. Programma's zijn echter +makkelijk te kopiëren; iedereen kan er zoveel maken als hij wil met +minimale inspanning. Dit gaat niet op voor voorwerpen omdat grondstoffen +worden gebruikt: iedere kopie moet net zo opgebouwd worden uit grondstoffen +als het origineel.</p> +<p> + Bij materiële voorwerpen is het logisch het gebruik te ontmoedigen +omdat minder voorwerpen ook betekent minder grondstoffen en minder +inspanning benodigd om het te maken. Er zijn meestal ook wel opstartkosten +aan verbonden maar die worden uitgesmeerd over de totale productie. Zolang +deze kosten marginaal zijn ten opzichte van de productiekosten zal het +toevoegen van de kosten voor ontwikkeling weinig verschil uitmaken op de +kwaliteit. En het vereist geen beperkingen op de vrijheid van reguliere +gebruikers.</p> +<p> + Echter, geld vragen voor iets wat anders gratis zou zijn is wel een +kwalitatieve verandering. Een centraal opgelegde bijdrage voor het +verspreiden van software ontmoedigt het gebruik sterk.</p> +<p> + Sterker nog, het centraal verspreiden van de software, zoals nu gebeurt, is +niet erg efficiënt. Het systeem bevat het onnodig verpakken van disks +en tapes, ze in grote hoeveelheden over de wereld verschepen en opslaan voor +de verkoop. Deze kosten worden voorgesteld als noodzakelijke zakelijke +uitgaven, terwijl het deels verspilling is vanwege het feit dat we zo nodig +eigenaren van software moeten hebben.</p> + +<h4 id="damaging-social-cohesion">Schadelijk voor de maatschappelijke betrokkenheid</h4> +<p> + Veronderstel dat zowel jij als je buurman het nuttig vinden om een bepaald +programma te gebruiken. Ethisch gezien zou je je verplicht moeten voelen om +het programma met je buurman te delen. Een voorstel om slechts +één van jullie toe te staan het programma te gebruiken en de +ander te beperken is onderscheidend; zowel jij als je buurman zouden dit +onacceptabel moeten vinden.</p> +<p> + Het ondertekenen van een doorsnee licentieovereenkomst staat gelijk aan je +buurman verraden: “Ik beloof mijn buurman dit programma te onthouden +zodat ik een kopie kan hebben voor alleen mezelf”. Wanneer mensen die +keuze maken voelen ze tegelijk een psychologische dwang om dit gedrag te +vergoelijken: door het belang van het helpen van je buurman te gaan +bagatelliseren— waarmee de maatschappelijke betrokkenheid in het +gedrang komt. Dit is dus psychosociale schade die voortkomt uit de +materiële schade als gevolg van de beperkingen in het gebruik van het +programma.</p> +<p> + Een hoop gebruikers herkennen het foute in het niet delen van software en +besluiten dus de licenties en wetten te laten voor wat ze zijn en toch tot +het delen van programma's over te gaan. Ze voelen zich daar echter vaak +schuldig over. Ze weten dat ze de wet moeten overtreden wanneer ze een goede +buur willen zijn, maar vinden wel dat mensen zich aan de wet moeten houden +en concluderen dus dat wanneer je een goede buur bent (en dat zijn ze) dit +iets slechts is om je over te schamen. Dat is ook een soort psychosociale +schade die je kunt ontlopen door aan te nemen dat licenties en wetten geen +morele waarden bevatten.</p> +<p> + Programmeurs lijden ook psychosociale schade in de wetenschap dat veel +gebruikers hun programma's niet mogen gebruiken. Dit leidt tot cynisme en +ontkenning. Een programmeur kan enthousiast vertellen over het werk dat hij +technisch uitdagend vindt; en dan, wanneer je hem de vraag stelt, “Mag +ik dat ook gebruiken?”, zie je z'n gezicht betrekken en toegeven dat +het antwoord nee is. Om de ontmoediging te ontlopen zal hij óf dit +gegeven meestal negeren óf hij neemt een cynische houding aan die het +belang ervan bagatelliseert.</p> +<p> + Sinds het Reagan-tijdperk is de grootste schaarste in de Verenigde Staten +niet die van technische innovatie maar meer de bereidheid van mensen om +samen te werken voor het algemeen belang. Het slaat nergens op om het eerste +te stimuleren ten koste van het tweede.</p> + +<h4 id="custom-adaptation">Het tegengaan van lokale wijzigingen in programma's</h4> +<p> + Het tweede niveau van materiële schade is de onmogelijkheid om +programma's aan te passen. Het gemak waarmee software aan kan worden gepast +is één van de grote voordelen ten opzichte van oudere +technologie. Maar de meeste commerciële software is niet verkrijgbaar +in een vorm waarin je het kunt wijzigen, zelfs niet nadat je het hebt +gekocht. Het staat je ter beschikking als een zwarte doos, slikken of +stikken—dat is alles.</p> +<p> + Een programma dat je uitvoert bestaat uit een reeks obscure +nummers. Niemand, zelfs geen goede programmeur, is in staat om die nummers +eenvoudig te veranderen zodat het programma wat anders doet.</p> +<p> + Programmeurs werken normaal gesproken met de “broncode” van een +programma dat geschreven is in een programmeertaal als Fortran of C. Het +gebruikt namen om data aan te duiden die wordt gebruikt en onderdelen van +het programma en het representeert berekeningen symbolisch zoals +‘+’ voor optellen en ‘-’ voor aftrekken. De taal is +ontworpen om programmeurs te helpen in het lezen en wijzigen van +programma's. Hieronder een voorbeeld van een programma om de afstand van +twee punten in een plat vlak tot elkaar te berekenen:</p> + +<pre> + float + distance (p0, p1) + struct point p0, p1; + { + float xdist = p1.x - p0.x; + float ydist = p1.y - p0.y; + return sqrt (xdist * xdist + ydist * ydist); + } +</pre> +<p> + Wat die broncode precies inhoud is niet belangrijk: het gaat erom dat het +lijkt op algebra en iemand die de programmeertaal kent zal het duidelijk +vinden en begrijpen. Ter contrast hier hetzelfde programma in uitvoerbare +vorm, op de computer waarop ik het programma ook schreef: +</p> + +<pre> + 1314258944 -232267772 -231844864 1634862 + 1411907592 -231844736 2159150 1420296208 + -234880989 -234879837 -234879966 -232295424 + 1644167167 -3214848 1090581031 1962942495 + 572518958 -803143692 1314803317 +</pre> + +<p> + Broncode kan nuttig zijn (in potentie) voor iedere gebruiker van een +programma. Maar de meeste gebruikers mogen geen kopie van de broncode +hebben. Meestal wordt de broncode van een privaat programma geheim gehouden +door de eigenaar, iemand zou er eens wat van mogen opsteken. Gebruikers +krijgen alleen een kopie van de bestanden met de obscure nummers die een +computer uitvoert. Dit betekent dat alleen de eigenaar van het programma dit +programma kan veranderen.</p> +<p> + Een vriend van me vertelde eens hoe hij, als programmeur voor een bank, zes +maanden bezig is geweest met het maken van een programma dat iets +soortgelijks deed als een commercieel verkrijgbaar programma. Zij was er van +overtuigd dat als ze toegang had gehad tot de broncode, ze het eenvoudig had +kunnen aanpassen op hun behoeften. De bank wilde er voor betalen maar mocht +dit niet —de broncode was geheim. Dus moest ze zes maanden bouwen aan +een imitatie, werk dat wel meetelt in het BNP maar eigenlijk gewoon +weggegooid geld is.</p> +<p> + Het <abbr title="Massachusetts Institute of Technology">MIT</abbr> +laboratorium voor kunstmatige intelligentie kreeg een grafische printer +geschonken door Xerox rond 1977. Het werd bestuurd door vrije software +waarin we vele aanpassingen maakten die voor ons nuttig waren. De software +meldde bijvoorbeeld meteen terug aan de gebruiker wanneer hij klaar was met +een uitdraai. Zodra de printer problemen had, klem zittend papier of papier +op, meldde de software dit onmiddellijk aan alle gebruikers die een uitdraai +hadden klaarstaan. Dit soort handigheidjes zorgde voor een glad verloop van +het print-proces.</p> +<p> + Wat later doneerde Xerox een snellere printer, een van de eerste +laserprinters, aan het laboratorium. Hij werd aangestuurd door private +software die op een aparte computer liep waardoor we onze favoriete +aanpassingen niet toe konden passen. We konden instellen dat er een melding +kwam wanneer er een uitdraai naar de printer werd gestuurd maar niet wanneer +het uiteindelijk op de printer belandde (bovendien was de vertraging van die +melding meestal groot). Er was geen enkele manier om te achterhalen of een +uitdraai ook daadwerkelijk gelukt was; hier kon je alleen maar naar +raden. En niemand kreeg een melding wanneer er papier klem zat dus dat kon +wel eens een uur duren voordat iemand dat door had.</p> +<p> + De systeemprogrammeurs op het laboratorium waren prima in staat om dit soort +extra functionaliteit toe te voegen, waarschijnlijk net zo goed als de +makers van het programma. Xerox wilde dit niet oplossen en koos ervoor +oplossingen van ons tegen te houden. We werden dus gedwongen deze problemen +te accepteren, ze werden nooit opgelost.</p> +<p> + De meeste goede programmeurs kennen deze frustratie. De bank kon het zich +veroorloven het probleem op te lossen middels het opnieuw schrijven van een +programma maar een doorsnee gebruiker, hoe capabel ook, kan het alleen maar +opgeven.</p> +<p> + Het opgeven leidt tot psychosociale schade—in je gevoel van +zelfstandigheid. Het is frustrerend om in een huis te wonen dat je niet zelf +mag inrichten. Het leidt tot berusting en moedeloosheid, die je kwaliteit +van leven weer beïnvloeden. Mensen die zich zo voelen zijn niet +gelukkig en presteren slecht.</p> +<p> + Stel je voor dat men met recepten op dezelfde manier om zou gaan als met +software. Je zou dan op kunnen merken: “Hoe kan ik dit recept +veranderen zodat er minder zout in zit?” en de machtige chef zou +antwoorden: “Hoe durf je mijn recept te beledigen, het product van +mijn brein en verhemelte, door ermee te gaan knoeien? Jij kunt zo'n +verandering helemaal niet inschatten en er het juiste resultaat uit +krijgen!”</p> +<p> + “Maar ik mag helemaal geen zout van de dokter! Wat kan ik hieraan +doen? Wil jij het er voor me uit halen?”</p> +<p> + “Natuurlijk, met alle liefde, en ik reken slechts 50.000 euro voor een +dergelijke wijziging”. Omdat een eigenaar het monopolie heeft op +wijzigingen zijn de tarieven meestal hoog. “Helaas heb ik nu echter +even geen tijd hiervoor. Ik ben bezig met een opdracht voor de marine om +nieuw scheepsbeschuit te ontwerpen. Over ongeveer twee jaar heb ik wel weer +tijd”.</p> + +<h4 id="software-development">Software-ontwikkeling tegenwerken</h4> +<p> + Het derde niveau van materiële schade betreft software-ontwikkeling. +Software-ontwikkeling was vroeger een evolutionair proces waarbij iemand een +bestaand programma nam en daarin wijzigingen en toevoegingen aanbracht voor +een bepaalde nieuwe toepassing. Vervolgens gebruikte een ander dat resultaat +weer om op zijn beurt wijzigingen en toevoegingen aan te brengen voor weer +een andere toepassing: in sommige gevallen ging dat wel twintig jaar zo +door. Intussen werden delen van dat programma weer +“gekannibaliseerd” om te gebruiken als basis voor weer een nieuw +programma.</p> +<p> + Het bestaan van eigenaren houdt dit soort evolutie tegen waardoor het +noodzakelijk wordt een nieuw programma van de grond af op te bouwen. Het +laat ook niet toe dat nieuwe programmeurs bestaande programma's bestuderen +om daarvan nuttige technieken te leren, of zelfs hoe grote programma's in +elkaar zitten.</p> +<p> + Eigenaren houden ook scholing tegen. Ik heb informaticastudenten ontmoet die +nog nooit de broncode van een groot programma hebben gezien. Ze zullen +wellicht goed zijn in het maken van kleine programma's, maar ze kunnen nog +niet eens de vaardigheden beginnen aan te leren van het schrijven van grote +programma's wanneer ze niet de kans krijgen te zien hoe anderen dit gedaan +hebben.</p> +<p> + In welk intellectueel streven dan ook kan men alleen grote hoogten bereiken +op de schouders van anderen. Maar dat mag over het algemeen niet meer in de +wereld van de software—je kan alleen op de schouders staan van anderen +<em>in je eigen bedrijf</em>.</p> +<p> + De resulterende psychosociale schade is van invloed op de geest van +wetenschappelijke samenwerking die vroeger zo sterk was dat het zelfs +oorlogen oversteeg. Zo was het mogelijk dat Japanse oceanografen die hun +laboratorium op een Pacifisch eiland moesten verlaten hun werk zorgvuldig +beschermd probeerden achter te laten voor de binnenvallende Amerikaanse +mariniers met een briefje erbij met het verzoek hier goed voor te zorgen.</p> +<p> + Het gevecht om winst heeft kapotgemaakt wat internationale oorlogen nooit is +gelukt. Tegenwoordig publiceren wetenschappers in vele disciplines niet +voldoende informatie meer in hun scripties om anderen in staat te stellen +het experiment te herhalen. Ze publiceren net genoeg zodat anderen kunnen +bewonderen wat ze allemaal wel niet bereikt hebben. Dit geldt zeker voor de +computerwetenschappen, waar de broncode waarover men schrijft meestal geheim +is.</p> + +<h4 id="does-not-matter-how">Het maakt niet uit hoe het delen wordt neperkt</h4> +<p> + Ik heb de gevolgen besproken die het heeft wanneer mensen verboden wordt om +programma's te kopiëren, wijzigen of uitbouwen. Ik heb het niet gehad +over hoe men dit verbiedt want dat maakt voor de gevolgen niets uit. Of het +nu gebeurd via kopieerbeveiligingen, auteursrecht, licenties, versleuteling, +<abbr title="Read-only Memory">ROM</abbr> kaarten of hardware serienummers, +als het <em>lukt</em> om gebruik te voorkomen, dan berokkent het schade.</p> +<p> + Gebruikers vinden sommige methoden hinderlijker dan andere methodes. Ik zou +zeggen dat de meest hinderlijke methode degene is die het daadwerkelijk lukt +ons van het gebruik af te houden.</p> + +<h4 id="should-be-free">Software zou vrij moeten zijn</h4> +<p> + Ik heb aangetoond dat het in eigendom hebben van een programma—de +macht om gebruik of distributie te verbieden—belemmerend werkt. Er +zijn veel belangrijke negatieve effecten aan verbonden. Hieruit volgt dat de +maatschappij het in eigendom hebben van programma's beter niet kan hebben.</p> +<p> + Een andere manier om dit te zeggen is dat de maatschappij vrije software +nodig heeft en dat private software een slechte vervanger is. Gebruik van +het surrogaat aanmoedigen om te krijgen wat we nodig hebben is niet logisch.</p> +<p> + Vaclav Havel adviseerde ons al om te “Werken voor iets omdat het goed +is, niet alleen omdat het een kans van slagen heeft”. Een bedrijf dat +private software maakt heeft kans van slagen op zijn eigen beperkte terrein +maar dat is niet goed voor de maatschappij.</p> + +<h3 id="why-develop">Waarom mensen software zullen maken</h3> +<p> + Wanneer we het auteursrecht uitschakelen als motivator voor mensen om +software te ontwikkelen zal er in eerste instantie minder software worden +ontwikkeld maar die software zal wel bruikbaarder zijn. Het is nog niet +duidelijk of de tevredenheid onder gebruikers zal afnemen; maar als dat zo +is, of wanneer we het sowieso willen verhogen, dan zijn er andere methoden +om het maken van software te stimuleren. Net als er andere manieren dan +alleen tolhuisjes zijn om financiering voor straten los te krijgen. Voordat +we die alternatieven gaan bekijken wil ik eerst eens vaststellen hoeveel +kunstmatige stimulering er eigenlijk echt nodig is.</p> + +<h4 id="fun">Programmeren is leuk</h4> +<p> + Er zijn een aantal beroepen die men alleen voor geld zou willen doen; +wegwerker bijvoorbeeld. Er zijn ook andere studies en kunstrichtingen waar +men nooit rijk van zal worden maar waar mensen van gefascineerd zijn of +denken een goede bijdrage aan de maatschappij mee te kunnen +leveren. Voorbeelden daarvan zijn mathematische logica, klassieke muziek en +archeologie. Mensen concurreren, meer tot hun verdriet dan bitter, om de +paar honderd plekken die te vergeven zijn en niet erg goed worden +betaald. Ze zullen soms zelfs betalen voor de kans om op dat gebied werkzaam +te zijn, als ze het zich kunnen veroorloven.</p> +<p> + Een dergelijke discipline kan volledig veranderen wanneer het de +mogelijkheid biedt om rijk te worden. Als één werker rijk +wordt gaan de anderen hetzelfde willen. Al snel zal iedereen grote bedragen +vragen voor het werk dat ze voorheen voor hun plezier deden. Na nog wat +jaren zullen ze eenieder uitlachen die het idee oppert dat het werk ook kan +worden gedaan zonder grote financiële compensaties. Ze zullen overheden +oproepen maatregelen te treffen om hun inkomsten veilig te stellen met +voorstellen over speciale voorrechten, machtigingen en monopolies en +suggereren dat dit nodig is.</p> +<p> + Deze verandering vond plaats in het programmeervak gedurende de jaren +tachtig. In de zevertiger jaren verschenen er artikelen over “computer +verslaving”: gebruikers waren de hele tijd “online” en +ontwikkelden honderd-euro-per-week gewoontes. Het was algemeen bekend dat +mensen zoveel van programmeren hielden dat het hun het huwelijk +kostte. Tegenwoordig programmeert er niemand meer zonder daar zwaar voor te +worden betaald. Mensen zijn vergeten wat ze toen wisten.</p> +<p> + Wanneer de meeste mensen in een vakgebied alleen willen werken voor veel +geld wil dat nog niet zeggen dat dit niet kan veranderen. Het proces kan +worden omgekeerd wanneer de maatschappij hier de stimulansen voor +aanlevert. Wanneer we de mogelijkheid wegnemen om in het vakgebied vreselijk +rijk te worden dan zal men na een tijdje, wanneer mensen aan de nieuwe +situatie gewend zijn geraakt, weer gemotiveerd raken om in dit vakgebied +voor de lol te werken.</p> +<p> + De vraag “Hoe kunnen we onze programmeurs betalen?” wordt +makkelijker te beantwoorden wanneer we ons realiseren dat ze geen fortuin +hoeven te verdienen. Een normaal salaris om van te leven is voldoende.</p> + +<h4 id="funding">Het financieren van Vrije Software</h4> +<p> + Instituten die programmeurs betalen hoeven niet persé +softwarebedrijven te zijn. Vele andere bestaande organisaties kunnen dit ook +doen.</p> +<p> + Hardwarefabrikanten vinden het belangrijk om softwareontwikkeling te steunen +ook al hebben ze zelf geen zeggenschap over die software. In 1970 was veel +van hun software vrij omdat ze niet op het idee kwamen er beperkingen op te +leggen. Tegenwoordig, met hun neiging consortia te vormen, wordt duidelijk +dat ze zich realiseren dat het in eigendom hebben van software niet +belangrijk is voor ze.</p> +<p> + Universiteiten voeren veel programmeerprojecten uit. Tegenwoordig verkopen +ze vaak de resultaten maar in 1970 deden ze dat nog niet. Is er iemand die +betwijfelt of universiteiten vrije software zouden ontwikkelen wanneer ze +geen software mogen verkopen? Dit soort projecten zou gefinancierd kunnen +worden met dezelfde overheidssubsidies en beurzen die nu worden gebruikt +voor het ontwikkelen van private software.</p> +<p> + Het is gewoonte geworden bij onderzoekers om subsidie te krijgen voor het +ontwikkelen van een systeem, dit net niet af te maken en het dan +“af” te verklaren. Om vervolgens een bedrijf te starten, waarin +het project daadwerkelijk wordt afgemaakt en het systeem bruikbaar +gemaakt. Soms verklaren ze de half voltooide versie nog “vrij”; +maar wanneer ze totaal corrupt zijn onderhandelen ze in plaats daarvan met +de universiteit over een exclusieve licentie. Dit is geen geheim; het wordt +openlijk toegegeven door alle betrokkenen. Wanneer onderzoekers echter niet +in de verleiding worden gebracht om dit soort dingen te doen, zouden ze nu +nog steeds onderzoek doen.</p> +<p> + Programmeurs die vrije software maken kunnen hun kostje bij elkaar +scharrelen door gerelateerde services te verkopen bij hun software. Ikzelf +ben ingehuurd om de <a href="/software/gcc/">GNU C-compiler</a> geschikt te +maken voor nieuwe hardware en voor het uitbreiden van de gebruikersinterface +van <a href= "/software/emacs/">GNU Emacs</a> (Ik geef deze verbeteringen +weer vrij wanneer ze ontwikkeld zijn). Ik geef ook betaald les.</p> +<p> + Ik ben niet de enige die zo werkt; er is nu een succesvol en groeiend +bedrijfje dat alleen dit soort werk doet. Verschillende andere bedrijven +bieden nu ook commerciële ondersteuning aan voor de vrije software van +het GNU-systeem. Dit is het begin van een onafhankelijke software support +industrie—een industrietak die heel groot zou kunnen worden wanneer +vrije software de voorkeur krijgt. Het geeft gebruikers een optie die +meestal niet beschikbaar is voor private software, behalve voor de heel +rijken.</p> +<p> + Nieuwe instellingen zoals de <a href="/fsf/fsf.html">Free Software +Foundation</a> (de stichting voor vrije software) kunnen ook programmeurs +sponsoren. De inkomsten van deze stichting zijn voornamelijk afkomstig van +gebruikers die tapes met software bestellen via de postorder. De software op +de tapes is vrij, wat inhoudt dat men deze mag wijzigen en kopiëren +maar velen betalen toch voor de kopie (“vrije” software slaat op +vrijheid in het gebruik, niet vrij van kosten). Sommige gebruikers die al +een kopie hebben bestellen toch de tapes, hun manier om een bijdrage te doen +voor de goede zaak. De stichting krijgt ook grote schenkingen van +computerfabrikanten.</p> +<p> + De Free Software Foundation is een liefdadige instelling en zijn inkomsten +worden besteed aan het inhuren van zoveel mogelijk programmeurs. Wanneer het +was opgezet als een zakelijke onderneming, waarbij dezelfde software voor +dezelfde vergoeding werd gedistribueerd, dan had dit de oprichter nauwelijks +in zijn levensonderhoud kunnen voorzien.</p> +<p> + Omdat de stichting een liefdadig doel is werken programmeurs vaak voor de +helft van de prijs die ze elders kunnen krijgen. Dit doen ze omdat we +gevrijwaard zijn van bureaucratie en omdat het ze een goed gevoel geeft om +software te maken die vrijelijk gebruikt kan worden. Maar ze doen het vooral +omdat ze programmeren leuk vinden. Daarbovenop zijn er ook vrijwilligers die +menig nuttig programma hebben bijgedragen (zelfs technisch schrijvers hebben +zich als vrijwilliger gemeld).</p> +<p> + Dit bewijst dat programmeren een fascinerend vak is, net zo fascinerend als +muziek en kunst. We hoeven ons geen zorgen te maken dat straks niemand meer +wil programmeren.</p> + +<h4 id="owe">Wat zijn gebruikers ontwikkelaars verschuldigd?</h4> +<p> + Het is terecht dat gebruikers zich moreel verplicht voelen om bij te dragen +aan de ontwikkelingen. Ontwikkelaars van vrije software dragen bij aan de +activiteiten van gebruikers en dus is het in het directe belang van +gebruikers, ook op de langere termijn, om financieel hieraan bij te dragen.</p> +<p> + Dit gaat echter niet op voor ontwikkelaars van private software. Hinderlijk +gedrag dient bestraft te worden, niet beloond.</p> +<p> + We hebben hier dus een paradox: de ontwikkelaar van nuttige software heeft +recht op steun van de gebruikers maar iedere poging deze morele plicht om te +zetten in een eis doet de plicht teniet. Een ontwikkelaar kan een beloning +verdienen of vragen maar niet beide tegelijk.</p> +<p> + Ik ben van mening dat een ethisch verantwoorde programmeur die met deze +paradox wordt geconfronteerd zich dusdanig op moet stellen dat hij de +beloning verdient maar tegelijkertijd gebruikers op hun gemoed moet spelen +door aan te dringen op vrijwillige bijdragen. Uiteindelijk zullen gebruikers +automatisch programmeurs steunen zonder morele druk, net zoals ze dat nu +doen met publieke radio- en televisiestations.</p> + +<h3 id="productivity">Wat is softwareproductiviteit? </h3> +<p> + Wanneer software vrij zou zijn zouden er nog steeds programmeurs zijn maar +wellicht minder dan nu. Zou dit slecht voor de maatschappij zijn?</p> +<p> + Niet persé. Tegenwoordig hebben de ontwikkelde landen minder boeren +dan in 1900 maar we zien dit niet als zijnde slecht voor de maatschappij +want de weinige boeren die we hebben leveren meer voedsel richting consument +dan de vele die we hadden. We noemen dit toegenomen productiviteit. We +zouden ook toe kunnen met minder programmeurs van vrije software door de +toegenomen productiviteit op alle niveaus:</p> + +<ul> +<li> Wijder verspreid gebruik van programma's die worden ontwikkeld.</li> +<li> De mogelijkheid bestaande programma's aan te passen aan specifieke behoeftes +in plaats van telkens opnieuw beginnen.</li> +<li> Betere opleiding van programmeurs.</li> +<li> Het wegnemen van dubbele ontwikkel-inspanningen.</li> +</ul> + +<p> + Degenen die tegen samenwerking zijn met de bewering dat dit leidt tot minder +emplooi voor programmeurs hebben dus eigenlijk bezwaar tegen een toename in +productiviteit. Meestal onderschrijven ze echter wel de algemeen gangbare +stelling dat de software-industrie meer productiviteit nodig heeft. Hoe kan +dat?</p> +<p> + “Productiviteit in software” kan op twee dingen betrekking +hebben: de algemene productiviteit van alle software-ontwikkelingen of de +productiviteit van individuele projecten. De maatschappij wil graag de +algemene productiviteit verhogen en de simpelste manier om dit te bereiken +is door het afschaffen van kunstmatige belemmeringen in samenwerking. Maar +onderzoekers die het probleem van “productiviteit in software” +onderzoeken spitsen het onderzoek toe op de tweede, meer beperkte, +interpretatie die moeilijke technologische oplossingen behoeven.</p> + +<h3 id="competition">Is concurrentie onvermijdelijk?</h3> +<p> + Is het onvermijdelijk dat mensen zullen proberen te concurreren met hun +rivalen in de maatschappij? Misschien wel. Maar concurrentie is niet +schadelijk; het schadelijke element is <em>vechten</em>.</p> +<p> + Er zijn vele manieren om te concurreren. Concurrentie kan eruit bestaan dat +men probeert steeds meer te bereiken dan tot nu toe of dingen beter te doen +dan anderen. Vroeger was er bijvoorbeeld concurrentie tussen +programmeertalenten—wedstrijdjes wie de computer de meest verbazende +dingen kon laten doen, of wie het kortste of snelste programma kon maken +gegeven een bepaalde taak. Dit soort competitie kan iedereen tot nut zijn, +<em>zolang men hier maar sportief mee om gaat</em>.</p> +<p> + Opbouwende concurrentie is voldoende competitie om mensen te stimuleren tot +grote dingen. Een aantal mensen streeft ernaar om de eerste te zijn die alle +landen op de wereld heeft bezocht; sommigen geven er zelfs fortuinen aan +uit. Maar ze zullen geen kapiteins omkopen om hun rivalen te laten stranden +op verlaten eilanden. Ze hebben er vrede mee dat de beste zal winnen.</p> +<p> + Concurrentie wordt vechten wanneer rivalen elkaar gaan proberen te +verhinderen iets te bereiken in plaats van te proberen zelf wat te +bereiken—wanneer “dat de beste mag winnen” verandert in +“laat mij winnen, ongeacht of ik de beste ben”. Private software +is schadelijk, niet omdat het een manier van concurreren is maar een vorm +van vechten tussen mensen in de maatschappij.</p> +<p> + Zakelijke concurrentie is niet per definitie vechten. Wanneer bijvoorbeeld +twee groentewinkels met elkaar concurreren is al hun inspanning gericht op +het verbeteren van hun eigen bedrijfsvoering, niet op het saboteren van de +ander. Dit is echter geen demonstratie van zakelijk fatsoen; het is meer zo +dat er weinig mogelijkheid is om te vechten, behalve het gebruik van fysiek +geweld. Niet alle zakelijke sectoren zitten zo in elkaar. Het achterhouden +van informatie die iedereen zou kunnen helpen is een vorm van vechten.</p> +<p> + Zakelijke ideologie bereidt het publiek niet voor op het weerstaan van +verleidingen om de concurrentie de loef af te steken. Sommige vormen van +concurrentie of strijd zijn bij wet verboden zoals concurrentievervalsing, +liegen bij het adverteren enzovoorts maar in plaats van dit breder te +trekken door bij wet dit soort strijd in het algemeen te verbieden, bedenken +zakenmensen steeds nieuwe vormen van strijd die niet specifiek zijn +verboden. Maatschappelijke gelden worden zo verkwist aan een economische +equivalent van burgeroorlog.</p> + +<h3 id="communism">“Waarom verkas je niet naar Rusland?”</h3> +<p> + Iedere voorstander in de Verenigde Staten van meer dan een minimale +overheidsbemoeienis heeft dit vaak te horen gekregen. Het wordt geuit tegen +voorstanders van meer overheidsbemoeienis met de gezondheidszorg, iets dat +alle andere ontwikkelde landen wel hebben. Het wordt geuit tegen +voorstanders van meer ondersteuning vanuit de overheid voor kunst, ook +gebruikelijk in alle andere ontwikkelde landen. Het idee dat inwoners wat +voor verplichting dan ook hebben richting de maatschappij wordt +gelijkgesteld aan communisme. Maar in hoeverre lijken die ideeën op +elkaar?</p> +<p> + Het communisme, zoals dat in de Sovjet-Unie werd gebezigd, was een centraal +gestuurd systeem waar alle activiteit was gereguleerd, onder het mom dat het +goed was voor de gemeenschap maar feitelijk alleen voor de leden van de +communistische partij. En waar kopieerapparatuur zwaar werd bewaakt om +illegaal kopiëren tegen te gaan.</p> +<p> + Het Amerikaanse systeem van auteursrecht oefent totale controle uit op het +distribueren van een programma en bewaakt het kopiëren met automatische +kopieerbeveiligingen om illegaal kopiëren tegen te gaan.</p> +<p> + Daarentegen ben ik een systeem aan het bouwen waarbij mensen vrij zijn om +zelf te beslissen wat ze ermee gaan doen; vooral vrij zijn om hun buren te +helpen en vrij zijn om de hulpmiddelen die ze in hun dagelijks leven +gebruiken te veranderen en verbeteren naar eigen believen. Een systeem, +gebaseerd op vrijwillige samenwerking en decentralisatie.</p> +<p> + Wanneer we dus inzichten beoordelen op hun gelijkenis met het Russische +communisme dan zijn het de eigenaren van software die de communisten zijn.</p> + +<h3 id="premises">De juiste uitgangspunten</h3> +<p> + In dit artikel ga ik er van uit dat de gebruiker van software niet minder +belangrijk is dan een auteur of zelfs de werkgever van een auteur. Met +andere woorden, ons besluit voor de juiste actie is gebaseerd op het +uitgangspunt dat hun belangen even groot zijn.</p> +<p> + Dit uitgangspunt wordt niet door iedereen gedeeld. Velen houden vol dat de +belangen van een werkgever belangrijker zijn dan ieder ander. Ze beweren +bijvoorbeeld dat het doel van het hebben van eigenaren van software de +werkgever juist het voordeel geven dat hij verdient—ongeacht wat voor +gevolgen dit heeft voor het publiek.</p> +<p> + Het heeft geen zin deze uitgangspunten aan te vechten. Bewijs wordt +gebaseerd op algemeen aanvaarde aannames. Dus het meeste van wat ik hier te +zeggen heb is voor diegenen die zich in mijn uitgangspunt kunnen vinden, of +in ieder geval nieuwsgierig zijn naar de consequenties. Dit artikel is +gewoon niet relevant voor diegenen die geloven dat eigenaren belangrijker +zijn dan de rest.</p> +<p> + Maar waarom zouden vele Amerikanen een uitgangspunt accepteren dat sommige +mensen boven anderen verheft? Gedeeltelijk doordat men gelooft dat dit +uitgangspunt onderdeel is van de juridische grondslag van de Amerikaanse +maatschappij. Sommigen zullen dit beleven als het aan de kaak stellen van +hun maatschappelijke basis.</p> +<p> + Het is belangrijk dat deze mensen zich realiseren dat dit uitgangspunt nooit +een onderdeel is geweest van onze (Amerikaanse) juridische traditie. Dat is +het ook nooit geweest.</p> +<p> + Aldus zegt de grondwet dat het doel van het auteursrecht is “het +stimuleren van wetenschappelijke vooruitgang en nuttige kunst”. Het +Hooggerechtshof heeft zich hier nog nader over uitgesproken met de uitspraak +in <em>Fox Film vs. Doyal</em> dat “het enige belang van de Verenigde +Staten en primaire doel van het verlenen van het [auteursrecht]monopolie +ligt in de algemene voordelen die de maatschappij zal genieten van het werk +van auteurs”.</p> +<p> + We hoeven het niet eens te zijn met de grondwet of met het Hooggerechtshof +(ze hebben in het verleden slavernij goedgekeurd). Dus hun standpunten doen +niets af aan het uitgangspunt van grotere belangen van werkgevers. Ik hoop +wel dat het besef dat dit een rechts-radicaal standpunt is en niet een +traditioneel, algemeen aanvaardbaar standpunt, de aantrekkingskracht van het +standpunt zal doen verminderen.</p> + +<h3 id="conclusion">Conclusie</h3> +<p> + Wij denken dat onze maatschappij het helpen van je buren stimuleert; maar +iedere keer dat we iemand belonen wanneer die iets tegenhoudt, of ze +bewonderen om de rijkdom die ze op die manier vergaard hebben, zenden we het +tegenovergestelde signaal uit.</p> +<p> + Het verzamelen van software is een uiting van onze neiging om persoonlijk +gewin voor het welbevinden van de maatschappij te stellen. We kunnen deze +neiging herleiden van Ronald Reagan naar Dick Cheney, van Exxon naar Enron, +van falende banken naar falende scholen. We kunnen het afmeten aan het +aantal zwervers en het aantal gevangenen. Dit asociale gedrag houdt zichzelf +in stand, want hoe meer we zien dat andere mensen ons niet willen helpen des +te kleiner wordt de neiging om hen te helpen. En aldus vervalt de +maatschappij tot een jungle.</p> +<p> + Wanneer we niet in een jungle willen leven moeten we ons gedrag +veranderen. We moeten het signaal gaan afgeven dat een goed burger er een is +die met anderen samenwerkt wanneer dat zo te pas komt, niet een die succes +heeft met dingen afnemen van anderen. Ik hoop dat de +vrijesoftwaregemeenschap hiertoe zal bijdragen: op tenminste +één gebied zullen we de jungle vervangen door een +efficiënter systeem dat gebaseerd zal zijn op vrijwillige samenwerking.</p> + + +<h3 id="footnotes">Voetnoten</h3> + +<ol> +<li id="f1">Het woord “vrij” in “vrije software” slaat op +vrijheid, niet op prijs; de prijs die je betaalt voor de kopie van een vrij +programma kan nul zijn, een beetje of (soms) heel veel (Noot van de +vertaler: “free” in het Engels betekent zowel vrijheid als +gratis, vandaar deze voetnoot).</li> + +<li id="f2">Problemen met vervuiling of filevorming veranderen de conclusie +niet. Wanneer we het rijden duurder willen maken om het te ontmoedigen is +het nog steeds ongunstig om tolhuisjes te gebruiken omdat die juist +bijdragen aan vervuiling en filevorming. Belasting op brandstof is veel +beter. Op dezelfde manier is het om veiligheidsredenen verlagen van de +maximumsnelheid niet relevant; een weg met vrije toegang verhoogt de +gemiddelde snelheid door het voorkomen van stoppen en vertragingen, voor +welke maximumsnelheid dan ook.</li> + +<li id="f3">Men zou een bepaald programma schadelijk kunnen vinden en van mening zijn +dat het nooit had moeten worden uitgebracht, zoals de Lotus Marketplace +databank met persoonlijke informatie, die uit de verkoop werd gehaald +vanwege de publieke afkeuring. De meeste beweringen die ik doe slaan niet op +dit geval, maar het is zinloos om aan te voeren dat een programma een +eigenaar zou moeten hebben zodat het programma beperkt wordt +uitgebracht. Een eigenaar zal het programma niet <em>volledig</em> beperken, +zoals je zou willen met een programma dat beschouwd wordt als schadelijk.</li> +</ol> + +<hr /> +<blockquote id="fsfs"><p class="big">Dit korte verhaal is gepubliceerd in <a +href="http://shop.fsf.org/product/free-software-free-society/"><cite>Vrije +Software, Vrije Maatschappij: Geselecteerde Artikelen van Richard +M. Stallman </cite></a>.</p></blockquote> + +<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> + +<p>Copyright © 1991, 1992, 1998, 2000, 2001, 2006, 2007, 2010, 2017, 2018, +2020 Free Software Foundation, Inc.</p> + +<p>Deze pagina is uitgebracht onder een <a rel="license" +href="https://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: 2020/07/05 14:01:37 $ + +<!-- timestamp end --> +</p> +</div> +</div> +<!-- for class="inner", starts in the banner include --> +</body> +</html> |