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

<!--#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 &ldquo;eigenaar&rdquo;?</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&mdash;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&euml;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&euml;ren, te bestuderen en te verbeteren: oftewel om
<a href= "/philosophy/free-sw.html">&ldquo;vrije&rdquo; 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: &ldquo;Ik heb mijn bloed, zweet en
tranen in dit programma zitten. <em>Ik</em> heb het gemaakt, het is van
<em>mij</em>!&rdquo;</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&mdash;en het doel dat dit diende. Zo heeft men er eeuwen tegenaan
gekeken.</p>
<p>
   Het economische argument gaat als volgt: &ldquo;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!&rdquo; 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&mdash; private software of geen software&mdash;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, &ldquo;moet het ontwikkelen van software gebonden zijn aan
het hebben van eigenaren die het gebruik ervan kunnen limiteren?&rdquo;.</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 &eacute;&eacute;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
&ldquo;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&rdquo;. 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&mdash;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&euml;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 &mdash;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 &ldquo;tolhuisjes&rdquo; opzetten voor nuttige programmatuur: het
maakt programma's duurder om te maken, duurder om te verspreiden en minder
bruikbaar en effici&euml;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&euml;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&euml;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&euml;le
gevolgen kan leiden.</p>
<p>
   De drie niveaus van materi&euml;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&euml;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&euml;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&euml;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&euml;ntie achteruit gaat wanneer we kijken naar mate van gebruikers
tevredenheid per gewerkt uur.</p>
<p>
   Dit is een belangrijk verschil tussen kopie&euml;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&euml;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&euml;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&euml;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
&eacute;&eacute;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: &ldquo;Ik beloof mijn buurman dit programma te onthouden
zodat ik een kopie kan hebben voor alleen mezelf&rdquo;. 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&mdash; waarmee de maatschappelijke betrokkenheid in het
gedrang komt. Dit is dus psychosociale schade die voortkomt uit de
materi&euml;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, &ldquo;Mag
ik dat ook gebruiken?&rdquo;, zie je z'n gezicht betrekken en toegeven dat
het antwoord nee is. Om de ontmoediging te ontlopen zal hij &oacute;f dit
gegeven meestal negeren &oacute;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&euml;le schade is de onmogelijkheid om
programma's aan te passen. Het gemak waarmee software aan kan worden gepast
is &eacute;&eacute;n van de grote voordelen ten opzichte van oudere
technologie.  Maar de meeste commerci&euml;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&mdash;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 &ldquo;broncode&rdquo; 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
&lsquo;+&rsquo; voor optellen en &lsquo;-&rsquo; 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 &mdash;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&mdash;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&iuml;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: &ldquo;Hoe kan ik dit recept
veranderen zodat er minder zout in zit?&rdquo; en de machtige chef zou
antwoorden: &ldquo;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!&rdquo;</p>
<p>
   &ldquo;Maar ik mag helemaal geen zout van de dokter! Wat kan ik hieraan
doen? Wil jij het er voor me uit halen?&rdquo;</p>
<p>
   &ldquo;Natuurlijk, met alle liefde, en ik reken slechts 50.000 euro voor een
dergelijke wijziging&rdquo;. Omdat een eigenaar het monopolie heeft op
wijzigingen zijn de tarieven meestal hoog. &ldquo;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&rdquo;.</p>

<h4 id="software-development">Software-ontwikkeling tegenwerken</h4>
<p>
   Het derde niveau van materi&euml;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
&ldquo;gekannibaliseerd&rdquo; 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&mdash;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&euml;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&mdash;de
macht om gebruik of distributie te verbieden&mdash;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 &ldquo;Werken voor iets omdat het goed
is, niet alleen omdat het een kans van slagen heeft&rdquo;. 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 &eacute;&eacute;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&euml;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 &ldquo;computer
verslaving&rdquo;: gebruikers waren de hele tijd &ldquo;online&rdquo; 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 &ldquo;Hoe kunnen we onze programmeurs betalen?&rdquo; 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&eacute;
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
&ldquo;af&rdquo; 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 &ldquo;vrij&rdquo;;
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&euml;le ondersteuning aan voor de vrije software van
het GNU-systeem.  Dit is het begin van een onafhankelijke software support
industrie&mdash;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&euml;ren
maar velen betalen toch voor de kopie (&ldquo;vrije&rdquo; 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&eacute;. 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>
   &ldquo;Productiviteit in software&rdquo; 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 &ldquo;productiviteit in software&rdquo;
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&mdash;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&mdash;wanneer &ldquo;dat de beste mag winnen&rdquo; verandert in
&ldquo;laat mij winnen, ongeacht of ik de beste ben&rdquo;. 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">&ldquo;Waarom verkas je niet naar Rusland?&rdquo;</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&euml;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&euml;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&euml;ren met automatische
kopieerbeveiligingen om illegaal kopi&euml;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&mdash;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 &ldquo;het
stimuleren van wetenschappelijke vooruitgang en nuttige kunst&rdquo;. Het
Hooggerechtshof heeft zich hier nog nader over uitgesproken met de uitspraak
in <em>Fox Film vs. Doyal</em> dat &ldquo;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&rdquo;.</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
&eacute;&eacute;n gebied zullen we de jungle vervangen door een
effici&euml;nter systeem dat gebaseerd zal zijn op vrijwillige samenwerking.</p>


<h3 id="footnotes">Voetnoten</h3>

<ol>
<li id="f1">Het woord &ldquo;vrij&rdquo; in &ldquo;vrije software&rdquo; 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: &ldquo;free&rdquo; 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 &amp; GNU te sturen naar <a
href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Er zijn ook nog <a
href="/contact/">andere manieren om in contact te komen</a> met de
FSF. Foute links en andere correcties graag sturen aan <a
href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>

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

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

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

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

<p>Copyright &copy; 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>