M.M. Groenenboom

Sinds het begin van de jaren negentig heeft open source software aan bekendheid en populariteit gewonnen. Eerst binnen de groep mensen die software ontwikkelt, later op de servermarkt, en de laatste tijd zelfs op de eindgebruikersmarkt. Met name de opkomst van het besturingssysteem Linux heeft open source software wereldwijd grote naamsbekendheid gegeven.

Er zijn allerlei organisaties opgericht om het gebruik van open source software te stimuleren. Voorbeelden hiervan zijn de Free Software Foundation (FSF)[1] en het Open Source Initiativ (OSI).[2] Beiden zijn not-for-profit organisaties met als doelstelling het stimuleren van het gebruik van software waar de broncode aan de gebruiker ter beschikking wordt gesteld en waar de gebruiker de mogelijkheden heeft de broncode aan te passen.[3] Uit het feit dat de FSF is opgericht in 1985, en dus al 18 jaar actief is, blijkt dat open source sofware niet zomaar een hype van de laatste jaren is, maar dat er nogal wat tijd verstreken is voordat open source software doorbrak bij het grote publiek.[4]

Niet alleen in de private sector, ook in de publieke sector is de belangstelling voor open source software sterk toegenomen. Eind 2002 heeft het kamerlid Vendrik een motie voorgesteld waarin hij de regering verzocht ervoor te zorgen dat in 2006 alle door de publieke sector gebruikte software aan open standaarden voldoet.[5] Tevens verzocht hij de regering “actief de verspreiding en ontwikkeling van open broncode[6] in de publieke sector te stimuleren en hiervoor concrete en ambitieuze doelstellingen te formuleren”. Naar aanleiding van dit verzoek zijn de ministeries van Binnenlandse Zaken en Economische Zaken het programma “open standaarden en open source software voor de overheid” gestart.[7] Blijkbaar zijn er vele partijen die, om economische danwel pragmatische overwegingen, interesse hebben in open source software.[8]

Centraal in dit artikel staan de auteursrechtelijke aspecten van open source software. Allereerst zal ik aangeven wat open source software nu precies is. Vervolgens zal ik enkele belangrijke aspecten uit de Auteurswet behandelen. In het laatste deel van het artikel wordt de relatie gelegd tussen de Auteurswet en open source software en worden er enkele aandachtspunten bij open source licenties voor afnemers genoemd.

1. Wat is open source software

Wat is nu open source software? De belangrijkste verschillen, die tot uitdrukking komen in de bij een programma behorende licentie, tussen open source software en “gesloten” software zijn:

1. Bij open source software wordt de broncode vrijelijk ter beschikking gesteld.
2. Bij open source software mag de gebruiker de broncode aanpassen aan zijn eigen wensen, en deze wijzingen (al dan niet tezamen met het originele programma) verder verspreiden.

Het eerste verschil heeft betrekking op de ter beschikking stelling van de source code. Bij “gesloten” software verkrijgt de gebruiker alleen de objectcode (ofwel de binaries in de vorm van nullen en enen). Dit zijn de instructies die de computer nodig heeft om het programma te kunnen draaien. De broncode (ofwel source code) is het programma in een hogere, voor mensen begrijpelijke programmeertaal (zoals C++, Pascal en Java).

Het tweede verschil betreft de toekenning van de bevoegdheden door de licentie behorende bij een programma. Bij open source software krijgt de gebruiker de bevoegdheid om de source code van een programma verder te verspreiden, om de source code van een programma te wijzigingen om hem zo aan te kunnen passen aan zijn eigen wensen en om de wijzigingen (al dan niet tezamen met het programma) te verspreiden. Bij gesloten software krijgt de gebruiker deze bevoegdheden niet vanzelfsprekend.

Het proces om software te wijzigen verloop als volgt. De enige manier om software te wijzigen geschiedt door het wijzigen van de onderliggende code, de source code. Vervolgens wordt een compiler gebruikt om het programma te compileren.[9] Het resultaat zijn nieuwe binaries en een aangepast programma. Een voorbeeld van een source code is:

Int main (void)
{
printf (“hello world\n)\”);
return 0 ;
}

Na het compileren wordt een Hello.exe file verkregen, bijvoorbeeld:

76 47 80 3E 7D 00 03 72 40 77 07 80 3E 7E 00 1E
v G .> } . . r @ w . . > ~ . .

Op grond van de Auteurswet (verder Aw) heeft de gebruiker van een programma onder bepaalde voorwaarden het recht om een programma te decompileren.[10] Met decompileren kan je in principe de source code van het programma verkrijgen. Echter, het is bijna onmogelijk om met decompileren de originele source code te verkrijgen. Hiernaast ontbreken bij decompilatie meestal de aanvullende verklaringen die een programmeur in de source code heeft opgenomen en die zeer waardevol kunnen zijn in het geval iemand een programma aan wil passen.

2. Voorbeelden van Open Source Software

Open source programma's komen in verschillende omgevingen rond de computer voor. Voorbeelden van veel gebruikte open source software zijn de Apache Web Server,[11] de mailserver Sendmail,[12] de Domain Name Server BIND (Berkeley Internet Name Daemon)[13] en het besturingssysteem Linux.[14]

Dat het hier niet gaat om zomaar een aantal programmaatjes blijkt uit vele onderzoeken.[15] Meer dan de helft (62%) van de webservers in de publieke en private sector draaide in 2001 op Apache en een groot aantal van alle e-mails komt in aanraking met Sendmail. Ook het programma Linux mag zich in toenemende populariteit verheugen, volgens onderzoek draait 55% van de computers in de servermarkt op Linux.

In de praktijk komt nog een aantal vormen van software voor waar de naam impliceert dat het om open source software zou kunnen gaan, maar waar dit niet het geval is. Voorbeelden hiervan zijn “freeware” en “shareware”. Bij deze categorieën software mag de software (de binaries) wel vrij verspreid worden, maar krijgt de gebruiker niet de beschikking over de source code en er is dus geen sprake van open source software.

Twee voorbeelden van programma's die op open source software lijken, maar het niet zijn, betreffen het “Shared Source programma” en het “Government Security Program” van Microsoft.

Bij het Shared Source programma deelt Microsoft de source code met gebruikers. Het programma bevat een groot scala aan software licenties die in de toegekende bevoegdheden aan de licentienemer niet allemaal even ver gaan.[16]

Hiernaast heeft Microsoft, speciaal voor overheden, het “Government Security Program” op 14 januari 2003 in het leven geroepen. Nationale overheden worden door dit programma in staat gesteld de source code en andere technische informatie van Windows 2000, XP, Server 2003 en CE in te zien. De naam van het programma geeft al aan dat dit inzien van de source code geschiedt in het kader van 'beveiliging'; overheden kunnen dan zelf de kwaliteit van de beveiligingsvoorzieningen van het Windowsplatform beoordelen. Tot nog toe hebben China, Rusland, het Verenigd Koninkrijk en de NATO gebruik gemaakt van deze mogelijkheid.[17]

3. De Nederlandse Auteurswet

Degene die een computerprogramma maakt, wordt beschermd door het auteursrecht. Artikel 1 Aw definieert het auteursrecht als:

“het uitsluitend recht van de maker van een werk van letterkunde, wetenschap, of kunst, of van diens rechtverkrijgenden om dit openbaar te maken en te verveelvoudigen, behoudens de beperkingen bij de wet gesteld”

De maker is degene die de geestelijk vader of schepper van het werk is.[18] De maker en de rechthebbende hoeven niet altijd in dezelfde persoon verenigd te zijn. De Aw kent een aantal uitzonderingen waar een ander dan de geestelijk vader of schepper van het werk als auteursrechthebbende wordt aangemerkt. Eén van deze uitzonderingen betreft werken gemaakt onder leiding van de werkgever. In paragraaf 4 wordt nader op deze uitzondering in relatie tot open source software ingegaan.

Om de bescherming van het auteursrecht te genieten, moet er sprake zijn van een “werk van letterkunde, wetenschap of kunst” in de zin van de Aw. Voor auteursrechtelijke bescherming is vereist dat het werk 'tot uitdrukking' is gebracht (zintuiglijk waarneembaar) en dat het werk 'oorspronkelijk' is (er moet sprake zijn van een eigen en persoonlijk karakter van het werk en het werk moet het stempel van de maker dragen[19] ).

Op grond van de Aw verkrijgt de auteursrechthebbende drie rechten:

1. het recht tot verveelvoudiging van het werk
2. het recht tot openbaarmaking van het werk
3. persoonlijkheidsrechten

De rechten tot het verveelvoudigen en het openbaar maken van een programma komen exclusief aan de auteursrechthebbende toe. Het gevolg hiervan is, dat als een ander één van deze handelingen wil verrichten, hij toestemming van de auteursrechthebbende nodig heeft.

Het eerste begrip, “verveelvoudigen” kan zowel betrekking hebben op het vervaardigen van (stoffelijke) exemplaren waarin het werk is vastgelegd (bijvoorbeeld kopiëren), als op het vertalen of bewerken van een werk.
Het tweede begrip, “openbaarmaking” kan onderverdeeld worden in stoffelijke en onstoffelijke openbaarmaking. Stoffelijke openbaarmaking is enkel mogelijk in het geval een werk in een waarneembare vorm is vastgelegd en kan bestaan uit verspreiden, verbreiden, verhuren of uitlenen. Een onstoffelijke openbaarmaking heeft betrekking op een op- of uitvoering van een werk.

De “persoonlijkheidsrechten” worden genoemd in artikel 25 Aw. De achtergrond van deze rechten ligt in de bescherming van de ideële band tussen de maker en het werk. De maker kan deze rechten niet overdragen, in enkele gevallen kan hij er wel afstand van doen. Voorbeelden van het persoonlijkheidsrecht zijn het recht op naamsvermelding en het recht om zich tegen wijziging in het werk te verzetten.

Aan de bij de wet gestelde beperkingen, die genoemd worden in de artikelen 15 tot en met 25a van de Aw, wordt in dit artikel geen aandacht besteed.[20]

4. Open source software en auteursrecht

In deze paragraaf wordt de relatie tussen open source software en het auteursrecht onderzocht. Achtereenvolgens komen aan bod de “maker”, het “werk” en tenslotte de rechten die de maker van een werk verkrijgt (verveelvoudigen, openbaarmaken en zijn persoonlijkheidsrecht).

a. Maker

Door de onconventionele bouwwijze van open source software kunnen zich enkele interessante vragen op het gebied van het makerschap voordoen. De kern van het bouwen van open source software is dat de groep makers in principe onbegrensd is. Het staat iedereen die iets bij wil dragen aan een project vrij dit ook daadwerkelijk te doen.[21] Vaak is er wel een groep van personen die beslist welke wijzigingen opgenomen worden in stabiele versies van het programma en welke wijzigingen minder relevant (of zelfs slecht) zijn.[22]

 De eerste kwestie betreft de vraag of er sprake is van een gemeenschappelijk auteursrecht van meerdere makers op één werk, of dat er sprake is van een combinatie van werken in het geval dat er meerdere mensen aan een programma bijgedragen hebben. Om deze vraag te kunnen beantwoorden heeft de rechtspraak het “scheidbaarheidscriterium” ontwikkeld:[23]

“Beslissend voor een gemeenschappelijk auteursrecht van de makers tezamen is, of het werk is ontstaan door een zodanige samenwerking van de auteurs, dat ieders afzonderlijke bijdrage daarvan niet meer te scheiden is en buiten het verband van het geheel dan ook geen voorwerp van afzonderlijke beoordeling kan zijn”

In het betreffende arrest ging het over de vraag of film en filmmuziek scheidbaar zijn. De Hoge Raad antwoordde hierop in bevestigende zin. Als de elementen scheidbaar zijn, is er sprake van een combinatie van werken. Als de elementen niet scheidbaar zijn, dan is er sprake van een gemeenschappelijk auteursrecht van de auteurs.

Bij een open source programma zal de makerschap-vraag dus afhangen van de vraag of er sprake is van een los onderdeel danwel een “onscheidbaar” geheel. In het geval dat iemand een applicatie schrijft, is het goed verdedigbaar dat deze los te zien is van het andere werk. Aan de andere kant is de applicatie soms met het oog op gebruik door een bepaald programma geschreven. Is er in dat geval dan sprake van “onscheidbaarheid”? In de praktijk is het vaak niet altijd even duidelijk of er sprake is van “scheidbaarheid” van de delen van een programma.

De vraag of er sprake is van meerdere makers en één werk of meerdere makers en een combinatie van werken komt met name tot uitdrukking in de uitoefening van de rechten met betrekking tot het werk, bijvoorbeeld het verlenen van een licentie. Dit dient in beginsel door alle auteurs gezamenlijk te geschieden. In het geval van open source software zou dit nogal wat problemen op kunnen leveren omdat er vaak heel veel bijdragers zijn en het praktisch ondoenlijk is om bij verlening van iedere licentie toestemming van alle auteurs te verkrijgen.[24]

Hiernaast ontstaat bij de ontwikkeling van open source software de vraag, of er sprake kan zijn van de situatie dat het werk tot stand gebracht is naar het ontwerp van een ander zoals omschreven in artikel 6 Aw.[25] In het geval dat er ook sprake is van leiding of toezicht van deze ander, dan wordt deze als leidinggever en als maker van het werk aangemerkt. Uit rechtspraak blijkt dat de leidinggever of ontwerper als maker te beschouwen is, in die gevallen waarin deze de uitvoerder zodanig door leiding en toezicht heeft geïnspireerd dat er bij de uitvoerder geen sprake is van een eigen schepping.[26] Het is op grond van artikel 6 Aw bij een open source project dan ook maar de vraag of degene die de wijziging heeft gemaakt, ook daadwerkelijk als maker aangemerkt kan worden. Het hangt van de omstandigheden van het geval af of de wijziging van een bepaald persoon tot stand is gekomen onder leiding en toezicht van een ander.

b. Werk

De Aw geeft aan dat “computerprogramma's en het voorbereidend materiaal” als een werk worden beschouwd en dus auteursrechtelijk beschermd kunnen worden.[27]

c. Verveelvoudiging/openbaarmaking en licenties

Als iemand een softwareprogramma (ook dus als het open source is!) wil gebruiken, dan heeft hij toestemming van de auteursrechthebbende nodig omdat hij door het programma te gebruiken het programma verveelvoudigd en openbaar maakt. De auteursrechthebbende kan in dat geval besluiten een gebruiksrecht op zijn werk aan de gebruikers van zijn programma te verlenen in de vorm van een licentie. Naast de rechten die een licentienemer op grond van de verstrekte licentie verkrijgt, komen hem ook enkele rechten toe op grond van de artikelen 45h -45n Aw.[28]

Het bijzondere van licenties die betrekking hebben op open source software is dat zij veel meer rechten verlenen dan de zogenaamde closed source licenties, zoals het recht tot het wijzigen van de source code. Aan de andere kant leggen open source software licenties soms verregaande verplichtingen aan de licentienemer op die bijvoorbeeld betrekking hebben op de verdere verspreiding van het werk, zoals het “copyleft”[29] vereiste dat de GPL stelt. Het Open Source Initiativ heeft een aantal voorwaarden opgesteld waaraan open source licenties volgens hen dienen te voldoen voordat zij zich open source mogen noemen:[30]

1. vrije verspreiding van de software;
2. het programma moet de broncode bevatten en moet vrije verspreiding toestaan, zowel in broncode als in gecompileerde vorm;
3. de licentie moet aanpassingen van het originele programma en afgeleide werken toestaan, en deze moeten onder dezelfde voorwaarden kunnen worden verspreid als het originele programma;
4. de integriteit van de broncode moet gewaarborgd zijn, in de source code wordt daarom aangegeven wie wát en wanneer gewijzigd heeft;
5. geen discriminatie tegen personen of groepen;
6. geen discriminatie tegen toepassingsgebieden;
7. de rechten die bij de licentie horen moeten ook van toepassing zijn op iedereen naar wie het programma is verspreid, zonder dat een extra licentie nodig is;
8. de licentie mag niet specifiek voor 1 product gelden;
9. de licentie mag andere software niet beïnvloeden;
10. de licentie moet technologie-neutraal zijn.

Enkele licenties die veel gebruikt worden en die volgens het Open Source Initiativ aan deze voorwaarden voldoen zijn de Berkeley Software Distribution License! (BSD),[31] Mozilla Public License (MPL) en de GNU General Public License (GPL). De GPL is in 1989 opgesteld en gaat dus al een flink aantal jaren mee, BSD en MPL stammen uit 1998.

Het grootste verschil tussen de licenties heeft betrekking op de verspreiding van de wijzigingen die iemand heeft gemaakt. Er zijn drie situaties denkbaar bij de verdere verspreiding van open source software door de licentienemer:
1. verspreiding van het originele programma;
2. verspreiding van het originele programma + de wijzigingen;
3. verspreiding van de wijzigingen.
Bij de tweede en de derde categorie gaat het dus om een werk dat voortbouwt op het originele werk, dit heet een afgeleid werk.

De BSD licentie staat de gebruiker toe om een afgeleid werk te maken maar hij heeft zelf de keus onder welke licentie hij zijn afgeleide werk wil gaan verspreiden. Hij kan dus besluiten zijn software “closed source” te maken, te verspreiden onder dezelfde licentie, ofwel te verspreiden onder de GPL.

De GPL vereist dat zowel de verspreiding van het originele werk als de verspreiding van afgeleide werken onder de GPL geschiedt. Hiernaast staat de GPL niet toe dat iemand bij de verspreiding van een werk waarop de GPL van toepassing is verklaard, additionele beperkingen aan de GPL toevoegt.

Het vereiste dat het originele programma “free” blijft en dat alle afgeleide werken van het originele programma ook “free” zijn, wordt “copyleft” genoemd. De GPL is dus copyleft, BSD is “non-copyleft”.

Tussen deze twee uitersten bestaat ook nog een tussencategorie. Deze vorm komt tot uitdrukking in de Mozilla Public License. De MPL geeft aan dat zij van toepassing is op de “covered code”, hieronder wordt verstaan de originele code, wijzigingen op deze code of de combinatie van de originele code + wijzigingen. De licentie maakt binnen “covered code” een onderscheid tussen:

1. source code
2. executables (elke andere vorm dan source code)

Voor de source code van het originele werk, de wijzigingen daarop en de (combinatie van het originele werk met de wijzigingen, geldt dat deze altijd “free” dient te zijn.

Ook de MPL staat de licentienemer niet toe additionele beperkingen aan de licentie toe te voegen. Wel bestaat de bevoegdheid additionele rechten op te nemen (artikel 3.1 MPL).

Een apart onderwerp betreft de samenloop van licenties. Omdat de GPL niet toestaat dat de gebruiker additionele beperkingen aan de GPL toevoegt, heeft dit tot gevolg dat source code waarop de GPL van toepassing is, niet gecombineerd kan worden met source code waarop bijvoorbeeld de MPL van toepassing is.

Om aan de behoefte in de praktijk tegemoet te komen om code te combineren, heeft Mozilla een “relicensing project” gestart.[32] Mozilla heeft twee licenties gemaakt die van toepassing zijn op de Mozilla source code:

• MPL 1.1 / GPL 2.0/ LGPL 2.1
• MPL 1.1 / GPL 2.0

Deze licenties geven de gebruiker de bevoegdheid, om code die zij hebben verkregen (en gewijzigd) op grond van de MPL, verder te verspreiden onder de GPL of de LGPL.

d. persoonlijkheidsrechten

De persoonlijkheidsrechten die de maker van een werk heeft, worden uiteen gezet in artikel 25 lid 1 Aw. De auteur kan zich, zelfs na overdracht, verzetten tegen:

a. openbaarmaking van het werk zonder vermelding van zijn naam of andere aanduiding als maker, tenzij het verzet onredelijk is;
b. openbaarmaking van het werk onder een andere naam en wijzigingen in de benaming van het werk (titel) of in de auteursaanduiding;
c. wijziging in het werk zelf;
d. misvorming, verminking of andere aantasting van het werk welke nadeel zou kunnen toebrengen aan de eer of de naam van de maker of aan zijn waarde in deze hoedanigheid.

De Auteurswet geeft de auteursrechthebbende de bevoegdheid om van sommige van deze rechten bij overeenkomst afstand te doen, dit kan bijvoorbeeld geschieden bij de verlening van de licentie. De auteur kan afstand doen van de rechten genoemd in sub a, b en c. Er is echter geen afstand mogelijk van het recht zich te verzetten tegen misvorming, verminking of andere aantasting van het werk (sub d). Wat de auteursrechthebbende ook doet (dus ook als hij zijn auteursrecht overdraagt), dit recht behoud hij te allen tijde.

Als een auteursrechthebbende een open source licentie van toepassing verklaart op zijn werk, en dus uitdrukkelijk wijziging van het werk toestaat, dan impliceert dit mijns inziens dat hij afstand heeft gedaan van zijn recht om zich tegen wijzigingen in het werk te verzetten.

Op grond van zijn recht zich tegen verminking die nadeel toebrengt aan de eer of goede naam van de maker te verzetten (sub d), zou een auteur zijn door de licentie verschafte rechten echter weer teniet kunnen doen.

Wat de auteur met de ene hand heeft gegeven (het recht tot wijziging van de source code), kan hij met de andere hand aldus terug nemen in het geval dat hij van mening is dat de wijziging leidt tot aantasting van het werk welke nadeel toebrengt aan zijn eer of goede naam. Helaas is er nog geen jurisprudentie in Nederland over dit onderwerp. Als een gebruiker iets wijzigt in een open source programma, dan zou de auteursrechthebbende op het originele werk op grond van zijn persoonlijkheidsrecht (artikel 25 sub d Aw) hiertegen kunnen ageren.

5. Aandachtspunten bij open source licenties

Een eerste aandachtspunt voor een gebruiker van open source software betreft het feit dat open source software licenties de gebruiker de beschikking geeft over de source code en de mogelijkheid deze te wijzigen en te verspreiden. Dit alles wordt echter niet zonder meer toegestaan. Er zijn strikte eisen waaraan iemand moet voldoen om verder te mogen verspreiden. Verspreiding mag soms alleen onder dezelfde licentie als het originele programma en de wijzigingen moeten in de documentatie behorende bij de software worden bijgehouden.

Een tweede belangrijk aandachtspunt voor gebruikers betreft het feit dat licenties behorende bij open source software vaak geen onderhoudsbepalingen bevat. Tevens sluit de licentie vaak iedere aansprakelijkheid van de leverancier uit. Een gebruiker van open source software dient hierop bedacht te zijn en aanvullende maatregelen te treffen. In de praktijk zijn er vele bedrijven die in het gat van het onderhoud in de markt springen. Zij verstrekken handleidingen bij de software en kunnen onderhoud leveren.[33]

In de praktijk bestaat nog grote onduidelijkheid of open source sofware nu goedkoper is dan closed source software. Het voordeel van het kunnen beschikken over de source code is dat men dan de mogelijkheid heeft het programma aan te passen aan de eigen wensen, en zich kan vergewissen van de veiligheid van het programma (men weet precies wat er in de source code staat). Dit zal echter wel bepaalde kosten met zich meebrengen. Deze en andere te verwachten kosten met betrekking tot implementatie, onderhoud, garantie en aansprakelijkheid zullen afgewogen dienen te worden tegen de lagere licentiekosten.

6. Conclusie

Auteursrecht en open source software zijn onlosmakelijk met elkaar verbonden. Op computerprogrammatuur rust volgens de Auteurswet immers auteursrecht. In het geval dat iemand een computerprogramma wil gebruiken, maakt hij inbreuk op de exclusieve rechten van de auteursrechthebbende tot het verveelvoudigen en openbaarmaken van een werk.

Om te zorgen dat een gebruiker een computerprogramma rechtmatig kan gebruiken, dient hij een licentie van de auteursrechthebbende te verkrijgen. Van belang is dat hij van de juiste persoon zijn licentie verkrijgt in het geval dat er bijvoorbeeld sprake is van meerdere makers van één werk of van meerdere makers en een combinatie van werken, en in het geval er sprake is van leiding geven zoals omschreven in artikel 6 Aw.

Een belangrijk aandachtspunt ten slotte bij open source software licenties betreft de omstandigheid dat de licentie vaak iedere aansprakelijkheid van de leverancier uitsluit en dat er geen onderhoud geleverd wordt. Een licentienemer dient op deze gebieden aanvullende maatregelen te treffen.

Noten

[1] http://www.fst.org
[2] http://www.opensource.org
[3] De FSF gebruikt de term "free software'; OSI gebruikt de term "open source software" voor de software. De FSF vereist dat een programma aan het "copyleft" vereiste dient te voldoen voordat sprake is van free software.
[4] OSI is in 1998 opgericht. Daar waar de FSF zeer pragmatisch is ingesteld, is OSI minder pragmatisch en houdt zij meer rekening met de marketingaspecten van open source software.
[5] Kamerstukken 112002103, 28600 XIII, nr. 30.
[6] Bedoeld wordt “open source software”.
[7] Kamerstukken 112002/03, nr. 825.
[8] Onder economische motieven kunnen eventuele kostenbesparingen en de onafhankelijkheid van bepaalde leveranciers begrepen worden. Onder pragmatische motieven kan begrepen worden het idee van de FSF dat alle software "free" dient te zijn zodat iedereen van de software kan profiteren. In het vervolg van dit artikel zullen deze onderwerpen slechts zijdelings aan bod komen.
[9] Elke programmeertaal heeft zijn eigen compiler; voor C is er de C compiler, voor Java een Java compiler etc.
[10] Artikel 45m Aw staat decompileren toe indien de handelingen onmisbaar zijn om de informatie te verkrijgen die nodig is om de interoperabiliteit van een onafhankelijk vervaardigd programma met andere computerprogramma's tot stand te brengen.
[11] http://www.apache.org
[12] http://www.sendmail.org
[13] http://www.bind.org
[14] http://www.linux.org
[15] Vergelijk het door IDA in juni 2001 verrichte onderzoek in opdracht van de Europese Commissie "Study into the use of Open Source Software in the Public Sector, part 2, Use of Open Source in Europe'; het onderzoek van Netcraft op http://www.netcraft.com/survey/ en ten slotte "Using Open Source Software in the South African Government, a proposed strategy compiled by the Government Information Technology Officers' Council (te vinden op http://www.oss.gov.za/).
[16] De shared source license voor Windows CE.NET bijvoorbeeld staat de gebruiker toe afgeleide werken te maken en te verspreiden indien sprake is van niet-commercieel gebruik. Het OEM (Original Equipment Manufacturer) source licensing program staat de gebruiker echter niet toe de source code te wijzigen.
[17] http://www.microsoft.com
[18] Zie de artikelen 3- 9 Aw.
[19] Hoge Raad 4 januari 1991, NJ 1991, 608 (van Dale/Romme).
[20] De artikelen 15- 25a Aw hebben o.a. betrekking op citeren, overnemen voor onderwijsdoeleinden en de verveelvoudiging voor eigen gebruik.
[21] Zie ook de artikelen "The cathedral and the bazaar" en "Homesteading on the noosphere" van E. Raymond op http://www.catb.org/-esr.
[22] Zo bestaan er twee versies van de "kernel" van Linux; een 'productie' en een 'ontwikkel' versie, zie http://www.linuxhq.com/kernel/index.html Bij Mozilla is er sprake van coördinatie van het project door een groepje mensen dat de "Staff" genoemd wordt, zie http://www.mozilla.org.
[23] Hoge Raad 25 maart 1949, NJ 1950, 643 (La belle et la bête).
[24] Uit artikel 26 Aw blijkt dat de handhaving van het recht door ieder der makers kan geschieden, tenzij zij anders overeenkomen. De exploitatie dient echter gezamenlijk plaats te vinden, voor deze situatie heeft de wet geen uitzondering opgenomen. Vgi. Spoor & Verkade, Auteursrecht, tweede druk, Deventer: Kluwer 1993, nrs 24 en 268.
[25] Artikel 6 Aw luidt: "Indien een werk is tot stand gebracht naar het ontwerp van een ander en onder diens leiding of toezicht, dan wordt deze als de maker van dat werk aangemerkt'.
[26] Hoge Raad 28 juni 1940, NJ 1941, 110 (Fire over England).
[27] Artikel 10 lid 1 sub 12 Aw.
[28] De artikelen zien bijvoorbeeld op de noodzakelijke verveelvoudiging van een werk voor het met dat werk beoogde gebruik, het maken van een reservekopie, het bestuderen van de werking van het werk teneinde de daaraan ten grondslag liggende ideeën te achterhalen, en het vertalen van de codevorm om de informatie te verkrijgen teneinde interoperabiliteit van dat programma met andere programma's tot stand te brengen. Voor de inhoud van de betreffende artikelen verwijs ik naar de Auteurswet.
[29] "Copyleft" betekent dat het originele werk en alle afgeleiden daarvan altijd "free" dienen te blijven. Vgl. http://www.fsf.org/copyleftlcopyleft.html.
[30] versie 1.9 Open source detinition is te vinden op http://www.opensource.org.
[31] De BSD licentie is vergelijkbaar met de MIT licentie. De MIT licentie is te vinden op http://www. opensource. org.
[32] Zie http://www.mozilla.org/MPUlicense-policy.html.
[33] Voorbeelden van dit soort bedrijven zijn Red Hat (http://www.redhat.com) en Caldera (http://www.caldera.com).

Geplaatst 28.06.2005