taler-merchant-demos

shouldbefree.html (52832B)

---

 <!--#set var="ENGLISH_PAGE" value="/philosophy/shouldbefree.en.html" -->
 
 <!--#include virtual="/server/header.nl.html" -->
 <!-- Parent-Version: 1.96 -->
 <!-- This page is derived from /server/standards/boilerplate.html -->
 <!--#set var="TAGS" value="essays aboutfs principles" -->
 <!--#set var="DISABLE_TOP_ADDENDUM" value="yes" -->
 
 <!-- This file is automatically generated by GNUnited Nations! -->
 <title>Waarom software vrij zou moeten zijn - GNU-project - Free Software
 Foundation</title>
 <style type="text/css" media="print,screen"><!--
 #content h3 { margin-top: 1.6em; }
 -->
 
 </style>
 
 <!--#include virtual="/philosophy/po/shouldbefree.translist" -->
 <!--#include virtual="/server/banner.nl.html" -->
 <!--#include virtual="/philosophy/ph-breadcrumb.nl.html" -->
 <!--GNUN: OUT-OF-DATE NOTICE-->
 <!--#include virtual="/server/top-addendum.nl.html" -->
 <div class="article reduced-width">
 <h2>Waarom software vrij zou moeten zijn</h2>
 
 <address class="byline">door <a href="https://www.stallman.org/">Richard Stallman</a></address>
 
 <p  id="introduction">
 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
 <code>+</code> voor optellen en <code>-</code> 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>
 <div class="column-limit"></div>
 
 <h3 id="footnotes" class="footnote">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 class="no-display" />
 <div class="edu-note c"><p id="fsfs">Dit artikel is opgenomen in <a
 href="https://shop.fsf.org/product/free-software-free-society/"><cite>Free
 Software, Free Society: The Selected Essays of Richard
 M. Stallman</cite></a>.</p></div>
 </div>
 
 <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" role="contentinfo">
 <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 contributing translations of
         our web pages, see <a
         href="/server/standards/README.translations.html">Translations
         README</a>. -->
 We doen ons best om goede vertalingen te maken maar staan altijd open voor
 verbeteringen. Suggesties, op- en aanmerkingen sturen aan: <a
 href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>.</p>
 <p>Zie <a href="/server/standards/README.translations.html"> Translations
 README</a> voor informatie over het onderhoud van vertalingen op deze
 website.</p>
 </div>
 
 <!-- Regarding copyright, in general, standalone pages (as opposed to
      files generated as part of manuals) on the GNU web server should
      be under CC BY-ND 4.0.  Please do NOT change or remove this
      without talking with the webmasters or licensing team first.
      Please make sure the copyright date is consistent with the
      document.  For web pages, it is ok to list just the latest year the
      document was modified, or published.
      
      If you wish to list earlier years, that is ok too.
      Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
      years, as long as each year in the range is in fact a copyrightable
      year, i.e., a year in which the document was published (including
      being publicly visible on the web or in a revision control system).
      
      There is more detail about copyright years in the GNU Maintainers
      Information document, www.gnu.org/prep/maintain. -->
 <p>Copyright &copy; 1991, 1992, 1998, 2006, 2010, 2021 Free Software
 Foundation, Inc.</p>
 
 <p>Deze pagina is uitgebracht onder de <a rel="license"
 href="http://creativecommons.org/licenses/by-nd/4.0/deed.nl">Creative
 Commons Naamsvermelding-GeenAfgeleideWerken 4.0 Internationaal licentie</a>.</p>
 
 <!--#include virtual="/server/bottom-notes.nl.html" -->
 <div class="translators-credits">
 
 <!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
 <strong>Vertaling:</strong> <a
 href="//savannah.gnu.org/projects/www-nl">www-nl</a></div>
 
 <p class="unprintable"><!-- timestamp start -->
 Bijgewerkt:
 
 $Date: 2021/09/28 16:34:04 $
 
 <!-- timestamp end -->
 </p>
 </div>
 </div>
 <!-- for class="inner", starts in the banner include -->
 </body>
 </html>