[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
www/philosophy shouldbefree.nl.html
|
From: |
Tom Uijldert |
|
Subject: |
www/philosophy shouldbefree.nl.html |
|
Date: |
Sat, 31 Mar 2007 23:32:17 +0000 |
CVSROOT: /web/www
Module name: www
Changes by: Tom Uijldert <tuijldert> 07/03/31 23:32:17
Added files:
philosophy : shouldbefree.nl.html
Log message:
Initial dutch translation from version 1.24 (finally)
CVSWeb URLs:
http://web.cvs.savannah.gnu.org/viewcvs/www/philosophy/shouldbefree.nl.html?cvsroot=www&rev=1.1
Patches:
Index: shouldbefree.nl.html
===================================================================
RCS file: shouldbefree.nl.html
diff -N shouldbefree.nl.html
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ shouldbefree.nl.html 31 Mar 2007 23:32:13 -0000 1.1
@@ -0,0 +1,1037 @@
+<!--#include virtual="/server/header.html" -->
+
+<title>Waarom Software Vrij Zou Moeten Zijn - GNU Project - Free Software
Foundation (FSF)</title>
+
+<!--#include virtual="/server/banner.html" -->
+
+<h2>Waarom Software Vrij Zou Moeten Zijn</h2>
+
+<!-- This document uses XHTML 1.0 Strict, but may be served as -->
+<!-- text/html. Please ensure that markup style considers -->
+<!-- appendex C of the XHTML 1.0 standard. See validator.w3.org. -->
+
+<body>
+
+<p>
+door <a href="http://www.stallman.org/";><strong>Richard
Stallman</strong></a></p>
+<p>
+(Versie van 24 April 1992)</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
+gebeurd? De betreffende personen? Of een andere partij, te weten de
“eigenaar”?
+</p>
+<p>
+Softwareontwikkelaars gaan er doorgaans vanuit dat een beslissing gebaseerd
zal
+zijn op het maximaliseren van de winst voor de ontwikkelaar. De politieke
kracht
+van bedrijven heeft ertoe geleid dat de regering dit criterium heeft
overgenomen
+en ook het antwoord wat daarop gegeven wordt door de ontwikkelaars: dat een
+programma een eigenaar heeft, meestal een bedrijf wat betrokken was bij de
+ontwikkeling.
+</p>
+<p>
+Ik zou graag diezelfde vraag in overweging willen nemen maar dan met een ander
uitgangspunt: de voorspoed en vrijheid van mensen in het algemeen.
+</p>
+<p>
+De beslissing kan niet genomen worden door huidige wetgeving—de wet
dient
+de ethiek te volgen, niet andersom. De huidige manier van werken kan dit ook
+niet beslissen, maar wel een mogelijke richting aangeven. De enige manier om
dit
+goed te kunnen beoordelen is door te kijken wie er mee is geholpen (en waarom
en
+hoeveel) en wie niet wanneer we erkennen dat software in eigendom kan zijn.
+Oftewel, een kosten-baten analyse voor de maatschappij als geheel, rekening
+houdend met individuele vrijheid alsook de productie van materiële
goederen.
+</p>
+<p>
+In dit artikel zal ik de gevolgen beschrijven wanneer software in eigendom
wordt
+genomen en aantonen dat dit schadelijk is. Mijn conclusie is dat programmeurs
de
+plicht hebben om iedereen aan te moedigen de software die ze maken te delen,
te
+kopiëren, te bestuderen en te verbeteren: oftewel om <a href=
+"/philosophy/free-sw.nl.html">“vrije” software</a> te maken.<a
href=
+"#f1">(1)</a>
+</p>
+
+<h3 id="owner-justification">Hoe Eigenaren Hun Macht Rechtvaardigen</h3>
+<p>
+Degenen die baat hebben bij de huidige praktijk van programma's die bezit
vormen,
+komen met twee rechtvaardigingen hiervoor: een emotionele en een economische.
+</p>
+<p>
+Het emotionele argument gaat als volgt: “Ik heb mijn bloed, zweet en
+tranen in dit programma zitten. <em>Ik</em> heb het gemaakt, het is van
<em>mij</em>!”
+</p>
+<p>
+Dit argument hoeven we amper te weerleggen. De gehechtheid aan een programma
is
+iets wat programmeurs kunnen veinzen wanneer het ze uit komt; het is niet
+onontkoombaar. Ga bijvoorbeeld maar eens na hoe makkelijk diezelfde
programmeurs
+al hun rechten inleveren bij een bedrijf in ruil voor een salaris; de
emotionele
+band met de programmatuur verdwijnt als sneeuw voor de zon. Zet daar de grote
+kunstenaars en ambachtslieden uit de Middeleeuwen tegenover, die hun werk niet
+eens signeerden. Voor hen was de naam van de kunstenaar niet belangrijk. Wat
van
+belang was was het werk dat gedaan moest worden—en het doel dat dit
+diende. Zo heeft men er eeuwen tegenaan gekeken.
+</p>
+<p>
+Het economische argument gaat als volgt: “Ik wil rijk worden (vaak wat
+slordig omschreven als 'je brood verdienen'), en als je mij niet toestaat rijk
+te worden door te programmeren dan ga ik niet programmeren. Iedereen denkt er
zo
+over dus niemand zal dan ooit programmeren. En dan zul je dus geen programma's
+meer hebben!” Dit wordt meestal gebracht als een vriendelijk advies van
+hen die het weten kunnen.
+</p>
+<p>
+Ik zal later uitleggen waarom dit dreigement bluf is. Eerst wil ik het hebben
+over een stille aanname die duidelijk wordt in een andere versie van
+datzelfde argument.
+</p>
+<p>
+Daarbij begint men het sociale nut van een privaat programma te vergelijken
met
+de situatie dat er geen programma is, waarbij men de conclusie trekt dat, door
+de bank genomen, private software dus nut heeft en moet worden gestimuleerd.
De
+fout in deze redenering is dat men slechts twee mogelijkheden vergelijkt—
+private software of geen software—en aanneemt dat er geen andere
+alternatieven zijn.
+</p>
+<p>
+Door het systeem van auteursrechten is de ontwikkeling van software meestal
+geassocieerd met een eigenaar die bepaald hoe de software wordt gebruikt.
+Zolang deze associatie bestaat hebben we dus meestal de keus tussen private
+software of geen software. Deze associatie is echter geen wetmatigheid of
+onontkoombaar: het is slechts het gevolg van onze sociale en juridische
+beleidskeuze die we hier aan de tand voelen: de beslissing om eigenaren te
+hebben. Door het neer te zetten als een keuze tussen private software of geen
+software wordt de vraag ontweken.
+</p>
+
+<h3 id="against-having-owners">Argumenten tegen het Eigenaarschap</h3>
+<p>
+De vraag is dus, “moet het ontwikkelen van software gebonden zijn aan
het hebben van eigenaren die het gebruik ervan kunnen limiteren?”.
+</p>
+<p>
+Om dit te kunnen beoordelen moeten we het effect van beide activiteiten op de
+maatschappij <em>afzonderlijk</em> bekijken: het effect van het ontwikkelen
van
+software (ongeacht hoe dit gedistribueerd wordt) en het effect van het
beperken
+van het gebruikersrecht (aannemende dat de software al ontwikkeld is). Als
+één ervan ons verder helpt en een ander ons schaadt dan zijn we
+beter af wanneer we de schadelijke activiteit stoppen.
+</p>
+<p>
+Anders gezegd, als het beperken van het gebruikersrecht van een programma dat
al
+is ontwikkeld schadelijk is voor de gemeenschap dan zal een gewetensvolle
+programmeur geen beperkingen in dat recht aanbrengen.
+</p>
+<p>
+Om het effect van het beperken van het delen van programma's vast te kunnen
+stellen moeten we vaststellen wat de waarde voor de gemeenschap is van een
+programma met gebruikersbeperkingen (oftewel privaat) en dat van een programma
+wat voor iedereen toegankelijk is. De twee mogelijkheden vergelijken dus.
+</p>
+<p>
+Deze analyse weerlegt ook een tegenargument wat soms wordt gebruikt dat
+“het voordeel dat men heeft door je buurman een kopie van het programma
te geven
+teniet wordt gedaan door het nadeel dat je de eigenaar berokkent”. Dit
+tegenargument veronderstelt dat de berokkende schade en het verkregen voordeel
+even groot zijn. De analyse vergelijkt dus ook de ernst van de gevolgen en zal
+aantonen dat het verkregen voordeel veel groter is dan de berokkende schade.
+</p>
+<p>
+Laten we de discussie ter verheldering eens toepassen op het bouwen van wegen.
+</p>
+<p>
+Het is mogelijk om het bouwen van wegen te financieren met tolheffing.
Hiervoor
+heb je tolhuisjes nodig op iedere kruising. Een dergelijk systeem bevat een
+grote prikkel om wegen te verbeteren. Bijkomend voordeel is dat alleen
+gebruikers van die weg ervoor hoeven te betalen. Een tolhuisje is echter een
+kunstmatig obstakel op de weg—kunstmatig doordat het niets te maken
heeft
+met hoe wegen of auto's werken.
+</p>
+<p>
+Wanneer we vervolgens het nut van tolwegen met vrije wegen vergelijken zien we
+dat (over het geheel genomen) wegen zonder tolhuisjes goedkoper zijn om te
+bouwen en te exploiteren, veiliger zijn en efficiënter in gebruik <a href=
+"#f2">(2)</a>. In arme landen zal tolheffing bepaalde bevolkingsgroepen
+uitsluiten van het gebruik van deze wegen. Wegen zonder tolheffing geven dus
een
+groter voordeel voor de maatschappij tegen minder kosten; maatschappelijk
gezien
+verdient dit dus de voorkeur. Dus dient de maatschappij een andere manier dan
+tolheffing te vinden voor het financieren van wegen. Het gebruik van wegen
zou,
+wanneer ze eenmaal gebouwd zijn, vrij moeten zijn.
+</p>
+<p>
+Wanneer voorstanders van tolhuisjes dit voorstellen als <em>slechts</em> een
+manier om de financiering rond te krijgen dan is dat niet de hele waarheid.
+Tolhuisjes brengen wel geld op maar ze doen ook nog iets anders: in feite
+verslechteren ze de weg. Een tolweg is niet zo goed als een vrije weg; het
+bouwen van meer- of technisch betere wegen zou wel eens geen vooruitgang
kunnen
+zijn wanneer dit betekent dat vrije wegen worden vervangen door tolwegen.
+</p>
+<p>
+Uiteraard is het bouwen van een weg niet gratis en zullen we die met z'n allen
+moeten financieren. Dit betekent echter niet automatisch dat we tolhuisjes
+moeten inzetten. Wij, die in beide gevallen voor de kosten moeten opdraaien
+krijgen meer waar voor ons geld wanneer we een vrije weg kopen.
+</p>
+<p>
+Ik beweer hier niet dat een tolweg nog slechter is dan helemaal geen weg. Dat
+zou alleen opgaan wanneer de tol zo hoog is dat bijna niemand hem zal gebruiken
+—iets wat niet snel voor zal komen doordat het niet in het voordeel is
van
+de tolheffer. Zolang tolhuisjes echter voor oponthoud en verspilling blijven
+zorgen is het raadzaam om wegen op een minder hinderlijke manier te
financieren.
+</p>
+<p>
+Om deze redenering nu door te zetten naar software ontwikkeling zal ik laten
+zien dat het de maatschappij behoorlijk wat schade berokkend wanneer we
+dergelijke “tolhuisjes” opzetten voor nuttige programmatuur: het
+maakt programma's duurder om te maken, duurder om te verspreiden en minder
+bruikbaar en efficiënt. Hieruit zal blijken dat het maken van programma's
+beter op een andere manier gestimuleerd kan worden. Daarna zal ik andere
+methoden behandelen om softwareontwikkeling te stimuleren en (voor zover
nodig)
+te financieren.
+</p>
+
+<h4 id="harm-done">De Schade van Software met Beperkingen</h4>
+<p>
+Neem even aan dat een nieuw programma is gemaakt en alle rekeningen voor de
+ontwikkeling ervan zijn voldaan; nu moet de maatschappij een keuze maken
tussen
+het privaat (auteursrechtelijk) 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 niveau's van materiële schade volgen uit dergelijke
+beperkingen:
+</p>
+
+<ul>
+<li>Minder mensen zullen het programma gebruiken.</li>
+
+<li>Geen enkele gebruiker kan het programma aanpassen of repareren.</li>
+
+<li>Andere ontwikkelaars kunnen niets leren van dit programma of het gebruiken
+als basis voor nieuwe ontwikkelingen.</li>
+</ul>
+
+<p>
+Ieder niveau van materiële schade gaat ook gepaard met een zekere
+psychosociale schade. Dit gaat om het fenomeen dat beslissingen van mensen
+gevolgen hebben voor hun gevoelens, houding en gemoedstoestand. Dit soort
+veranderingen in het denken van mensen zal op zijn beurt weer gevolgen hebben
op
+hun onderlinge relaties met anderen, wat weer tot materiële gevolgen kan
+leiden.
+</p>
+<p>
+De drie niveau's van materiële schade doen afbreuk aan de bijdrage van
een
+programma maar niet zozeer dat er helemaal geen sprake meer is van een
bijdrage.
+Wanneer de afbreuk de bijdrage zou neutraliseren dan is de maximale schade
voor
+de gemeenschap gelijk aan de inspanning die het gekost heeft om het programma
te
+maken. Verder is aan te voeren dat een programma dat winst maakt kennelijk
iets
+toevoegt wat direct materieel resultaat oplevert.
+</p>
+<p>
+Rekening houdend met de bijkomende psychosociale nadelen, is er geen grens aan
+de mate waarin private software schade kan aanrichten.
+</p>
+
+<h4 id="obstructing-use">Gebruiksbeperkingen van Programma's</h4>
+<p>
+Het eerste nadelige niveau heeft betrekking op het directe gebruik van een
+programma. Een kopie van een programma kost bijna niets (en je kunt die kosten
+nog drukken door zelf te kopiëren) dus in een vrije markt zou de prijs
+bijna nul zijn. Een licentiebijdrage is een groot obstakel wanneer je het
+programma wilt gebruiken. Wanneer een breed toepasbaar programma privaat is
+zullen veel minder mensen het gebruiken.
+</p>
+<p>
+Het is eenvoudig aan te tonen dat de totale bijdrage van een programma aan de
+gemeenschap wordt verminderd wanneer een programma een eigenaar krijgt. Iedere
+potentiële gebruiker van het programma die wordt geconfronteerd met de
eis
+te betalen als ze het willen gebruiken zal een keuze maken: gebruiken of niet.
+Wanneer de gebruiker beslist het te gebruiken en dus te betalen vind er een
+neutrale overdracht van welvaart plaats tussen gebruiker en eigenaar. Iedere
+keer echter dat een gebruiker het verkiest om niet te betalen en het dus niet
te
+gebruiken berokkent het die potentiële gebruiker schade zonder dat iemand
+er ook profijt van heeft. De som van deze negatieve gevolgen en de neutrale
+transacties kan dus alleen maar negatief zijn.
+</p>
+<p>
+Dit verminderd echter niet de hoeveelheid werk die erin gaat zitten om het
+programma te <em>ontwikkelen</em>. Resultaat hiervan is dus dat de mate van
+efficiëntie achteruit gaat wanneer we kijken naar mate van gebruikers
+tevredenheid per gewerkt uur.
+</p>
+<p>
+Dit is een belangrijk verschil tussen kopieën van programma's en auto's,
+stoelen of broodjes. Er bestaat geen kopieermachine voor gebruiksvoorwerpen,
+behalve in science fiction. Programma's zijn echter makkelijk te
kopiëren;
+iedereen kan er zoveel maken als hij wil met minimale inspanning. Dit gaat
niet
+op voor voorwerpen omdat grondstoffen worden gebruikt: iedere kopie moet net
zo
+opgebouwd worden uit grondstoffen als het origineel.
+</p>
+<p>
+Bij materiële voorwerpen is het logisch het gebruik te ontmoedigen omdat
+minder voorwerpen ook betekent minder grondstoffen en minder inspanning
benodigd
+om het te maken. Er zijn meestal ook wel opstartkosten aan verbonden maar die
+worden uitgesmeerd over de totale productie. Zolang deze kosten marginaal zijn
+ten opzichte van de productiekosten zal het toevoegen van de kosten voor
+ontwikkeling weinig verschil uitmaken op de kwaliteit. En het vereist geen
+beperkingen op de vrijheid van reguliere gebruikers.
+</p>
+<p>
+Echter, geld vragen voor iets wat anders gratis zou zijn is wel een
kwalitatieve
+verandering. Een centraal opgelegde bijdrage voor het verspreiden van software
+ontmoedigd het gebruik sterk.
+</p>
+<p>
+Sterker nog, het centraal verspreiden van de software, zoals nu gebeurd, is
niet
+erg efficiënt. Het systeem bevat het onnodig verpakken van disks en
tapes,
+ze in grote hoeveelheden over de wereld verschepen en opslaan voor de verkoop.
+Deze kosten worden voorgesteld als noodzakelijke zakelijke uitgaven, terwijl
het
+deels verspilling is vanwege het feit dat we zo nodig eigenaren van software
+moeten hebben.
+</p>
+
+<h4 id="damaging-social-cohesion">Schadelijk voor de Maatschappelijke
Betrokkenheid</h4>
+<p>
+Veronderstel dat zowel jij als je buurman het nuttig vinden om een bepaald
+programma te gebruiken. Ethisch gezien zou je je verplicht moeten voelen om
het
+programma met je buurman te delen. Een voorstel om slechts één
van
+jullie toe te staan het programma te gebruiken en de ander te beperken is
+onderscheidend; zowel jij als je buurman zouden dit onacceptabel moeten vinden.
+</p>
+<p>
+Het ondertekenen van een doorsnee licentie overeenkomst staat gelijk aan je
+buurman verraden: “Ik beloof mijn buurman dit programma te onthouden
zodat
+ik een kopie kan hebben voor alleen mezelf”. Wanneer mensen die keuze
+maken voelen ze tegelijk een psychologische dwang om dit gedrag te
vergoelijken:
+door het belang van het helpen van je buurman te gaan bagatelliseren—
+waarmee de maatschappelijke betrokkenheid in het gedrang komt. Dit is dus
+psychosociale schade die voortkomt uit de materiële schade als gevolg van
+de beperkingen in het gebruik van het programma.
+</p>
+<p>
+Een hoop gebruikers herkennen het foute in het niet delen van software en
+besluiten dus de licenties en wetten te laten voor wat ze zijn en toch tot het
+delen van programma's over te gaan. Ze voelen zich daar echter vaak schuldig
+over. Ze weten dat ze de wet moeten overtreden wanneer ze een goede buur
willen
+zijn, maar vinden wel dat mensen zich aan de wet moeten houden en concluderen
+dus dat wanneer je een goede buur bent (en dat zijn ze) dit iets slechts is om
+je over te schamen. Dat is ook een soort psychosociale schade die je kunt
+ontlopen door aan te nemen dat licenties en wetten geen morele waarden
bevatten.
+</p>
+<p>
+Programmeurs lijden ook psychosociale schade in de wetenschap dat veel
+gebruikers hun programma's niet mogen gebruiken. Dit leidt tot cynisme en
+ontkenning. Een programmeur kan enthousiast vertellen over het werk dat hij
+technisch uitdagend vind; en dan, wanneer je hem de vraag stelt, “Mag ik
+dat ook gebruiken?”, zie je z'n gezicht betrekken en toegeven dat het
+antwoord nee is. Om de ontmoediging te ontlopen zal hij óf dit gegeven
+meestal negeren óf hij neemt een cynische houding aan die het belang
+ervan bagatelliseert.
+</p>
+<p>
+Sinds het Reagan-tijdperk is de grootste schaarste in de Verenigde Staten niet
+die van technische innovatie maar meer de bereidheid van mensen om samen te
+werken voor het algemeen belang. Het slaat nergens op om het eerste te
+stimuleren ten koste van het tweede.
+</p>
+
+<h4 id="custom-adaptation">Het Tegengaan van Lokale Wijzigingen in
Programma's</h4>
+<p>
+Het tweede niveau van materiële schade is de onmogelijkheid om
programma's
+aan te passen. Het gemak waarmee software aan kan worden gepast is
+één van de grote voordelen ten opzichte van oudere technologie.
+Maar de meeste commerciële software is niet verkrijgbaar in een vorm
waarin
+je het kunt wijzigen, zelfs niet nadat je het hebt gekocht. Het staat je ter
+beschikking als een zwarte doos, slikken of stikken—dat is alles.
+</p>
+<p>
+Een programma dat je uitvoert bestaat uit een reeks obscure nummers. Niemand,
+zelfs geen goede programmeur, is in staat om die nummers eenvoudig te
veranderen
+zodat het programma wat anders doet.
+</p>
+<p>
+Programmeurs werken normaal gesproken met de “broncode” van een
+programma dat geschreven is in een programmeertaal als Fortran of C. Het
+gebruikt namen om data aan te duiden die wordt gebruikt en onderdelen van het
+programma en het representeert berekeningen symbolisch zoals “+”
+voor optellen en “-” voor aftrekken. De taal is ontworpen om
+programmeurs te helpen in het lezen en wijzigen van programma's. Hieronder een
+voorbeeld van een programma om de afstand van twee punten in een plat vlak tot
+elkaar te berekenen:
+</p>
+
+<pre>
+ float
+ distance (p0, p1)
+ struct point p0, p1;
+ {
+ float xdist = p1.x - p0.x;
+ float ydist = p1.y - p0.y;
+ return sqrt (xdist * xdist + ydist * ydist);
+ }
+</pre>
+<p>
+Hieronder datzelfde programma, maar nu in de vorm waarin de computer het
uitvoert:
+</p>
+
+<pre>
+ 1314258944 -232267772 -231844864 1634862
+ 1411907592 -231844736 2159150 1420296208
+ -234880989 -234879837 -234879966 -232295424
+ 1644167167 -3214848 1090581031 1962942495
+ 572518958 -803143692 1314803317
+</pre>
+
+<p>
+Broncode kan nuttig zijn (in potentie) voor iedere gebruiker van een
programma.
+Maar de meeste gebruikers mogen geen kopie van de broncode hebben. Meestal
wordt
+de broncode van een privaat programma geheim gehouden door de eigenaar, iemand
+zou er eens wat van mogen opsteken. Gebruikers krijgen alleen een kopie van de
+bestanden met de obscure nummers die een computer uitvoert. Dit betekent dat
+alleen de eigenaar van het programma dit programma kan veranderen.
+</p>
+<p>
+Een vriend van me vertelde eens hoe hij, als programmeur voor een bank, zes
+maanden bezig is geweest met het maken van een programma dat iets soortgelijks
+deed als een commercieel verkrijgbaar programma. Zij was er van overtuigd
+dat als ze toegang had gehad tot de broncode, ze het eenvoudig had kunnen
+aanpassen op hun behoeften. De bank wilde er voor betalen maar mocht dit niet
+—de broncode was geheim. Dus moest ze zes maanden bouwen aan een
imitatie,
+werk dat wel meetelt in het BNP maar eigenlijk gewoon weggegooid geld is.
+</p>
+<p>
+Het MIT 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 laser
printers,
+aan het laboratorium. Hij werd aangestuurd door private software die op een
+aparte computer liep waardoor we onze favoriete aanpassingen niet toe konden
+passen. We konden instellen dat er een melding kwam wanneer er een uitdraai
naar
+de printer werd gestuurd maar niet wanneer het uiteindelijk op de printer
+belandde (bovendien was de vertraging van die melding meestal groot). Er was
+geen enkele manier om te achterhalen of een uitdraai ook daadwerkelijk gelukt
+was; hier kon je alleen maar naar raden. En niemand kreeg een melding wanneer
er
+papier klem zat dus dat kon wel eens een uur duren voordat iemand dat door had.
+</p>
+<p>
+De systeemprogrammeurs op het laboratorium waren prima in staat om dit soort
+extra functionaliteit toe te voegen, waarschijnlijk net zo goed als de makers
+van het programma. Xerox wilde dit niet oplossen en koos ervoor oplossingen
van
+ons tegen te houden. We werden dus gedwongen deze problemen te accepteren, ze
+werden nooit opgelost.
+</p>
+<p>
+De meeste goede programmeurs kennen deze frustratie. De bank kon het zich
+veroorloven het probleem op te lossen middels het opnieuw schrijven van een
+programma maar een doorsnee gebruiker, hoe capabel ook, kan het alleen maar
+opgeven.
+</p>
+<p>
+Het opgeven leidt tot psychosociale schade—in je gevoel van
+zelfstandigheid. Het is frustrerend om in een huis te wonen dat je niet zelf
mag
+inrichten. Het leidt tot berusting en moedeloosheid, die je kwaliteit van
leven
+weer beïnvloeden. Mensen die zich zo voelen zijn niet gelukkig en
+presteren slecht.
+</p>
+<p>
+Stel je voor dat men met recepten op dezelfde manier om zou gaan als met
+software. Je zou dan op kunnen merken, “Hoe kan ik dit recept veranderen
+zodat er minder zout in zit?” en de machtige chef zou antwoorden, “
+Hoe durf je mijn recept te beledigen, het product van mijn brein en
verhemelte,
+door ermee te gaan knoeien? Jij kunt zo'n verandering helemaal niet inschatten
+en er het juiste resultaat uit krijgen!”
+</p>
+<p>
+“Maar ik mag helemaal geen zout van de dokter! Wat kan ik hieraan doen?
+Wil jij het er voor me uit halen?”
+</p>
+<p>
+“Natuurlijk, met alle liefde, en ik reken slechts 50.000 euro voor een
+dergelijke wijziging”. Omdat een eigenaar het monopolie heeft op
+wijzigingen zijn de tarieven meestal hoog. “Helaas heb ik nu echter even
+geen tijd hiervoor. Ik ben bezig met een opdracht voor de marine om nieuw
+scheepsbeschuit te ontwerpen. Over ongeveer twee jaar heb ik wel weer
tijd”.
+</p>
+
+<h4 id="software-development">Software Ontwikkeling Tegenwerken</h4>
+<p>
+Het derde niveau van materiële schade betreft software ontwikkeling.
+Software ontwikkeling was vroeger een evolutionair proces waarbij iemand een
+bestaand programma nam en daarin wijzigingen en toevoegingen aanbracht voor
een
+bepaalde nieuwe toepassing. Vervolgens gebruikte een ander dat resultaat weer
om
+op zijn beurt wijzigingen en toevoegingen aan te brengen voor weer een andere
+toepassing: in sommige gevallen ging dat wel twintig jaar zo door. Intussen
+werden delen van dat programma weer “gekannibaliseerd” om te
+gebruiken als basis voor weer een nieuw programma.
+</p>
+<p>
+Het bestaan van eigenaren houdt dit soort evolutie tegen waardoor het
+noodzakelijk wordt een nieuw programma van de grond af op te bouwen. Het laat
+ook niet toe dat nieuwe programmeurs bestaande programma's bestuderen om
daarvan
+nuttige technieken te leren, of zelfs hoe grote programma's in elkaar zitten.
+</p>
+<p>
+Eigenaren houden ook scholing tegen. Ik heb studenten computer science ontmoet
+die nog nooit de broncode van een groot programma hebben gezien. Ze zullen
+wellicht goed zijn in het maken van kleine programma's maar ze kunnen nog niet
+eens de vaardigheden beginnen aan te leren van het schrijven van grote
+programma's wanneer ze niet de kans krijgen te zien hoe anderen dit gedaan
hebben.
+</p>
+<p>
+In welk intellectueel streven dan ook kan men alleen grote hoogten bereiken op
+de schouders van anderen. Maar dat mag over het algemeen niet meer in de
wereld
+van de software—je kan alleen op de schouders staan van anderen <em>in
je
+eigen bedrijf</em>.
+</p>
+<p>
+De resulterende psychosociale schade is van invloed op de geest van
+wetenschappelijke samenwerking die vroeger zo sterk was dat het zelfs oorlogen
+oversteeg. Zo was het mogelijk dat Japanse oceanografen die hun laboratorium
op
+een pacifisch eiland moesten verlaten hun werk zorgvuldig beschermd probeerden
+achter te laten voor de binnenvallende Amerikaanse mariniers met een briefje
+erbij met het verzoek hier goed voor te zorgen.
+</p>
+<p>
+Het gevecht om winst heeft kapotgemaakt wat internationale oorlogen nooit is
+gelukt. Tegenwoordig publiceren wetenschappers in vele disciplines niet
+voldoende informatie meer in hun scripties om anderen in staat te stellen het
+experiment te herhalen. Ze publiceren net genoeg zodat anderen kunnen
bewonderen
+wat ze allemaal wel niet bereikt hebben. Dit geldt zeker voor de
+computerwetenschappen, waar de broncode waarover men schrijft meestal geheim
is.
+</p>
+
+<h4 id="does-not-matter-how">Het Maakt Niet Uit Hoe Het Delen Wordt
Beperkt</h4>
+<p>
+Ik heb de gevolgen besproken die het heeft wanneer mensen verboden wordt om
+programma's te kopiëren, wijzigen of uitbouwen. Ik heb het niet gehad
over
+hoe men dit verbiedt want dat maakt voor de gevolgen niets uit. Of het nu
+gebeurd via kopieerbeveiligingen, auteursrecht, licenties, versleuteling, ROM
+kaarten of hardware serienummers, als het <em>lukt</em> om gebruik te
voorkomen,
+dan berokkent het schade.
+</p>
+<p>
+Gebruikers vinden sommige methoden hinderlijker dan andere methodes. Ik zou
+zeggen dat de meest hinderlijke methode degene is die het daadwerkelijk lukt
ons
+van het gebruik af te houden.
+</p>
+
+<h4 id="should-be-free">Software Zou Vrij Moeten Zijn</h4>
+<p>
+Ik heb aangetoond dat het in eigendom hebben van een programma—de macht
om
+gebruik of distributie te verbieden—belemmerend werkt. Er zijn veel
+belangrijke negatieve effecten aan verbonden. Hieruit volgt dat de
maatschappij
+het in eigendom hebben van programma's beter niet kan hebben.
+</p>
+<p>
+Een andere manier om dit te zeggen is dat de maatschappij vrije software nodig
+heeft en dat private software een slechte vervanger is. Gebruik van het
+surrogaat aanmoedigen om te krijgen wat we nodig hebben is niet logisch.
+</p>
+<p>
+Vaclav Havel adviseerde ons al om te “Werken voor iets omdat het goed
is,
+niet alleen omdat het een kans van slagen heeft”. Een bedrijf dat
private
+software maakt heeft kans van slagen op zijn eigen beperkte terrein maar dat
is
+niet goed voor de maatschappij.
+</p>
+
+<h3 id="why-develop">Waarom Mensen Software Zullen Maken</h3>
+<p>
+Wanneer we het auteursrecht uitschakelen als motivator voor mensen om software
+te ontwikkelen zal er in eerste instantie minder software worden ontwikkeld
maar
+die software zal wel bruikbaarder zijn. Het is nog niet duidelijk of de
+tevredenheid onder gebruikers zal afnemen; maar als dat zo is, of wanneer we
het
+sowieso willen verhogen, dan zijn er andere methoden om het maken van software
+te stimuleren. Net als er andere manieren dan alleen tolhuisjes zijn om
+financiering voor straten los te krijgen. Voordat we die alternatieven gaan
+bekijken wil ik eerst eens vaststellen hoeveel kunstmatige stimulering er
+eigenlijk echt nodig is.
+</p>
+
+<h4 id="fun">Programmeren is Leuk</h4>
+<p>
+Er zijn een aantal beroepen die men alleen voor geld zou willen doen;
wegwerker
+bijvoorbeeld. Er zijn ook andere studies en kunstrichtingen waar men nooit
rijk
+van zal worden maar waar mensen van gefascineerd zijn of denken een goede
+bijdrage aan de maatschappij mee te kunnen leveren. Voorbeelden daarvan zijn
+mathematische logica, klassieke muziek en archeologie. Mensen concurreren,
meer
+tot hun verdriet dan bitter, om de paar honderd plekken die te vergeven zijn
en
+niet erg goed worden betaald. Ze zullen soms zelfs betalen voor de kans om op
+dat gebied werkzaam te zijn, als ze het zich kunnen veroorloven.
+</p>
+<p>
+Een dergelijke discipline kan volledig veranderen wanneer het de mogelijkheid
+biedt om rijk te worden. Als één werker rijk wordt gaan de
anderen
+hetzelfde willen. Al snel zal iedereen grote bedragen vragen voor het werk dat
+ze voorheen voor hun plezier deden. Na nog wat jaren zullen ze eenieder
+uitlachen die het idee oppert dat het werk ook kan worden gedaan zonder grote
+financiële compensaties. Ze zullen overheden oproepen maatregelen te
+treffen om hun inkomsten veilig te stellen met voorstellen over speciale
+voorrechten, machtigingen en monopolies en suggereren dat dit nodig is.
+</p>
+<p>
+Deze verandering vond plaats in het programmeervak gedurende het laatste
+decennium. Vijftien jaar geleden verschenen er artikelen over “computer
+verslaving”: gebruikers waren de hele tijd “online” en
+ontwikkelden honderd-euro-per-week gewoontes. Het was algemeen bekend dat
mensen
+zoveel van programmeren hielden dat het hun het huwelijk kostte. Tegenwoordig
+programmeert er niemand meer zonder daar zwaar voor te worden betaald. Mensen
+zijn vergeten wat ze vijftien jaar geleden wisten.
+</p>
+<p>Wanneer de meeste mensen in een vakgebied alleen willen werken voor veel
geld
+wil dat nog niet zeggen dat dit niet kan veranderen. Het proces kan worden
+omgekeerd wanneer de maatschappij hier de stimulansen voor aanlevert. Wanneer
we
+de mogelijkheid wegnemen om in het vakgebied vreselijk rijk te worden dan zal
+men na een tijdje, wanneer mensen aan de nieuwe situatie gewend zijn geraakt,
+weer gemotiveerd raken om in dit vakgebied voor de lol te werken.
+</p>
+<p>
+De vraag “Hoe kunnen we onze programmeurs betalen?” wordt
+makkelijker te beantwoorden wanneer we ons realiseren dat ze geen fortuin
hoeven
+te verdienen. Een normaal salaris om van te leven is voldoende.
+</p>
+
+<h4 id="funding">Het Financieren van Vrije Software</h4>
+<p>
+Instituten die programmeurs betalen hoeven niet persé softwarebedrijven
+te zijn. Vele andere bestaande organisaties kunnen dit ook doen.
+</p>
+<p>
+Hardware fabrikanten vinden het belangrijk om software ontwikkeling te steunen
+ook al hebben ze zelf geen zeggenschap over die software. In 1970 was veel van
+hun software vrij omdat ze niet op het idee kwamen er beperkingen op te
leggen.
+Tegenwoordig, met hun neiging consortia te vormen, wordt duidelijk dat ze zich
+realiseren dat het in eigendom hebben van software niet belangrijk is voor ze.
+</p>
+<p>
+Universiteiten voeren veel programmeerprojecten uit. Tegenwoordig verkopen ze
+vaak de resultaten maar in 1970 deden ze dat nog niet. Is er iemand die
+betwijfelt of universiteiten vrije software zouden ontwikkelen wanneer ze geen
+software mogen verkopen? Dit soort projecten zou gefinancierd kunnen worden
met
+dezelfde overheidssubsidies en beurzen die nu worden gebruikt voor het
+ontwikkelen van private software.
+</p>
+<p>
+Het is gewoonte geworden bij onderzoekers om subsidie te krijgen voor het
+ontwikkelen van een systeem, dit net niet af te maken en het dan
“af”
+ te verklaren. Om vervolgens een bedrijf te starten, waarin het project
+daadwerkelijk wordt afgemaakt en het systeem bruikbaar gemaakt. Soms verklaren
+ze de half voltooide versie nog “vrij”; maar wanneer ze totaal
+corrupt zijn onderhandelen ze in plaats daarvan met de universiteit over een
+exclusieve licentie. Dit is geen geheim; het wordt openlijk toegegeven door
alle
+betrokkenen. Wanneer onderzoekers echter niet in de verleiding worden gebracht
+om dit soort dingen te doen, zouden ze nu nog steeds onderzoek doen.
+</p>
+<p>
+Programmeurs die vrije software maken kunnen hun kostje bij elkaar scharrelen
+door gerelateerde services te verkopen bij hun software. Ikzelf ben ingehuurd
om
+de <a href="/software/gcc/gcc.html">GNU C compiler</a> geschikt te maken voor
+nieuwe hardware en voor het uitbreiden van de gebruikersinterface van <a href=
+"/software/emacs/emacs.html">GNU Emacs</a> (Ik geef deze verbeteringen weer
vrij
+wanneer ze ontwikkeld zijn). Ik geef ook betaald les.
+</p>
+<p>
+Ik ben niet de enige die zo werkt; er is nu een succesvol en groeiend
bedrijfje
+dat alleen dit soort werk doet. Verschillende andere bedrijven bieden nu ook
+commerciële ondersteuning aan voor de vrije software van het GNU systeem.
+Dit is het begin van een onafhankelijke software support industrie—een
+industrietak die heel groot zou kunnen worden wanneer vrije software de
voorkeur
+krijgt. Het geeft gebruikers een optie die meestal niet beschikbaar is voor
+private software, behalve voor de heel rijken.
+</p>
+<p>
+Nieuwe instellingen zoals de <a href="/fsf/fsf.html">Free Software
Foundation</a>
+ (de stichting voor vrije software) kunnen ook programmeurs sponsoren. De
+inkomsten van deze stichting zijn voornamelijk afkomstig van gebruikers die
+tapes met software bestellen via de postorder. De software op de tapes is
vrij,
+wat inhoudt dat men deze mag wijzigen en kopiëren maar velen betalen toch
+voor de kopie (“vrije” software slaat op vrijheid in het gebruik,
+niet vrij van kosten). Sommige gebruikers die al een kopie hebben bestellen
toch
+de tapes, hun manier om een bijdrage te doen voor de goede zaak. De stichting
+krijgt ook grote schenkingen van computerfabrikanten.
+</p>
+<p>
+De Free Software Foundation is een liefdadige instelling en zijn inkomsten
+worden besteedt 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 Software Productiviteit? </h3>
+<p>
+Wanneer software vrij zou zijn zouden er nog steeds programmeurs zijn maar
+wellicht minder dan nu. Zou dit slecht voor de maatschappij zijn?
+</p>
+<p>
+Niet persé. Tegenwoordig hebben de ontwikkelde landen minder boeren dan
+in 1900 maar we zien dit niet als zijnde slecht voor de maatschappij want de
+weinige boeren die we hebben leveren meer voedsel richting consument dan de
vele
+die we hadden. We noemen dit toegenomen produktiviteit. We zouden ook toe
kunnen
+met minder programmeurs van vrije software door de toegenomen produktiviteit
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 overnieuw 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
+produktiviteit. Meestal onderschrijven ze echter wel de algemeen gangbare
+stelling dat de softwareindustrie meer produktiviteit nodig heeft. Hoe kan dat?
+</p>
+<p>
+“Produktiviteit in software” kan op twee dingen betrekking hebben:
de
+algemene produktiviteit van alle software ontwikkelingen of de produktiviteit
+van individuele projecten. De maatschappij wil graag de algemene
produktiviteit
+verhogen en de simpelste manier om dit te bereiken is door het afschaffen van
+kunstmatige belemmeringen in samenwerking. Maar onderzoekers die het probleem
+van “produktiviteit in software” onderzoeken spitsen het onderzoek
+toe op de tweede, meer beperkte, interpretatie die moeilijke technologische
+oplossingen behoeven.
+</p>
+
+<h3 id="competition">Is Concurrentie Onvermijdelijk?</h3>
+<p>
+Is het onvermijdelijk dat mensen zullen proberen te concurreren met hun
rivalen
+in de maatschappij? Misschien wel. Maar concurrentie is niet schadelijk; het
+schadelijke element is <em>vechten</em>.
+</p>
+<p>
+Er zijn vele manieren om te concurreren. Concurrentie kan eruit bestaan dat
men
+probeert steeds meer te bereiken dan tot nu toe of dingen beter te doen dan
+anderen. Vroeger was er bijvoorbeeld concurrentie tussen programmeertalenten
+—wedstrijdjes wie de computer de meest verbazende dingen kon laten doen,
+of wie het kortste of snelste programma kon maken gegeven een bepaalde taak.
Dit
+soort competitie kan iedereen tot nut zijn, <em>zolang men hier maar sportief
+mee om gaat</em>.
+</p>
+<p>
+Opbouwende concurrentie is voldoende competitie om mensen te stimuleren tot
+grote dingen. Een aantal mensen streven ernaar om de eerste te zijn die alle
+landen op de wereld heeft bezocht; sommigen geven er zelfs fortuinen aan uit.
+Maar ze zullen geen kapiteins omkopen om hun rivalen te laten stranden op
+verlaten eilanden. Ze hebben er vrede mee dat de beste zal winnen.
+</p>
+<p>
+Concurrentie wordt vechten wanneer rivalen elkaar gaan proberen te verhinderen
+iets te bereiken in plaats van te proberen zelf wat te bereiken—wanneer
+“dat de beste mag winnen” veranderd in “laat mij winnen,
+ongeacht of ik de beste ben”. Private software is schadelijk, niet omdat
+het een manier van concurreren is maar een vorm van vechten tussen mensen in
+de maatschappij.
+</p>
+<p>
+Zakelijke concurrentie is niet per definitie vechten. Wanneer bijvoorbeeld
twee
+groentewinkels met elkaar concurreren is al hun inspanning gericht op het
+verbeteren van hun eigen bedrijfsvoering, niet op het saboteren van de ander.
+Dit is echter geen demonstratie van zakelijk fatsoen; het is meer zo dat er
+weinig mogelijkheid is om te vechten, behalve het gebruik van fysiek geweld.
+Niet alle zakelijke sectoren zitten zo in elkaar. Het achterhouden van
+informatie die iedereen zou kunnen helpen is een vorm van vechten.
+</p>
+<p>
+Zakelijke ideologie bereidt het publiek niet voor op het weerstaan van
+verleidingen om de concurrentie de loef af te steken. Sommige vormen van
+concurrentie of strijd zijn bij wet verboden zoals concurrentievervalsing,
+liegen bij het adverteren enzovoorts maar in plaats van dit breder te trekken
+door bij wet dit soort strijd in het algemeen te verbieden, bedenken
zakenmensen
+steeds nieuwe vormen van strijd die niet specifiek zijn verboden.
+Maatschappelijke gelden worden zo verkwist aan een economische equivalent van
+burgeroorlog.
+</p>
+
+<h3 id="communism">“Waarom Verkas je niet naar Rusland?”</h3>
+<p>
+Iedere voorstander in de Verenigde Staten van meer dan een minimale
+overheidsbemoeienis heeft dit vaak te horen gekregen. Het wordt geuit tegen
+voorstanders van meer overheidsbemoeienis met de gezondheidszorg, iets dat
alle
+andere ontwikkelde landen wel hebben. Het wordt geuit tegen voorstanders van
+meer ondersteuning vanuit de overheid voor kunst, ook gebruikelijk in alle
+andere ontwikkelde landen. Het idee dat inwoners wat voor verplichting dan ook
+hebben richting de maatschappij wordt gelijkgesteld aan communisme. Maar in
+hoeverre lijken die ideeën op elkaar?
+</p>
+<p>
+Het communisme, zoals dat in de Sovjet Unie werd gebezigd was een centraal
+gestuurd systeem waar alle activiteit was gereguleerd, onder het mom dat het
+goed was voor de gemeenschap maar feitelijk alleen voor de leden van de
+communistische partij. En waar kopieerapparatuur zwaar werd bewaakt om
illegaal
+kopiëren tegen te gaan.
+</p>
+<p>
+Het Amerikaanse systeem van auteursrecht oefent totale controle uit op het
+distribueren van een programma en bewaakt het kopiëren met <a href=
+"http://www.digitalspeech.org/";>automatische kopieerbeveiligingen</a> om
+illegaal kopiëren tegen te gaan.
+</p>
+<p>
+Daarentegen ben ik een systeem aan het bouwen waarbij mensen vrij zijn om zelf
+te beslissen wat ze ermee gaan doen; vooral vrij zijn om hun buren te helpen
en
+vrij zijn om de hulpmiddelen die ze in hun dagelijks leven gebruiken te
+veranderen en verbeteren naar eigen believen. Een systeem, gebaseerd op
+vrijwillige samenwerking en decentralisatie.
+</p>
+<p>
+Wanneer we dus inzichten beoordelen op hun gelijkenis met het Russische
+communisme dan zijn het de eigenaren van software die de communisten zijn.
+</p>
+
+<h3 id="premises">De Juiste Uitgangspunten</h3>
+<p>
+In dit artikel ga ik er van uit dat de gebruiker van software niet minder
+belangrijk is dan een auteur of zelfs de werkgever van een auteur. Met andere
+woorden, ons besluit voor de juiste actie is gebaseerd op het uitgangspunt dat
+hun belangen even groot zijn.
+</p>
+<p>
+Dit uitgangspunt wordt niet door iedereen gedeeld. Velen houden vol dat de
+belangen van een werkgever belangrijker zijn dan ieder ander. Ze beweren
+bijvoorbeeld dat het doel van het hebben van eigenaren van software de
werkgever
+juist het voordeel geven dat hij verdient—ongeacht wat voor gevolgen dit
+heeft voor het publiek.
+</p>
+<p>
+Het heeft geen zin deze uitgangspunten aan te vechten. Bewijs wordt gebaseerd
op
+algemeen aanvaarde aannames. Dus het meeste van wat ik hier te zeggen heb is
+voor diegenen die zich in mijn uitgangspunt kunnen vinden, of in ieder geval
+nieuwsgierig zijn naar de consequenties. Dit artikel is gewoon niet relevant
+voor diegenen die geloven dat eigenaren belangrijker zijn dan de rest.
+</p>
+<p>
+Maar waarom zouden vele Amerikanen een uitgangspunt accepteren dat sommige
+mensen boven anderen verheft? Gedeeltelijk doordat men gelooft dat dit
+uitgangspunt onderdeel is van de juridische grondslag van de Amerikaanse
+maatschappij. Sommigen zullen dit beleven als het aan de kaak stellen van hun
+maatschappelijke basis.
+</p>
+<p>
+Het is belangrijk dat deze mensen zich realiseren dat dit uitgangspunt nooit
een
+onderdeel is geweest van onze (Amerikaanse) juridische traditie. Dat is het
ook
+nooit geweest.
+</p>
+<p>
+Aldus zegt de grondwet dat het doel van het auteursrecht is “het
+stimuleren van wetenschappelijke vooruitgang en nuttige kunst”. Het
+Hooggerechtshof heeft zich hier nog nader over uitgesproken met de uitspraak
in
+“Fox Film vs. Doyal” dat “het enige belang van de Verenigde
+Staten en primaire doel van het verlenen van het [autuersrecht] monopolie ligt
+in de algemene voordelen die de maatschappij zal genieten van het werk van
+auteurs”.
+</p>
+<p>
+We hoeven het niet eens te zijn met de grondwet of met het Hooggerechtshof (ze
+hebben in het verleden slavernij goedgekeurd). Dus hun standpunten doen niets
af
+aan het uitgangspunt van grotere belangen van werkgevers. Ik hoop wel dat het
+besef dat dit een rechts-radicaal standpunt is en niet een traditioneel,
+algemeen aanvaardbaar standpunt, de aantrekkingskracht van het standpunt zal
+doen verminderen.
+</p>
+
+<h3 id="conclusion">Conclusie</h3>
+<p>
+Wij denken dat onze maatschappij het helpen van je buren stimuleert; maar
iedere
+keer dat we iemand belonen wanneer die iets tegenhoudt, of ze bewonderen om de
+rijkdom die ze op die manier vergaard hebben, zenden we het tegenovergestelde
+signaal uit.
+</p>
+<p>
+Het verzamelen van software is een uiting van onze neiging om persoonlijk
gewin
+voor het welbevinden van de maatschappij te stellen. We kunnen deze neiging
+herleiden van Ronald Reagan naar Dick Cheney, van Exxon naar Enron, van
falende
+banken naar falende scholen. We kunnen het afmeten aan het aantal zwervers en
+het aantal gevangenen. Dit asociale gedrag houdt zichzelf in stand, want hoe
+meer we zien dat andere mensen ons niet willen helpen des te kleiner wordt de
+neiging om hen te helpen. En aldus vervalt de maatschappij tot een jungle.
+</p>
+<p>
+Wanneer we niet in een jungle willen leven moeten we ons gedrag veranderen. We
+moeten het signaal gaan afgeven dat een goed burger er een is die met anderen
+samenwerkt wanneer dat zo te pas komt, niet een die succes heeft met dingen
+afnemen van anderen. Ik hoop dat de vrije software gemeenschap hiertoe zal
+bijdragen: op tenminste één gebied zullen we de jungle vervangen
+door een efficiënter systeem dat gebaseerd zal zijn op vrijwillige
+samenwerking.
+</p>
+
+
+<h3 id="footnotes">Voetnoten</h3>
+
+<ol>
+<li> <a id="f1"> Het woord “vrij” in “vrije software”
+slaat op vrijheid, niet op prijs; de prijs die je betaalt voor de kopie van
een
+vrij programma kan nul zijn, een beetje of (soms) heel veel (Noot van de
+vertaler: “free” in het Engels betekent zowel vrijheid als gratis,
+vandaar deze voetnoot).</a></li>
+
+<li> <a 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 maximum snelheid dan ook.
+</a></li>
+
+<li> <a 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.
+</a></li>
+</ol>
+
+
+<hr />
+<h4>Dit korte verhaal is gepubliceerd in <a
href="/doc/book13.html"><cite>Vrije
+Software, Vrije Maatschappij: Geselecteerde Artikelen van Richard M. Stallman
+</cite></a></h4>
+
+<h4><a href="/philosophy/philosophy.nl.html">Andere artikelen</a></h4>
+<hr />
+
+<!-- If needed, change the copyright block at the bottom. In general, -->
+<!-- all pages on the GNU web server should have the section about -->
+<!-- verbatim copying. Please do NOT remove this without talking -->
+<!-- with the webmasters first. -->
+<!-- Please make sure the copyright date is consistent with the document -->
+<!-- and that it is like this "2001, 2002" not this "2001-2002." -->
+</div><!-- for id="content", starts in the include above -->
+<!--#include virtual="/server/footer.html" -->
+<div id="footer">
+
+<p>
+Gelieve vragen over FSF & GNU te sturen naar
+<a href="mailto:address@hidden";><em>address@hidden</em></a>.
+Er zijn ook nog <a href="/contact/">andere manieren om in contact te komen</a>
+met de FSF.
+<br />
+Gelieve meldingen van verkeerde links en andere verbeteringen (of suggesties)
+te sturen aan:
+<!-- If you are a project maintainer or developer, please use -->
+<!-- your own email, as webmasters does not manage most -->
+<!-- project webpages (those that we do, you know who you are). -->
+<a href="mailto:address@hidden";><em>address@hidden</em></a>.
+</p>
+
+<p>
+Zie <a href="/server/standards/README.translations">Translations
+README</a> voor nadere informatie over het eventueel vertalen van dit artikel.
+</p>
+
+<p>
+Copyright (C) 1998, 2001, 2005, 2006 Free Software Foundation, Inc.
+<p>
+<address>51 Franklin St, Fifth Floor, Boston, MA 02110, USA</address>
+<p>Het letterlijk overnemen en kopiëren van dit artikel is toegestaan op
+willekeurig welk medium op voorwaarde dat deze mededeling ook wordt meegenomen.
+</p>
+
+<p>
+Updated:
+<!-- timestamp start -->
+$Date: 2007/03/31 23:32:13 $ $Author: tuijldert $
+<!-- timestamp end -->
+</p>
+</div>
+<div id="translations">
+<h3>Vertalingen van dit artikel:</h3>
+
+<!-- Please keep this list alphabetical. -->
+<!-- Comment what the language is for each type, i.e. de is Deutsch.-->
+<!-- If you add a new language here, please -->
+<!-- advise address@hidden and add it to -->
+<!-- - /home/www/bin/nightly-vars either TAGSLANG or WEBLANG -->
+<!-- - /home/www/html/server/standards/README.translations.html -->
+<!-- - one of the lists under the section "Translations Underway" -->
+<!-- - if there is a translation team, you also have to add an alias -->
+<!-- to mail.gnu.org:/com/mailer/aliases -->
+<!-- Please also check you have the 2 letter language code right versus -->
+<!-- <URL:http://www.w3.org/WAI/ER/IG/ert/iso639.htm> -->
+<!-- Please use W3C normative character entities -->
+
+<ul class="translations-list">
+<!-- English -->
+<li><a
href="/philosophy/shouldbefree.zh-cn.html">简体中文</a>
<!-- Chinese(Simplified) --></li>
+<li><a
href="/philosophy/shouldbefree.zh-tw.html">繁體中文</a>
<!-- Chinese(Traditional) --></li>
+<li><a href="/philosophy/shouldbefree.cs.html">Česky</a> <!--
Czech --></li>
+<li><a href="/philosophy/shouldbefree.de.html">Deutsch</a> <!-- German
--></li>
+<li><a href="/philosophy/shouldbefree.html">English</a></li>
+<li><a href="/philosophy/shouldbefree.es.html">Español</a> <!--
Spanish --></li>
+<li><a href="/philosophy/shouldbefree.fr.html">Français</a> <!--
French --></li>
+<li><a
href="/philosophy/shouldbefree.he.html">עברית</a>
<!-- Hebrew --></li>
+<li><a href="/philosophy/shouldbefree.id.html">Bahasa Indonesia</a> <!--
Indonesian --></li>
+<li><a href="/philosophy/shouldbefree.nl.html">Nederlands</a> <!-- Dutch
--></li>
+<li><a href="/philosophy/shouldbefree.pl.html">Polski</a> <!-- Polish
--></li>
+<li><a href="/philosophy/shouldbefree.pt.html">Português</a> <!--
Portuguese --></li>
+<li><a
href="/philosophy/shouldbefree.ru.html">Русский</a>
<!-- Russian --></li>
+<li><a
href="/philosophy/shouldbefree.sr.html">Српски</a>
<!-- Serbian --></li>
+<li><a href="/philosophy/shouldbefree.fi.html">Suomi</a> <!-- Finnish
--></li>
+</ul>
+</div>
+</div>
+</body>
+</html>
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- www/philosophy shouldbefree.nl.html,
Tom Uijldert <=