Waarom software vrij zou moeten zijn

door Richard Stallman

Het bestaan van software leidt onherroepelijk tot de vraag hoe men beslist over het gebruik ervan. Een individu bijvoorbeeld, met een kopie van een programma, loopt iemand anders tegen het lijf die ook een kopie zou willen hebben. Het is mogelijk om hiervan een kopie te maken; wie zou mogen beslissen of dit ook gebeurt? De betreffende personen? Of een andere partij, te weten de “eigenaar”?

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.

Ik zou graag diezelfde vraag in overweging willen nemen maar dan met een ander uitgangspunt: de voorspoed en vrijheid van mensen in het algemeen.

De beslissing kan niet genomen worden door huidige wetgeving—de wet dient de ethiek te volgen, niet andersom. De huidige manier van werken kan dit ook niet beslissen, maar wel een mogelijke richting aangeven. De enige manier om dit goed te kunnen beoordelen is door te kijken wie er mee is geholpen (en waarom en hoeveel) en wie niet wanneer we erkennen dat software in eigendom kan zijn. Oftewel, een kosten-batenanalyse voor de maatschappij als geheel, rekening houdend met individuele vrijheid alsook de productie van materiële goederen.

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 “vrije” software te maken.(1)

Hoe eigenaren hun macht rechtvaardigen

Degenen die baat hebben bij de huidige praktijk van programma's die bezit vormen, komen met twee rechtvaardigingen hiervoor: een emotionele en een economische.

Het emotionele argument gaat als volgt: “Ik heb mijn bloed, zweet en tranen in dit programma zitten. Ik heb het gemaakt, het is van mij!”

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.

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.

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.

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.

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.

Argumenten tegen het eigenaarschap

De vraag is dus, “moet het ontwikkelen van software gebonden zijn aan het hebben van eigenaren die het gebruik ervan kunnen limiteren?”.

Om dit te kunnen beoordelen moeten we het effect van beide activiteiten op de maatschappij afzonderlijk 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.

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.

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.

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.

Laten we de discussie ter verheldering eens toepassen op het bouwen van wegen.

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.

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 (2). 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.

Wanneer voorstanders van tolhuisjes dit voorstellen als slechts 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.

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.

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.

Om deze redenering nu door te zetten naar software ontwikkeling zal ik laten zien dat het de maatschappij behoorlijk wat schade berokkent wanneer we dergelijke “tolhuisjes” opzetten voor nuttige programmatuur: het maakt programma's duurder om te maken, duurder om te verspreiden en minder bruikbaar en efficiënt. Hieruit zal blijken dat het maken van programma's beter op een andere manier gestimuleerd kan worden. Daarna zal ik andere methoden behandelen om softwareontwikkeling te stimuleren en (voor zover nodig) te financieren.

De schade van software met beperkingen

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 (3).

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?

Drie verschillende niveaus van materiële schade volgen uit dergelijke beperkingen:

• Minder mensen zullen het programma gebruiken.
• Geen enkele gebruiker kan het programma aanpassen of repareren.
• Andere ontwikkelaars kunnen niets leren van dit programma of het gebruiken als basis voor nieuwe ontwikkelingen.

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.

De drie niveaus van materiële schade doen afbreuk aan de bijdrage van een programma maar niet zozeer dat er helemaal geen sprake meer is van een bijdrage. Wanneer de afbreuk de bijdrage zou neutraliseren dan is de maximale schade voor de gemeenschap gelijk aan de inspanning die het gekost heeft om het programma te maken. Verder is aan te voeren dat een programma dat winst maakt kennelijk iets toevoegt wat direct materieel resultaat oplevert.

Rekening houdend met de bijkomende psychosociale nadelen, is er geen grens aan de mate waarin private software schade kan aanrichten.

Gebruiksbeperkingen van programma's

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.

Het is eenvoudig aan te tonen dat de totale bijdrage van een programma aan de gemeenschap wordt verminderd wanneer een programma een eigenaar krijgt. Iedere potentiële gebruiker van het programma die wordt geconfronteerd met de eis te betalen als ze het willen gebruiken zal een keuze maken: gebruiken of niet. Wanneer de gebruiker beslist het te gebruiken en dus te betalen vindt er een neutrale overdracht van welvaart plaats tussen gebruiker en eigenaar. Iedere keer echter dat een gebruiker het verkiest om niet te betalen en het dus niet te gebruiken berokkent het die potentiële gebruiker schade zonder dat iemand er ook profijt van heeft. De som van deze negatieve gevolgen en de neutrale transacties kan dus alleen maar negatief zijn.

Dit vermindert echter niet de hoeveelheid werk die erin gaat zitten om het programma te ontwikkelen. Resultaat hiervan is dus dat de mate van efficiëntie achteruit gaat wanneer we kijken naar mate van gebruikers tevredenheid per gewerkt uur.

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.

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.

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.

Sterker nog, het centraal verspreiden van de software, zoals nu gebeurt, is niet erg efficiënt. Het systeem bevat het onnodig verpakken van disks en tapes, ze in grote hoeveelheden over de wereld verschepen en opslaan voor de verkoop. Deze kosten worden voorgesteld als noodzakelijke zakelijke uitgaven, terwijl het deels verspilling is vanwege het feit dat we zo nodig eigenaren van software moeten hebben.

Schadelijk voor de maatschappelijke betrokkenheid

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.

Het ondertekenen van een doorsnee licentieovereenkomst staat gelijk aan je buurman verraden: “Ik beloof mijn buurman dit programma te onthouden zodat ik een kopie kan hebben voor alleen mezelf”. Wanneer mensen die keuze maken voelen ze tegelijk een psychologische dwang om dit gedrag te vergoelijken: door het belang van het helpen van je buurman te gaan bagatelliseren— waarmee de maatschappelijke betrokkenheid in het gedrang komt. Dit is dus psychosociale schade die voortkomt uit de materiële schade als gevolg van de beperkingen in het gebruik van het programma.

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.

Programmeurs lijden ook psychosociale schade in de wetenschap dat veel gebruikers hun programma's niet mogen gebruiken. Dit leidt tot cynisme en ontkenning. Een programmeur kan enthousiast vertellen over het werk dat hij technisch uitdagend vindt; en dan, wanneer je hem de vraag stelt, “Mag ik dat ook gebruiken?”, zie je z'n gezicht betrekken en toegeven dat het antwoord nee is. Om de ontmoediging te ontlopen zal hij óf dit gegeven meestal negeren óf hij neemt een cynische houding aan die het belang ervan bagatelliseert.

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.

Het tegengaan van lokale wijzigingen in programma's

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.

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.

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:

     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);
     }

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:

     1314258944      -232267772      -231844864      1634862
     1411907592      -231844736      2159150         1420296208
     -234880989      -234879837      -234879966      -232295424
     1644167167      -3214848        1090581031      1962942495
     572518958       -803143692      1314803317

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.

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.

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.

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.

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.

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.

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.

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!”

“Maar ik mag helemaal geen zout van de dokter! Wat kan ik hieraan doen? Wil jij het er voor me uit halen?”

“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”.

Software-ontwikkeling tegenwerken

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.

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.

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.

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 in je eigen bedrijf.

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.

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.

Het maakt niet uit hoe het delen wordt neperkt

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 lukt om gebruik te voorkomen, dan berokkent het schade.

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.

Software zou vrij moeten zijn

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.

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.

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.

Waarom mensen software zullen maken

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.

Programmeren is leuk

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.

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.

Deze verandering vond plaats in het programmeervak gedurende de jaren tachtig. In de zevertiger jaren verschenen er artikelen over “computer verslaving”: gebruikers waren de hele tijd “online” en ontwikkelden honderd-euro-per-week gewoontes. Het was algemeen bekend dat mensen zoveel van programmeren hielden dat het hun het huwelijk kostte. Tegenwoordig programmeert er niemand meer zonder daar zwaar voor te worden betaald. Mensen zijn vergeten wat ze toen wisten.

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.

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.

Het financieren van Vrije Software

Instituten die programmeurs betalen hoeven niet persé softwarebedrijven te zijn. Vele andere bestaande organisaties kunnen dit ook doen.

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.

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.

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.

Programmeurs die vrije software maken kunnen hun kostje bij elkaar scharrelen door gerelateerde services te verkopen bij hun software. Ikzelf ben ingehuurd om de GNU C-compiler geschikt te maken voor nieuwe hardware en voor het uitbreiden van de gebruikersinterface van GNU Emacs (Ik geef deze verbeteringen weer vrij wanneer ze ontwikkeld zijn). Ik geef ook betaald les.

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.

Nieuwe instellingen zoals de Free Software Foundation (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.

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.

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).

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.

Wat zijn gebruikers ontwikkelaars verschuldigd?

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.

Dit gaat echter niet op voor ontwikkelaars van private software. Hinderlijk gedrag dient bestraft te worden, niet beloond.

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.

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.

Wat is softwareproductiviteit?

Wanneer software vrij zou zijn zouden er nog steeds programmeurs zijn maar wellicht minder dan nu. Zou dit slecht voor de maatschappij zijn?

Niet persé. Tegenwoordig hebben de ontwikkelde landen minder boeren dan in 1900 maar we zien dit niet als zijnde slecht voor de maatschappij want de weinige boeren die we hebben leveren meer voedsel richting consument dan de vele die we hadden. We noemen dit toegenomen productiviteit. We zouden ook toe kunnen met minder programmeurs van vrije software door de toegenomen productiviteit op alle niveaus:

• Wijder verspreid gebruik van programma's die worden ontwikkeld.
• De mogelijkheid bestaande programma's aan te passen aan specifieke behoeftes in plaats van telkens opnieuw beginnen.
• Betere opleiding van programmeurs.
• Het wegnemen van dubbele ontwikkel-inspanningen.

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?

“Productiviteit in software” kan op twee dingen betrekking hebben: de algemene productiviteit van alle software-ontwikkelingen of de productiviteit van individuele projecten. De maatschappij wil graag de algemene productiviteit verhogen en de simpelste manier om dit te bereiken is door het afschaffen van kunstmatige belemmeringen in samenwerking. Maar onderzoekers die het probleem van “productiviteit in software” onderzoeken spitsen het onderzoek toe op de tweede, meer beperkte, interpretatie die moeilijke technologische oplossingen behoeven.

Is concurrentie onvermijdelijk?

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 vechten.

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, zolang men hier maar sportief mee om gaat.

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.

Concurrentie wordt vechten wanneer rivalen elkaar gaan proberen te verhinderen iets te bereiken in plaats van te proberen zelf wat te bereiken—wanneer “dat de beste mag winnen” verandert in “laat mij winnen, ongeacht of ik de beste ben”. Private software is schadelijk, niet omdat het een manier van concurreren is maar een vorm van vechten tussen mensen in de maatschappij.

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.

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.

“Waarom verkas je niet naar Rusland?”

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?

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.

Het Amerikaanse systeem van auteursrecht oefent totale controle uit op het distribueren van een programma en bewaakt het kopiëren met automatische kopieerbeveiligingen om illegaal kopiëren tegen te gaan.

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.

Wanneer we dus inzichten beoordelen op hun gelijkenis met het Russische communisme dan zijn het de eigenaren van software die de communisten zijn.

De juiste uitgangspunten

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.

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.

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.

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.

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.

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 [auteursrecht]monopolie ligt in de algemene voordelen die de maatschappij zal genieten van het werk van auteurs”.

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.

Conclusie

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.

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.

Wanneer we niet in een jungle willen leven moeten we ons gedrag veranderen. We moeten het signaal gaan afgeven dat een goed burger er een is die met anderen samenwerkt wanneer dat zo te pas komt, niet een die succes heeft met dingen afnemen van anderen. Ik hoop dat de vrijesoftwaregemeenschap hiertoe zal bijdragen: op tenminste één gebied zullen we de jungle vervangen door een efficiënter systeem dat gebaseerd zal zijn op vrijwillige samenwerking.

Voetnoten

1. 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).
2. 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.
3. 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 volledig beperken, zoals je zou willen met een programma dat beschouwd wordt als schadelijk.

---