Open Source Software: Een verkenning naar de juridische aspecten van open source software

Open Source Software: Een verkenning naar de juridische aspecten van open source software

Open Source Software: Een verkenning naar de juridische aspecten van open source software

Redactie Elisabeth Thole, Regine Scholten en Wouter Seinen

Nederlandse Vereniging voor Informatietechnologie en Recht (NVvIR)

ISBN 90 5901 768 4 NUR 820 © 2005 Juliëtte van Balen, Bianca Bauer, Martine Boonk, Jan van den Bosch, F.J. van Eeckhoutte, Ronald Emons, Lucie Guibault, Arno van Hekesen, Nico Hollebeek, Walter van Holst, Huub de Jong, Kamiel Koelman, Arend Lagemaat, Edward de Lange, Anette Ligtenstein, Julius Röschlau, Jack van de Sande, Jean-Paul Sars, Regine Scholten, Merijn Seelt, Wouter Seinen, Willem Sinninghe Damsté, Vincent Soek, Bartosz Sujecki, Peter Terporten, Elisabeth Thole, Eric Tjong Tjin Tai, Erik Valgaeren, Irene Verheijen, Eliane de Vilder, Elles Vink en Eva Visser. Alle rechten voorbehouden. Niets uit deze uitgave mag worden verveelvoudigd, opgeslagen in een geautomatiseerd gegevensbestand, of openbaar gemaakt, in enige vorm of op enige wijze hetzij elektronisch, mechanisch, door fotokopieën, opnamen, of op enige andere manier, zonder voorafgaande schriftelijke toestemming van de uitgever. Voorzover het maken van kopieën uit deze uitgave is toegestaan op grond van artikel 16B Auteurswet 1912 jo het Besluit van 20 juni 1974, Stb. 351, zoals gewijzigd bij Besluit van 23 augustus 1985, Stb. 471 en artikel 17 Auteurswet 1912, dient men de daarvoor wettelijk verschuldigde vergoedingen te voldoen aan de Stichting Reprorecht (Postbus 3060, 2130 KB Hoofddorp). Voor het overnemen van gedeelte(n) uit deze uitgave in bloemlezingen, readers en andere compilatiewerken (artikel 16 Auteurswet 1912) dient men zich tot de uitgever te wenden. Hoewel bij deze uitgave de uiterste zorg is nagestreefd, kan voor de aanwezigheid van eventuele (druk)fouten en onvolledigheden niet worden ingestaan en aanvaarden auteurs, redacteuren en uitgever deswege geen aansprakelijkheid.

Inhoud

Voorwoord

11

Kort overzicht van het preadvies

13

1

Open source software Regine Scholten en Nico Hollebeek

15

1.1 1.2

Wat is open source software? Andere termen: freeware, trial software, shareware en open standaarden Historie open source software Open source definition OSS-licentievoorwaarden OSS-communities Toepassingen en praktijkvoorbeelden Voor- en nadelen van OSS Afsluitende opmerkingen

15

1.3 1.4 1.5 1.6 1.7 1.8 1.9

16 17 18 20 21 22 23 26

2

Overheid en Open Source Software Jan van den Bosch, Ronald Emons, Willem Sinninghe Damsté, Elles Vink en Eva Visser

27

2.1 2.2 2.3 2.3.1 2.3.2 2.4 2.4.1 2.4.2 2.5

Inleiding Overheid als stimulator en promotor van OSS De overheid als gebruiker van OSS De praktijk Juridische aspecten De overheid als verspreider van OSS De praktijk Juridische aspecten Vooruitblik/Conclusie

27 28 30 30 31 35 35 36 40

5

Open Source Software

2.5.1 2.5.2 2.5.3

Overheid als stimulator Overheid als gebruiker Overheid als verspreider

40 41 41

3

Auteursrecht en open source software Juliette van Balen, Bianca Bauer, Walter van Holst, Kamiel Koelman, Anette Ligtenstein, Regine Scholten en Merijn Seelt

43

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8

Inleiding Werk Makerschap Exploitatierechten Beperkingen; de wettelijke licenties Persoonlijkheidsrechten Duur van auteursrechtelijke bescherming bij OSS Handhaving

43 44 44 47 49 51 53 55

4

Octrooirecht en open source software H. de Jong, J. Röschlau, J. van de Sande, P. Terporten en E. Valgaeren.

59

4.1 4.2 4.3 4.4 4.5

Octrooi op software Octrooirecht versus OSS Het octrooirecht ter ondersteuning van OSS ‘Octrooiparagrafen’ in OSS-licenties Tot slot

59 61 66 70 72

5

Databankenrecht en open source databanken (OSD’s) F. van Eeckhoutte, L. Guibault en P. Terporten

73

5.1 5.2

Inleiding De databank in de zin van de Auteurswet 1912 en van de Databankenwet76 De rechthebbende op het databankenrecht

73

5.3

6

81

Inhoud

5.4 5.5 5.6

De exclusieve rechten van de rechthebbende; niet databankenrechtelijke rechten en plichten van de producent Het rechtmatige gebruik; licenties Conclusie

83 86 90

6

Licentievormen van open source software Arno van Hekesen, Nico Hollebeek, en Eric Tjong Tjin Tai

91

6.1 6.1.1 6.1.2 6.1.3 6.2 6.3

Beschrijving belangrijkste soorten OSS-licenties Copyleft licenties Non-copyleft licenties Beperkt copyleft licenties Onderlinge verenigbaarheid van OSS-licenties Het begrip ‘afgeleid werk’ en de reikwijdte van de copyleftvoorwaarde in de GPL100 Het begrip ‘afgeleid werk’ Afgeleid werk en ‘linken’ Lesser GPL en andere uitzonderingen op de GPL De juridische werking van de verervende copyleft-voorwaarde Besluit

91 92 94 96 99

6.3.1 6.3.2 6.3.3 6.3.4 6.4

101 104 107 109 110

7

Een vermogensrechtelijke verkenning van OSS-licentiëring Martine Boonk, Arno van Hekesen, Walter van Holst, Wouter Seinen, Elisabeth Thole, Eric Tjong Tjin Tai en Eva Visser

113

7.1 7.2 7.3 7.4 7.5 7.6 7.7

De feitelijke terbeschikkingstelling van OSS Aanschaf en licentiëring van OSS Kwalificatie van de licentiëring van OSS naar civiel recht Aanpassingswet richtlijn elektronische handel OSS-licentieovereenkomsten en de Wet algemene voorwaarden Wie zijn partij bij de OSS-licentieovereenkomst? Verspreiding OSS zonder geldige licentie

113 116 118 123 125 128 130

7


8

Aansprakelijkheid en open source software Arend Lagemaat en Eliane de Vilder

133

8.1 8.2 8.3 8.3.1 8.3.2 8.4 8.4.1 8.4.2 8.5

Inleiding Posities De aansprakelijkheid van Power De aansprakelijkheid van Power jegens Kant & Klaar De aansprakelijkheid van Power jegens Jansen De aansprakelijkheid van Kant & Klaar Contractuele aansprakelijkheid van Kant & Klaar jegens Jansen Productenaansprakelijkheid Conclusie

133 135 135 135 139 142 142 144 145

9

Levering van open source software onder de BiZamodelcontracten of de FENIT-voorwaarden Walter van Holst, Arend Lagemaat en Edward de Lange

147

9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8

Inleiding Intellectuele eigendomsrechten Omvang van het gebruiksrecht De aansprakelijkheid van de leverancier De door de leverancier verstrekte garanties Vrijwaringen Rechts- en forumkeuze Conclusie en aanbeveling voor de praktijk

148 148 150 152 155 156 158 158

10

OSS vanuit internationaal privaatrechtelijk perspectief Jean-Paul Sars, Bartosz Sujecki en Irene Verheijen

161

10.1 10.2 10.3 10.4 10.5

Inleiding Toepasselijk recht Bevoegde rechter Tenuitvoerlegging van rechterlijke uitspraak Conclusie

161 164 172 177 181

8

Inhoud

11

Geschillen over Open Source Software Walter van Holst, Vincent Soek, Bartosz Sujecki en Eva Visser

183

11.1 11.1.1 11.1.2 11.1.3 11.1.4 11.2 11.2.1 11.2.2 11.2.3 11.2.4 11.3 11.3.1 11.3.2 11.3.3 11.3.4 11.3.5 11.3.6 11.3.7 11.3.8 11.3.9 11.3.10 11.4

OSS-schikkingen Apache vs. JBoss Netfilter-schikkingen TOMTOM Go Drew Technologies vs. Society of Automotive Engineers OSS-rechtszaken Progress vs. MySQL Planetary Motion Inc. vs. Techsplosion Inc. Netfilter (Welte) vs. Sitecom Computer Associates International vs. Quest Software Inc. De SCO-zaken Geschiedenis van Unix Geschiedenis van Linux Caldera, SCO en de SCO Group SCO Group vs. IBM SCO Group vs. Novell SCO vs. Univention GmbH Red Hat vs. SCO Group SCO Group vs. Autozone SCO Group vs. DaimlerChrysler De kernvraag en analyse Afsluitende opmerkingen

183 183 184 184 185 186 186 187 187 189 191 191 192 192 192 193 193 194 194 194 195 196

9

Voorwoord

Wat ooit begonnen is als ideologie ter verbetering van de wereld, is inmiddels uitgegroeid tot een ware hype: Open Source Software (OSS). Met name dankzij de ontwikkeling van het internet en de internetgemeenschap is dit fenomeen sterk opgebloeid, en nu is het ook onder de aandacht van het grote publiek gekomen. Iedereen lijkt er dan ook van doordrongen: OSS is niet meer weg te denken uit onze samenleving. Zowel de overheid als het bedrijfsleven kijkt nu serieus naar deze nieuwe wijze van ontwikkeling en distributie van software. Het is niets te veel gezegd vast te stellen dat OSS de IT-wereld danig op zijn kop heeft gezet. OSS is, in tegenstelling tot ‘proprietary’ closed source software, programmatuur waarbij de broncode vrijelijk ter beschikking wordt gesteld. Hierdoor kan iedereen op basis van de broncode de programmabestanden definiëren, en zo nodig aanpassen en/of uitbreiden. Dit staat haaks op de tot dan toe geldende praktijk. Gebruikelijk was dat men voor het aanpassen en onderhouden van software steeds afhankelijk bleef van de softwareleverancier, die over de broncode beschikte en deze niet snel prijsgaf. Met de komst van OSS lijkt de gebruiker zich dus plotseling los te maken van de traditionele afhankelijkheid van zijn softwareleverancier. Ongetwijfeld is het besturingssysteem Linux, met het daarbij behorende logo van het geel-zwarte pinguïntje, een van de bekendste OSS-toepassingen voor pc’s. OSS is echter ook voor diverse andere doeleinden inzetbaar, zoals internetservers of dichter bij huis: tekstverwerking en gebruik van e-mail en internet. Bekende voorbeelden zijn OpenOffice.org, een OSS-alternatief voor de tot nu gangbare kantoorpakketten voor tekstverwerking en het maken van spreadsheets of presentaties, en Mozilla.org, die verschillende open source internetbrowsers ‘in de markt zet’. Voorstanders van de open source beweging zien alleen maar voordelen: meer transparantie, onafhankelijkheid en minder kosten. Toch bestaat er nog veel onduidelijkheid over wat OSS nu precies is. Zo is nog niet voor iedereen duidelijk wat het betekent dat deze programmatuur ‘open’ is, of men gebruikersondersteuning en onderhoud kan krijgen voor OSS-toepassingen en hoe OSS kan samenwerken met andere programma’s die reeds aanwezig zijn binnen het

11


bedrijf. Menig ICT-er staat dan ook voor de moeilijke beslissing of en wanneer hij het management ervan moet overtuigen de overstap naar OSS te maken. Niet in de laatste plaats verdienen in dat verband ook de juridische aspecten van OSS de aandacht. Met zijn artikel ‘Terug naar de bron: open source en copyleft’ in Informatierecht/ AMI uit 2000 komt aan Kamiel Koelman de eer toe als eerste in Nederland te rapporteren over OSS vanuit juridisch perspectief. Vervolgens is het even stil gebleven totdat in september 2004 de OSS-Computerrechtspecial verscheen. Op uitnodiging van het bestuur van de Nederlandse Vereniging voor Informatietechnologie en Recht is eveneens in september 2004 de Studiecommissie OSS geformeerd. Voortbouwend op de Computerrecht-special analyseert de Studiecommissie in dit preadvies een aantal relevante juridische aspecten van OSS vanuit het Nederlands recht bezien. Hoewel in dit preadvies vanuit diverse perspectieven naar OSS wordt gekeken en verschillende onder de noemer ‘open source’ geschaarde initiatieven de revue passeren, pretenderen wij niet volledig te zijn. Dit preadvies had, gelijk een OSS-programma, niet tot stand kunnen komen zonder de vele auteurs, waarvoor onze dank. Achterin treft u hun cv aan. Op deze plaats willen wij tevens Prof. mr. Kees Stuurman danken, die als bestuurslid van de NVvIR zijn steun heeft geboden bij de eindspurt van dit preadvies. Elisabeth Thole/Regine Scholten/Wouter Seinen Redactie Preadvies NVvIR Studiecommissie Open Source Software

12

Kort overzicht van het preadvies

Het onderzoek start met een uitleg van wat onder OSS moet worden verstaan. Daartoe gaat het eerste hoofdstuk in op de vraag hoe de open source beweging is ontstaan en welke toepassingen in de praktijk bekend zijn. Vanwege de bijzondere relatie tussen overheid en OSS behandelt hoofdstuk 2 de aspecten die verbonden zijn aan de overheid als gebruiker en als verspreider van OSS. Eind 2002 zette de motie van GroenLinks Tweede Kamerlid Kees Vendrik OSS voor het eerst op de politieke agenda. In mei 2003 is het overheidsprogramma OSOSS (Open Standaarden en Open Source Software voor de overheid) van start gegaan. Dit programma, waarvan de looptijd tot 2008 is verlengd, beoogt overheden te informeren over en te stimuleren bij het gebruik van OSS. Hoofdstuk 3 gaat in op de paradoxale rol die het auteursrecht bij de ontwikkeling, distributie en het gebruik van OSS speelt. Terwijl dit intellectuele eigendomsrecht van oorsprong vooral bedoeld is ter bescherming van de rechthebbende, zet de open source beweging dit recht juist in om af te dwingen dat de open source voorwaarden worden nageleefd, die er op toezien dat de OSS vrijelijk kan worden gebruikt en verspreid. De discussie over octrooien en OSS wordt vooral overheerst door de gedachte dat octrooien een bedreiging zouden vormen voor het bestaan en de verdere ontwikkeling van OSS. Het belangeloos uitwisselen van de broncode om de softwareontwikkeling te bevorderen, lijkt nu eenmaal haaks te staan op het octrooiconcept dat uitgaat van monopolisering van uitvindingen. Vandaar dat er ook sterk verzet in de OS-gemeenschap is geweest tegen het inmiddels ingetrokken Europese voorstel over octrooieerbaarheid van software. Hoofdstuk 4 staat stil bij de bedreigingen, maar ook de kansen die het octrooirecht kan meebrengen voor de OSS-beweging. In hoofdstuk 5 wordt een uitstapje gemaakt naar de Open Source Databanken. Een bekend voorbeeld hiervan is Wikipedia, een digitale encyclopedie in meer dan 50 talen. Het hoofdstuk gaat in op de vraag in hoeverre zo een databank in aanmerking komt voor bescherming via het databankenrecht, het auteursrecht of als geschrift. Het document dat het raamwerk voor de OSS-licentievoorwaarden verschaft, staat bekend als de open source definition (OSD). Meer dan vijftig OSS-licentievoorwaarden zijn al gecertificeerd op basis van de OSD. De bekendste licentiemodellen zijn: de GNU General Public License (GPL), Lesser of Library GPL

13


(LGPL), Mozilla Public License (MPL) en Berkeley Software Distribution (BSD). In hoofdstuk 6 wordt aan de hand van het copyleft principe een onderscheid gemaakt tussen de belangrijkste OSS-licenties. Tevens komen de in de (internationale) literatuur veel besproken begrippen ‘afgeleid werk’ en de ‘virale’ werking van de GPL aan de orde. In hoofdstuk 7 wordt bezien hoe de OSS-licentievoorwaarden naar Nederlands recht te kwalificeren zijn. Ervan uitgaande dat sprake is van een contractuele relatie, doet zich de vraag voor hoe deze rechtsverhouding totstandkomt, en wie daarbij partij zijn. Nog een ander relevant aspect is of de OSS-licentievoorwaarden algemene voorwaarden zijn in de zin van het Burgerlijk Wetboek, en zo ja, wanneer deze rechtsgeldig van toepassing zijn verklaard. In hoofdstuk 8 wordt aan de hand van een casus de mogelijke aansprakelijkheid (en de houdbaarheid van contractuele bedingen ter beperking daarvan) van zowel de licentiegever/leverancier van OSS, als die van de OSS-dienstverlener onder de loep genomen. Hoofdstuk 9 maakt een vergelijking tussen enerzijds de Fenit-voorwaarden en Biza-modelcontracten en anderzijds de meest voorkomende OSS-licenties. De onderwerpen die worden behandeld zijn: intellectuele eigendomsrechten, omvang van het gebruiksrecht, aansprakelijkheid van de leverancier, garanties, vrijwaringen en rechts- en forumkeuze. Aangezien de verspreiding van OSS veelal in een internationale context plaatsvindt roept dit vragen op die liggen op het terrein van het internationale privaatrecht, die in hoofdstuk 10 centraal staan. Ten slotte verschaft hoofdstuk 11 een overzicht van de belangrijkste (internationale) rechtspraak over OSS.

14

1

Open source software Regine Scholten en Nico Hollebeek

Wat is open source software (OSS)? Waar ligt de oorsprong van OSS en wie hebben een belangrijke rol gespeeld in de OSS-beweging? Dit zijn een paar van de vragen die in dit hoofdstuk aan de orde komen. Zonder OSS-communities komt er geen OSS tot stand. Daarom wordt ook kort ingegaan op het functioneren van deze communities. Tot slot zal nog een aantal voor- en nadelen van het gebruik van OSS de revue passeren.

1.1

Wat is open source software?

Toen de IT-markt nog in de kinderschoenen stond, placht men software gratis met de hardware mee te leveren. Vanaf begin jaren tachtig van de vorige eeuw is daar verandering in gekomen. Met de stijging van de vraag naar software stegen ook de prijzen die voor software in rekening werden gebracht. Sindsdien is de software-industrie een volwassen branche geworden met grote economische belangen. Wereldwijd is de hoeveelheid software in producten enorm gestegen. Van de fase waarbij de software nog hardware gebonden was, zijn we overgestapt naar open systemen. Bij open systemen kan door standaardisering de software van de ene leverancier ook draaien op de hardware van een andere leverancier. De software wordt dan veelal geleverd onder strikte licentievoorwaarden. Inmiddels heeft zich een volgende fase aangediend: open source software (OSS).1 OSS is een term die regelmatig de koppen van de kranten haalt, zeker in ICTgeoriënteerde bladen als de Automatisering Gids en Computable. Vanwege de grote verbreidheid van OSS wordt in de pers er meestal vanuit gegaan dat men inmiddels bekend is met dit fenomeen. Voor een goed begrip van de onderwerpen die in dit preadvies aan de orde komen, wordt hierna toch kort op de kenmerken van OSS ingegaan.2 Software heeft twee verschillende verschijningsvormen: de broncode, ook vaak source code genoemd, en de objectcode. De broncode bevat de door de program-

1

Vgl. M. van Genuchten, Groei software kans voor Europa, Informatie oktober 2003, pp. 30-34. Omdat de vertaling ‘computerprogramma’s waarvan de broncode is vrijgegeven’ wat omslachtig klinkt, gebruiken we de meer gangbare term ‘open source software’ of kortweg OSS. 2

15


meur geschreven instructies in een bepaalde programmeertaal, terwijl de objectcode de voor de computer leesbare versie hiervan is. Er is meestal een vertaalprogramma nodig om de broncode in objectcode om te zetten.3 Om software te kunnen onderhouden, herstellen, uit te breiden, of te vernieuwen, is de beschikbaarheid van de broncode veelal onontbeerlijk. Daarom beschouwen vele softwareleveranciers de broncode als belangrijke know how die geheim moet worden gehouden. Men spreekt ook wel van ‘closed software’. In het belang van de softwareleverancier ontvangt de afnemer van closed software deze uitsluitend in de objectcode. Aan het gebruik van closed software worden in de toepasselijke licentievoorwaarden ook vaak tal van beperkingen gesteld. Deze zijn gebaseerd op de bescherming die de softwareleverancier met name ontleent aan het auteursrecht, dat hem de mogelijkheid geeft derden te verbieden of toe te staan de software te verveelvoudigen en openbaar te maken. Een belangrijk kenmerk van OSS is dat de broncode veelal juist vrij ter beschikking staat. Elementair is dat de software en bijbehorende broncode door een ieder mag worden bestudeerd, verbeterd, aangevuld en voor eigen doeleinden mag worden gebruikt. Deze uitgangspunten zijn in de OSS-licentievoorwaarden verankerd, en zijn gebaseerd op de nog te bespreken zogenaamde open source definition.

1.2

Andere termen: freeware, trial software, shareware en open standaarden

Naast OSS rouleren er tal van andere termen die soms worden verward met OSS, maar die toch ieder op hun beurt een eigen betekenis hebben.4 Het gaat om begrippen zoals feeware, trial software, shareware en open standaarden. Wanneer software gratis wordt aangeboden zonder dat de broncode wordt vrijgegeven, spreekt men van freeware. Freeware mag verder worden verspreid en het gebruik is onbeperkt. In dit verband kunnen de producten van Adobe waarmee PDF-files worden gelezen als voorbeeld worden genoemd.5 Om software op proef te verstrekken – try before you buy – wordt vaak gebruik gemaakt van trial

3

Voor sommige programma’s is die aparte vertaalslag niet nodig. Dat geldt bijvoorbeeld voor programma’s die in een scripting-taal zijn geschreven. Met behulp van een interpretatieprogramma kan de broncode van die programma’s worden gelezen en direct door de computer worden uitgevoerd. 4 Zie hierover onder meer M.M. Groenenboom, Software licenties: van closed source tot open source, Computerrecht, 2002/01, pp. 21-29. 5 Vgl. .

16

Open source software

software. Deze software is vrij verkrijgbaar, doorgaans via internet, maar beschikt niet altijd over alle functies of kent andere belemmeringen. Tegen een vergoeding kan de gebruiker soms de volledige versie verkrijgen of beschikken over ondersteuning en documentatie. Shareware is software die tijdelijk gratis op proef wordt verstrekt. Indien men het gebruik van de software na de proefperiode wenst voort te zetten, moet een licentievergoeding worden betaald. In de praktijk kan het voor de licentieverstrekker lastig zijn toe te zien op de naleving hiervan. Het belangrijkste verschil tussen deze licentievormen en OSS is dat alleen bij OSS doorgaans ook de broncode wordt vrijgegeven. Het vrijelijk en het veelal kosteloze gebruik is het meest in het oog springende punt van overeenstemming. Open standaarden zijn weer geheel iets anders en spelen vooral een rol bij de interoperabiliteit van informatiesystemen. Het OSOSS, het programma Open Standaarden en Open Source Software voor de overheid, spreekt van open standaarden wanneer aan een viertal voorwaarden is voldaan.6 De kern hiervan is dat de standaard gepubliceerd is, dat er vrijelijk of tegen vergoeding van de nominale waarde over kan worden beschikt en dat er geen beperkingen worden gesteld aan het hergebruik.

1.3

Historie open source software

Ofschoon OSS een relatief nieuw fenomeen is, kent deze wijze van distributie van software ook al een geheel eigen geschiedenis. Bij de ideevorming over OSS heeft met name de Amerikaan Richard Stallman een belangrijke rol gespeeld.7 Hij is de voortrekker geweest van de beweging die het vrijelijk gebruik van software propageert. Al in de jaren zestig was het in bepaalde kringen niet ongebruikelijk om kennis van de broncode met anderen te delen en zo de ontwikkeling van programmatuur te stimuleren. Vooral in de academische wereld kwam dit veelvuldig voor, bijvoorbeeld op het Massachusetts Institute of Technology (MIT) waar Richard Stallman tot 1984 werkzaam was als programmeur. Stallman constateerde echter dat bij de ontwikkeling van programmatuur de kennis hiervan uit commerciële overwegingen steeds vaker niet langer gedeeld werd. Medio jaren tachtig verliet Stallman het MIT en startte hij het GNU-project waarin een op Unix gebaseerd besturingssysteem werd ontwikkeld.8

6 7 8

Zie: . Zie onder andere: en . De afkorting GNU betekent: ‘GNU ’s not UNIX’.

17


In 1985 richtte Stallman de Free Software Foundation (FSF) op, waarmee een belangrijke impuls is gegeven aan de totstandkoming van de OSS-beweging. De FSF heeft tot doel te stimuleren dat gebruikers software vrijelijk mogen gebruiken, kopiëren, verspreiden, bestuderen, wijzigen en verbeteren. De FSF hanteert de ‘Free Software Definition’ om duidelijk te maken aan welke eisen volgens haar moet zijn voldaan, wil er sprake zijn van ‘free software’.9 Het gaat meer in het bijzonder om de volgende vier vrijheden voor de gebruikers: – de vrijheid om het programma voor elk gewenst doel uit te voeren; – de vrijheid om de werking van het programma te bestuderen en om het programma naar behoefte aan te passen, waarbij toegang tot de broncode is onontbeerlijk is; – de vrijheid om kopieën te verspreiden ‘om de buurman te helpen’; – de vrijheid om het programma te verbeteren, en de verbeteringen te publiceren zodat de hele gemeenschap ervan kan profiteren.

1.4

Open source definition

Om los te komen van het idealistische imago van de vrije software beweging is in 1998 door onder andere Bruce Perens en Eric Raymond in Amerika het open source Initiative (OSI) opgericht. Deze non-profit organisatie probeert de open source ontwikkeling vanuit een zakelijke benadering te bevorderen en heeft de ‘open source definition’ gepubliceerd waaraan licenties volgens haar moeten voldoen. De open source definition is evenals de vele OSS-producten geen statisch begrip. Voortdurend wordt aan de inhoud daarvan geschaafd, hetgeen wel blijkt uit het feit dat er inmiddels een versie 1.9 van de open source definition bestaat. Deze versie bevat de volgende ‘tien geboden’:10 1 Vrije herdistributie. De licentie mag geen beperkingen bevatten ten aanzien van de distributie van de software. Zo mag bijvoorbeeld geen royalty of andere vergoeding worden verlangd. 2 Verspreiding inclusief broncode De software moet de broncode bevatten en de licentie moet de distributie toestaan in zowel broncode als in gecompileerde vorm. Wordt de software zonder de

9 10

18

Zie: . Zie:< http://www.opensource.org/docs/definition.php >.


broncode verspreid, dan moet de broncode tegen vergoeding van hooguit de reproductiekosten, op een goed gedocumenteerde wijze en bij voorkeur via het internet kunnen worden gedownload. De broncode moet in zodanige vorm ter beschikking worden gesteld dat een programmeur op basis daarvan de software kan aanpassen. 3 Mogelijkheid van verspreiding van afgeleide werken onder dezelfde voorwaarden Het aanpassen van zowel het originele programma als van de daarvan afgeleide werken moet toegestaan zijn. Deze afgeleide werken moeten onder dezelfde voorwaarden verspreid kunnen worden als de originele software. 4 Handhaving van de integriteit van de originele broncode De licentie mag de verspreiding van de aangepaste broncode alleen beperken als verspreiding van ‘patch files’ met de broncode op basis van de licentie is toegestaan ten behoeve van de aanpassing van het programma gedurende de ontwikkeling daarvan. De licentie moet de distributie van software die met gebruik van de aangepaste broncode is ontwikkeld expliciet toestaan. De licentie kan bepalen dat afgeleide werken een andere naam of een ander versiernummer moeten voeren dan de originele software. 5 Geen onderscheid naar personen of groepen van personen De licentie mag voor wat het gebruik van de software betreft niet bepaalde personen of groepen van personen voortrekken dan wel uitsluiten. Een ieder moet de gelegenheid hebben de OSS te gebruiken en bij te dragen aan de ontwikkeling daarvan. 6 Geen onderscheid naar toepassingsgebied De licentie mag niemand verhinderen om de software voor een bepaald toepassingsgebied te gebruiken. De licentie zal bijvoorbeeld niet mogen verbieden dat de software door bepaalde bedrijven of voor bepaalde onderzoeksdoeleinden gebruikt wordt. 7 Doorgeven van de licentie De licentie moet worden doorgegeven. De rechten die bij de licentie horen, moeten ook gelden voor iedere volgende verkrijger van de software, zonder dat een additionele licentie vereist is.

19


8 De licentie mag niet specifiek aan één product zijn verbonden Indien de software samen met andere programmatuur wordt verspreid, maar de software op een gegeven moment weer los van die programmatuur wordt verspreid, dan zullen de opvolgende gebruikers van de software deze onder dezelfde licentievoorwaarden moeten kunnen gebruiken als die waaronder de software oorspronkelijk verspreid werd. 9 De licentie mag geen beperkingen opleggen ten aanzien van andere software De licentie mag geen beperkingen opleggen aan andere programmatuur die samen met de software wordt verspreid. De licentie mag bijvoorbeeld niet bepalen dat uitsluitend andere OSS-producten samen met de OSS mogen worden verspreid. 10 De licentie moet technologie-onafhankelijk zijn De licentie mag niet gericht zijn op een bepaalde technologie.

1.5

OSS-licentievoorwaarden

De open source definition vormt het raamwerk voor veelgebruikte OSS-licentievoorwaarden, waaronder de OSS verspreid wordt. Als er OSS-licentievoorwaarden zijn ontwikkeld, kunnen deze ter toetsing aan het OSI worden voorgelegd.11 Het OSI onderzoekt of de licentievoorwaarden aan de open source definition voldoen. Als dat zo is, mag een speciaal daarvoor in het leven geroepen ‘keurmerk’ worden gevoerd, zodat voor iedereen duidelijk is dat de OSS-licentievoorwaarden aan de open source definition voldoen. Inmiddels zijn er al meer dan vijftig OSS-licentievoorwaarden gecertificeerd door het OSI op basis van de open source definition. Bekende voorbeelden zijn: de GNU General Public License (GPL), Lesser of Library GPL (LGPL), Modzilla Public License (MPL) en de Berkeley Software Distribution (BSD). Ook hebben al veel gerenommeerde bedrijven, zoals Nokia, IBM en Intel hun eigen OSS-licentievoorwaarden op basis van voormelde criteria door het OSI laten toetsen. Ofschoon de gecertificeerde OSS-licentievoorwaarden geschreven zijn op basis van dezelfde uitgangspunten, bestaan er ook aanzienlijke verschillen daartussen, met alle juridische consequenties van dien. Maar wat de OSS-licentievoorwaar-

11

20

Zie: < http://www.opensource.org/docs/certification_mark.php >.


den in ieder geval met elkaar gemeen hebben, is dat de broncode vrijwel steeds vrijelijk ter beschikking wordt gesteld. Tevens worden er rechten ter verdere verspreiding en doorontwikkeling verleend. Elders in dit preadvies wordt uitgebreid ingegaan op de verschillende OSS-licentievoorwaarden.

1.6

OSS-communities

Een intrigerende vraag is, hoe OSS tot stand komt. Vaak zijn het honderden of zelfs duizenden programmeurs uit tal van landen, die dikwijls onbezoldigd en op vrijwillige basis deelnemen aan de ontwikkeling van OSS. Veelal vindt dat plaats binnen een zogenaamde OSS-community. OSS-communities zijn virtuele organisatievormen die het kader scheppen waarin de ontwikkeling van OSS plaatsvindt. Bekende voorbeelden zijn de Linux en de Apache community. Binnen zo een community wordt de broncode open en vrij gedeeld, hetgeen de betrokken programmeurs in staat stelt om aanpassingen in de OSS aan te brengen en deze verder te onderhouden. Het is bijzonder dat in het kader van een community complexe en werkzame programmatuur tot stand komt. Zeker indien men dit vergelijkt met hoe de klassieke closed software totstandkomt, hetgeen veelal plaatsvindt binnen een georganiseerd commercieel verband zoals een onderneming. Vanuit een bedrijfseconomisch perspectief heeft Van Wendel de Joode onderzocht hoe OSS-communities georganiseerd zijn en hoe de continuïteit wordt gewaarborgd.12 Uit zijn bevindingen volgt dat gemeenschappen van programmeurs die aan OSS werken zelforganiserend zijn. Ook blijkt dat individuen die deel uitmaken van OSS-communities zich in hun handelen voornamelijk laten leiden door hun eigen keuzes. Aan de hand van een aantal criteria kan worden getoetst waarom zelforganisatie in sommige communities mogelijk is en in andere juist niet. Volgens één van deze criteria geldt dat er grenzen moeten zijn die bepalen wat er met de OSS gedaan mag worden. Daaraan wordt in een OSS-community met name vorm gegeven door het hanteren van OSS-licenties. Deze zijn erop gericht dat de OSS niet door buitenstaanders wordt toegeëigend en gemonopoliseerd, hetgeen een streven is dat door deelnemers van een community wordt gedeeld.

12

R. van Wendel de Joode, Understanding open source communities. An organizational perspective, dissertatie Technische Universteit Delft, 2005. Van Wendel de Joode bespreekt in zijn dissertatie een zevental ‘ontwerpprincipes’ aan de hand waarvan kan worden verklaard of in een community zelforganisatie mogelijk is.

21


Een ander criterium is dat er bepaalde regels dienen te gelden voor de productie van OSS, waardoor deze ondanks de vele deelnemers niet uitmondt in chaos. Twee mechanismen zijn hierbij volgens Van Wendel de Joode bepalend: elegantie en modulariteit. Beide mechanismen vinden hun oorsprong in de beschikbaarheid van de broncode. Ontwikkelaars blijken erop te zijn gericht elegante, dat wil zeggen eenvoudige en heldere broncode te produceren. Doordat anderen eenvoudige en heldere broncode produceren, kan een ontwikkelaar gemakkelijker voortgaan met nieuwe ontwikkelingen en door zelf eveneens elegantie na te streven, stelt hij op zijn beurt anderen daartoe weer in staat. Het andere mechanisme, modulariteit, houdt in dat de software vaak is opgedeeld in modules die redelijk onafhankelijk van elkaar zijn en waaraan ontwikkelaars dan ook zelfstandig kunnen werken, zonder zich te hoeven vergewissen van de ontwikkelingen en wijzigingen in andere modules. Het ligt in de verwachting dat binnen communities met veel deelnemers conflicten zich eenvoudig kunnen voordoen. Deze zouden een bedreiging voor de continuïteit van een community kunnen vormen. Conflicten komen uiteraard voor, maar in de praktijk blijkt dat toch vaak niet tot problemen of discontinuïteit te leiden. Er wordt op een bepaalde manier met conflicten omgegaan, waardoor deze niet escaleren. Als men van mening verschilt, werkt men gewoon zijn eigen ideeën verder uit en uiteindelijk blijkt dan wel of en wie er gelijk heeft. Er ontstaan daardoor parallelle ontwikkelingslijnen. Onder meer ook de erkenning door externen van processen in de OSS-communities draagt bij aan de ontwikkeling van OSS. Al deze elementen blijken bij te dragen aan het zelforganiserend vermogen van OSS-communities waardoor een omgeving wordt gecreëerd waarin OSS tot stand kan komen.

1.7

Toepassingen en praktijkvoorbeelden

Er zijn tal van bekende en minder bekende OSS-producten. Eén van de bekendste producten is Linux, een op UNIX gebaseerd besturingssysteem, dat onder de GPL-licentie wordt uitgebracht. Linux is vernoemd naar zijn grondlegger de Fin Linus Torvald. Kenmerkend voor Linux is dat er vele verschillende versies van zijn. Deze worden distributies genoemd.13 Enkele bekende namen zijn: Mandrake, SuSe, Debian en Slackware. Iedere distributie heeft zijn eigen kenmerken

13

22

Zie: .


en functies. Sommige zijn bijvoorbeeld gericht op persoonlijk gebruik, maar er zijn ook distributies voor zakelijk gebruik.14 Een andere bekende OSS-toepassing is Apache, ’s werelds meest gebruikte webserver-software waarvoor de Apache Software Licence geldt. Python is een succesvolle programmeertaal, die onder een eigen OSI-gecertificeerde Python-licentie wordt verspreid. OpenOffice.org is een office-programma, met onder andere de mogelijkheid tot tekstverwerking en het werken met spreadsheets. Voor de broncode van OpenOffice.org gelden de Lesser of Library GPL (LGPL) voorwaarden. Ook zijn er OSS-spelletjes verkrijgbaar zoals the Battle for Wesnoth. Verschillende Nederlandse overheden zijn inmiddels al overgegaan op het gebruik van OSS-producten. De Gemeente IJsselstein maakt bijvoorbeeld gebruik van het Linux besturingssysteem en de Apache webserver. Ook het Ministerie van Economische Zaken heeft er voor gekozen haar ERP-systeem op Linux te laten draaien. De Gemeente Haarlem heeft in 2004 besloten voor de office-toepassingen over te stappen OpenOffice.org. Ook in het onderwijs bestaat volop aandacht voor OSS. Er is zelfs een speciale website waarop tal van OSSprojecten in de onderwijswereld zijn te vinden.15 Op de website van OSSOS staat voor wie geïnteresseerd is een uitgebreide lijst met andere voorbeelden van het gebruik van OSS (en open standaarden) in de overheidssfeer. In het bedrijfsleven heeft OSS eveneens zijn ingang gevonden. Bedrijven als Yahoo, Google en Amazon.com draaien bedrijfskritische applicaties op OSSplatforms en ook de New York Stock Exchange en IBM werken met OSS.

1.8

Voor- en nadelen van OSS

Over de voor- en nadelen van OSS zijn de meningen erg verdeeld.16 De voor- en tegenargumenten zijn dan ook niet van politiek, economisch en emotioneel belang ontbloot. Begrijpelijkerwijs laat Microsoft zich bijvoorbeeld veel kritischer uit over OSS dan Linux-aanhangers.17 Zonder volledig te willen zijn, wor-

14

Zie: . Zie: < http://www.ossinhetonderwijs.nl/voorbeeldprojecten >. 16 Vgl. A. Benschop, Open Source: mens durf te delen, zie http://www2.fmg.uva.nl/sociosite/websoc/ open_source.html. 17 Zie: < http://www.microsoft.com/netherlands/partner/verkoopenmarketing/csi/faq.aspx > voor een uiteenzetting van de standpunten van Microsoft ten aanzien van open source software. Zie tevens: M. van der Bel, Open source: geen doel maar middel, Computable 29 augustus 2003. 15

23


den hier enige voor- en nadelen aangestipt die in de discussies vaak in het oog springen.18 Kosten Een veel gehoord argument vóór het gebruik van OSS is dat OSS veel goedkoper is dan software die onder een closed source licentie op de markt wordt gebracht. Als uitsluitend naar de licentiekosten wordt gekeken, is dit juist, omdat voor OSS veelal geen licentiekosten in rekening worden gebracht. Maar de licentiekosten zijn uiteraard niet de enige kosten die in aanmerking worden genomen bij een besluit tot aanschaf van software. Ook aan de implementatie, het beheer en het onderhoud zijn kosten verbonden. Van deze kosten kan niet zonder meer gezegd worden dat zij voor OSS lager uitvallen dan voor closed software. Kwaliteit & transparantie OSS zou beter van kwaliteit en tevens veiliger zijn, omdat de broncode transparant is en vele ontwikkelaars eraan meewerken die elkaar onderling scherp houden en elkaar wijzen op fouten en onvolkomenheden. Zeker bij veiligheidslekken wordt het als een voordeel gezien dat de broncode vrij beschikbaar is. Zonodig kan de hele broncode worden uitgepluisd om te ontdekken waar het lek zit. Bij closed software is men hiervoor afhankelijk van de leverancier en moet de gebruiker er op vertrouwen dat het lek is gedicht, zonder dat hij dat kan (laten) controleren. Leveranciers van closed software zouden volgens sommige OSSvoorstanders er zelfs belang bij kunnen hebben fouten in hun software zo lang mogelijk stil te houden, omdat herstel tijd en moeite vraagt en dus geld kost. Aan de andere kant moet het aan de ‘traditionele’ softwareleveranciers worden toegegeven, dat zij juist door het geheim houden van de broncode licentiegelden verwerven die onder andere weer geïnvesteerd kunnen worden in de verdere ontwikkeling en verbetering van hun producten. Onafhankelijkheid Onafhankelijkheid van softwareleveranciers en van andere software- en hardwareproducten, wordt eveneens vaak gezien als een groot voordeel van het gebruik van OSS. Ook hier is enige nuancering op zijn plaats. Er zijn voorbeelden van OSS die uitsluitend door bepaalde leveranciers kunnen worden geïmplementeerd. Ook is er OSS op de markt die alleen met bepaalde andere closed soft-

18

Zie verder: ‘Fabels en Feiten Open source software’ op de website van OSOSS: < http://www.ososs.nl/ index.jsp?page=2426 >.

24


ware werkt, waardoor de koper alsnog met hoge licentiekosten kan worden geconfronteerd.19 Continuïteit Stel dat een OSS-community op een gegeven moment ‘uitsterft’ en er niet langer wordt voort gewerkt aan het product. Wat betekent dit dan voor de continuïteit? Door het open karakter van de broncode kan men echter ook dan de OSS blijven gebruiken. Een gebruiker zou een derde in de arm kunnen nemen voor de verdere ontwikkeling en het onderhoud van het product. Overigens is continuïteit evenmin te allen tijde gewaarborgd door te kiezen voor closed software. Een leverancier kan immers op enig moment besluiten een product niet langer te ondersteunen. OSS solide product? Soms wordt nog wel eens betoogd dat OSS niet voldoende serieus genomen kan worden om als geschikt alternatief te dienen voor vergelijkbare closed software producten. Dit zal voor een aantal OSS-producten zeker kunnen gelden, net zo goed als voor closed software producten, maar voor de bekende OSS-producten zoals bijvoorbeeld Linux en Apache geldt dat zeker niet. Alleen al het feit dat meer dan de helft van alle internet websites door Apache wordt ondersteund, bewijst het tegendeel. Ook zij verwezen naar de reeds gegeven voorbeelden van overheden en bedrijven die voor een deel van hun bedrijfsvoering voor OSS hebben gekozen. Verantwoordelijkheid Bij de aanschaf van closed software is normaal gesproken duidelijk wie verantwoordelijk is voor het goed functioneren van de software. Een veelgehoorde klacht is dat de gebruiker van OSS in onzekerheid verkeert over de vraag bij wie hij verhaal kan halen bij problemen met de software en op zich is deze vrees begrijpelijk. Daar komt bij dat in de meeste OSS-licentievoorwaarden de aansprakelijkheid expliciet wordt uitgesloten of beperkt. Toch geldt ook hier weer dat de praktijk minder zwart-wit is dan zij op het eerste gezicht lijkt. In closed software licentievoorwaarden zijn meestal ook zeer ruime exoneraties opgenomen, dus het is maar de vraag of en in hoeverre een closed software leverancier daadwerkelijk verhaal biedt. Bovendien kan een afnemer proberen of hij OSS door tussenkomst van een ICT-leverancier kan verwerven, waarbij de afspraak

19 gl. R. van Wendel de Joode, E. Dooper, en J. Lahaye, Hype met valkuilen, Computable 4 juni 2004, te vinden op .

25


wordt gemaakt dat deze ICT-leverancier verantwoordelijkheid neemt voor het functioneren van de software. Where to find? Tot slot zij nog vermeld dat de gemiddelde gebruiker nog niet altijd weet waar hij OSS-producten kan vinden en hoe hij deze kan verwerven. De OSS-producten blijken vaak onbekender te zijn – een daarmee wellicht ook onbemind – dan de software die onder een closed software licentie wordt aangeboden. Naar verwachting zal dit in de loop der tijd wel veranderen, mede gezien het feit dat de overheid de rol op zich heeft genomen voorlichting te geven over OSS.

1.9

Afsluitende opmerkingen

Dit hoofdstuk verschafte inzicht in wat onder OSS moet worden verstaan, alsmede waar en wanneer de OSS-beweging precies is ontstaan. Ook zijn enige voor- en nadelen van het gebruik van OSS aan de orde gekomen. Met deze bagage over de achtergronden van OSS, wordt een beeld neergezet over het onderwerp van dit preadvies.

26

2

Overheid en Open Source Software Jan van den Bosch, Ronald Emons, Willem Sinninghe Damsté, Elles Vink en Eva Visser1

Mede dankzij de eind 2002 verschenen motie van het Groenlinks Tweede Kamerlid Vendrik, is OSS hier in Nederland voor het eerst op de politieke agenda geplaatst. Sindsdien is het niet stil gebleven. Zo is in mei 2003 het overheidsprogramma OSOSS (open standaarden en open source software voor de overheid) officieel van start gegaan. Dit programma beoogt overheden te informeren over en te stimuleren bij het gebruik van OSS. Vanwege de bijzondere relatie tussen overheid en OSS behandelt dit hoofdstuk de specifieke aspecten die verbonden zijn aan de positie van de overheid ten opzichte van OSS. Naast de beleidsmatige kant komt hierna ook de positie van de overheid respectievelijk als gebruiker en als verspreider van OSS aan de orde.

2.1

Inleiding

In toenemende mate maakt de overheid bij de uitvoering van haar publieke taken gebruik van software. Een deel van deze programmatuur is reeds open source software. Het gebruik van open source software binnen de overheid betreft tot op heden vooral zogenaamde backoffice programmatuur en in mindere mate bedrijfsapplicaties. Meer dan 35% van de websites van overheidsinstellingen draait bijvoorbeeld op de open source webserver Apache.2 Een ander voorbeeld is de inzet van Linux voor de meting van waterstanden.3 Nog weer een ander voorbeeld is de centrale overheidswebsite ‘Overheid.nl’, die gebruik maakt van het content management systeem MMBase.4 Ook een aantal gemeenten, waaronder Amsterdam, maakt gebruik van MMBase voor haar websites.

1

Bij de totstandkoming van dit hoofdstuk hebben mr. drs. Bart S.J. Knubben (Juridisch adviseur/Adviseur Open Source Software) en mr. Audrie M. Spelmink (juridisch adviseur), beiden werkzaam bij het programma OSOSS/Stichting ICTU (), als klankbord gefungeerd. Dit hoofdstuk is ten dele een bewerking van het artikel van B.S.J. Knubben, Van overheid en openheid – Keuzevrijheid begint bij transparantie van intellectuele eigendom, Computerrecht 2004/5, pp. 237-241. 2 Tweede Kamer, vergaderjaar 2003-2004, Aanhangsel van de Handelingen, KVR19881. 3 OSOSS-Voorbeeldproject, Rijksinstituut voor Kust en Zee (RIKZ), Droge voeten door Linux, 2004. Zie . 4 Zie .

27


Hieronder zal worden aangegeven op welke wijze de overheid optreedt als stimulator van OSS, en wat de motivatie hiervoor is. Vervolgens wordt de overheid als gebruiker en als verspreider beschreven. Met name de bijzondere positie van de overheid komt hierbij aan de orde. Afgesloten wordt met een vooruitblik en conclusie.

2.2

Overheid als stimulator en promotor van OSS

Wellicht ingegeven door het nog aarzelende gebruik van OSS in de praktijk, verscheen eind 2002 de motie van het Tweede Kamerlid Vendrik.5 In deze motie wordt de regering verzocht ervoor te zorgen dat in 2006 alle door de publieke sector gebruikte software aan open standaarden voldoet, alsmede dat de regering actief de verspreiding en ontwikkeling van software met een open broncode (open source software) in de publieke sector stimuleert en hiervoor concrete en ambitieuze doelstellingen formuleert. Mede door deze motie geniet open source software in Nederland volop de politieke belangstelling. Op basis van deze motie kreeg ‘de overheid’ de opdracht het gebruik van open source software te stimuleren. Wat moet hier nu onder ‘de overheid’ worden verstaan en op welke wijze is deze stimulering vormgegeven? Aannemelijk is dat de inhoud van het begrip overheid in dit verband verder strekt dan alleen de rijksoverheid, en dat daaronder zeker ook de lagere overheden en andere publiekrechtelijke lichamen zijn begrepen. Nu het hier evenals bij de aanbestedingsrichtlijnen gaat om een politieke wens ten aanzien van de besteding van publieke middelen, zou aansluiting gezocht kunnen worden bij het begrip aanbestedende dienst, dat in het aanbestedingsrecht wordt gehanteerd.6 Hierdoor wordt een helder kader gecreëerd. In het kader van de in de motie Vendrik genoemde stimulering ging begin 2003 het programma Open Standaarden en Open Source Software voor de overheid (OSOSS) van start.7 OSOSS wordt uitgevoerd door Stichting ICTU. Aanvankelijk in opdracht van het Ministerie van Binnenlandse Zaken en Koninkrijksrela-

5

Tweede Kamer, vergaderjaar 2002-2003, 28 600 XIII, nr. 30. Het begrip aanbestedende dienst omvat de staat, zijn territoriale lichamen, publiekrechtelijke instellingen en verenigingen gevormd door één of meer territoriale lichamen en/of publiekrechtelijke instellingen, aldus artikel 1 lid 9 Richtlijn 2014/18/EG. Aanbestedingsrechtelijke aspecten van de verspreiding van open source software vallen overigens buiten de reikwijdte van dit hoofdstuk. Zie hiervoor ondermeer de Handleiding ‘Open Source Software in aanbestedingen’ te vinden op . 7 Zie. 6

28

Overheid en Open Source Software

ties en het Ministerie van Economische Zaken. Later heeft het Ministerie van Onderwijs, Cultuur en Wetenschappen zich ook daarbij aangesloten. Het programma informeert overheidsorganisaties over de mogelijkheden van OSS. Daarnaast richt het programma zich op open standaarden.8 Het programma OSOSS kende aanvankelijk een looptijd tot 2006.9 Inmiddels is bekend dat de activiteiten met twee jaar worden verlengd, tot begin 2008, zij het in een andere organisatorische opzet. Het voornemen bestaat om open standaarden 2005 onder te brengen bij het Nationaal Overleg Open Standaarden en open source bij de Gemeenschappelijk Beheer Organisatie Overheid (GBO.Overheid). Dat schrijft minister Brinkhorst aan de Tweede Kamer. Duidelijk spreekt uit de oprichting van het programma OSOSS dat de politiek kennelijk sturend wenst op te treden in de wijze waarop overheidsgelden worden besteed ten aanzien van de ICT-uitgaven. Dit niet alleen omdat het publiek geld betreft, maar ook omdat op deze wijze de overheid een voorbeeldfunctie kan vervullen voor het gebruik en verspreiden van OSS. Hierbij spelen niet alleen de algemene voordelen van open standaarden en OSS (denk aan betere gegevensuitwisseling, de mogelijke verlaging van de kosten, vermindering van afhankelijkheid van leveranciers en het tegengaan van monopolieposities). Van belang is ook het beleid dat de overheid in andere programma’s propageert, zoals de ‘Andere Overheid’. In het bijbehorende actieprogramma10 is bijvoorbeeld het streven vastgelegd dat in 2007 65% van de publieke dienstverlening plaats kan vinden via het Internet. Daarnaast staat het streven naar administratieve lastenverlichting voor burgers en bedrijven bij de overheid hoog in het vaandel. Aan het bereiken van deze doelen kan het gebruik van open standaarden een grote bijdrage leveren, bijvoorbeeld omdat hiermee de interoperabiliteit tussen overheden en de mogelijkheid tot directe gegevensuitwisseling wordt vergroot. Het is de vraag in hoeverre een dergelijke politieke wens door overheidsinstanties zonder meer kan worden gerealiseerd. Immers, met name bij grotere overheidsinstellingen spelen naast een dergelijke politieke aanwijzing ook bedrijfseconomische belangen mee bij de afweging welke software wordt aangeschaft (reeds lopende verplichtingen, compatibiliteit met bestaande systemen, gedane investeringen). In de navolgende paragrafen zal worden geschetst wat de praktijk tot nu

8

Bewerking van het artikel van B.S.J. Knubben, ‘Van overheid en openheid. Keuzevrijheid begint bij transparantie van intellectuele eigendom’, Computerrecht 2004/5, pp. 237-241. 9 Zie motie Vendrik, Tweede Kamer, vergaderjaar 2002-2003, 28 600 XIII, nr. 30. 10 Zie .

29


toe laat zien en wat de belemmeringen zijn voor de overheid om OSS te gebruiken en/of te verspreiden. De politieke betrokkenheid in verband met de stimulering van het gebruik van open standaarden dan wel OSS volgt eens te meer uit de commotie die in december 2004 is ontstaan toen Microsoft in onderhandeling was met de overheid over het afsluiten van een mantelcontract. Tijdens de onderhandelingen is vanuit de Tweede Kamer forse kritiek gekomen. De linkse oppositie en D66 meenden dat de onderhandelingen met Microsoft haaks stonden op eerdergenoemde motie van het GroenLinks-kamerlid Kees Vendrik die in 2002 werd aangenomen.11 Er zijn ook kamervragen gesteld strekkende tot het verkrijgen van uitleg omtrent de eventuele aanschaf van Microsoft-software in het licht van de beleidslijnen van programma OSOSS en de motie Vendrik.12 Vermeldenswaard is, dat de minister van Justitie in zijn antwoord aangeeft dat de gegroeide praktijk (de hoge mate van standaardisatie en het aangewezen zijn op Microsoft producten) een reden is voor het vooralsnog continueren van de contracten met Microsoft in plaats van het overgaan naar open source software.

2.3

De overheid als gebruiker van OSS

2.3.1

De praktijk

Alvorens op de positie van de overheid als gebruiker van OSS in te gaan, wordt melding gemaakt van een in opdracht van het programma OSOSS uitgevoerd onderzoek onder ICT-managers werkzaam bij de overheid.13 Doel van dit onderzoek, waarvan de resultaten op 24 november 2003 zijn gepubliceerd, was om inzicht te krijgen in de wijze waarop overheidsorganisaties omgaan met OSS en open standaarden. Uit het onderzoek is gebleken dat gesloten standaarden op het gebied van kantoorautomatisering een dominante positie innemen. In het onderzoek is ook nagegaan welke houding de ICT-managers bij de overheid hebben ten aanzien van open standaarden. In het algemeen is geconcludeerd dat deze ICTmanagers duidelijk voordelen zien in het gebruik van open standaarden. Zo zien

11

Zie . TK 2004-2005, Vragen met nummers 2040504530, 2040504970 en 2040504980. TK 2004-2005, Aanhangsel Handelingen, Antwoorden nrs. 674, 675, 676, 857, 903. 13 Het onderzoek is uitgevoerd door het bureau MERIT. Dit is een onderzoeksinstituut van de Universiteit Maastricht, dat op 1 januari 1988 is opgericht om onderzoek te verrichten en onderwijs te verzorgen op het gebied van technologie en innovatie. Zie ook . MERIT heeft haar onderzoek gehouden onder ICT-managers van in totaal 277 organisaties op alle niveaus: rijk, provincies, gemeenten, waterschappen, en ZBO’s. 12

30


zij vooral verbeteringen bij de uitwisseling van gegevens als gevolg van het gebruik van open standaarden. Ze vinden dat de toegankelijkheid van gegevens in de toekomst beter is gegarandeerd bij open dan bij gesloten standaarden.14 Kortom: de houding ten opzichte van open standaarden is positief, maar dit vertaalt zich nog niet naar de praktijk. Wellicht is dit verklaarbaar vanuit de hierboven al aangehaalde bedrijfseconomische belangen. Uit hetzelfde onderzoek volgt dat 85% van de overheidsinstellingen reeds enige gebruikservaring heeft met OSS.15 Een Amerikaanse denktank heeft geconcludeerd dat ook wereldwijd overheidsinstellingen tientallen open source initiatieven hebben goedgekeurd.16 Ten aanzien van de lagere overheden heerst er een wisselend beeld inzake het gebruik van OSS. Vanuit het programma EGEM, dat door het departement van BZK en VNG samen is opgericht, wordt het gebruik van OSS gestimuleerd maar zijn er geen richtlijnen gegeven.17 Formeel gesproken moet de keuze voor OSS tot de ‘huishouding’ van de gemeente worden gerekend. Daardoor valt die keuze onder volledige verantwoordelijkheid van het bestuur van de gemeente. Gemeenten kunnen dus voor zichzelf richtlijnen opstellen bijvoorbeeld als onderdeel van een standaardisatie- of inkoopstrategie. Zo heeft de gemeenteraad van Nijmegen een motie aangenomen waarin het gebruik van open source software min of meer dwingend wordt voorgeschreven. Omdat er echter geen middelen vrijgemaakt zijn om de noodzakelijke expertise op te bouwen, laat de uitvoering nog op zich wachten. Over de toepassing van open standaarden en open source software bij provincies kan worden opgemerkt dat er geen uniform geldend kader is afgesproken tussen de provincies. De grondhouding van de provincies ten aanzien van het beleidsvoornemen van de overheid is overigens positief en het aantal serieuze pilots neemt gestaag toe.

2.3.2

Juridische aspecten

Uit eerdergenoemd onderzoek van OSOSS blijkt dat overheidsorganisaties gemiddeld ruim 25% van hun ICT-budget besteden aan licentievergoedingen

14

Publicatie OSOSS, ‘Situatie open standaarden en open source software binnen overheid’; . 15 MERIT, Open Standaarden en Open Source Software in Nederland, een kwantitatief onderzoek naar houding en gedrag van Nederlandse overheden, http://www.ososs.nl/article.jsp?article=8801, 24 november 2003, p. 23. 16 Zie rapport Centre for Strategic and International Studies, ‘Government open source policies’, . 17 .

31


voor software. Over het algemeen wordt dit aandeel als te hoog ervaren. Aan OSS zijn daarentegen per definitie geen licentiekosten verbonden.18 Daarom kan OSS in sommige gevallen een aantrekkelijk alternatief zijn. Met name voor grotere overheidsorganisaties speelt deze factor een rol, omdat er geen rekening hoeft te worden gehouden met het aantal gebruikers binnen de overheidsorganisatie of het aantal machines waarop de software wordt geïnstalleerd. Licentiebeheer wordt daardoor bovendien eenvoudiger, tenzij de implementatie- en onderhoudskosten afhankelijk zijn van het aantal gebruikers en/of machines (sommige OSS-licentievormen staan dat toe). Hoewel OSS door de afwezigheid van licentiekosten de overheid kansen biedt om tot aanzienlijke besparingen te komen, moet wel bedacht worden dat er naast licentiekosten ook altijd andere kosten aan software verbonden zijn. Denk bijvoorbeeld aan kosten die samenhangen met implementatie en onderhoud. Daarom zal de overheid, net als iedere andere organisatie, van geval tot geval moeten bekijken of OSS wel een financieel aantrekkelijke keuze is.19 Er bestaan echter genoeg voorbeelden uit de praktijk die aantonen dat met OSS aanzienlijke kostenbesparingen te behalen zijn.20 Gelet op de doelstellingen van de centrale overheid zoals hierboven omschreven, zou het minstens vast beleid van alle overheidsorganisaties moeten zijn om bij iedere aanschaf eerst na te gaan of OSS mogelijk kan worden gebruikt. Nu het gebruik van OSS vanuit regering en parlement wordt gestimuleerd, rijst de vraag of een dergelijk beleid kan worden opgelegd. Met betrekking tot toezicht op de wijze van gebruik zal hooguit een taak zijn weggelegd voor (toezichthoudende) organen zoals bijvoorbeeld de Algemene Rekenkamer. Of daarvan door overheden daadwerkelijk gebruik wordt gemaakt, zoals door regering en parlement gewenst, is een kwestie van toezicht in politieke zin. Ervan uitgaande dat het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties daarop toeziet en erover rapporteert aan de Minister, kan deze dan al of niet daartoe uitgenodigd, het Parlement verder informeren. Het is duidelijk dat bij het ontwikkelen van beleid ten aanzien van open source software overheden en organisaties in de gepremieerde en gesubsidieerde sector

18

Er kunnen wel kosten in rekening worden gebracht voor onderhoud, implementatie en verstrekking van een fysiek exemplaar. Het kan wel zo zijn dat een Linux-distributie ook gesloten software bevat waarvoor licentiekosten in rekening kunnen worden gebracht (bijvoorbeeld Sun Java desktop-system). 19 Zie voor meer informatie over de kosten en baten van open source software de publicatie ‘Investeren in openheid’, . 20 Een voorbeeld is de overheidsdienst Rijksinstituut voor Kust en Zee (RIKZ), die door de overgang naar Linux 50% op de kosten voor hardware en licenties bespaart; zie: .

32


vaak gebonden zijn aan toezicht in de zin van regels die door opdrachtgevers of toezichthouders worden opgelegd. Dergelijke toezichtconstructies kunnen het ontwikkelen van beleid in de lijn van de motie Vendrik blokkeren. Als voorbeeld hiervoor kan dienen een besluit van het Landelijk Instituut Sociale Verzekeringen (Lisv), de toenmalige opdrachtgever van de uitvoeringsregelingen sociale verzekeringen.21 In dit Lisv-besluit is in zijn algemeenheid bepaald dat een overeenkomst waarbij werkzaamheden worden uitbesteed, waarborgen dienen te bevatten dat de betrokken instellingen hun publieke verantwoordelijkheden kunnen waarmaken. Deze waarborgen dienen betrekking te hebben op de kwaliteit en tijdigheid van de te leveren diensten/producten. Bovendien dient een uitbestedingsovereenkomst garanties en aansprakelijkheidsvoorwaarden te bevatten. Deze voorwaarden staan op gespannen voet met de huidige constructies waaronder open source software in de regel wordt aangeboden. Immers, licenties voor open source software bieden de licentienemer in beginsel geen juridische waarborgen. De licentie bevat geen verklaring van de ontwikkelaar van de programmatuur omtrent de eigendom, noch omtrent zijn bevoegdheid de desbetreffende licentie te verlenen. Vanzelfsprekend wordt dan ook geen vrijwaring verleend voor aanspraken van derden die claimen dat de open source software inbreuk maakt op hun intellectuele eigendomsrechten. OSS-licenties, zoals de GNU General Public Licence, bevatten bovendien uitdrukkelijk geen garantie voor de programmatuur. Het volledige risico betreffende de kwaliteit en de prestaties van het programma wordt bij de gebruiker gelegd.22 Vanuit het voorbeeld van de Lisv-regels kan wellicht worden geconcludeerd dat het grootste struikelblok ligt in het ontbreken van garanties voor de kwaliteit en van vrijwaring voor aanspraken van derden. Als deze lacune op enigerlei wijze met aanvullende maatregelen gedicht kan worden, kan aan de overige eisen en

21

Besluit toetsingsvoorwaarden voor uitbesteding van taken door een uitvoeringsinstelling van 27 augustus 1997, Stcrt. 1997, nr. 172, p.15. Dit besluit is overigens formeel niet bekrachtigd door de Inspectie Werk en Inkomen (IWI, de huidige toezichthouder van UWV, maar deze heeft informeel wel aangegeven dat de strekking van dit besluit ten aanzien van het UWV nog steeds als geldend moet worden beschouwd. 22 Het Lisv-besluit bevat ook nog een specifieke voorwaarde omtrent de eigendomsrechten op programmatuur. Uitvoeringsinstellingen dienen materieel en intellectueel eigenaar te blijven van hun huidige en in de toekomst te ontwikkelen informatiesystemen. Deze eis is nog nader uitgewerkt in een opvolgend besluit. De strekking van dit besluit is, dat beoogd wordt de zelfstandigheid en continuïteit te waarborgen door het eisen van de intellectuele eigendom van de maatwerkprogrammatuur. Hiertoe wordt tevens bepaald dat de uitvoeringsinstelling te allen tijde toegang kan krijgen tot (het relevante gedeelte van) de broncode van maatwerkprogrammatuur en het recht heeft daarin wijzigingen aan te brengen. Deze specifieke eisen zijn wel goed te combineren met de licentievorm van open source software. De essentie daarvan is nu juist dat de broncode direct voor de gebruiker toegankelijk is en dat deze alle vrijheid heeft daarin wijzigingen aan te (laten) brengen.

33


voorwaarden van opdrachtgevers en toezichthouders met enige creativiteit waarschijnlijk wel tegemoet worden gekomen. Het verkrijgen van garantie voor de werking van software van de gemeenschap van programmeurs van OSS is niet of nauwelijks denkbaar. De GPL staat het bijvoorbeeld wel toe dat de licentienemer in onderhandeling treedt met de licentiegever over eventueel te verstrekken garanties in ruil voor een geldelijke beloning (artikel 1 GPL). Van een implementerende of beherende dienstverlener kan evenwel, net zoals bij de installatie van gesloten software, terzake van (de gevolgen van) uitval van de software garantie worden bedongen (de praktijk is echter weerbarstig; meestal garandeert een dienstverlener nauwelijks meer dan hetgeen hem door de producent van de software wordt gegarandeerd). Het programma OSOSS heeft een ‘Handreiking beheersing juridische risico’s overheid bij OSS’ uitgebracht waaruit valt te destilleren dat de overheid, indien zij licentienemer bij een OSS-licentie (met een dienstverlener die de open source software implementeert of beheert) is, haar aansprakelijkheid of schade in de overeenkomst met de dienstverlener op deze kan trachten af te wentelen.23 Te denken valt dan aan inbreuk op intellectuele eigendomsrechten (auteurs- of octrooirechten) van derden bij het gebruik van die software door de overheid enerzijds en aan schade bij de overheid als gevolg van een gebrek in die software anderzijds. In Amerika bestaat reeds een bedrijf dat verzekeringen verkoopt tegen eventuele risico’s bij het gebruik van open source.24 Een dergelijke afwenteling van aansprakelijkheid of schade zal niet eenvoudig zijn te realiseren indien er geen dienstverlener is ingehuurd, doch de overheid de implementatie of het beheer zelf ter hand heeft genomen. Dit ligt anders bij aanbestedingsplichtige overheidsinstanties: deze kunnen aansprakelijkheid van de dienstverlener als eis opnemen in aanbestedingsprocedures voor programmatuurontwikkeling, waarbij bedongen wordt dat het eindresultaat als open source software zal worden aangeboden, of bij procedures gericht op beheer en implementatie van open source software.

23

Zie . Open Source Risk Management: ; zie ook .

24

34


2.4

De overheid als verspreider van OSS

2.4.1

De praktijk

De Unie van Waterschappen inventariseert thans de mogelijkheden van verspreiding van OSS-software binnen de waterschappen. Het ligt in het voornemen om, in het kader van de bestuurlijke samenwerking tussen de centrale en decentrale overheid in 2005 tot afspraken te komen, ook over het ontwikkelen van software onder OSS-licenties. De Unie van Waterschappen is momenteel doende met het opzetten van een structuur voor operationele afspraken op ICT-gebied (het Waterschapshuis). Daarin kunnen afspraken over het gebruik van OSS worden ingebed. Een enkel waterschap is momenteel zeer ver met het uitrollen van Linux en OpenOffice op servers en werkstations. De ervaringen die daarbij worden opgedaan, zullen het toekomstige beleid in sterke mate bepalen.25 Door met gelden uit openbare middelen ontwikkelde software onder een OSSlicentie aan te bieden, staat deze software kosteloos ter beschikking van andere overheidsorganisaties en het publiek. Daardoor kunnen eveneens besparingen worden gerealiseerd. Zo distribueert de Technische Universiteit Delft SWAN een applicatie voor golfmodellering, onder een OSS-licentie.26 Een ander voorbeeld is de Gemeente Amsterdam die WIAB heeft laten ontwikkelen, welke nu onder een OSS-licentie beschikbaar is.27 Er zijn ook gevallen bekend van buitenlandse overheden die actief bijdragen aan OSS. In Amerika is bijvoorbeeld de National Security Agency medeontwikkelaar van Linux.28 En in Duitsland heeft de Bundesamt für Sicherheit in der Informationstechnik verschillende open source projecten, waaronder het Kroupware-project geïnitieerd.29 Ook de Europese Commissie ondersteunt sinds 1998 verschillende initiatieven op het gebied van OSS.30

25

Voor een overzicht van initiatieven bij lagere overheden zie: . Zie: . 27 WIAB staat voor Web-in-a-box; zie . 28 Zie . 29 Zie . 30 Zie . Zie verder voor de overheid als gebruiker, Handreiking beheersing juridische risico’s overheid bij OSS, paragraaf 3, en de overheid als verspreider, Handreiking beheersing juridische risico’s overheid bij OSS, paragraaf 4. 26

35


2.4.2

Juridische aspecten

2.4.2.1 Verspreiding moet voldoen aan open source definition Als een overheidsorganisatie OSS ontwikkelt of laat ontwikkelen en vervolgens, conform de geldende definitie, wil overgaan tot verspreiding, moet zij zich houden aan de volgende kenmerken van OSS: – de vrije beschikbaarheid van de broncode van de software; – een licentiemodel waarin de intellectuele eigendom en het (her)gebruik van de software en bijbehorende broncode dusdanig is geregeld dat de licentienemer de broncode mag inzien, gebruiken, verbeteren, aanvullen en distribueren. Een open source licentie dwingt vaak af dat de broncode van het product vrij beschikbaar moet zijn. Tevens dwingen veel open source licenties af dat software die afgeleid is van open source software of software die een gemodificeerde vorm is van open source software, zelf ook beschikbaar gemaakt moet worden onder dezelfde open source licentie. Als de licentie bepaalt dat de broncode vrij beschikbaar moet zijn, dient de broncode van afgeleide of gemodificeerde software ook vrij beschikbaar te zijn. Om helder te maken wanneer software open source software genoemd mag worden, is door het open source initiative31 voorwaarden opgesteld waaraan een licentie moet voldoen, zodat de software die onder die licentie vrijgegeven wordt, open source genoemd mag worden. In het kort komt dit naast de bovengenoemde punten neer op: geen enkele vorm van discriminatie ten aanzien van de distributie, geen restrictie ten aanzien van het gebruik, of de koppeling met andere software en de software moet technologieneutraal zijn. 2.4.2.2 Civiel- en/of bestuursrechtelijke implicaties De risico’s die overheidsorganisaties lopen bij de verspreiding van OSS, zijn onder meer de risico’s van inbreuk op intellectuele eigendomsrechten van derden en schade door toedoen van gebreken in/van de software, alsmede toerekenbare tekortkoming of acties uit onrechtmatige daad. De overheid verkeert als bewaker van publieke belangen per definitie in een bijzondere positie. De overheid moet vanuit die kwaliteit haar verantwoordelijkheid nemen en willen dat de door haar opgepakte zaken goed en op een transparante manier verlopen. De overheid zit vanwege haar bijzondere positie in de maatschappij in een glazen huis en vormt, ook gelet op haar bijzonder goede solvabi-

31

36

Zie de website .


liteit, een gemakkelijk doelwit bij eventuele schadeclaims. Dit alles bijeengenomen is voor de overheid een belangrijke reden om extra voorzichtig te zijn op het terrein van de OSS, met name ook bij het verspreiden ervan. Als er sprake is van een door de overheid bij de ontwikkeling ingeschakelde opdrachtnemer kan weer van hem een vrijwaring of garantie worden bedongen waarbij het de opdrachtnemer kenbaar moet zijn gemaakt dat de overheid het voornemen heeft om de software als open source software beschikbaar te stellen. Het is niet vanzelfsprekend dat die vrijwaring of garantie ook daadwerkelijk en voor 100% dekkend wordt verkregen. De overheid zal echter in het kader van haar zorgplicht jegens de gebruikers hoe dan ook aanvullende beheersingsmaatregelen in de sfeer van testen en audits moeten (laten) nemen. Indien er geen sprake is van een opdrachtnemer, zal de overheid in relatie tot de gebruikers verdergaande beheersingsmaatregelen moeten treffen. Niet alleen zal de zelf ontwikkelde software deugdelijk moeten worden getest. Er zal een keuze van licentie moeten plaatsvinden en de wijze waarop de licentie (met de daarin opgenomen aansprakelijkheidsuitsluitingen) door de gebruikers wordt geaccepteerd moet zo helder mogelijk zijn. De prijs voor de gebruikers dient zo mogelijk (voorzover de genoemde risico’s kunnen worden uitgesloten) te worden beperkt tot de distributiekosten van de overheid. Een actieve informatieverstrekking met een gebruikersfaciliteit is zonder meer vereist. Volgens het programma OSOSS ‘kunnen de risico’s door de uitvoering van de genoemde beheersingsmaatregelen tot een acceptabel niveau worden gereduceerd’. Het voorafgaand inwinnen van juridisch advies wordt echter sterk aanbevolen. Ook ten aanzien van de productie/verspreiding van OSS door overheden, rijst de vraag of hier concreet toezicht vanuit de centrale overheid is aangewezen. Bij gebrek aan een concreet daartoe ingesteld toezichthoudend orgaan lijkt hier weinig ruimte voor aanwezig. Vooralsnog lijkt dit overigens ook niet geboden omdat de risico’s en aansprakelijkheid, die voor overheidsinstanties jegens auteurs en gelaedeerde derden mogelijk ontstaan, aan het oordeel van de civiele rechter kunnen en zullen worden voorgelegd. Daarbij ligt, het zij herhaald, op het doen en nalaten van de overheid een verzwaarde zorgvuldigheidsplicht en dus een vergrote kans op aanwezigheid van aansprakelijkheid. Of deze met eventueel publiekrechtelijk toezicht door een naast hogere overheid of door een specifiek ingesteld toezichthoudend orgaan weer zou kunnen worden afgezwakt wordt hier in het midden gelaten.

37


2.4.2.3 OSS en de Wob Naast potentiële prijsvoordelen biedt open source software de overheid ook kansen op het gebied van kwaliteit van de software. Door de openheid van broncode is de kwaliteit van de software ten eerste controleerbaar. Bij het gebruik van OSS heeft een overheidsorganisatie of een derde-partij te allen tijde de mogelijkheid een inspectie van de broncode te (laten) doen. De werking van open source software is daardoor in hoge mate transparant, waardoor de controleerbaarheid en verifieerbaarheid van overheidshandelen toeneemt. De openheid kan uiteindelijk leiden tot een hogere mate van vertrouwen in het overheidshandelen.32 Een dergelijke openheid lijkt ook in lijn met het wettelijke kader inzake overheidsinformatie. Artikel 3 Wet openbaarheid bestuur (Wob) verschaft aan eenieder recht op informatie door een bestuursorgaan of een onder verantwoordelijkheid van een bestuursorgaan werkzame instelling, dienst of bedrijf. Het betreft hier informatie neergelegd in documenten over bestuurlijke aangelegenheden. Artikel 10 Wob bevat uitzonderingsgronden en beperkingen op dit informatierecht. In het algemeen worden deze uitzonderingsgronden en beperkingen restrictief uitgelegd. De Wet openbaarheid van bestuur (Wob) is van toepassing op bestuursorganen die in artikel 1 van de Wob nader worden omschreven en op organisaties die onder de verantwoordelijkheid van een bestuursorgaan opereren.33 Het uitgangspunt van de Wob is dat informatie die bij de overheid berust in principe openbaar is. Hiermee regelt de Wob de openbaarheid van informatie van de overheid. De reden hiervoor is dat het voor iedereen mogelijk moet zijn om overheidshandelen te controleren. Eenieder kan derhalve een verzoek tot openbaarheid van informatie indienen. De openbaarheid van informatie is echter beperkt tot informatie, die is neergelegd in documenten en betrekking heeft op een bestuurlijke aangelegenheid. De Wob verstaat onder de bestuurlijke aangelegenheid:34 ‘een aangelegenheid die betrekking heeft op beleid van een bestuursorgaan, daaronder begrepen de voorbereiding en de uitvoering ervan.’

32

Voor een argumentatie waarom open source software leidt tot veiligheid en vertrouwen, zie: B. Jacobs/J.H Hoepman, Open source software: bron van vertrouwen?, I&I, 21 (6), 2003, pp 12-19, . 33 Artikel 1 Wob verstaat onder bestuursorganen: a. Onze Ministers, b. de bestuursorganen van provincies, gemeenten, waterschappen en publiekrechtelijke organisaties, c. bestuursorganen die onder de verantwoordelijkheid van de onder a en b genoemde organen werkzaam zijn en d. andere bestuursorganen, voorzover niet bij algemene maatregel van bestuur uitgezonderd. Artikel 3, eerste lid bepaalt: ‘Een ieder kan een verzoek om informatie … richten tot een bestuursorgaan of een onder verantwoordelijkheid van een bestuursorgaan werkzame persoon’. 34 Vergelijk artikel 3 lid Wob.

38


Informatie die niets met beleid of bestuur te maken heeft, valt derhalve ook niet onder de reikwijdte van de Wob. Gezien de reikwijdte van de Wob is het – om te bepalen of de Wob van toepassing is op het gebruik van open standaarden en open source software – van belang om te kijken naar de kenmerken van open standaarden en open source software. Software bestaat uit een reeks constructies die door een computer(systeem) worden gebruikt om het programma te laten functioneren. Open standaarden zijn afspraken over de indeling van de gegevens. Op basis van vorenstaande kan worden geconcludeerd dat bij het gebruik van open standaarden en open source software in beginsel geen sprake is van een bestuurlijke aangelegenheid in de zin van de Wob. Voorzover informatie die betrekking heeft op het beleid van een bestuursorgaan zonder de desbetreffende software niet te raadplegen is, zou dit anders kunnen zijn.35 In dit geval voldoen open standaarden en open source software eigenlijk altijd aan het vereiste van openbaarheid, aangezien zowel open standaarden als de broncode van open source software gepubliceerd worden. 36 In een onderzoek van de Landsadvocaat en de K.U. Brabant wordt gesteld dat het ‘niet ondenkbaar is dat dit [software] informatie in de zin van de Wob [Wet openbaarheid van bestuur] is omdat met de software veelal berekeningen en modellen worden gemaakt die verband houden met de voorbereiding van beleid, waarbij de informatie zonder die software in een aantal gevallen bovendien niet goed kan zijn te raadplegen. Dit kan betekenen dat de overheid op grond van de Wob verplicht is die broncodes ter beschikking te stellen aan burgers.’37

Dat de controleerbaarheid van broncode geen overbodige luxe is, toont een recent onderzoek van een aantal academici naar de veiligheid van stemmachines van het Amerikaanse bedrijf Diebold die bij verkiezingen in de VS zijn gebruikt. De veiligheid van deze stemmachines, waarvan de broncode van de software was uitgelekt, bleek twijfelachtig te zijn.38 Mede omwille van de controleerbaarheid heeft het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties onlangs de broncode van de stemdienst Kiezen Op Afstand (KOA) onder de GPL openbaar gemaakt. De software is ingezet bij de

35

Zie hierover J.M. Barendrecht,/I. Giesen,/M.H.M. Schellekens/M.W. Scheltema, Aansprakelijkheid voor overheidsinformatie. Den Haag/Tilburg: Pels Rijken & Droogleever Fortuijn en KU Brabant, paragraaf 5.10. 36 Afkomstig uit de handleiding ososs in Nederlandse en Europese Aanbestedingen. 37 Pels Rijcken & Droogleever Fortuijn en K.U. Brabant, Aansprakelijkheid voor overheidsinformatie., 29 augustus 2001. 38 Zie .

39


verkiezing van het Europees Parlement in juni 2004, zodat kiezers vanuit het buitenland per internet en telefoon konden stemmen.39 Een treffend voorbeeld in dit kader is de vraag die aan de minister van Bestuurlijke Vernieuwing en Koninkrijksrelaties is gesteld, namelijk of hij het ermee eens is dat gebruikers van closed source software grotere veiligheidsrisico’s lopen dan gebruikers van open source software – aangezien fouten minder snel ontdekt worden, gebruikers zelf geen aanpassingen kunnen verrichten en leveranciers fouten verborgen kunnen houden voor klanten. Hierop heeft Minister De Graaf laten weten dat gebruikers van closed source software in het algemeen geen grotere veiligheidsrisico’s lopen dan gebruikers van open source software. Evenmin vormt openheid van de broncode op zich een garantie van veiligheid. Een goed systeembeheer is belangrijker voor de veiligheid dan de vraag of de software open dan wel gesloten is. De keuze voor open of closed source software hangt af van de eisen die in een specifieke situatie worden gesteld, aldus de bewindsman.40 Voorts zei hij dat zijn streven er op gericht is om de keuzevrijheid bij het gebruik van software te vergroten. Om dit te bereiken wil de Minister de volgende zaken op de rails zetten: – het programma van eisen voor de aanschaf van software door de overheid moet aan zowel leveranciers van gesloten als open software gelijke kansen bieden; – in sommige toepassingsgebieden waar men erg afhankelijk is van gesloten varianten, pilots starten om te laten zien dat open source software een betrouwbaar alternatief kan zijn; – hergebruik van door overheden zelfontwikkelde software bevorderen door deze waar mogelijk als open source software aan andere overheden ter beschikking te stellen41.

2.5

Vooruitblik/Conclusie

2.5.1

Overheid als stimulator

De motie Vendrik heeft het gebruik van OSS door de overheid aangemoedigd, hetgeen zich mede heeft geuit in de oprichting van het programma OSOSS. Het

39

Software van de stemdienst Kiezen op Afstand nu open source, . Het Tweede-Kamerlid Szolt Szabo, VVD, heeft zich kritisch tegen het gebruik van OSS uitgelaten, zie Automatisering Gids 25 juni 2003. Het is echter zeer de vraag of dit een unaniem en weldoordacht standpunt van zijn fractie is. 41 Tweede Kamer, vergaderjaar 2003-2004, 26 387, nr. 20. 40

40


programma OSOSS beoogt het gebruik van OSS verder te stimuleren. Het beleid ten aanzien van dit gebruik op de diverse niveaus bevindt zich nog in een experimentele fase. Het moet nog worden ontwikkeld en deze ontwikkeling moet haar vorm vinden binnen de eventuele kaders die toezichthouders stellen en binnen de mogelijkheden die in de praktijk nog moeten worden ontwikkeld voor de huidige obstakels op het gebied van aansprakelijkheid. Het programma OSOSS zou aanvankelijk eindigen in 2006, inmiddels is dit in een aangepaste vorm verlengd tot 2008. Dit geeft aan dat rol van de overheid als stimulator nog niet is uitgespeeld.

2.5.2

Overheid als gebruiker

Hoewel uit onderzoek blijkt dat managers in overheidsorganisaties positief staan tegenover het gebruik van OSS, blijft de praktijk nog achter. Dit is, naast historische redenen zoals die ook naar voren kwamen in de beantwoording van de ‘Microsoft vragen’ ook ingegeven door een aantal juridische risico’s. Het zal zeker helpen als voor deze risico’s oplossingen kunnen worden gevonden.

2.5.3

Overheid als verspreider

Als de overheid als verspreider wenst op te treden, zal zij zich moeten houden aan de open source definitie. Ook hier zullen constructies moeten worden gevonden om een verregaande aansprakelijkheid in te perken dan wel af te wentelen. Vooralsnog blijft de praktijk terughoudend en betreft het vooral overheidsinstanties die gelijke werkvelden bestrijken, en onderling de ontwikkelde software beschikbaar stellen.

41

3

Auteursrecht en open source software Juliette van Balen, Bianca Bauer, Walter van Holst, Kamiel Koelman, Anette Ligtenstein, Regine Scholten en Merijn Seelt

Het auteursrecht speelt een belangrijke, maar enigszins paradoxale rol bij de ontwikkeling, distributie en het gebruik van OSS. Terwijl het auteursrecht van oorsprong vooral is geschreven om ervoor te zorgen dat een rechthebbende het gebruik van zijn werk kan verbieden of beperken, wordt door de open source beweging het auteursrecht juist ingezet om af te dwingen dat de open source voorwaarden worden nageleefd, die er op zien dat de OSS vrijelijk gebruikt en verspreid kan worden. Auteursrechtelijke begrippen als makerschap, werk, de exploitatierechten en persoonlijkheidsrechten staan bij OSS daardoor vaak in een wat ander daglicht dan gebruikelijk. Dat komt mede doordat OSS veelal door meerdere personen wordt ontwikkeld. In dit hoofdstuk wordt toegespitst op de bijzondere auteursrechtelijke vragen ten aanzien van OSS.

3.1

Inleiding

Een belangrijk kenmerk van OSS is dat het zich dankzij de inspanningen van vele programmeurs steeds verder ontwikkelt. Voortdurend wordt de bestaande software verbeterd en bijgesteld en worden er elementen aan toegevoegd. Diverse vragen dienen zich aan. Is een toevoeging een op zichzelf niet beschermde bewerking van een reeds bestaand, auteursrechtelijk beschermd werk? Of wordt er met het aanbrengen van een wijziging of toevoeging een geheel nieuw werk gecreëerd? Wie is ‘maker’ en wie ‘bewerker’ en hoe verhouden hun rechten zich tot elkaar? Wat moet men bijdragen om een auteursrecht te verkrijgen? Om deze vragen te kunnen beantwoorden, wordt eerst bekeken wat de Auteurswet verstaat onder een ‘werk’. Vervolgens komen het makerschap, de exploitatierechten en de persoonlijkheidsrechten aan de orde. We sluiten af met de mogelijkheden tot handhaving van het auteursrecht. Dit alles in relatie tot OSS.

43


3.2

Werk

Wanneer we spreken over software als auteursrechtelijk beschermd werk, geldt artikel 1 lid 3 van de Software Richtlijn als aanknopingspunt.1 Volgens dit artikel is een computerprogramma beschermd ‘wanneer het in die zin oorspronkelijk is, dat het een eigen schepping van de maker is’. Daarbij is belangrijk dat er ‘geen andere criteria worden aangelegd’. Dit criterium verschilt niet veel van de ten tijde van de implementatie van de Software Richtlijn in de Nederlandse jurisprudentie algemeen geformuleerde maatstaf: het eigen oorspronkelijk karakter en het persoonlijk stempel van de maker bepalen of een werk auteursrechtelijke bescherming geniet.2 Bij de implementatie van de Software Richtlijn heeft men het daarom niet nodig geacht artikel 1 lid 3 van de Software Richtlijn op te nemen in de Auteurswet. Voor OSS geldt geen ander criterium. Voor de beoordeling of er auteursrechtelijke bescherming geldt, zal steeds de vraag moeten worden beantwoord of de OSS een voldoende oorspronkelijk karakter heeft. Bijdragen ter wijziging of aanvulling van de software kunnen zelfstandige auteursrechtelijke bescherming genieten. Vaak zal een kleine aanvulling of wijziging in bestaande code, bijvoorbeeld een stukje code dat in één regel is gevat of een eenvoudige bugfix, geen zelfstandig auteursrechtelijk werk zijn. Niet iedereen die een bijdrage heeft geleverd aan OSS, is daardoor rechthebbende geworden op dat programma. Ook wordt bij de ontwikkeling van OSS vaak voortgeborduurd op een werk dat anderen tot stand hebben gebracht. Of een dergelijke bewerking zelfstandig voor auteursrechtelijke bescherming in aanmerking komt, wordt verderop in dit hoofdstuk bij de bespreking van de exploitatierechten uiteengezet.

3.3

Makerschap

Als gezegd wordt OSS vaak door vele programmeurs gezamenlijk tot stand gebracht. Keer op keer zal gekeken moeten worden wie voor welk onderdeel van de OSS auteursrechthebbende is, omdat alleen de auteursrechthebbende mag beslissen over gebruik van zijn bijdrage onder een OSS-licentie. Ook bij de handhaving van OSS-licenties is van belang te weten wie auteursrechthebbende is.

1

Richtlijn betreffende bescherming van computerprogramma’s, 91/250/EEG, Pb. L122/42. HR 28 juni 1946, NJ 1946, 712, Van Gelder / Van Rijn; HR 29 november 1985, NJ 1087, 880, Screenoprints/Citroën; HR 4 januari 1991, NJ 1991, 608, Van Dale/Romme.

2

44

Auteursrecht en open source software

In beginsel wordt de programmeur die een auteursrechtelijk beschermingswaardige bijdrage aan de OSS heeft geleverd auteursrechthebbende, maar ook andere partijen kunnen het auteursrecht verkrijgen. In sommige OSS-projecten wordt bijvoorbeeld gewerkt met een comité van experts. Dat comité beoordeelt of aangeboden wijzigingen en bijdragen het waard zijn om in een volgende versie van het programma te worden opgenomen. De rol van het comité kan vergelijkbaar zijn met die van de samensteller van een verzamelwerk als bedoeld in artikel 5 Auteurswet. Wanneer dit het geval is, is het comité rechthebbende op het geheel, onverminderd de rechten van de makers van de onderdelen.3 Ook kan de situatie zich voordoen dat een aantal ontwikkelaars gezamenlijk bijvoorbeeld een nieuw stuk Linux-code heeft ontwikkeld dat als zelfstandig werk kwalificeert. Als hierbij één persoon het brein is van deze nieuwe ontwikkeling en het feitelijke ontwikkelwerk onder zijn supervisie heeft plaatsgevonden, kan hij krachtens artikel 6 Auteurswet als maker worden aangemerkt van het nieuw ontwikkelde stukje OSS en kan hij in die hoedanigheid het auteursrecht uitoefenen. Vaak zal echter de ontwikkeling in gezamenlijk overleg hebben plaatsgevonden, zonder dat het ontwerp aan één persoon is toe te schrijven en zonder dat sprake is geweest van leiding en toezicht in de zin van artikel 6 Auteurswet. Hoewel de Auteurswet hier niet met zoveel woorden over spreekt, namelijk alleen in de context van de handhaving van het gemeenschappelijk auteursrecht krachtens artikel 26 Auteurswet, kan er sprake zijn van co-auteurschap. Als de gezamenlijke inspanningen hebben geleid tot één eindproduct, is voor de exploitatie ervan toestemming nodig van elk van de betrokken programmeurs. Dat brengt met zich dat wanneer de nieuw ontwikkelde software als bijdrage ter beschikking wordt gesteld in het kader van een open source project, alle programmeurs moeten instemmen met de licentieverlening, tenzij zij hierover andersluidende afspraken hebben gemaakt.4 Gezamenlijke inspanningen kunnen ook leiden tot wel van elkaar scheidbare onderdelen die in combinatie een eindproduct opleveren. Als elk onderdeel in voldoende mate een eigen oorspronkelijk karakter bezit, berust het auteursrecht bij de maker van dat onderdeel. Dan zijn er ook nog vele grote ICT-ondernemingen die fors investeren in OSS. Deze ICT-ondernemingen zetten programmeurs in om bij te dragen aan de verdere ontwikkeling van OSS in de hoop dat daarvan een impuls uitgaat voor de

3 4

Zie hierover ook: K.J. Koelman, ‘Brothers in Arms: open source en auteursrecht’, Computerrecht 2004, 36. De regeling van de gemeenschap als bepaald in de artikelen 3:166 BW en verder is hier van toepassing.

45


verkoop van eigen producten en diensten. Sun Microsystems bijvoorbeeld, speelt een belangrijke rol bij de ontwikkeling van OpenOffice.5 Een ander voorbeeld is IBM dat het OSS-pakket Linux heeft geïntegreerd in haar dienstverlening.6 Krachtens artikel 7 Auteurswet wordt de werkgever aangemerkt als maker van werken die zijn werknemers in dienstverband tot stand hebben gebracht als dit tot de taak van die werknemers behoort. Hier bestaat dus niet, zoals bij het auteursrecht op een verzamelwerk en auteursrecht op in teamverband tot stand gebrachte werken, een direct verband tussen degene die het werk daadwerkelijk maakte en degene die het auteursrecht kan uitoefenen. Een dienstverband wordt aangenomen als er sprake is van een gezagsverhouding en er loon betaald wordt. Verdedigbaar is dat als er gebruik gemaakt wordt van uitzendkrachten of sprake is van detachering, het auteursrecht naar analogie toekomt aan de inlener.7 Om een dispuut daarover te voorkomen, wordt in inleenovereenkomsten vaak bepaald dat mocht er door toedoen van de ingeleende kracht een auteursrechtelijk beschermd werk ontstaan, het auteursrecht aan de inlenende partij moet worden overgedragen.8 Ook als personeel wordt ingehuurd voor de ontwikkeling van OSS, is het raadzaam over het auteursrecht helderheid te scheppen in de inleenovereenkomst. Voor academici geldt mogelijk niet onverkort dat het auteursrecht op door hen tot stand gebrachte OSS toekomt aan de universiteit waaraan zij zijn verbonden, omdat er vanwege de academische vrijheid geen sprake zou zijn van een gezagsverhouding. Ook als een onderneming gebruik maakt van studenten of stagiaires zal veelal geen sprake zijn van een dienstverband in de zin van artikel 7 Auteurswet, waardoor de onderneming niet van rechtswege auteursrechthebbende wordt. Aan opdrachtgevers van op freelance basis werkende specialisten die in opdracht een bijdrage hebben geleverd aan de ontwikkeling van OSS, biedt artikel 8 Auteurswet mogelijk een basis om zonder overdracht het auteursrecht naar zich toe te trekken. Als een publieke of private rechtspersoon de OSS openbaar maakt en daarbij niet de naam van een natuurlijke persoon als maker vermeldt, wordt de rechtspersoon als maker van dat programma aangemerkt, aldus dit artikel. Dus als een bijdrage van een freelancer ter beschikking wordt gesteld onder een OSSlicentie en de opdrachtgever daarvan vermeldt zijn eigen naam, wordt de opdrachtgever daarmee mogelijk als maker van het werk aangemerkt. Dit gaat

5

Vgl. < http://sunsource.net> en http://openoffice.org. In verband hiermee is IBM overigens in een geruchtmakende rechtszaak verzeild geraakt met het Amerikaanse software bedrijf SCO. 7 Vgl. Ch. Gielen / D.W.F. Verkade (red.), Intellectuele Eigendom, Tekst en Commentaar, Kluwer 1998, p. 9. 8 Vgl. ICT Modelcontracten, contract E.3.18, artikel 8.1, Kluwer 2003. 6

46


uiteraard niet op als sprake was van onrechtmatige openbaarmaking. Of de freelancer afstand van zijn recht moet hebben gedaan, of dat voldoende is dat niet gebleken is van enig bezwaar tegen openbaarmaking zonder naamsvermelding, is in de literatuur geen uitgemaakte zaak.9 Ook hier geldt overigens dat discussie hierover kan worden vermeden door in de overeenkomst met de freelancer duidelijke afspraken te maken. Artikel 8 Auteurswet staat daaraan niet in de weg, omdat het van aanvullend recht is. Ten slotte kan het auteursrecht op OSS net als bij andere werken ook worden verkregen door erfopvolging of overdracht.

3.4

Exploitatierechten

Het auteursrecht is een exclusief recht waardoor een rechthebbende het gebruik van zijn werk kan controleren. Alleen de rechthebbende mag zijn werk ‘verveelvoudigen en openbaar maken’. Dit brengt mee dat hij aan anderen de exploitatie van zijn werk kan verbieden of toestaan.10 Opmerkelijk is dat veel OSS-licenties niet of nauwelijks beperkingen aan de gebruikers opleggen. OSS-licenties wenden het auteursrecht aan om de voor de gebruikers gecreëerde vrijheden te waarborgen bij verdere verspreiding van de (gewijzigde) software. De exclusieve rechten van de rechthebbenden tot het verveelvoudigen en openbaar maken worden op deze wijze ingezet om te bewerkstelligen dat de OSS vrijelijk verspreid en gebruikt kan worden en om te waarborgen dat ook níemand anderen kan verhinderen om de OSS te gebruiken of te bewerken. Het auteursrecht wordt in die zin als het ware ‘tegennatuurlijk’ gebruikt. Wat wordt nu onder openbaar maken en verveelvoudigen verstaan en gelden er in dit verband nadere bijzonderheden voor OSS? Openbaar maken en verveelvoudigen Doorgaans wordt OSS publiekelijk voor gebruik ter beschikking gesteld. Meestal gebeurt dat via het internet. Is daarbij sprake van ‘openbaar maken’ in de zin van de Auteurswet? Uit de wetgeschiedenis volgt dat het begrip openbaar maken in de eerste plaats moet worden opgevat in de betekenis die deze heeft naar normaal spraakge-

9 Ch. Gielen / D.W.F. Verkade (red.), Intellectuele Eigendom, Tekst en Commentaar, Kluwer 1998, p. 10; vgl. J.H. Spoor / D.W.F. Verkade/D.J.G. Visser, Auteursrecht, Kluwer 2005, pp. 48-51. 10 Artikel 1 Auteurswet definieert het auteursrecht als het uitsluitend recht van de maker van een werk van letterkunde, wetenschap en kunst, of van diens rechtverkrijgenden, om dit openbaar te maken en te verveelvoudigen, behoudens de beperkingen, bij de wet gesteld.

47


bruik. Daarnaast vond de wetgever het nodig een aantal aanvullingen hierop te formuleren, terwijl ook de rechter invulling aan het begrip heeft gegeven.11 Het komt erop neer dat het verspreiden of verkrijgbaar stellen van een werk aan het publiek is te zien als ‘openbaar maken’. Van openbaar maken van software zal, gezien de ruime strekking van het begrip snel sprake zijn. Ook het beschikbaar stellen van OSS op internet kan als ‘openbaar maken’ in de zin van de Auteurswet worden beschouwd en is dus in principe exclusief voorbehouden aan de rechthebbende(n) op de OSS. Volgens artikel 45i Auteurswet is het normale gebruik van software verveelvoudigen in de zin van de Auteurswet waartoe in beginsel uitsluitend de maker gerechtigd is.12 Dat betekent dat het downloaden en gebruiken van OSS zijn aan te merken als ‘verveelvoudigen’. Ook het voortborduren op een werk van anderen kan een vorm van verveelvoudigen opleveren. Of dat het geval is, zal afhangen van de mate waarin de OSS is bewerkt. Bewerkingen Bij de ontwikkeling van OSS wordt vaak voortgeborduurd op een werk dat anderen tot stand hebben gebracht. In dit verband is van belang dat bewerkingen auteursrechtelijk gezien twee kanten hebben die zijn neergelegd in de artikelen 10 lid 2 en 13 van de Auteurswet. Als sprake is van ‘verveelvoudigingen in gewijzigde vorm’, waaronder mede begrepen bewerkingen, rust daarop volgens artikel 10 lid 2 Auteurswet een zelfstandig auteursrecht, mits de bewerking oorspronkelijk is. Van bewerken als bedoeld in artikel 10 lid 2 Auteurswet is alleen sprake als (i) het onderliggende werk waarvan de bewerking is afgeleid zelf een auteursrechtelijk beschermd werk is en (ii) de bewerking zelf een eigen oorspronkelijk karakter heeft en daarmee een auteursrechtelijk beschermingswaardig werk is. Het nieuw ontstane auteursrecht op de bewerking laat het auteursrecht op het oorspronkelijke werk onverlet. Van een bewerking of nabootsing in de zin van artikel 13 is sprake als aan twee voorwaarden is voldaan. Essentieel is dat auteursrechtelijk beschermde trekken van een werk herkenbaar moeten zijn overgenomen in een ander voortbrengsel. Iedere wijziging van een werk, die niet als een nieuw, oorspronkelijk werk kan worden aangemerkt, valt onder de werking van artikel 13 en kan als een verveelvoudiging van het oorspronkelijke werk worden aangemerkt.13 Het auteursrecht

11

Vgl. artikel 12 Auteurswet. Vgl: J.H. Spoor / D.W.F. Verkade/D.J.G. Visser, Auteursrecht, Kluwer 2005, pp. 156-158. 13 Artikel 2 van de GPL spreekt bijvoorbeeld over ‘a work based on the Program’ waarvoor geldt dat dit onder dezelfde voorwaarden moet worden verspreid als de oorspronkelijke programmatuur. 12

48


op de bewerking berust in dat geval bij degene die het auteursrecht heeft op het onderliggende werk en niet bij de bewerker. Er ontstaat immers geen nieuw auteursrechtelijk werk met de bewerking. Hierin ligt het essentiële verschil met artikel 10 lid 2. Voor OSS geldt op dit punt hetzelfde als voor andere auteursrechtelijke werken. Aan de hand van de bovenstaande criteria zal moeten getoetst of een bijdrage aan OSS al dan niet als zelfstandig auteursrechtelijk werk moet worden aangemerkt. Overigens staat in sommige OSS-licenties dat de van de OSS afgeleide werken onder dezelfde licentievoorwaarden moeten worden verspreid als de OSS zelf.14 De betekenis van bewerking in de Auteurswet kan dan op zichzelf een aanknopingspunt bieden voor de invulling van het begrip afgeleid werk. Het verschil tussen een bewerking in de zin van artikel 10 lid 2 of van artikel 13 is daarbij minder relevant.

3.5

Beperkingen; de wettelijke licenties

Teneinde tegengewicht te bieden aan de exclusieve rechten van de auteursrechthebbende op software, formuleert de Auteurswet een aantal beperkingen op diens rechten. Door deze beperkingen van de rechten van de rechthebbende, worden tegelijkertijd wettelijke licenties gecreëerd voor de gebruikers. Hierna zal blijken dat, op een enkele uitzondering na, aan de OSS-gebruiker ofwel geen beroep op de wettelijke licentie toekomt, omdat niet aan alle voorwaarden is voldaan, ofwel dat hij geen wettelijke licentie nodig heeft, omdat de OSS-licenties veelal ieder gebruik van de OSS toestaan. Artikel 45j Auteurswet bepaalt dat de verveelvoudiging door een ‘rechtmatige verkrijger’ van een ‘exemplaar’ van software geen auteursrechtinbreuk oplevert, als die verveelvoudiging noodzakelijk is voor het ‘beoogde gebruik’ van die software.15 Wat wordt nu onder ‘rechtmatige verkrijger’ verstaan? Dat is degene die van de rechthebbende of van diens daartoe bevoegde licentienemer de programmatuur heeft verkregen.16 Ook de opvolgende verkrijger van hetzelfde exemplaar van de software kan op basis van de uitputtingsleer een rechtmatige verkrijger zijn, mits zijn wijze van verkrijging geen onrechtmatige daad jegens de auteurs-

14 15 16

Zie hiervoor ook het hoofdstuk ‘Een vermogensrechtelijke verkenning van OSS-licentiëring’. J.H. Spoor/D.W.F. Verkade/ D.J.G. Visser, Auteursrecht, Recht en Praktijk 42, Kluwer Deventer 2005, p. 597. Zie P.C. Van Schelven/H. Struik, Softwarerecht, Deventer: Kluwer 1995, pp. 79-82.

49


rechthebbende of diens licentienemer oplevert.17 Wat onder ‘beoogd gebruik’ wordt verstaan, vloeit niet rechtstreeks voort uit de wet. Hierbij kan gedacht worden aan het gebruik zoals door de rechthebbende werd beoogd en het gebruik zoals wordt beoogd door de rechtmatige verkrijger.18 In de context van OSS zal gauw voldaan zijn aan het vereiste van beoogd gebruik, nu de OSS-licenties juist zo ongeveer elk denkbaar gebruik mogelijk maken. Meer nog van belang is dat om een beroep te kunnen doen op artikel 45j, er ten slotte sprake moet zijn van een fysiek exemplaar. Als OSS online wordt verkregen, hetgeen doorgaans het geval is, zal aan dit vereiste niet zijn voldaan. Hierdoor boet deze wettelijke licentie aan belang in voor OSS. Daarnaast heeft de rechtmatige gebruiker van software het recht een reservekopie te maken indien een kopie voor het beoogde doel noodzakelijk is (artikel 45k Auteurswet). Dit geldt ook voor OSS. In de praktijk zal deze wettelijke beperking nauwelijks van belang zijn, nu juist kenmerkend is voor OSS dat aan de gebruiker geen beperkingen worden opgelegd om de OSS te verveelvoudigen. In artikel 45l Auteurswet staat dat het is toegestaan om tijdens het gebruik van software de werking daarvan waar te nemen, te bestuderen en te testen met als doel de achterliggende ideeën en beginselen te achterhalen. Ook deze beperking is op OSS van toepassing, maar van weinig belang. Veel OSS-licenties vereisen dat de broncode openbaar wordt gemaakt en als men over de broncode beschikt, is het niet nodig om omslachtig de werking van een programma te achterhalen terwijl het draait. Op grond van artikel 45m Auteurswet worden bepaalde vormen van reverse engineering, die ook wel, zij het technisch minder accuraat, decompilatie van software worden genoemd, niet als auteursrechtinbreuk beschouwd. Onder reverse engineering wordt wel verstaan: ‘het analyseren van de software van een ander om op basis van de hierdoor verkregen informatie nieuwe, eigen programmatuur te ontwikkelen’.19 Artikel 45m Auteurswet bepaalt onder welke voorwaarden reverse engineering wel en niet is toegestaan. Op zich is deze wettelijke licentie voor OSS van weinig belang nu de broncode, die door programmeurs soms gekscherend de ultieme documentatie wordt genoemd, beschikbaar is. Niettemin kan

17 P.C. van Schelven / H. Struik, Softwarerecht, Deventer, Kluwer 1995, pp. 83-87, merken op dat doorslaggevend voor de beantwoording van de vraag wat in een gegeven geval het beoogde doel is, is de naar omstandigheden van het geval vast te stellen wil van de licentiegever en -nemer met betrekking tot het gebruik van het programma. 18 Achtergrondinformatie Juridische aspecten open source software, Den Haag 6 juli 2004, p.18. Voor een gedegen behandeling van dit fenomeen verwijzen we P. Samuelson/R. Davis/ N.D. Kapoy/ J. Reichman, A. manifesto concerning the legal protection of computer programs, in: Columbia Law Review, vol. 94, nr. 8, december 1994, pp. 2308-2431. 19 Eric S. Raymond, The Cathedral & the Bazaar, O’Reilly, 1999.

50


deze wettelijke licentie juist weer wel relevant zijn indien de OSS compatibel dient te zijn met ‘gesloten’ software, waarvan de broncode niet openbaar toegankelijk is. Op basis van artikel 45m Auteurswet bestaan dan toch mogelijkheden om de OSS met deze ‘gesloten software’ te laten samenwerken. Opvallend is ten slotte dat in de context van OSS het citaatrecht van artikel 15a Auteurswet opeens van belang kan blijken te zijn. Vanwege de beschikbaarheid van de broncode, zoals veelal het geval is bij OSS, kan onder de hiervoor geldende voorwaarden vrijelijk worden geciteerd uit bijvoorbeeld de broncode van Linux in een handboek over besturingssystemen. ‘Closed sofware’ zoals MS Windows wordt daarentegen veelal uitsluitend in object code vorm verspreid, waardoor het uitoefenen van het citaatrecht ten aanzien van de broncode daarvan feitelijk niet mogelijk is. Kortom: de wettelijke beperkingen zijn van weinig belang voor OSS. Alleen het citeerrecht en de beperking in verband met reverse engineering lijken enige relevantie te hebben.

3.6

Persoonlijkheidsrechten

Vergeleken met software die onder meer traditionele licenties verspreid wordt, de closed software, kunnen persoonlijkheidsrechten bij OSS een relatief grotere rol spelen. De reden hiervoor is dat bij OSS niet zelden erkenning door vakgenoten de drijfveer is, terwijl bij traditionele licenties de maker vaak commerciële motieven heeft. Dat blijkt bijvoorbeeld uit het volgende citaat van Eric S. Raymond, de grondlegger van de Open Source Initiative (OSI): The ‘utility function’ Linux hackers are maximizing is not classically economic, but is the intangible of their own ego satisfaction and reputation among other hackers. (One may call their motivation ‘altruistic’, but this ignores the fact that altruism is itself a form of ego satisfaction for the altruist). Voluntary cultures that work this way are not actually uncommon; one other in which I have long participated is science fiction fandom, which unlike hackerdom has long explicitly recognized ‘egoboo’ (ego-boosting, or the enhancement of one’s reputation among other fans) as the basic drive behind volunteer activity.20

Wanneer de OSS auteursrechtelijk beschermd is, komen aan de maker ook persoonlijkheidsrechten toe. Deze persoonlijkheidsrechten zijn voornamelijk gere-

20

Zie bijvoorbeeld: E.P.M. Thole, Software, een novum in het vermogensrecht, Deventer 1991, pp. 116-117; P.C. van Schelven,/H. Struik, Softwarerecht, Deventer 1995, pp. 64-65.

51


geld in artikel 25 van de Auteurswet en zijn verbonden aan de persoon van de maker. Het gaat hierbij kort gezegd om het recht van naamsvermelding, het recht zich te verzetten tegen wijzigingen in, dan wel misvorming, verminking of andere aantasting van zijn werk. Zelfs al draagt de maker zijn auteursrecht over, dan nog blijven de persoonlijkheidsrechten bij hem berusten. Naar hun aard zijn de persoonlijkheidsrechten niet overdraagbaar. De Auteurswet laat wel toe dat in enkele gevallen afstand wordt gedaan van deze rechten. Alleen van het recht op naamsvermelding en van het recht van de maker zich te verzetten tegen wijziging van het werk of van de benaming kan afstand worden gedaan (artikel 25 lid 3 Auteurswet). In het verleden is in de literatuur de vraag aan de orde gesteld of persoonlijkheidsrechten wel relevant zijn voor software.21 Zo is wel betoogd dat het utilitaire karakter van software de toepasselijkheid van persoonlijkheidsrechten in de weg zou staan of dat deze daardoor minder van belang zouden zijn. Ook berust het auteursrecht op software in de praktijk veelal niet bij de feitelijke maker, maar bijvoorbeeld bij zijn werkgever, waardoor de persoonlijke band een geringere rol speelt. In de context van OSS is daarentegen juist veel te zeggen voor het toekennen van persoonlijkheidsrechten aan de maker(s). Vooral de erkenning door de peers wordt als een belangrijke motivatie voor makers van OSS gezien. In die zin is het hierboven aangehaalde citaat van Eric S. Raymond interessant, omdat het kan worden gezien als een antwoord op het argument dat het utilitaire karakter van software de toepasselijkheid van persoonlijkheidsrechten in de weg zou staan. Tegelijkertijd kunnen de persoonlijkheidsrechten op een aantal punten botsen met het idee van OSS. Een voorbeeld daarvan is het recht om zich tegen verminkingen van het werk te verzetten, een recht waarvan bovendien geen afstand kan worden gedaan. Kenmerkend voor OSS is nu juist dat de gebruiker een freedom to tinker krijgt. Dit houdt in dat een ieder zonder enig voorbehoud wijzigingen kan aanbrengen in de OSS, zelfs al zou de wijziging een verminking van het werk van de andere makers inhouden. Een ander voorbeeld waar persoonlijkheidsrechten en OSS botsen, is in het geval van forked projecten. Dit is een fenomeen waarbij twee projecten naast elkaar ontstaan, omdat de programmeurs die bijdragen aan een specifiek stuk OSS van mening verschillen over de koers daarvan. Beide projecten zullen doorgaans

21

Voorbeelden hiervan zijn o.a. Emacs en XEmacs (http:// www.xemacs.org), Sodipodi (http://www.sodipodi.com) en Inkscape .

52


onder verschillende namen opereren.22 Het nieuwe project, de fork bouwt voort op de oude code. In theorie kunnen op grond van artikel 25 Auteurswet de makers van de oude code opkomen tegen het gebruik van de code onder een nieuwe titel of naam. Over het algemeen wordt een dergelijke naamswijziging echter juist wenselijk geacht in OSS-omgevingen, zodat helder is dat de beide groepen hun eigen weg zijn ingeslagen. Bij een aantal projecten zal er zelfs een merkenrechtelijke aanleiding voor een naamswijziging bestaan. Overigens zullen de genoemde ‘botsingen’ in de praktijk sowieso niet tot al te grote problemen leiden. Een veelgebruikte OSS-licentie als de GPL heeft het wijzigingsrecht aan voorwaarden onderworpen zoals vermelding van de naam van degene die de wijzigingen heeft aangebracht en een omschrijving van de wijzigingen. Op die manier kan worden voorkomen dat het werk onder een andere naam dan die van de maker wordt openbaar gemaakt.23 Niettemin zijn er ook OSS-licenties waar dergelijke voorwaarden ontbreken, bijvoorbeeld de veelgebruikte BSD-licentie. Op basis van bovengenoemde voorbeelden kan gesteld worden dat het concept van OSS-licenties enerzijds kan wringen met de persoonlijkheidsrechten, terwijl anderzijds de persoonlijkheidsrechten in de context van OSS juist aan belang kunnen winnen.

3.7

Duur van auteursrechtelijke bescherming bij OSS

Hoe lang geldt nu het auteursrecht dat verleend wordt aan de maker van OSS en hoe lang kan de maker derden dus verplichten de software uitsluitend te gebruiken onder de voorwaarden die de toepasselijke OSS-licentie stelt? De standaardduur van het auteursrecht op een werk loopt op grond van artikel 37 lid 1 Auteurswet tot 70 jaar na de dood van de maker. Bij OSS zijn er doorgaans meerdere makers betrokken en soms ook anonieme makers of rechtspersonen die als maker optreden. Dat leidt tot verschillende uitkomsten. Indien een OSS-product zonder bekendmaking van de identiteit van de maker wordt gepubliceerd – hetgeen op internet zeer eenvoudig onder een breed publiek kan –, geldt het auteursrecht daarop tot 70 jaar na de eerste januari van het jaar

22

W.H. van Holst/N.K. van Mullem, De (on)geldigheid van de GPL, JAVI, juni 2004, nr. 3, pp. 94-99. De MvA vermeldt dat deze bekendmaking door de maker zelf moet geschieden en niet door derden zoals zijn erfgenamen (MvA bij w.v. 7877, PG p. 38.7).

23

53


volgend op het jaar van publicatie (artikel 38 lid 1 Auteurswet). Maar als de anonieme maker zich vóór het verstrijken van deze termijn alsnog bekend maakt, wordt op grond van artikel 38 lid 3 Auteurswet de bescherming verlengd tot 70 jaar na de dood van de maker.24 Bij OSS is als gezegd vaak sprake is van meerdere makers. Als er sprake is van elkaar opvolgende bewerkingen – bijvoorbeeld maker 2 voegt een functie toe aan een OSS-product dat maker 1 heeft gemaakt en maakt deze openbaar als nieuwe versie – dan is er, op voorwaarde van voldoende oorspronkelijkheid, sprake van een nieuw werk op grond van artikel 10 lid 2 Auteurswet en hiervoor geldt dan een beschermingstermijn van 70 jaar na de overlijdensdatum van de bewerker. Als de bijdragen van de verschillende programmeurs van een OSS-product of een bewerking daarvan niet kunnen worden gescheiden, is er mogelijk sprake van een gezamenlijk werk. Hierop hebben de verschillende makers dan een gezamenlijk auteursrecht dat geldt tot 70 jaar na de dood van de langstlevende maker.25 Indien er sprake is van het gezamenlijk schrijven van een OSS-product naar het ontwerp van, en onder leiding en toezicht van één van de programmeurs, dan wordt die programmeur volgens artikel 6 Auteurswet als de maker aangemerkt en is hij de enig rechthebbende. De beschermingsduur is dan afhankelijk van de levensduur van die maker volgens de basisregel van artikel 37 lid 1 Auteurswet. Indien de persoon die de software schrijft in dienst is van een rechtspersoon, dan komt op grond van artikel 7 Auteurswet het auteursrecht toe aan die rechtspersoon. In geval het software programma vervolgens onder de naam van die rechtspersoon openbaar wordt gemaakt, dan geldt op grond van 38 lid 2 Auteurswet dezelfde duur als bij anoniem openbaar gemaakte werken: 70 jaar na de eerste januari van het jaar volgend op het jaar van publicatie, behalve indien bij de publicatie de naam van de natuurlijke persoon wordt vermeld die het software programma schreef, want dan loopt de beschermingsduur alsnog tot 70 jaar na de dood van die persoon. Het gevolg van het voorgaande is dat voor de onderdelen van eenzelfde OSS-product de duur van de bescherming kan variëren, omdat er meer nog dan bij de

24

HR 25 maart 1949, NJ 1950, 643 (La Belle et la Bête); Artikel 37 lid 2 Auteurswet. Dit houdt verband met de exponentiële groei van de kracht van computers. Deze exponentiële groei wordt wel Moore’s Law genoemd, omdat Gordon Moore, een van de oprichters van processor fabrikant Intel reeds in 1968 voorspelde dat de verwerkingscapaciteit van microprocessors zich iedere 18 maanden zou blijven verdubbelen. Zie voor meer info de website van Intel, .

25

54


meeste andere auteursrechtelijk beschermde werken, verschillende rechthebbenden zijn. De beschermingsduur van 70 jaar is lang gezien de snelle ontwikkelingen in de IT-industrie. Ongeacht of het om closed software of OSS gaat. Van de meeste software programma’s en besturingssystemen komen jaarlijks of vaker nieuwe versies op de markt.26 Ook veranderen de gebruikte standaarden in zowel computerhardware als software snel. Als nadeel van de lange beschermingsduur wordt wel genoemd dat dit de mogelijkheid beperkt om op uitgebrachte werken voort te bouwen.27 Gezien de snelle ontwikkelingen in de IT-industrie geldt dit nadeel voor software des te sterker, daar het voortbouwen op oude software programma’s hierdoor al snel geen zin meer heeft. Dit nadeel is mogelijk een van de redenen van de opkomst van OSS. De behoefte om samen te werken en te kunnen voortbouwen op het werk van een ander is een van de belangrijkste doelen van het gebruik van OSS-licenties. Door het gebruik van deze licenties wordt dit nadeel van de lange duur van het auteursrecht ondervangen. De paradox is daarmee dat de lange beschermingsduur aan de ene kant de maker de gelegenheid biedt om verdere bewerkingen van de door hem ontwikkelde software lange tijd te blokkeren, maar aan de andere kant de maker ook de mogelijkheid biedt om via OSS-licenties bewerkers van zijn werk te dwingen verdere bewerkingen van hun bewerking toe te staan.

3.8

Handhaving

Als OSS wordt gebruikt of verspreid op een manier die de licentie niet toestaat, levert dat, behalve wanprestatie, ook auteursrechtinbreuk op. De auteursrechthebbenden kunnen de gebruikelijke vorderingen instellen tegen een inbreukma-

26

Genoemd door Lawrence Lessig, een bekend voorvechter van beperking van de duur van auteursrechtelijke bescherming in het algemeen en Professor rechtsgeleerdheid verbonden aan de universiteit van Yale. Zie voor meer informatie over hem en zijn pleidooien op dit vlak: < htttp:// www.lessig.org >, onder meer in zijn in 2002 gehouden speech ‘Ninth Annual Herbert Tenzer Distinguished Lecture in Intellectual Property’, gehouden op de Benjamin N. Cardozo School of Law op 7 februari 2002, gepubliceerd in Cardozo Arts & Entertainment Law Journal, Volume 20, nummer 3, 2002., 623. Lessig geeft als voorbeeld de diverse Disney films die gebaseerd zijn op oude sprookjes en verhalen, zoals Sneeuwwitje en Pocahontas. Disney kon deze verfilmingen maken, omdat de auteursrechten op de oorspronkelijke verhalen waren verlopen. Dergelijke bewerkingen van werken van Disney zelf uit de jaren dertig van de vorige eeuw (bijvoorbeeld de Mickey Mouse verhalen uit die tijd) mogen echter nog steeds niet gemaakt worden zonder toestemming van Disney. Om deze reden heeft Lessig de wet die in 1998 in Amerika werd ingevoerd om de auteursrechtelijke beschermingsduur te verlengen de ‘Mickey Mouse protection Act’genoemd, mede omdat deze wet door sterk lobby werk van Disney tot stand was gekomen. 27 Zie en .

55


ker. Zij kunnen een verbod of bevel, schadevergoeding, winstafdracht, inbeslagname en vernietiging van inbreukmakende software eisen. Indien er sprake is van een gemeenschappelijk auteursrecht zijn alle partijen onafhankelijk van elkaar bevoegd om een dergelijke juridische actie te initiëren op grond van artikel 26 Auteurswet. Licentienemers kunnen slechts een vordering instellen als zij daartoe een procesvolmacht hebben verkregen. In de regel ontbreekt zo’n volmacht bij OSS-licenties. In het welbekende GNU-project van de Free Software Foundation worden auteurs aangespoord om hun rechten over te dragen aan deze organisatie, zodat zij de rechten en de open source voorwaarden kunnen handhaven.28 Het is duidelijk dat effectieve handhaving wordt bevorderd indien alle rechten onomstreden bij één partij liggen. Daarmee kan het verweer worden ondervangen dat de eiser geen rechthebbende is ten aanzien van het overgenomen onderdeel of element en kunnen de problemen van internationaal privaatrecht worden omzeild. Technische bescherming Technische bescherming – bijvoorbeeld encryptie van software of kopieerbeveiliging – en de open source filosofie lijken haaks op elkaar te staan. De meeste open source licenties staan onbeperkt kopiëren toe en een belangrijke doelstelling van de open source beweging is dat iedereen gemakkelijk toegang heeft tot (de broncode van) software. Het zou daarom incompatibel zijn met de open source doelstellingen om anderen door middel van encryptie de toegang tot software te ontzeggen of om technisch het kopiëren van software te verhinderen. Technische voorzieningen – ook wel Digital Rights Management (DRM) systemen genoemd – zijn in beginsel bedoeld om technisch af te dwingen dat een gebruiker zich aan de voorwaarden houdt die een licentiegever stelt. De in een licentie gestelde gebruiksbeperkingen worden automatisch gehandhaafd. De belangrijkste open source voorwaarden hebben betrekking op verdere verspreiding van een computerprogramma; die verspreiding moet op een zodanige wijze gebeuren dat opvolgende verwervers ook weer aan de voorwaarden zijn gebonden en dat zij anderen toestaan de software te gebruiken, te bewerken en te verspreiden. Vooralsnog kunnen echter slechts condities met betrekking tot het verkrijgen van toegang tot de inhoud van een bestand en tot kopiëren technisch worden bekrachtigd. Voorzover bekend bestaan er nog geen systemen waarmee kan worden verhinderd dat een bestand wordt verspreid op een manier die een

28

56

Richtlijn 2001/29/EG van het Europees Parlement en de Raad van 22 mei 2001, PbEG L167/10.


licentie niet toestaat. Het lijkt daarom (nog?) niet tot de mogelijkheden te behoren om technisch af te dwingen dat open source voorwaarden worden nageleefd. Eventueel zou technische bescherming kunnen worden ingezet om te verzekeren dat iedere open source gebruiker daadwerkelijk een overeenkomst aangaat wat in de huidige praktijk niet altijd het geval is. Dan zou bijvoorbeeld een encryptielaag zich pas openen, wanneer de verwerver aan de formaliteiten heeft voldaan die wettelijk worden gesteld aan de totstandkoming van een verbintenis. Open source licenties zouden moeten vereisen dat dezelfde technische beveiliging op verdere distributies van (bewerkingen van) de software wordt aangebracht, zodat opvolgende verwervers ook weer technisch gedwongen worden om aan die formaliteiten te voldoen. Om in overeenstemming te zijn met de open source gedachte zou de beveiliging, als hij eenmaal is geopend, de gebruiker uiteraard niet mogen verhinderen de software te gebruiken of te bewerken. Technische beveiliging van software wordt juridisch beschermd door artikel 32a Auteurswet, het nieuwe artikel 29a Auteurswet heeft betrekking op de beveiliging van alle andere werktypen. Deze bepaling verbiedt, kort gezegd, het verhandelen van middelen waarmee softwarebeveiliging kan worden gekraakt. Het kraken zelf valt er niet onder. Dit betekent dat de bepaling niet kan worden ingeroepen, wanneer een gebruiker een technische voorziening zou kraken om te vermijden aan de open source licentie voorwaarden gebonden te zijn. Kortom, technische beveiliging en de bescherming daarvan kunnen vooralsnog weinig betekenen voor de open source methode. Technische bescherming kan de open source gedachte wel ondermijnen. Soms is het nodig om de werking van een ander programma te bestuderen om een daarmee compatibele (open source) applicatie te kunnen maken. De artikelen 45l en 45m Auteurswet staan dat onder bepaalde voorwaarden ook toe. Maar als een programma is versleuteld, moet een technische beveiliging worden doorbroken om toegang te krijgen tot de voor compatibiliteit vereiste informatie. Zoals gezegd staat artikel 32a Auteurswet op zichzelf aan het kraken van een beveiliging niet in de weg. Verder blijkt uit overweging 50 van de Auteursrechtrichtlijn dat de Europees rechtelijke bepaling waarvan artikel 32a Auteurswet afstamt, en daarom ook de Nederlandse bepaling, er niet toe mogen leiden dat de door artikel 45l en 45m Auteurswet toegestane handelingen worden belet.29 Dit kan inhouden

29

Zie over dit onderwerp onder meer ook: K.J. Koelman, Octrooi op software, I&I 2003-6, pp. 20-27; A. Engelfriet, Open source software en octrooien: een moeilijke combinatie, BIE 2003, pp 204-208 en E.Valgaeren, Open source code en octrooien – van ‘copyleft’ naar ‘patentleft’, Computerrecht 2004/5, pp. 233-237.

57

dat de middelen die nodig zijn om bijvoorbeeld geëncrypteerde software te ontsleutelen voorzover dat nodig om compatibiliteit te bewerkstelligen, mogen worden gemaakt en verspreid.

4

Octrooirecht en open source software H. de Jong, J. Röschlau, J. van de Sande, P. Terporten en E. Valgaeren.

Octrooirecht wordt veelal als een bedreiging gezien voor OSS. Tegelijkertijd geldt ook dat het octrooirecht kansen biedt voor OSS. Beide visies komen hierna aan de orde. Dit nadat eerst de laatste stand van zaken rond octrooieerbaarheid van software in het algemeen is toegelicht. Ten slotte wordt beschreven hoe OSSorganisaties met deze mogelijke bedreigingen en kansen omgaan.

4.1

Octrooi op software

Uiteraard kan het octrooirecht alleen dan relevant zijn voor de ‘open source methode’, als software zelf octrooieerbaar is.1 Volgens de Nederlandse Rijksoctrooiwet (‘ROW’) en het Europese Octrooiverdrag (‘EOV’) zijn alleen ‘uitvindingen’ vatbaar voor octrooirechtelijke bescherming. Computerprogramma’s ‘als zodanig’ worden niet als uitvindingen beschouwd.2 Niettemin laat de verleningspraktijk van het Europees Octrooibureau (‘EOB’) zien, dat computerprogramma’s toch octrooieerbaar kunnen zijn. Zo kunnen uitvindingen die bestaan uit een combinatie van programmatuur en apparatuur in aanmerking komen voor octrooirechtelijke bescherming. Voorwaarde is steeds dat de programmatuur een ‘technisch karakter’ of een ‘technisch effect’ heeft. Kijkt men echter naar de nationale wetten en de jurisprudentie van de lidstaten van de Europese Unie dan blijken in de uitwerking hiervan verschillen te bestaan. Deze constatering en de vrees dat de verschillen groter zouden kunnen worden, heeft ertoe geleid dat men op Europees niveau getracht heeft te komen tot een richtlijn over de octrooieerbaarheid van software. Dit enerzijds ter vastlegging van de bestaande praktijk en anderzijds ter harmonisering van de verschillen tussen de lidstaten. Op 20 februari 2002 publiceerde de Europese Commissie een eerste voorstel voor een richtlijn betreffende het octrooieren van in computers geïmplementeerde uitvindingen (‘Ontwerp Richtlijn’).3 Na een eerste behandeling in het Europees Parlement in september 2003, werd in maart 2005 een

1 2

Vgl. artikel 2.2.c. ROW 1995 en artikel 52.3 EOV. Vgl. .

59


Gemeenschappelijk Standpunt vastgesteld door de Raad van Ministers. Hierbij werden amendementen van het Europees Parlement slechts in zeer beperkte mate gehonoreerd. Het voorstel is evenwel van meet af aan omstreden geweest. Dit blijkt niet alleen uit de vele publicaties waarin betoogd werd dat de Ontwerp Richtlijn een directe bedreiging voor OSS is, maar ook uit de stellingnamen tegen de Ontwerp Richtlijn in de verschillende nationale parlementen.4 Door de commissaris voor de interne markt en diensten, McCreevy, was reeds aangegeven, dat als het Europees Parlement de Ontwerp Richtlijn zou verwerpen, de Raad niet met een nieuw voorstel zou komen.5 Op 6 juli 2005, dus ruim drie jaar na indiening van het eerste voorstel, is de Ontwerp Richtlijn uiteindelijk met maar liefst 648 tegen 14 stemmen verworpen door het Europees Parlement. Daarmee is nieuwe Europese regelgeving over de octrooieerbaarheid van software definitief van de baan.6 De commotie over de Ontwerp Richtlijn vindt haar oorsprong in, al dan niet vermeende, tegengestelde belangen van enerzijds grote (software)bedrijven en anderzijds kleine bedrijven en supporters van OSS. M. Rocard, rapporteur van het Europees Parlement heeft het aldus verwoord: ‘The common position, if approved, would have allowed patenting of computer-implemented inventions. This outcome was advocated by big software firms, which argued that patents would encourage research spending and defend European inventions from US competition. On the contrary, the directive was criticised by supporters of ‘open source’ software, mainly smaller companies, who claimed copyright already protects their inventions and were afraid that patenting would raise legal costs.’ 7

Hierbij was opvallend dat de lobby voor de grote bedrijven via de regeringen van de landen gevoerd werd en dat de lobby voor de kleine bedrijven via de nationale parlementen en het Europees Parlement liep. Nu er geen Richtlijn komt, zal de huidige verleningspraktijk van het EOB en de nationale verlenende instanties gecontinueerd worden. Deze verleningspraktijk

3

Vgl. . 4 Vgl. . 5 Vgl. . 6 Vgl. . 7 Zie:.

60

Octrooirecht en open source software

wordt voor wat het EOB betreft, vastgelegd en steeds geactualiseerd in de ‘Guidelines for Examination in the European Patent Office’ (‘Guidelines’).8 Volgens deze Guidelines zijn softwareuitvindingen niet uitgesloten van octrooiering als deze een technisch karakter bezitten. Evenwel uitvindingen waarbij gebruik wordt gemaakt van computerprogramma’s die geen andere technische effecten teweegbrengen dan de normale fysieke interactie tussen een programma en de computer, zijn niet octrooieerbaar. Uit de Guidelines volgt dat ook een programma op een drager als een uitvinding beschouwd kan worden ‘if the program has the potential to bring about, when running on a computer, a further technical effect which goes beyond the normal physical interactions between the program and the computer’.

Dit vloeit voort uit uitspraak T1173/97 van de Technical Board of Appeal van het EOB.

4.2

Octrooirecht versus OSS

De discussie over octrooien en OSS wordt overheerst door de gedachte dat octrooien een bedreiging zouden kunnen vormen voor het bestaan, de verdere ontwikkeling en het gebruik van OSS. Het belangeloos en vrij uitwisselen van de broncode om de software ontwikkeling te bevorderen, lijkt nu eenmaal haaks te staan op het octrooiconcept dat uitgaat van monopolisering van uitvindingen. Vandaar ook het sterke verzet van de OSS-gemeenschap tegen de Ontwerp Richtlijn. Van de belangrijkste bedreigingen die de OSS-gemeenschap in het octrooirecht ziet, wordt hierna een schets gegeven, waarbij tegelijkertijd enige nuance wordt aangebracht.9 Voorstanders van OSS vrezen eerst en vooral dat OSS-projecten geblokkeerd kunnen worden doordat men bij de ontwikkeling van OSS op een bestaand octrooi kan stuiten.10 Er zijn evenwel methoden om het risico dat inbreuk wordt gemaakt op octrooien van derden zoveel mogelijk te beperken. Grote bedrijven doen dit door bij de aanvang van een project een voorbereidend onderzoek te verrichten naar de stand van de techniek en de reeds bestaande octrooien. Bij OSSprojecten die door vrijwilligers worden gerund, is het daarentegen niet aanneme-

8 9 10

Zie E.Valgaeren ‘Open source en octrooien: van copyleft naar patentleft’, Computerrecht 2004, 37. Vgl. . .

61


lijk dat een dergelijk onderzoek zal plaatsvinden. De kennis van de stand van de techniek zal daarbij niet zozeer het probleem zijn: de doorgaans vlotte informatie-uitwisseling en samenwerking tussen de leden van een OSS-gemeenschap zal dit juist vergemakkelijken. Echter het vaststellen welke octrooien relevant zijn en welke niet vormt wel een groot obstakel. Niet in de laatste plaats vanwege het grote onoverzichtelijke aantal octrooien dat er bestaat. Deze problematiek is aan de orde gesteld tijdens hearings gehouden door de Federal Trade Committee. Dit Amerikaanse overheidsorgaan had de opdracht gekregen aanbevelingen te doen om het Amerikaanse octrooisysteem in balans te brengen met het mededingingsrecht en het antitrust recht. Tijdens deze hearings kwam naar voren dat in gebieden waar incrementele innovaties plaatsvinden, zoals computerhardware en software, er sprake is van een ‘patent thicket’. Daaronder wordt verstaan ‘a dense web of overlapping intellectual property rights that a company must hack its way through in order to actually commercialize new technology’.11

Waar degenen die waren gehoord zich in het bijzonder ongerust over maakten, was het mogelijke grote aantal ongeldige softwareoctrooien. Octrooiverleningsinstanties dienen zich beter te organiseren. Bijvoorbeeld door meer te investeren in systemen die het mogelijk maken de bestaande octrooien en stand van de techniek te evalueren en door onderzoekers aan te trekken met voldoende kennis van software en van de sector om aanvragen voor een octrooi op software deskundig te beoordelen.12 Ook de oppositieprocedure zou hierbij een belangrijke rol kunnen spelen. Deze procedure geeft de mogelijkheid om een octrooi te ‘dwarsbomen’. Het uitvindingsgehalte en de nieuwheid van een vinding zijn voorwaarden voor het verkrijgen van een octrooi en in een oppositieprocedure zou men het gebrek aan uitvindingsgehalte of nieuwheid kunnen inroepen. Echter, het is twijfelachtig of deelnemers aan een OSS-project een oppositieprocedure zullen starten, mede gezien de wijze waarop de meeste OSS-communities zijn georganiseerd. Een tweede risico dat vanuit octrooirechtelijk perspectief voor de deelnemers aan een OSS-project is gesignaleerd, is het volgende. Een van de deelnemers kan een bijdrage leveren waarop hijzelf vervolgens een octrooi aanvraagt. Op die manier

11

Voor meer kritische beschouwingen inzake het toekennen en toetsen van octrooien, zie J. Brinkhof, Wensen op het gebied van het octrooirecht, BIE 2003, 372. 12 Zie paragraaf 4.

62


zou deze deelnemer een exclusief recht verwerven op (een onderdeel van) de OSS. Deze bedreiging is door de meeste OSS-gemeenschappen serieus genomen en heeft geleid tot het opnemen van octrooigerelateerde clausules in OSS-licenties. Deze clausules moeten het vestigen van octrooien ontmoedigen, dan wel het toekennen van licenties op vooraf bestaande octrooien verzekeren, zodat daarmee meteen ook het eerstgenoemde probleem aan de kaak is gesteld.13 Tot slot is een interessante vraag of de ontwikkeling en uitwisseling van de broncode in het kader van een OSS-project ook daadwerkelijk inbreuk kan vormen op een softwareoctrooi. Bij een bevestigende beantwoording van de vraag zou dit daarmee uiteraard eveneens een bedreiging kunnen opleveren voor de ontwikkeling en verdere verspreiding van OSS. Alvorens de gestelde vraag te beantwoorden is enige toelichting op het octrooirechtelijke begrip ‘conclusie’ op zijn plaats. Artikel 69 van het EOV bepaalt dat de omvang van het door een octrooi verkregen recht bepaald wordt door de inhoud van de conclusies. De conclusies stellen vast waarop een octrooihouder een vermeende inbreukmaker kan aanspreken. In één zin moet een conclusie van een octrooi een nauwkeurige beschrijving van het verleende recht geven. Er kunnen hoofdzakelijk twee categorieën conclusies worden onderscheiden: apparaatconclusies en werkwijzeconclusies. In de praktijk bevat een octrooi meestal zowel apparaatconclusies als werkwijzeconclusies. Op grond van de apparaatconclusie kan een octrooihouder optreden tegen eenieder die een apparaat op de markt brengt, dat voldoet aan de beschrijving van de apparaatconclusie. Op grond van de werkwijzeconclusie kan een octrooihouder optreden tegen eenieder die de stappen zoals beschreven in de werkwijzeconclusie uitvoert. In de Verenigde Staten betogen sommigen dat de broncode überhaupt op zichzelf niet het voorwerp kan zijn van enige octrooiconclusie. Zij menen dat deze vorm niet voldoet aan de definitie van ‘computerprogramma’ in de rechtspraak, ongeacht of het nu gaat om een een apparaatconclusie, een werkwijzeconclusie dan wel een ‘manufacture claim’ of ‘Beauregard claim’ (een programmaproductconclusie, bijvoorbeeld een programma op een drager). Volgens hen heeft uitsluitend de ‘machineversie’ van software – dus de objectcode – het vereiste technische karakter om als ‘computerprogramma’ te kwalificeren zodat alleen op niveau van de objectcode sprake kan zijn van octrooibescherming en octrooi-inbreuk.14

13

D. Lin/M. Sag/R.S. Laurie, Source code versus object code: patent implications for the open source community, 18 Santa Clara Computer and High Technology Law Journal, 235, May 2002. 14 Vgl de EP Guidelines .

63


Het is de vraag of deze stelling ook opgaat in de EU-opvatting omtrent octrooien. Om te beoordelen of het uitwisselen van en het experimenteren met de broncode inbreuk maakt op een octrooi, zijn verschillende elementen relevant. Hierbij is van belang dat het experimenteren met geoctrooieerde materie zelf geen inbreukmakende handeling is. Distributie is dat wel. Bij een commercieel bedrijf zullen deze handelingen veelal gescheiden zijn. Bij de OSS-methode zijn deze beide zaken daarentegen onlosmakelijk met elkaar verbonden. Als een broncode inbreuk zou maken op een bestaand octrooi, moet allereerst worden nagegaan wat de precieze aard en omvang is van de beweerdelijk geschonden octrooiconclusie. Hierbij moet gekeken worden of het een ‘apparaat’ dan wel een ‘werkwijze’ betreft. Ook de mate waarin het computerprogramma voorwerp uitmaakt van de conclusie is van belang. Deze twee categorieën geven geen bescherming voor het programma op een drager en geven de octrooihouder dan ook niet het recht op te treden tegen verspreiding van een inbreukmakend programma als zodanig. Ten tweede moet men rekening houden met de notie van de ‘programmaproductconclusie’. Omdat op grond van apparaat- en werkwijzeconclusie een octrooihouder niet op kan treden tegen verspreiding van een inbreukmakend programma als zodanig, is het EOB er in de verleningspraktijk toe over gegaan ook een conclusie-categorie toe te staan voor een programma op een drager.15 Door deze maatregel wordt eveneens een inbreukmakend programma, bijvoorbeeld op een drager, een geoctrooieerd voortbrengsel, waartegen een octrooihouder op kan treden in overeenstemming met artikel 53 lid 1 ROW. Ten derde is aan de orde de vraag wat de definitie is van ‘een computerprogramma’ dat het voorwerp kan uitmaken van een ‘programmaproduct-conclusie’, en in het bijzonder of het onderscheid tussen broncode en objectcode daarbij relevant is. In de jurisprudentie zijn hierover nog geen duidelijke uitspraken bekend. De eerdergenoemde uitspraak T1173/97 van de Technical Board of Appeal van het EOB, waaraan ook de Guidelines refereren, zegt hierover onder andere: ‘This means that a computer program product having the potential to cause a predetermined further technical effect is, in principle, not excluded from patentability under Article 52(2) and (3).’16

15 16

64

Vgl. http://legal.european-patent-office.org/dg3/pdf/t971173ex1.pdf. Ten titel van voorbeeld verwijzen wij naar de Belgische Octrooiwet van 1984, artikel 28, §1.


Een programma in broncode heeft deze potentie. In dezelfde uitspraak wordt verder gezegd: ‘In the view of the Board, a computer program by itself is not excluded from patentability if the program, when running on a computer or loaded into a computer, brings about, or is capable of bringing about, a technical effect which goes beyond the ‘normal’ physical interactions between the program (software) and the computer (hardware) on which it is run.’

Een programma in broncode, op zich, is niet in staat een technisch effect te veroorzaken en valt dus niet onder déze omschrijving. Indien de ruime notie van computerprogramma’s toepassing gaat vinden in de handhavingspraktijk voor de beoordeling van de beschermingsomvang van een ‘programmaproduct-conclusie’, staat dit lijnrecht tegenover de eerdergenoemde Amerikaanse stelling en zal het experimenteren met broncode en de distributie hiervan aanleiding kunnen geven tot een octrooi-inbreuk. Bepaalde handelingen vormen geen inbreuk op het octrooi van de octrooihouder. De uitzonderingen op het principe van octrooi-inbreuk voor ‘handelingen in de particuliere sfeer en voor niet-commerciële doeleinden’ of ‘proefnemingen aangaande het voorwerp van de geoctrooieerde uitvinding’

zouden dienstig kunnen zijn aan de OSS-gemeenschap.17 Voor wat de eerstgenoemde uitzondering betreft: bepaalde OSS-activiteiten kunnen daaronder worden gebracht. Dit zal uiteraard niet het geval zijn voor grootschalige OSS-projecten met een duidelijke commerciële inslag. Voor wat de tweede uitzondering betreft: bij het bedrijfsmatig ontwikkelen van software hoeft nog geen rekening gehouden te worden met octrooien van derden, het ontwikkelen van software is duidelijk gescheiden van het op de markt brengen van software. In een OSS-project is het ontwikkelen van software en het verspreiden ervan onlosmakelijk met elkaar verbonden en zou een octrooihouder op kunnen treden tegen het verspreiden ervan. De OSS-gemeenschap dient dus terdege rekening te houden met de genoemde octrooirisico’s. Waakzaamheid, informatievergaring en -uitwisseling zijn daarbij van groot belang. Nu de Ontwerp Richtijn het definitief niet gehaald heeft, is het aan de nationale wetgevers en rechters om verder bij te sturen, want het is duide-

17

A.P. Meijboom, Pleidooi voor een evenwichtiger benadering van octrooien door de OS-gemeenschap, Computerrecht 2004, 31, p. 214.

65


lijk dat de discussie nog gaande is. Veel bezwaren zijn vanuit de OSS-gemeenschap naar voren gebracht tegen octrooieerbaarheid van software Maar het is tegelijkertijd wel belangrijk dat men, ook vanuit de OSS-gemeenschap, realistisch omspringt met het bestaande juridische kader. Sommige auteurs roepen dan ook terecht op tot een evenwichtige houding.18

4.3

Het octrooirecht ter ondersteuning van OSS

De discussie over OSS en octrooien wordt, zoals gezegd, overheerst door het idee dat octrooien een bedreiging vormen voor het bestaan en de verdere ontwikkeling en gebruik van OSS. In deze paragraaf zal worden ingegaan op de kansen die het octrooisysteem biedt om de positie van de OSS-beweging te versterken. Verder zal worden stilgestaan bij de mogelijkheid om met behulp van OSS de octrooiering van software te voorkomen. Om voor octrooibescherming in aanmerking te komen moet een uitvinding (i) nieuw zijn, (ii) op uitvinderswerkzaamheid berusten en (iii) toegepast kunnen worden op het gebied van de nijverheid en voorzover het software betreft dient deze een ‘technisch karakter’ of een ‘technisch effect’ te hebben. Daar komt de praktische eis bij dat de aanvrager over de financiële middelen moet beschikken om een octrooiaanvraag te kunnen financieren. Nieuwheid Om voor een octrooi in aanmerking te komen moet de OSS, net als andere uitvindingen, zoals gezegd, nieuw zijn. Met andere woorden: nog niet tot de stand van de techniek behoren. De stand van de techniek wordt onder andere gevormd door hetgeen openbaar toegankelijk is gemaakt door een schriftelijke of mondelinge beschrijving, door toepassing van een vinding en de publicatie van de inhoud van eerder ingediende octrooiaanvragen. De dag van de indiening van de aanvrage is hierbij in de regel bepalend, ongeacht waar ter wereld iets toegankelijk is geworden.19 OSS wordt veelal ontwikkeld in meer of minder georganiseerde verbanden die doorgaans via internet contact houden en hun creaties uitwisselen. Deelname aan deze verbanden staat in beginsel open voor eenieder, zolang de uitgangspunten

18

Zie over octrooirecht onder meer: L. Wichers Hoeth, Kort begrip van het intellectuele eigendomsrecht, pp. 11-75. Vgl. bijvoorbeeld The Apache Software Foundation <www.apache.org>, Mozilla.org en verschillende Linux Development Projects <www.ibiblio.org/mdw/links/devel.html>.

19

66


van de OSS-gemeenschap maar worden gerespecteerd. Juist spoedige en volledige openbaarmaking lijkt een belangrijk uitgangspunt en bovendien een drijvende kracht achter de ontwikkeling van OSS te zijn. De nieuwheidseis lijkt hiermee een belangrijk struikelblok te vormen voor het aanvragen van octrooi op OSS. Of anders gezegd, het geheimhouden van OSS is lijnrecht in tegenspraak met de OSS-gedachte. Theoretisch zou via de georganiseerde initiatieven de vereiste nieuwheid door een strikte geheimhoudingsverplichting voor de deelnemers kunnen worden gewaarborgd, maar dit lijkt in strijd met de uitgangspunten – en daarmee wellicht ook het succes – van de OSS-ontwikkeling.20 Los daarvan is het maar de vraag of deze gemeenschappen niet te groot zijn en georganiseerd genoeg zijn om bij een ongewenste of onbedoelde voortijdige publicatie een beroep te kunnen doen op ‘kennelijk misbruik ten opzichte van de aanvrager of diens rechtsvoorganger bij openbaarmaking’.21 In de Verenigde Staten is de vereiste nieuwheid in dit opzicht mogelijk een minder groot probleem. Daar bestaat een zogenaamde ‘grace period’ van één jaar.22 Dat betekent dat een publicatie van de uitvinding door de uitvinder zelf binnen één jaar voor indiening niet als stand van de techniek gebruikt mag worden tegen de ingediende octrooiaanvrage. Deze ‘grace period’ is voorbehouden aan de uitvinder (en niet aan de aanvrager). Een dergelijke ‘grace period’ is mogelijk, omdat het Amerikaanse octrooisysteem, in tegenstelling tot het Europese systeem, een ‘one and true inventor’ kent die het recht op octrooi heeft. De ‘one and true inventor’ is degene die de uitvinding het eerst geconcipieerd heeft, dat wil zeggen degene met de oudste ‘conception date’ van de uitvinding. Het voorgaande lijkt in de praktijk overigens geen belemmering voor verschillende ondernemingen die vanuit hun professie OSS op de markt brengen. Het Amerikaanse bedrijf RedHat heeft bijvoorbeeld, evenals Novell, vanuit de gedachte dat software octrooiering nu eenmaal een gegeven is, juist gekozen voor de inzet van software octrooien ter bescherming van het gebruik en de verdere ontwikkeling van OSS. RedHat verklaart op haar website, net als Novell, niet op te treden op grond van haar octrooirecht tegen partijen die ten behoeve van OSS

20 21 22

Artikel 55 lid 1 sub a EOV. 35 U.S.C. artikel 102 b. Vgl. < http://www.redhead.com/legal/patent_policy.html en http://www.novell.com/company/policies/patent/>.

67


gebruik maken van haar octrooien.23 Daarmee lijkt het octrooirecht dus juist kansen te bieden voor de ontwikkeling van OSS. Uitvinder Een ander vraagstuk dat zich opdringt bij het octrooieren van OSS is de kwestie wie het octrooi mag aanvragen. De uitvinder is degene die aanspraak heeft op een octrooi. Als hoofdregel beschouwt de Rijksoctrooiwet 1995 de aanvrager als uitvinder. Hierop zijn uitzonderingen gemaakt. Zo komt een octrooi, indien een uitvinding volgens afspraak door verscheidene personen gezamenlijk is gedaan, aan hen gezamenlijk toe. Een doelbewuste technische samenwerking lijkt hierbij voldoende. De kracht van OSS lijkt vooral de gezamenlijke ontwikkeling te zijn, waarbij eenieder gebruik kan maken van de broncode. Hierbij zijn de programmeurs veelal verenigd in verscheidene groeperingen die zijn ontstaan rond het gezamenlijk (door)ontwikkelen van OSS. Dit levert de vraag op in hoeverre deze programmeurs een mede-eigendom op een OSS-octrooi kunnen claimen.24 De Rijksoctrooiwet 1995 maakt het mogelijk dat de verschillende mede-programmeurs samen een octrooi aanvragen. Ook is denkbaar dat de verscheidene OSSgemeenschappen, universiteiten of commerciële gebruikers van OSS als aanvrager zullen fungeren.25 Op het eerste gezicht lijkt daarom de kwestie wie als uitvinder heeft te gelden geen principiële blokkade op te werpen voor octrooi op OSS. Het kan niettemin wel tot praktische problemen leiden als er bijvoorbeeld dertig ontwikkelaars zijn waarvan er vijf op de een of andere manier niet bereikbaar zijn, en er tien niet willen meedoen met een aanvraagprocedure, bijvoorbeeld vanwege de kosten of uit principe. Kosten Een laatste struikelblok dat hier wordt genoemd, betreft de relatief hoge kosten die gepaard gaan met het verkrijgen van een octrooi. Er zijn kosten verbonden aan het verkrijgen van een octrooi in de vorm van taxen. Niet alleen de indiening, het nieuwheidsonderzoek, het verleningsonderzoek en de verlening, maar ook de instandhouding van het octrooi kosten geld. Wil men een octrooi in een aantal landen aanvragen en vervolgens omstreeks 20 jaar in stand houden dan moet

23

Vgl. artikel 13 EOV. Vgl. artikel 12 EOV. 25 Vgl respectievelijk license.php> 24

68

<www.opensource.org/licenses/apache2.0.php>

en

<www.opensource.org/licenses/gpl-


rekening gehouden worden met taxen in de orde van grootte van 100.000 euro. Voor veel ontwikkelaars van OSS zal dit een te grote hindernis vormen. Zeker als het om een octrooi in meerdere landen gaat en de aanvraag geschiedt door een ‘hobbyist’. In het licht van de kosten is het van belang zich tegelijk te realiseren dat de OSSbeweging zich steeds verder lijkt te professionaliseren. Rond deze vorm van softwareontwikkeling ontstaan nieuwe opbrengstmodellen. Hierbij kan bijvoorbeeld gedacht worden aan de eerdergenoemde bedrijven RedHat en Novell, maar ook ondernemingen zoals Mandrake en Suse. Genoemde partijen hebben hun businessmodel (volledig) gebaseerd op OSS. De praktijk heeft inmiddels aangetoond dat deze partijen in de positie verkeren om software octrooien te financieren. Mogelijkheid om met behulp van OSS-octrooiering te voorkomen De OSS-beweging beschouwt octrooien als een bedreiging voor OSS. Door het aantasten van de nieuwheidseis heeft zij echter goede mogelijkheden om de octrooiering van software te voorkomen. Ook voor aanbieders van closed source software geldt immers dat iedere voorgaande openbaarmaking in beginsel de voor een succesvolle octrooiaanvraag vereiste nieuwheid schaadt. De snelle, grootschalige en laagdrempelige ontwikkeling van OSS lijkt een reëel gevaar voor aanbieders van closed source software die een octrooi wensen aan te vragen. Iedere publicatie, op internet of anderszins, die de softwarevinding openbaar maakt, tast de voor een octrooi vereiste nieuwheid aan. Niet alle publicaties door OSS-gemeenschappen lijken er overigens aan in de weg te staan dat een professioneel georganiseerde closed source softwareontwikkelaar octrooien kan verkrijgen. De grote versnippering van OSS-ontwikkeling lijkt het immers onmogelijk te maken alle publicaties te beoordelen die aan de nieuwheidseis in de weg zouden kunnen staan. Een niet nieuwe aanvraag of toekenning kan door de rechter nietig worden verklaard. Praktisch zal hiervoor wel de vaak vluchtige internet informatie achterhaald moeten kunnen worden en de betrouwbaarheid zal voldoende aangetoond moeten kunnen worden. De verdere professionalisering van de OSS-beweging zal mogelijk stimuleren dat dit ook daadwerkelijk gebeurt. Een ander wapen dat – voornamelijk uit defensief oogpunt – haar opwachting heeft gemaakt, betreft de opbouw van een octrooiportefeuille door professionele (lees: over de vereiste kennis en kapitaal beschikkende) aanbieders van OSS. Hierover werden in dat licht al de stappen genoemd die RedHat en Novell op dit gebied hebben ondernomen. Dit wapen kan zich overigens ook tegen de OSSontwikkeling keren, indien door bijvoorbeeld overdracht deze rechten in de han-

69


den van andere partijen komen. RedHat en Novell kunnen bovendien onverhoopt failliet gaan, waarbij de boedel verkocht wordt aan een partij die zich niet aan de toezegging van RedHat en Novell op dit vlak gehouden acht. Het is de vraag of de eenzijdige verbintenis van RedHat en Novell niet op te treden tegen partijen die ten behoeve van OSS gebruik maken van hun octrooien door een opvolgende verkrijger van het (absolute) octrooirecht dient te worden gerespecteerd. Het voorkomen van geldige software-octrooien door aanbieders van OSS-software lijkt overigens nog niet de voornaamste reden voor aanbieders van OSS om zelf een octrooi aan te vragen. Belangrijker lijkt de opbouw van een waardevolle octrooiportefeuille, die – mits de goede bedoelingen van de aanbieder oprecht zijn en blijven – kan worden ingezet om onder gunstige condities licenties te verwerven op strategische octrooien van closed source software aanbieders. Risico hiervan is wel dat de OSS ‘besmet’ raakt met closed source software. Dit laat onverlet dat het eenmaal geconfronteerd met een mogelijke octrooi-inbreuk de onderhandelingspositie van de OSS-aanbieder kan versterken.

4.4

‘Octrooiparagrafen’ in OSS-licenties

In het algemeen geldt dat, indien men handelingen wil verrichten die zijn voorbehouden aan een octrooihouder, men toestemming behoeft van de octrooihouder. Artikel 56 ROW 1995 geeft enkele algemene regels voor licenties onder octrooien. Thans zal hier vanuit octrooirechtelijk perspectief nog worden ingegaan op twee licentievormen die bij OSS regelmatig worden gebruikt, te weten de Apache license v 2.0 en GNU General Public License (GPL).26 In deze licenties wordt, zoals eerder aangegeven, gepoogd de effecten van octrooien op een vrije verspreiding en een vrij gebruik van OSS te ondervangen. De Apache software wordt beschikbaar gesteld onder de Apache license v2.0. De Apache Foundation is in dit geval de licentiegever. De verkrijger, degene die het programma gedownload heeft, is de licentienemer en zal zich moeten houden aan de voorwaarden van de licentie. Degene die een bijdrage levert aan de Apache Software is een zogenaamde ‘contributor’. Een contributor levert een bijdrage onder een Contributors License Agreement.27 De Apache license v 2.0 stelt dat

26

Vgl. artikel 3 van de Individual Contributor License Agreements, artikel 4 van de Corporate Contributor License Agreements, artikel 1.b van de Software Grant Agreements; zie www.apache.org/licenses). 27 Deze open source databanken zijn te vinden op respectievelijk: ; en .

70


de door een ‘contributor’ verstrekte octrooilicentie onder andere royalty-free is en zich uitstrekt tot die octrooiconclusies, die noodzakelijkerwijze geschonden worden door zijn bijdrage alleen of in combinatie met het OSS-programma waaraan bijgedragen wordt. Tevens wordt gesteld dat indien de licentienemer een inbreukzaak aanspant tegen wie dan ook op basis van het OSS-programma, al de aan hem verleende licenties onder octrooien vervallen per de datum waarop de inbreukzaak ingediend wordt. In de overeenkomst met de licentienemer kan de licentiegever degenen die ook hebben bijgedragen aan de software, de zogenaamde ‘contributors’, niet binden. De aard en omvang van dat risico wordt in belangrijke mate bepaald door de octrooibepalingen in de bovengenoemde Contributors License Agreement. De gebruiker loopt overigens ondanks de licentie die hij krijgt op grond van de Apache license v 2.0 nog steeds het risico dat hij door de combinatie van de aldus gelicentieerde software met andere software of andere producten of werkwijzen een breder octrooi van een derde schendt. Een ander probleem waar de gebruiker mee blijft zitten, is dat de licentie wel mooi is opgeschreven, maar dat, als die licentie bij nader inzien niet blijkt te kloppen (bijvoorbeeld omdat de licenties en andere verklaringen van de contributors niet afdoende blijken te zijn) geen verhaal op de licentiegever mogelijk is, zo lezen we in artikelen 7 en 8 (respectievelijk ‘Disclaimer of Warranty’ en ‘Limitation of Liability’), bepalingen die overigens niet ongebruikelijk zijn in een licentie die om niet verstrekt wordt. De GNU GPL bevat in de preambule en voorts in onder meer de artikelen 6 en 7 bepalingen over octrooien. In de preambule staat: ‘We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone’s free use or not licensed at all’.

In lijn hier mee bepaalt artikel 6: ‘You may not impose any further restrictions on the recipients’ exercise of the rights granted herein’.

Op grond daarvan verbindt de licentienemer zich geen octrooi aan te vragen op de betreffende OSS, of, als hij dat wel doet, zijn octrooirecht niet in te roepen tegen degenen die van hem direct of indirect de OSS verkrijgen. Artikel 7 verbiedt de verdere distributie van OSS indien de licentienemer niet kan toezeggen dat degenen die van hem direct of indirect de OSS zullen verkrijgen niet getroffen kunnen worden door een octrooi. 71


Samenvattend kan gesteld worden dat door in OSS-licenties voorwaarden op te nemen ten aanzien van octrooien, rekening wordt gehouden met octrooien en het octrooisysteem en gepoogd wordt vrije uitwisseling en toepassing van OSS te waarborgen.

4.5

Tot slot

Dit hoofdstuk stelde de relatie tussen OSS en het octrooirecht aan de orde. De OSS-beweging streeft een vrij gebruik van software na, terwijl het octrooirecht juist voorziet in een tijdelijk monopolie op een uitvinding en dat geldt dus ook voor een octrooi op software. De belangen van octrooihouders en van voorstanders van OSS lijken dus tegengesteld te zijn. Enerzijds kan het octrooisysteem de vrije ontwikkeling en distributie van OSS belemmeren. Zo is het niet denkbeeldig dat een OSS-project stuit op een bestaand octrooi en daardoor wordt geblokkeerd. Hierbij is het maar de vraag of het een geldig octrooi betreft, want er zijn vermoedens dat er mogelijk grote aantallen ongeldige software octrooien bestaan. Een reële bedreiging zou ook de ‘programmaproduct-claim’ kunnen zijn, voorzover deze de uitwisseling van broncode in het kader van een OSS-project zou kunnen verhinderen. Anderzijds kan de OSS-gemeenschap het octrooirecht ook gebruiken om haar positie te versterken, door te proberen zelf octrooien te verkrijgen. De nieuwheidseis lijkt hier een belangrijk struikelblok te vormen: het geheimhouden van OSS is een directe bedreiging voor haar huidige succes. Dit alles weerhoudt professionele aanbieders van OSS er niet van octrooien aan te vragen en een octrooiportefeuille op te bouwen welke strategisch ingezet kan worden. De grootste kracht van de OSS-beweging is echter uiteindelijk toch gelegen in de betrachte openbaarheid: iedere publicatie, op internet of anderszins, die een softwarevinding openbaar maakt, maakt het onmogelijk dat wie dan ook deze softwarevinding daarna nog kan octrooieren.

72

5

Databankenrecht en open source databanken (OSD’s) F. van Eeckhoutte, L. Guibault en P. Terporten

Naast open source software zijn op internet ook databanken te vinden die, evenals open source software, vrij toegankelijk zijn en waarbij vermeld wordt dat het gebruik van de databank in zekere zin vrij is. Soms wordt het publiek uitgenodigd om bijdragen te leveren aan de verdere bouw van de databank. In dit hoofdstuk komt aan de orde in hoeverre de creatie van zo’n databank, die ook wel – naar analogie van de open source software – open source databank wordt genoemd, databankenrecht doet ontstaan, en hoe vrij het publiek eigenlijk is bij het gebruik van een dergelijke databank.

5.1

Inleiding

Al geruime tijd zijn op internet databanken beschikbaar die vrij toegankelijk zijn en waarvan het gebruik min of meer vrij is. Soms wordt het publiek ook uitgenodigd om bijdragen te leveren aan de verdere bouw van de databank. Voorbeelden van dergelijke ‘open source databanken’ zijn de zogenaamde wiki’s. De term wiki staat voor een verzameling van gegevenselementen waaraan gebruikers gegevenselementen kunnen toevoegen, en waarvan gebruikers de gegevenselementen kunnen wijzigen. Voorbeelden van wiki’s zijn onder meer: de Wikipedia (een encyclopedie in meer dan 50 talen), de Wiktionary (een woordenboek), en de Wikisource (een verzameling teksten).1 Al deze databanken worden gefaciliteerd door de Wikimedia Foundation uit Florida (VS). Het voor het creëren en het gebruiken van deze open source databanken toegepaste programma is MediaWiki, een vorm van groupware.2 De ontwikkeling van MediaWiki wordt eveneens gefaciliteerd door de Wikimedia Foundation. MediaWiki is – hoe kan het ook anders – open source software, beschikbaar onder de GNU General Public License (GNU GPL). Met MediaWiki kan ieder die dat wil, de ontwikkeling van een wiki faciliteren. De inhoud van de wiki’s van de Wikimedia Founda-

1

Het gaat hier niet alleen om de database engine, maar ook om de web interface, gezamenlijk ook wel de wiki engine, of kortweg – ook – wiki, genoemd. 2 Vgl. .

73


tion wordt beschikbaar gesteld onder GNU Free Documentation License (GNU FDL of kortweg GFDL).3 Naast MediaWiki bestaan er vele andere wiki engines, al dan niet implementaties van MediaWiki. Verder zijn er ook andere open source database engines, zoals MySQL. Nog weer andere voorbeelden van via het internet toegankelijke open source databanken zijn: De digitale bibliotheek voor de Nederlandse letteren, Gallica, Project Laurens Jz Coster, en de Nederlandse Volksverhalenbank.4 Verder kan de zogenaamde repository van een open source software project ook als een open source databank worden beschouwd.5 Een bijzondere categorie van databanken met een min of meer open karakter bestaat ten slotte uit databanken die naast of als onderdeel van OSS gebruikt worden, zoals de thesauri en de verzamelingen grammaticaregels bij spellingcontroleprogramma’s, en software libraries. Met software library wordt doorgaans aangeduid een verzameling subroutines die min of meer zelfstandig bestaan naast – of als onderdeel van – een computerprogramma. Een zekere ordening is per definitie aanwezig omdat de subroutines door het programma moeten kunnen worden aangeroepen. Voor veel van de hierboven genoemde online databanken geldt dat deze – onder bepaalde voorwaarden – vrij gebruikt en hergebruikt mogen worden. Dat geldt echter ook voor de meeste ‘proprietary’ databanken (‘closed source databanken’). Het is niet eenvoudig om een scherp omlijnde definitie van een OSD te verschaffen. We zullen met de term open source databank(en) of OSD (in meervoud OSD’s) die (elektronische) gegevensverzamelingen aanduiden waarbij – naar analogie van de open source software – de absolute rechten van de makers worden aangewend om aanvulling en verbetering en gebruik door het publiek, en verspreiding onder het publiek te bevorderen. De open source aspecten bij databanken komen er dus op neer dat dergelijke databanken, anders dan traditionele (online) databanken, vrijelijk voor een ieder toegankelijk zijn, vrijelijk te gebruiken zijn, en dat hergebruik van zoekresultaten in vergaande mate is toegestaan.6 Bovendien

3

Vgl. respectievelijk: ; ; ; en . 4 Een repository is een plaats op internet waar een verzameling materiaal (programma’s, programma-onderdelen, procedures, etc.) staat. De website is een voorbeeld van een heel grote verzameling van repositories met open source software. 5 Vgl. Jaeger en Metzger, die in het kader van de auteursrechtelijke behandeling van ‘Open Content’ als wezenlijke kenmerken van Open Content beschouwen ‘dass jedermann lizenzgebührenfrei Nutzungsrechte an dem Werk verschafft und dem Lizenznehmer weitergehende Nutzungsrechte eingeräumt werden, als zur bloßen Benutzung des Werks erforderlich sind’ (T. Jaeger/ A., Metzger.: Open Content – Lizenzen nach deutschem Recht, MMR 7/2003 p. 431). 6 Respectievelijk , en .

74

Databankenrecht en open source databanken (OSD’s)

kan het publiek de databanken – al dan niet middels een soort van redactie – aanvullen, verbeteren, of anderszins wijzigen. Geen OSD’s in deze zin zijn bijvoorbeeld de diverse veilingsites. Dat zijn wel databanken, en ze worden door het publiek gevuld, en ze kunnen vrijelijk geraadpleegd worden, maar de databankeigenaren staan bepaald niet toe dat zoekresultaten vrijelijk hergebruikt worden. Evenmin zijn OSD’s in deze zin de via het internet toegankelijke databanken waarvan het gebruik en hergebruik niet uitdrukkelijk vrijgegeven is. Voorbeelden daarvan zijn: het internet zelf, Lycaeus Juridisch Woordenboek, Lycaeus Economisch Woordenboek en de Encyclopædia Britannica.7 Een scherpe definitie van een OSD is in het kader van dit hoofdstuk overigens ook niet zozeer van belang. Het gaat hier voornamelijk om de vraag of een databank – die op een of andere wijze een open karakter heeft – kwalificeert als databank onder de Databankenwet. Bij die vraag komen de diverse aspecten van het open karakter vanzelf aan de orde. Ten behoeve van de rechtsbescherming van databanken dient onderscheid te worden gemaakt tussen (a) de data elementen, (b) de structuur van de verzameling van de data elementen, en (c) de voor het vullen, doorzoeken, en wijzigen van de databank, en voor het presenteren van zoekresultaten benodigde programmatuur. In dit hoofdstuk komen de eventuele intellectuele eigendomsrechten op de data elementen (sub a) niet aan de orde. De intellectuele eigendomsrechten op de databankprogrammatuur (sub c) – als gezegd vaak OSS – komen hier evenmin aan de orde (daarop is volgens artikel 1.3 Databankenwet het auteursrecht van toepassing). Databanken, dus ook OSD, die aan de criteria van de Databankenwet voldoen, komen in aanmerking voor bescherming onder het databankenrecht. Voordat de databankenrichtlijn8 was geïmplementeerd waren makers van databanken voor rechtsbescherming in Nederland aangewezen op het auteursrecht – daaronder begrepen de geschriftenbescherming – en het recht inzake de onrechtmatige daad. Nederland heeft de Databankenrichtlijn deels geïmplementeerd door aanpassing van de bestaande Auteurswet 1912, en deels door de vaststelling van de nieuwe Databankenwet. De Databankenwet9, onlangs nog aangepast ter uitvoering van de Richtlijn inzake auteursrecht en naburige rechten in de informatiemaatschappij10, creëert voor de maker van een databank onder bepaalde voor-

7

Richtlijn 96/9. Stb. 1999, 303. 9 Aanpassingswet Auteurswet 1912, enz. ter uitvoering van de Richtlijn 2001/29/EG van het Europees Parlement en de Raad van de Europese Unie inzake auteursrecht en naburige rechten in de informatiemaatschappij, Stb. 2004, 336. 10 Vgl. P.B. Hugenholtz, ‘Het wetsvoorstel implementatie databankrichtlijn’, IER 1998/6, p. 244. 8

75


waarden een sui generis recht: het databankenrecht. Het is een nieuwe loot aan de stam van het intellectuele eigendomsrecht. In dit hoofdstuk wordt de uitdaging aangenomen om dat nieuwe databankenrecht toe te passen op een nog nieuwer verschijnsel, dat van de OSD. Hiertoe is ook alle reden omdat er steeds meer OSD’s komen, waardoor het economische belang daarvan toeneemt. In dit hoofdstuk wordt voornamelijk het databankenrecht onder de loep genomen. Summierlijk wordt tevens ingegaan op de auteursrechtelijke bescherming en de geschriftenbescherming van open source databanken. Verder wordt ook aandacht besteed aan de positie van de rechthebbende en van diens exclusieve rechten. Ten slotte komt de positie van de gebruiker aan de orde, en worden de licenties GFDL (GNU Free Documentation License) en CCPL (Creative Commons Public License) besproken. De kwaliteit en de betrouwbaarheid van de wiki’s en de andere open source databanken is natuurlijk een punt van zorg, maar daar zullen we niet verder op ingaan. Wel behandelen we nog enkele niet-databankenrechtelijke rechten en plichten van de producent ten aanzien van ‘zijn’ open source databank.

5.2

De databank in de zin van de Auteurswet 1912 en van de Databankenwet

Er zijn in beginsel drie verschillende beschermingsregimes voor databanken in Nederland, die ook van toepassing zijn op OSD’s: 1 bescherming onder het auteursrecht, voor databanken die een oorspronkelijk karakter vertonen; 2 bescherming onder het sui generis regime van de Databankenwet voor databanken die aan de definitie en vereisten uit de Databankenwet voldoen;11 en 3 bescherming onder de (oude) geschriftenbescherming voor niet-oorspronkelijke databanken, die evenmin voldoen aan het vereiste van substantiële investering. De drie beschermingsregimes worden hierna nader uitgelegd. Een databank is in beginsel vatbaar voor bescherming onder de Auteurswet indien deze door de samenstelling, de selectie en arrangement van het geheel een eigen karakter heeft en het persoonlijk stempel van de maker draagt. Hetzelfde geldt ten aanzien van de afzonderlijke elementen van de databank. Een databank,

11

76

HR 29 november 1985, NJ 1987, 880 (Van Dale/Romme).


zoals de Wikipedia of de Wikisource, zou in zijn geheel als een auteursrechtelijke beschermde werk kunnen worden beschouwd; de selectie en het arrangement van de elementen die deel uitmaken van deze twee databanken voldoen ons inziens aan het criterium van oorspronkelijkheid. Op grond van de bestaande jurisprudentie zou de Wiktionary waarschijnlijk niet aan het criterium van oorspronkelijkheid voldoen omdat een verzameling van een hoeveelheid feitelijke gegevens als zodanig voor auteursrechtelijke bescherming niet in aanmerking komt.12 De auteursrechtelijke bescherming van databanken past in de lange auteursrechtelijke traditie. Mede omdat elders in dit preadvies het auteursrecht uitgebreid aan de orde komt als het gaat om de bescherming van OSS, wordt in dit hoofdstuk dit aspect van de auteursrechtelijke bescherming van databanken niet verder uitgewerkt. Naast de traditionele auteursrechtelijke bescherming bestaat er in Nederland sinds 1998 een sui generis regime voor de juridische bescherming van databanken. De Databankenwet omschrijft in artikel 1 onder a een databank als een verzameling van werken, gegevens of andere zelfstandige elementen die systematisch of methodisch geordend en afzonderlijk met elektronische middelen of anderszins toegankelijk zijn en waarvan de verkrijging, de controle of de presentatie van de inhoud in kwalitatief of kwantitatief opzicht getuigt van een substantiële investering. Het moet gaan om verzamelingen van werken, gegevens of andere zelfstandige elementen. De zelfstandigheid van de gegevens is aldus een belangrijk criterium in de definitie van een databank.13 De zelfstandige elementen van een verzameling moeten daarnaast systematisch of methodisch geordend zijn. Met het vereiste dat de elementen afzonderlijk toegankelijk dienen te zijn, wordt bedoeld dat de verschillende onderdelen van de databank – werken, gegevens of andere elementen – per stuk kunnen worden opgevraagd.14 Een verzameling geldt alleen als databank in de zin van de Databankenwet als het getuigt van een substantiële investering in de verkrijging, de controle of de presentatie van de inhoud, in kwalitatief of kwantitatief opzicht. Een investering kan behalve in geld

12

P.B. Hugenholtz, De databankenrichtlijn eindelijk aanvaard: een zeer kritisch commentaar, Computerrecht 1996, p. 131-132; T. Kolle, in: J.E.J. Prins et al., Recht en Informatietechnologie – Handboek voor Rechtspraktijk en Beleid, Den Haag 1999, hoofdstuk 7J, p. 4. 13 Zie: F.J. van Eeckhoutte, Afzonderlijke toegankelijkheid van niet-elektronische databanken, Noot bij Hof Leeuwarden, 27 november 2002, te raadplegen op:. 14 HR 22 maart 2002 (NVM/Telegraaf), met noot van D.J.G. Visser, AMI 2002, 88-104; Nederlandse Mededingingsautoriteit (NMa) 10 september 1998, zaak 1 (Telegraaf / NOS), met noot van P.B. Hugenholtz Mediaforum 1998/10, 304.

77


ook bestaan in tijd, moeite en energie. Waaraan men bij een ‘substantiële investering’ moet denken is aan de rechter overgelaten.15 Het Europese Hof heeft geoordeeld dat onder het begrip substantiële investering, bepalend voor de bescherming van de fabrikant van een databank, slechts het opzoeken, verzamelen, controleren en presenteren van bestaande gegevens valt, en niet de middelen die zijn gebruikt voor het creëren van de gegevens die samen de databank vormen.16 Dit betekent dat de investeringen die de producent van een databank heeft gedaan in het creëren van de elementen in het kader van zijn hoofdactiviteit niet mogen meetellen voor de vereiste investeringen in de met die elementen op te bouwen databank, als het opstellen van de databank niet ook tot de hoofdactiviteit van de maker behoort. Open source databanken, zoals de Wikipedia, Wiktionary en Wikisource, zouden onder de definitie van een databank kunnen vallen. De elementen daarvan zijn naar alle waarschijnlijkheid systematisch of methodisch geordend. Maar ook hier is vereist dat het verkrijgen, controleren en presenteren daarvan getuigt van een substantiële investering, anders dan als voortvloeisel van een hoofdactiviteit. Die investering kan overigens zeer wel betrekking hebben op het beschikbaar maken en houden van de technische en organisatorische infrastructuur. Maar waaruit bestaat de substantiële investering van de producent nog meer, als zijn databank zich buiten hem om vult? Het is maar de vraag of er dan überhaupt sprake is van een substantiële investering. Het zou in strijd zijn met een basisprincipe van de intellectuele eigendomsrechten, indien zou kunnen worden opgetreden tegen gebruik van informatie voor de totstandkoming waarvan men (zelf) geen kosten heeft gemaakt.17 In de zaak van El Cheapo besliste het Hof dat de NVM geen substantiële investering had verricht bij het opzetten van de databank. Alle huizengegevens waren immers al verzameld voor gebruik door de makelaars die aangesloten waren bij de NVM. Die gegevens dan op internet zetten vergde dan nauwelijks nog een investering.18 Dit werd bevestigd door het Europese Hof van

15

Hof van Justitie in de zaken C-46/02, C-203/02, C-338/02 en C-444/02 (Fixtures Marketing Ltd / Oy Veikkaus Ab, The British Horseracing Board Ltd e.a. / William Hill Organization Ltd, Fixtures Marketing Ltd / Svenska Spel AB, Fixtures Marketing Ltd /Organismos prognostikon agonon podosfairou AE (OPAP)), 9 november 2004. 16 Zie de noot van K.J. Koelman bij Vzr Rb Groningen 18 juli 2002 (Wegener/Hunter Select): (). 17 Zie Vzr Rb Den Haag, 12 september 2000 NVM/De Telegraaf, met noot van M. van Eechoud (). Dit arrest werd door de Hoge Raad gepasseerd op grond van de spin-off theorie (HR, 22 maart 2002 LJN AD9138). 18 Arrest van het Hof van Justitie in de zaak C-46/02 (Fixtures Marketing) (HvJEG); noch de verkrijging, noch de controle of de presentatie van de inhoud van een kalender voor voetbalwedstrijden of paardenrennen getuigt van een substantiële investering die moet worden beschermd tegen het gebruik van gegevens door derden, aldus het Europese Hof van Justitie.

78


Justitie.19 Of in de praktijk een OSD aan de criteria van de Databankenwet voldoet hangt dus eigenlijk van de feiten af. Naast de gebruikelijke OSD’s, die door een combinatie van teksten, beelden, en geluiden worden samengesteld, rijst de vraag of een software ‘library’ onder de definitie van databank in de wettelijke zin kan vallen. Een software ‘library’ is een verzameling van subprogramma’s die voor de ontwikkeling van andere programma’s worden gebruikt. De elementen van de library zijn niet altijd zelfstandig executeerbaar, maar dat neemt niet weg dat ze zelfstandige elementen van een databank in de zin van de Databankenwet kunnen zijn. Een ‘software library’ lijkt dus te kunnen voldoen aan het vereiste dat sprake moet zijn van een verzameling van ‘zelfstandige elementen die systematisch of methodisch geordend en afzonderlijk met elektronische middelen of anderszins toegankelijk zijn’ moet zijn. En, in navolging van het Europese Hof, sluit de omstandigheid dat de samensteller van de databank tevens degene is die de in deze databank opgenomen elementen heeft gecreëerd, niet per definitie uit dat zijn databank door het sui generis recht kan worden beschermd, op voorwaarde dat hij aantoont dat de verkrijging van deze elementen of de controle dan wel de presentatie daarvan, een substantiële investering heeft gevergd, los van het creëren van deze elementen.20 Het is duidelijk dat de hulpcodes van een software library systematisch of methodisch zijn geordend, maar het is wel de vraag of het verkrijgen, controleren en presenteren daarvan getuigt van een substantiële investering anders dan als spin-off van het hoofdactiviteit van de maker, met name het maken van een software programma. Op grond van zijn databankenrecht kan de producent optreden tegen een gebruiker die bijvoorbeeld een eigen website met zoekscherm bouwt waarmee in de databank gezocht kan worden. Dat geldt echter doorgaans niet voor producenten van een OSD. Bij een OSD is het nu juist doorgaans expliciet toegestaan om een deel van de databank op te vragen en zelfs te distribueren (lees: hergebruiken), zij het dat daaraan meestal licentievoorwaarden verbonden zullen zijn. Het prerogatief van de producent van de OSD beperkt zich dan tot het aanpassen van de licentievoorwaarden en het in en buiten rechte aanspreken van diegenen die en met (een gedeelte van) de OSD opereren zonder respectering van de overeenkomst (lees: licentievoorwaarden). In dat geval is de producent de enige belanghebbende die tegen inbreukmakers op het databankenrecht kan

19

Hof van Justitie in de zaken C-46/02, C-203/02, C-338/02 en C-444/02, 9 november 2004. Dit laat onverlet dat ook auteurs kunnen optreden tegen inbreukmakers op hun auteursrecht, zelfs al komen hun werken voor in een OSD. De OSD impliceert immers niet dat op de daarin opgeslagen werken geen auteursrecht meer rust.

20

79


optreden.21 Het databankenrecht en licenties komen in de navolgende paragrafen uitgebreider aan de orde. Ook al draagt een databank niet het persoonlijk stempel van de maker en voldoet deze niet aan het criterium van substantiële investering, dan is deze databank in Nederland mogelijk toch vatbaar voor bescherming, en wel onder het regime van de geschriftenbescherming. Dit op grond van artikel 10 lid onder 1 van de Auteurswet.22 De geschriftenbescherming is geen ‘gewone’ auteursrechtelijke bescherming, maar een ‘pseudo-auteursrechtelijke’ bescherming die toekomt aan de opsteller van een ‘geschrift’.23 Bescherming wordt op grond van de rechtspraak verleend voorzover het geschrift openbaar is gemaakt of bestemd is om te worden openbaar gemaakt. In de Televizier-zaak is uitgemaakt dat het niet van belang voor bescherming in Nederland of de betrokken geschriften (uitsluitend) voor openbaarmaking in het buitenland zijn bestemd.24 De omvang van de geschriftenbescherming is veel beperkter dan die van de reguliere auteursrechtelijke bescherming: de opsteller van een geschrift kan zich alleen verzetten tegen klakkeloze nadruk. Dus ook OSD’s die geen persoonlijk stempel van de maker dragen en die evenmin aan het criterium van substantiële investering voldoen, kunnen bescherming krijgen onder de geschriftenbescherming. Bij een OSD is het echter doorgaans expliciet is toegestaan een deel van de databank op te vragen en te hergebruiken, zij het dat daaraan meestal licentievoorwaarden verbonden zullen zijn. Daarom zal ook hier, net als bij het databankenrecht, de rol van de producent van de OSD doorgaans beperkt zijn tot het aanpassen van de licentievoorwaarden en het in en buiten rechte aanspreken van diegenen die de licentievoorwaarden niet nakomen. De eerste twee hierboven behandelde beschermingsregimes laten zich niet cumuleren ten aanzien van hetzelfde object. Dit is uitdrukkelijk vastgelegd in artikel 10 lid 4 Auteurswet. Of een databank die getuigt van een substantiële investering naast databankenrecht ook geschriftenbescherming geniet, is afhankelijk van de vraag of geschriftenbescherming als auteursrecht in de zin van artikel 10 lid 4 Auteurswet geldt. Spoor/Verkade/Visser beantwoorden deze vraag bevestigend.25

21

Ook al veronderstellen Spoor/Verkade/Visser dat ‘geschriftenbescherming [voor databanken] had moeten worden afgeschaft toen de Databankenrichtlijn werd geïmplementeerd’. Vgl. J.H. Spoor/ D.W.F. Verkade/D.J.G. Visser, Auteursrecht, Deventer, 2005, p. 639. 22 J.H. Spoor,/D.W.F. Verkade/D.J.G. Visser, Auteursrecht, Deventer 2005, p. 81. 23 HR 25 juni 1965, NJ 1966, 116 (Radioprogramma III of Televizier). 24 J.H. Spoor/ D.W.F. Verkade/D.J.G. Visser, Auteursrecht, Deventer 2005, p. 609 (tabel) en p. 639. 25 Artikel 7 Databankenwet.

80


5.3

De rechthebbende op het databankenrecht

Op grond van de Databankenwet is de rechthebbende op een databank de producent daarvan.26 Als producent wordt beschouwd degene die het risico draagt van de voor de databank te maken investering. Hoewel het niet is uitgesloten dat producent en maker van een databank in eenzelfde persoon zijn vertegenwoordigd27, zullen meestal meerdere partijen bij de totstandkoming van een databank betrokken zijn, in welk geval de producent de rechthebbende is. We moeten hierbij indachtig zijn dat, gelet op artikel 7 Databankenwet, de in artikel 2 Databankenwet beschreven rechten toekomen aan de producent van de databank of zijn rechtverkrijgende ‘die onderdaan is van of zijn gewone verblijfplaats heeft op het grondgebied van een lidstaat van de Europese Unie of van een staat die partij is bij de Overeenkomst betreffende de Europese Economische Ruimte van 2 mei 1992’ of komt uit een ander land waarmee de EU een verdrag inzake databankenrecht heeft gesloten. Voor een producent die rechtspersoon is, gelden soortgelijke eisen. Aan een in Florida (VS) gevestigde producent van wikiís komt dus, bij gebreke van een verdrag als in artikel 7 Databankenwet bedoeld, het sui generis recht op grond van de Europese regelgeving niet toe. Van de databankenrechtelijke rechten op de databank is ook de openbare macht uitgezonderd indien het gaat om databanken waarvan zij producent is en waarvan de inhoud bestaat uit ‘openbaar eigendom’ zoals wetten, besluiten, verordeningen maar ook gerechtelijke uitspraken.28 Verder is het databankenrecht niet van toepassing op databanken waarvan de openbare macht de producent is en die andere informatie dan regelgeving en jurisprudentie bevat, tenzij het recht hetzij in het algemeen bij de wet, besluit of verordening, hetzij in een bepaald geval blijkens mededeling op de databank zelf of bij de terbeschikkingstelling aan het publiek van de databank uitdrukkelijk is voorbehouden.29

26

Zie ter illustratie Woordenboek Juridische Terminologie en Politiejargon van Jaap van der Wijk op . 27 Artikel 8 lid 1 Databankenwet. 28 Artikel 8 lid 2 Databankenwet. 29 Hier valt een verwijzing te maken naar de zaak Vermande/Bojkovski van 20 maart 1998, waarin de voorzieningenrechter overwoog: ‘Het valt evenwel niet zonder meer in te zien waarom een particuliere producent van een wettendatabank de reguliere databankbescherming zou moeten ontberen, terwijl voor het tot stand brengen van een dergelijke databank aanzienlijke investeringen vereist zijn, die noodzakelijk zijn geworden omdat de overheid volstaat met de uitgifte van Staatsbladen en soortgelijke publicaties waarin wetswijzigingen zijn opgenomen, zonder (anders dan bij uitzondering) – gecompileerde, doorlopende teksten van de geldende wetten beschikbaar te stellen.’ ().

81


Databanken bestaan bij de gratie van hun streven naar volledigheid op de door hen bestreken onderwerpen. Databanken die verre van compleet zijn, zullen door gebruikers laag worden gewaardeerd en zijn in dat geval geen lang leven beschoren. In ieder geval hebben zij weinig tot geen commerciële potentie. Producenten zullen er daarom steeds naar streven om zo compleet mogelijke databanken op de markt te zetten, waarbij het voor zich kan spreken dat zij alle bijdragen ter aanvulling van de databank welkom heten. De groei van een OSD komt niet of nauwelijks door de bijdrage van de producent, maar juist door de vele duizenden gebruikers die al dan niet sporadisch een bijdrage aan de databank leveren. In dat opzicht lijkt de taak van de producent c.q. de substantiële investering uitgehold, zij het dat de producent in de meeste gevallen de inhoud van de OSD onder toezicht zal zetten van een eindredacteur, al was het maar om het kaf van het koren te scheiden. Bovendien zal met de software van de producent altijd een geautomatiseerde of semi-geautomatiseerde classificering, ordening en opvraagbaarheid van de gegevens mogelijk gemaakt worden. Die software zal de producent ofwel hebben gekocht ofwel zelf hebben ontwikkeld, waaruit blijkt dat het hem feitelijk tijd, moeite en/of geld heeft gekost.30 Andere middelen waarin geïnvesteerd moet worden zijn de benodigde hardware en de communicatielijnen. Er kan sprake zijn van een databank in de zin van de Databankenwet, ook al heeft de producent er, behalve het ter beschikking stellen van een webadres, software, etc. en een eindredacteur, de inhoud van de databank niet zelf gemaakt. Illustraties van dergelijke databanken zijn legio.31 De investering in het maken van de inhoud van de OSD telt overigens sowieso niet mee bij de beantwoording van de vraag of sprake is van een substantiële investering indien het maken van de inhoud tot de hoofdactiviteit van de producent behoort en de publicatie van de database een nevenactiviteit is.32 In theorie kan de functie van de producent worden teruggebracht tot diegene die voor het welslagen of de ondergang van de databank het financiële risico loopt. Immers, de ontwikkeling van software en het laten draaien van de machineversies daarvan kan de producent volledig outsourcen. Als dan de producent zijn databank laat vullen met ingekocht materiaal of bijdragen in het kader van zijn

30

Het gaat dan met name om allerlei veilingsites, en marktplaatsen zoals www.marktplaats.nl, www.ebay.nl, www.marktnet.nl, die beslist als databanken zijn te beschouwen en bestaan bij de gratie van de bijdragen die de diverse aanbieders, kopers en verkopers leveren. Dergelijke databanken zijn overigens doorgaans geen OSD’s. 31 Zie de reeds aangehaalde arresten van het Hof van Justitie van 9 november 2004. 32 Artikel 6 lid 1 respectievelijk lid 2 Databankenwet.

82


open source systeem schiet er bitter weinig over van zijn taak als producent, behalve die van (financieel) investeerder. Echter, in vrijwel alle gevallen zal de producent zijn databank laten draaien onder een eigen domeinnaam. Dat is wellicht nog het meest tastbare wat er van de producent te zien is. De rest kan hij helemaal uitbesteden en toch de rechthebbende blijven op de databank. Daarbij dient bedacht te worden dat ook een organisatie zonder winstoogmerk, zoals een producent van een OSD er vaak een zal zijn, een financieel risico kan lopen. Zo’n organisatie mikt weliswaar op een netto bedrijfsresultaat van 0, maar loopt het risico dat het minder dan 0 wordt. De rechthebbende op de OSD is derhalve de producent daarvan. Op de keper beschouwd is er dus wat dit betreft geen wezenlijk verschil tussen de producent van een ‘gewone’ databank en de producent van een OSD. Het criterium is dat de producent het (financiële of materiële) risico draagt van de voor de databank te maken investering. Dat leidt tot de gedachte dat de producent de (rechts)persoon is die met de publicatie en/of commerciële activiteiten van de databank de wind vangt.

5.4

De exclusieve rechten van de rechthebbende; niet databankenrechtelijke rechten en plichten van de producent

De rechten van de producent ontstaan automatisch op het moment waarop de databank is voltooid, dan wel de niet voltooide databank wordt gepubliceerd.33 De rechten vervallen na verloop van vijftien jaren na voltooiing van de databank, dan wel de publicatie van de niet voltooide databank.34 Om het vervallen van de databankenrechten te voorkomen, doet de producent er goed aan om periodiek zijn databank te vernieuwen.35 Voor de meeste OSD’s geldt dat het moment van initiële voltooiing en het moment van voltooiing van substantiële wijzigingen moeilijk is aan te geven omdat het ontstaan van een OSD een geleidelijk proces is. Hetzelfde geldt overigens ook voor commerciële databanken. Wellicht dat

33

Artikel 6 lid 1 respectievelijk lid 2 Databankenwet. Lid 3 van artikel 6 Databankenwet bepaalt: ‘Met elke in kwalitatief of kwantitatief opzicht substantiële wijziging van de inhoud van de databank, met name door opeenvolgende toevoegingen, weglatingen of veranderingen, die in kwalitatief of kwantitatief opzicht getuigt van een nieuwe substantiële investering, ontstaat een nieuw recht als bedoeld in artikel 2, eerste lid, voor de door die investering ontstane databank’. Dit kan een perpetuele beschermingsduur betekenen. 35 Opvragen wordt in artikel 1c Databankenwet gedefinieerd als: ‘het permanent of tijdelijk overbrengen van de inhoud van een databank of een deel daarvan op een andere drager, ongeacht op welke wijze en in welke vorm’. 34

83


algemene criteria inzake de gebruikswaarde van de databank hier van dienst kunnen zijn. Op grond van de Databankenwet heeft de producent het uitsluitende recht om toestemming te verlenen voor de navolgende handelingen: – het opvragen of hergebruiken van het geheel of een in kwalitatief of kwantitatief opzicht substantieel deel van de inhoud van een databank; – het herhaald en systematisch opvragen of hergebruiken van in kwalitatief of in kwantitatief opzicht niet-substantiële delen van de inhoud van een databank, voorzover dit in strijd is met de normale exploitatie van die databank of ongerechtvaardigde schade toebrengt aan de rechtmatige belangen van de producent van de databank. Opvragen wil zeggen een of meer elementen uit de databank halen, bijvoorbeeld door een naam in te voeren en een adres en telefoonnummer terug te krijgen.36 Hergebruiken gaat nog iets verder in die zin dat de opgevraagde gegevens opnieuw aan het publiek worden aangeboden.37 Het hoeft niet te gaan om een groot deel van de databank, ook voor herhaaldelijk een klein deel opvragen (zgn. melken van de databank) is toestemming van de producent vereist indien dit in strijd is met de normale exploitatie van die databank is of ongerechtvaardigde schade toebrengt aan de rechtmatige belangen van de producent van de databank.38 Hiervoor is er al op gewezen dat de omvang van de rechtsbescherming van een OSD in sterke mate bepaald wordt door de op het gebruik betrekking hebbende licentie. Op de licenties wordt verderop in dit hoofdstuk ingegaan. Na de hiervoor gegeven uiteenzetting van de databankenrechtelijke rechten van de producent wordt hieronder kort ingegaan op enkele niet-databankenrechtelijke rechten en plichten van de producent. Het gaat hier om de positie van de producent ten aanzien van (a) het vullen dan de databank, (b) de inrichting van de databank, en (c) het beëindigen van zijn activiteiten ten aanzien van de databank.

36

Hergebruiken wordt in artikel 1d Databankenwet gedefinieerd als: ‘elke vorm van het aan het publiek ter beschikking stellen van de inhoud van een databank of een deel daarvan door verspreiding van exemplaren, verhuur, on line transmissie of transmissie in een andere vorm’. 37 Artikel 2.1.b en 4 Databankenwet. 38 Artikel 6:3.2.b Burgerljjk Wetboek.

84


Intellectuele eigendomsrechten op de bijdragen zullen doorgaans niet aan de producent toekomen. Maar beschikt de producent over een exclusief weigerings- en wijzigingsrecht? Normaal gesproken worden alle bijdragen (toevoeging, verandering of verwijdering van gegevens) zonder meer in de OSD opgenomen, zij het dat de producent én de gebruikers iedere bijdrage kunnen screenen en te allen tijde kunnen wijzigen en zelfs verwijderen, uiteraard met inachtneming van elkaars rechten, waaronder eventueel het auteursrecht. In zoverre is er in de status tussen producent en gebruiker geen verschil. Er is echter veel voor te zeggen dat bijdragen vooraleer ze worden gepubliceerd eerst door de producent c.q. diens eindredacteur worden gecontroleerd, al was het maar ter voorkoming van vandalisme in de databank. Een dergelijk controlemoment doet geen afbreuk aan de gedachte die achter het fenomeen OSD schuilgaat. Een ander recht van de producent is het recht om de OSD naar eigen goeddunken in te richten. Het staat de producent vrij om zijn OSD in een frame te ontsluiten en tegelijk (op een ander voor gebruikers onbereikbaar frame) te adverteren. Uiteraard kan de producent ook reclameboodschappen plaatsen in de OSD. Die rechten zijn echter niet exclusief voor de producent. Gebruikers mogen hetzelfde doen (en dus in de OSD hun eigen reclameboodschappen opnemen) of de advertentie(s) van de producent wijzigen of verwijderen. Dit kan uiteraard tot het uitsluitend recht van de producent worden gemaakt, als hij dat recht in de gebruikersovereenkomst/licentie uitdrukkelijk voor zichzelf voorbehoudt. Aan alles kan een einde komen, zo ook aan een OSD. De producent kan er plotseling de brui aan geven. Hij kan ook de databank fysiek ontoegankelijk maken c.q. slechts toegankelijk maken voor diegenen die aan bepaalde voorwaarden voldoen (bijvoorbeeld betalen of persoonlijke gegevens achterlaten). Vraag is echter in hoeverre de producent daartoe het recht heeft? Doordat de OSD vrijwel uitsluitend ontstaat door vaak talloze onbaatzuchtige bijdragen van gebruikers en door wellicht nog meer gebruikers wordt geraadpleegd, kan de OSD naarmate zijn populariteit en de waardering toeneemt, uitgroeien van particulier kleinschalig initiatief tot gemeenschapsproject of – uiteindelijk – gemeengoed. Zo’n ontwikkeling heeft echter voor de producent een wat minder aantrekkelijke kant. Immers, hoe meer een OSD tot gemeengoed verwordt, hoe minder de producent er over te zeggen heeft, in dier voege dat hij er dan niet zomaar de stekker kan uit trekken. Wellicht ontstaat zelfs op enig moment een natuurlijke verbintenis39 tus-

39

Artikel 6:162 BW: een doen of nalaten in strijd met hetgeen volgens ongeschreven recht in het maatschappelijk verkeer betaamt.

85


sen producent en afnemers. Voorts maakt de producent die zonder goede reden van een OSD de vrije opvraagbaarheid en het vrije hergebruik blokkeert zich mogelijk schuldig aan een onrechtmatige daad jegens de gebruikers van de OSD die door de inburgering van de OSD en de wijze waarop die is tot stand gekomen erop mogen vertrouwen dat de OSD blijft bestaan. De producent handelt dan in strijd met de in acht te nemen maatschappelijke zorgvuldigheid.40 Deze schending van ongeschreven recht heeft een vrij casuïstisch karakter; de rechter zal in voorkomend geval het belang van de gemeenschap bij voortzetting van de OSD afwegen tegen het belang van de producent bij beëindiging van de OSD. Dat belang kan bijvoorbeeld daarin bestaan dat de financiële middelen voor het instandhouden van de infrastructuur niet meer toereikend zijn. Van de producent zal in ieder geval gevergd mogen worden dat hij zich de nodige inspanningen getroost om tegen redelijke condities de OSD en de website waaronder die draait aan een andere producent over te dragen en/of tijdig van zijn voornemen kennis te geven, opdat gebruikers het verlies van de databank kunnen voorkomen, of alternatieven kunnen ontwikkelen.

5.5

Het rechtmatige gebruik; licenties

In deze paragraaf wordt aandacht besteed aan het gebruik dat het publiek rechtmatig kan maken van de OSD. Gebruik van een OSD door het publiek omvat enerzijds het gebruik maken van het zoekmechanisme, en anderzijds het gebruik van de in de OSD aangetroffen informatie. Het gebruik van het zoekmechanisme is onderworpen aan het auteursrecht op het zoekprogramma. Op dit aspect zullen we hier niet verder in gaan. Evenmin zullen wij aandacht besteden aan de auteursrechtelijke of nabuurrechtelijke aspecten van de inhoud van de OSD. Een OSD waaraan eenieder informatie kan toevoegen kan men ook voor allerlei doeleinden gebruiken als publicatieplatform, maar op dat gebruik – hoe interessant ook – zullen wij hier evenmin ingaan. Gebruik door het publiek kan – databankenrechtelijk gezien – rechtmatig zijn ofwel (a) omdat het niet door het databankenrecht is verboden, ofwel (b) omdat daarvoor een wettelijke beperking op het absolute recht geldt, ofwel (c) omdat een contractuele licentie geldt. Hierna zal achtereenvolgens aan alle drie situaties aandacht worden besteed.

40

86

Artikel 8 Databankenwet.


In hoeverre het publiek zonder een contractuele licentie rechtmatig gebruik kan maken van een OSD van een ander wordt bepaald door het antwoord op de vraag naar enerzijds de reikwijdte van de Databankenwet, en anderzijds de in de Databankenwet opgenomen – wettelijke – beperkingen op het absolute recht. Op enkele aspecten van beide vragen gaan we kort in. Een van de grenzen van de werking van de Databankenwet is het vereiste van de substantiële investering, zonder welke geen databankenrecht ontstaat. In de vorige paragrafen werd dit vereiste al nader uiteengezet. Zo is er al op gewezen dat het HvJEG in enkele recente arresten de zogenaamde spin-off theorie heeft aanvaard. Indien op grond hiervan zou komen vast te staan dat bij een OSD geen sprake is van substantiële investering, dan ontstaat geen databankenrecht. Daarmee zou de open source beweging enerzijds wat dichter bij haar doel gekomen zijn, anderzijds wat verder er vandaan. Wat dat laatste betreft: als de inhoud van een OSD vrijelijk kan worden gebruikt dan kan die ook verwerkt worden in niet-open source databanken, en het tegengaan daarvan kan dan alleen door middel van licenties. Zonder databankenrecht is de juridische basis voor open source licenties echter wel smal. Hiervoor is er al op gewezen dat de investering in het beschikbaar maken en houden van de technische en organisatorische infrastructuur die nodig is voor de verzameling van de data elementen ook van belang is. Een andere grens van de werking van de Databankenwet is te vinden in artikel 2 lid 1 sub a en b Databankenwet. Daaruit volgt dat het opvragen en hergebruiken van een in kwalitatief of kwantitatief opzicht niet substantieel deel van de inhoud van de databank buiten het daar neergelegde exclusieve recht blijft, zolang het niet herhaald en systematisch gebeurt en daardoor geen strijd ontstaat met de normale exploitatie van die databank of ongerechtvaardigde schade wordt toegebracht aan de rechtmatige belangen van de producent van de databank. Bij een OSD is niet altijd sprake van commerciële exploitatie, en het opvragen en hergebruiken van een in kwalitatief of kwantitatief opzicht niet substantieel deel van de inhoud zal doorgaans geen ongerechtvaardigde schade toebrengen aan de rechtmatige belangen van de producent van de databank. Dat betekent dat doorgaans eenieder het recht heeft tot het opvragen en hergebruiken van een in kwalitatief of kwantitatief opzicht niet substantieel deel van de inhoud van een OSD, ook als dat herhaald en systematisch gebeurt. Ten slotte, de door de overheid geproduceerde databanken met regelgeving en jurisprudentie, en in bepaalde gevallen ook andere door de overheid geproduceerde databanken, vallen niet onder het databankenrecht.41 Maar dat zijn eigenlijk ook geen OSD’s.

41

Men zie daarvoor bijvoorbeeld .

87


In de Databankenwet vinden we – anders dan in de Auteurswet 1912 – geen wettelijke beperkingen op het absolute recht, behalve artikel 1 lid 2 Databankenwet, waarop we hier niet zullen ingaan, en artikel 3-5 Databankenwet. Laatstgenoemde artikelen betreffen echter de rechtmatige gebruiker, en daarmee zijn we aangekomen bij de behandeling van de licenties en de positie van de contractueel gelicentieerde gebruiker. De vraag naar de gebondenheid aan open source licenties wordt elders in dit preadvies behandeld. Wij zullen hier dat onderwerp hier niet behandelen. Het staat de producent in theorie vrij alle beperkingen die hij ingevolge zijn databankenrecht zou kunnen laten gelden, contractueel los te laten, zodat het mogelijk is dat de databank door gebruikers volledig wordt gemolken en opnieuw wordt gedistribueerd (al zou je je natuurlijk kunnen afvragen wat daar de zin van is, als de gegevens toch al vrij verkrijgbaar zijn). Er bestaat een groot aantal min of meer frequent gebruikte open source licenties voor content.42 Twee licenties die regelmatig voor OSD’s worden gebruikt zullen wij hier summier behandelen: de GNU Free Documentation License (GNU FDL of GFDL), en de Creative Commons Public License (CCPL).43 De GFDL is blijkens de preambule bedoeld voor teksten (documents), en niet voor databanken gevuld met teksten. De GFDL regelt dus nauwelijks iets over het opvragen en hergebruiken van elementen uit een OSD, tenzij men een ‘document’ opvat als een element van een databank. Verder blijkt uit de tekst van de GFDL dat bij het opstellen ervan gedacht is aan auteursrecht, en in het geheel niet aan databankenrecht. Toch wordt de GFDL voor alle wiki’s van de Wikimedia Foundation gebruikt, en voor veel andere OSD’s. Het gevolg is dat de GFDL aan het publiek behoorlijk wat onwerkbare of op zijn minst zeer moeilijk hanteerbare beperkingen oplegt. Als we bijvoorbeeld aannemen dat met ‘document’ in de GFDL een element van de OSD wordt bedoeld, dan moet bij hergebruik van een element van 10 woorden de complete tekst van de GFDL (3279 woorden!) worden toegevoegd.44 Voor de CCPL gelden soortgelijke problemen, zij het dat bij hergebruik van een element niet de complete tekst van de CCPL hoeft te worden toegevoegd, maar volstaan kan worden met het toevoegen van de ‘Uniform Resource Identifier’ van de CCPL, dus http://creativecommons.org/licenses/by/2.0 (artikel 4.a. CCPL).

42

Vgl. respectievelijk: en < http://creativecommons.org/licenses/by/2.0>. Artikel 2 GFDL. 44 Met dank aan Arnoud Engelfriet, Barbara Fris en John Konijn voor hun commentaar op een eerdere versie van dit hoofdstuk. 43

88


Uit de systematiek van de Databankenwet en de daaraan ten grondslag liggende Richtlijn 96/9 blijkt dat met rechtmatige gebruiker wordt bedoeld een gebruiker die een – contractuele – licentie heeft. Dat betekent dat voor degene voor wie een contractuele licentie geldt, tevens de bepalingen uit artikel 3-5 Databankenwet gelden. Artikel 3 Databankenwet geeft de rechtmatige gebruiker van een OSD bepaalde minimumrechten die van dwingendrechtelijke aard zijn, hetgeen wil zeggen dat van die minimumrechten niet in een contractuele licentie ten nadele van de rechtmatige gebruiker kan worden afgeweken. Artikel 4 Databankenwet verbiedt de rechtmatige gebruiker om handelingen te verrichten waardoor hij de normale exploitatie van de databank in gevaar brengt of ongerechtvaardigde schade aan de producent toebrengt. Daarvan zal, zo zagen we hiervoor, bij een OSD niet gauw sprake zijn. Artikel 5 Databankenwet geeft ten slotte de rechtmatige gebruiker enkele – niet dwingendrechtelijke – rechten. Het in artikel 5 sub a bepaalde geldt echter niet voor een OSD omdat een OSD een elektronische databank is. Artikel 5 sub c staat de rechtmatige gebruiker onder meer toe een substantieel deel van de inhoud van de databank op te vragen of te hergebruiken voor de openbare veiligheid. Het is overigens in het huidige tijdsgewricht opmerkelijk dat laatstgenoemde bepaling van regelend recht is. Uit het bovenstaande volgt dat een gebruiker onder omstandigheden er belang bij kan hebben de OSD te gebruiken zonder contractuele licentie omdat die hem alleen maar lastige of zelfs onwerkbare beperkingen oplevert die voortvloeien uit de contractuele licentie, gewijzigd en aangevuld door – onlosmakelijk verbonden aan het gebruik op basis van een contractuele licentie – artikel 3-5 Databankenwet. We zagen hierboven eveneens dat zonder een contractuele licentie het publiek doorgaans voldoende rechtmatig gebruik van de OSD kan maken. Op de civielrechtelijke vraag hoe een open source licentie geweigerd of opgezegd kan worden, gaan we hier niet in. Ontbinding van de GFDL of de CCPL is echter eenvoudig te realiseren: als de gebruiker zich niet stoort aan de licentie dan zal hij weldra in strijd daarmee handelen, waardoor de licentie van rechtswege eindigt (artikel 9 GFDL en artikel 7 CCPL). Voor het opvragen of hergebruiken van de gehele databank of van een in kwalitatief of kwantitatief opzicht substantieel deel van de inhoud van de databank is de gebruiker wel aangewezen op een licentie (artikel 2 lid 1 sub a Databankenwet). De rechthebbende kan zo dus voorkomen dat de databank geheel of grotendeels ‘achter een kassa’ wordt geplaatst. De licenties GFDL en CCPL verbieden dat ook. Maar doorgaans heeft de gebruiker geen behoefte aan het opvragen of her-

89


gebruiken van de gehele databank of een groot deel van de inhoud van de databank.

5.6

Conclusie

Geconcludeerd kan worden dat OSD’s zeer wel in aanmerking kunnen komen voor databankenrecht, zolang de producent maar komt uit een lidstaat van de EU of de EER of uit een ander land waarmee de EU een verdrag inzake databankenrecht heeft gesloten. Databankrechthebbende is in beginsel degene die de kosten draagt voor het beschikbaar maken en houden van de technische en organisatorische infrastructuur waarmee de data elementen worden verzameld. Omdat OSD’s doorgaans zonder winstoogmerk in stand worden gehouden heeft eenieder doorgaans het recht tot het opvragen en hergebruiken van een in kwalitatief of kwantitatief opzicht niet substantieel deel van de inhoud van een OSD, ook als dat herhaald en systematisch gebeurt. Voor de meeste gebruikers is dit genoeg, en een licentie zou hen alleen maar lastige beperkingen kunnen opleggen. Voorzover de gebruiker gebonden wordt aan de licentie kan hij daar in het geval van de onderzochte GFDL en CCPL vanaf komen door zich er simpelweg niet aan te storen. Niets staat de gebruiker dus in de weg om een betalende dienst aan te bieden waarvan onderdeel uit maakt het doorzoeken van een of meerdere OSD’s, zolang het gaat om niet substantiële delen. Wel kan de rechthebbende voorkomen dat de databank in zijn geheel of grotendeels ‘achter een kassa’ wordt geplaatst. Dat verbieden de licenties GFDL en CCPL ook. De mogelijkheid voor de open source gemeenschap om via het databankenrecht de ontwikkeling van open source databanken te beheersen is vrij beperkt. Dit komt doordat een gebruiker doorgaans uit een databank slechts niet substantiële delen opvraagt, en daarin wordt de gebruiker van OSD’s door de Databankenwet nauwelijks beperkt. Het wegnemen van het automatische eindigen van de licenties zoals GFDL en CCPL zou niet zo veel helpen. Immers, indien een licentie afbreuk doet aan de wettelijke positie die de gebruiker heeft zonder licentie, dan zou het niet redelijk zijn om de gebruiker tegen zijn wil aan de licentie gebonden te achten. Opgemerkt zij nog dat het recht ter bescherming van databanken wereldwijd nogal wat verschillen vertoont. Daardoor is het regelen van de wereldwijde ontwikkeling van OSD’s door middel van licenties sowieso niet eenvoudig.

90

6

Licentievormen van open source software Arno van Hekesen, Nico Hollebeek, en Eric Tjong Tjin Tai1

Kenmerkend voor OSS is dat deze software ter beschikking wordt gesteld onder licentievoorwaarden die het iedereen vrijwel zonder beperkingen toestaan om de OSS te gebruiken en aan te passen. De belangrijkste soorten OSS-licenties kunnen worden onderverdeeld in drie categorieën. Daarbij vormt het zogenaamde copyleft principe het onderscheidend criterium. Hierna komen behalve de verschillende soorten OSS-licenties, ook het begrip ‘afgeleid werk’ aan de orde, alsmede in samenhang daarmee de ‘virale’ werking van de GPL en de (juridische) consequenties daarvan, nu hierover in de praktijk de meeste vragen lijken te bestaan.

6.1

Beschrijving belangrijkste soorten OSS-licenties

Vrijwel alle OSS-licenties staan de gebruiker toe de OSS onbeperkt te gebruiken, te wijzigen en, al dan niet in gewijzigde vorm, verder te verspreiden.2 Daarnaast hebben de verschillende OSS-licenties ieder hun eigen specifieke voorwaarden.3 Wij onderscheiden drie categorieën OSS-licenties, te weten: (i) copyleft, (ii) beperkt copyleft en (iii) non-copyleft licenties.4 De zogenaamde copyleft-voorwaarde, die het onderscheidend criterium is voor deze indeling, is het aspect dat

1

Vgl. de open source definition (OSD) op < http://opensource.org/docs/definition.php >, beheerd door het Open Source Initiative (OSI). Dit is een non-profit organisatie die de OSD propageert. Zij beheert een keurmerk (‘OSI Certified’). Aan de standpunten van het OSI wordt een zekere autoriteit toegekend; een juridische betekenis hebben deze standpunten echter niet. 2 Alle door het Open Source Initiative (OSI) gecertificeerde, oftewel goedgekeurde, licenties zijn te vinden op . Dit zijn er inmiddels meer dan vijftig. Deze goedgekeurde licenties worden geacht te voldoen aan de voorwaarden zoals bepaald in de open source definition. Zie over de OSD: B. Perens, The Open Source Definition, in: Open Sources: Voices from the Open Source Revolution, Cambridge, Massachusets, te vinden op: . 3 Zie voor een gedetailleerde beschrijving van de te bespreken licenties onder meer: L. Rosen, Open Source Licensing: Software Freedom and Intellectual Property Law, Upper Saddle River (New Jersey), 2004; K. Rosenberg, Open Source, The Unauthorized White Papers, te vinden op: . Overigens wordt in de praktijk vaker een onderscheid gemaakt tussen OSS-licenties met en zonder copyleft-voorwaarde: Non-permissive of Protective License enerzijds en Permissive of Non-Protective License anderzijds. 4 De GPL bevat een aantal overwegingen die deze filosofie toelichten. Door die toelichting heeft het GPL deels het karakter van een “manifest”. Voor een nadere beschrijving van de filosofie van de FSF (de voornaamste sponsor van het GNU-project) zie: FSF, The GNU Manifesto te vinden op: . Zie ook: B. Perens, The Open Source Definition, in: Open Sources: Voices from the Open Source Revolution, Cambridge, Massachusets, te vinden op: en S. Williams, Free as in Freedom, Richard Stallman’s Crusade for Free Software, p. 83 -94, te vinden op: .

91


verreweg het meest ter discussie staat. Kort gezegd, heeft de copyleft-voorwaarde betrekking op de (juridische) voorwaarden die verbonden zijn aan verspreiding van OSS of onderdelen daarvan. Reden waarom wij in dit hoofdstuk ons bij bespreking van de meest gehanteerde OSS-licenties zullen richten op dit aspect.

6.1.1

Copyleft licenties

Aan copyleft OSS-licenties ligt de filosofie ten grondslag dat iedereen de vrijheid moet hebben om de OSS, waarop de licentie betrekking heeft, te gebruiken, aan te passen en verder te verspreiden.5 Als tegenprestatie moeten wijzigingen en andere afgeleide werken van de OSS weer gratis onder dezelfde OSS-licentievoorwaarden ter beschikking worden gesteld aan de open source gemeenschap (ook wel ‘public commons’ genoemd), zodat iedereen daarvan kan profiteren en daarop kan voortborduren.6 De belangrijkste copyleft OSS-licentie, en waarschijnlijk tevens de bekendste, is de GNU General Public License (kortweg ook wel aangeduid als de GPL).7 Wij zullen deze hierna als uitgangspunt nemen. Om er voor te zorgen dat de OSS die onder de GPL verspreid wordt daadwerkelijk vrij beschikbaar blijft, maakt de GPL gebruik van de copyleft-voorwaarde.8 Concreet houdt dit in, dat bij de distributie van het OSS-programma en aanpassingen, verbeteringen en andere afgeleide werken daarvan, de broncode van het OSS-programma én die aanpassingen, verbeteringen en andere afgeleide werken beschikbaar moeten worden gesteld, onder dezelfde (licentie)voorwaarden als de OSS zelf, zonder verdere restricties. Het is daarnaast verboden een vergoeding te bedingen voor het gebruik van de broncode.9 Copyleft zorgt er derhalve voor dat met behulp van het copyright het vrije gebruik van de OSS bij verdere distributie behouden blijft. Of zoals Richard Stallman, een van de auteurs van de GPL stelt,

5

Ook wel aangeduid als het share and share alike of commons principe. De huidige versie van de GPL, versie 2, dateert reeds uit 1991. Naar verluidt zijn Eben Moglen en Richard Stallman bezig met het opstellen van een nieuwe – derde – versie. In 2002 is door Affero – met steun van, maar niet door de Free Software Foundation (FSF) – de Affero General Public License (AGPL) gepubliceerd. Deze licentie bevat ten opzichte van de GPL een additionele bepaling (artikel 2.d) met betrekking tot het gebruik van OSS over een netwerk, die waarschijnlijk in gewijzigde vorm in de GPL v3 zal worden opgenomen. Affero is een organisatie van webhosting/blogging wiens licentie enige bekendheid heeft verkregen < http://www.affero.com >. 7 Zie ook: What is Copyleft? op: <www.gnu.org/copyleft/copyleft.html>; K.J. Koelman, Terug naar de bron: open source en copyleft, Informatierecht/AMI 2000/8, p. 149 – 155. 8 A contrario volgt dit uit art. 1 GPL, dat bepaalt dat het wel is toegestaan een vergoeding te vragen voor het ter beschikking stellen van een exemplaar van de software of voor het geven van garanties. 9 R. Stallman, The GNU Operating System and the Free Software Movenent, in: Open Sources: Voices from the Open Source Revolution, Cambridge, Massachusets, p. 59, te vinden op: 6

92

Licentievormen van open source software

het auteursrecht wordt gebruikt ‘but flip it over to serve the opposite of its usual purpose: instead of privatizing software, [copyright] becomes a means of keeping software free’.10 In de GPL is dit aldus gespecificeerd, dat de copyleft-voorwaarde betrekking heeft op ieder programma dat enige GPL-code (code die verspreid is onder de GPL) bevat of is afgeleid (derived) van een GPL-programma.11 Als GPL-code in een proprietary programma (closed source software) wordt opgenomen, en dat proprietary programma vervolgens publiekelijk wordt verspreid in object codevorm (al dan niet tegen betaling), moet ook de broncode van dit programma onder de GPL worden vrijgegeven. Feitelijk leidt dit ertoe dat ook de delen van het programma die niet direct berusten op GPL-code niet langer als proprietary software kunnen worden behouden: de broncode daarvan moet immers als onderdeel van het ‘afgeleid werk’ worden geopenbaard voor algemeen vrij gebruik. Voor alle duidelijkheid: de GPL schrijft niet voor dat het programma altijd moet worden verspreid (met de broncode). Alleen indien het programma (met aanpassingen) publiekelijk wordt verspreid, zal ook de broncode ter beschikking moeten worden gesteld onder de GPL.12 Als het programma alleen binnen de organisatie wordt gebruikt, geldt dit dus niet. Dan hoeft de broncode niet te worden vrijgegeven onder de GPL, ook al bevat het GPL-code. Op zichzelf is dan ook de vrees gegrond, dat door het ‘per ongeluk’ opnemen van een paar regels GPL-code in een proprietary programma, dat gehele programma onder de GPL zou moeten worden vrijgegeven, ten minste indien het programma publiek wordt verspreid. Alleen door zorgvuldig er op toe te zien dat geen GPLcode in een proprietary programma wordt opgenomen, kan dit worden voorkomen. Aan dit ‘besmettende’ effect zou de GPL zijn zogenaamde ‘virale’ karakter ontlenen. Sommige auteurs spreken overigens liever van vererving (inheritance), omdat dat begrip beter tot uitdrukking zou brengen dat het onder de GPL komen te vallen van een programma het gevolg is van de aanvaarding van de voorwaarden (en dus niet van het simpelweg ‘in contact komen’ met een GPL-pro-

10

Vgl. Art 2 GPL. Vgl. Art. 2 en 3 GPL. 12 Bijvoorbeeld C. De Preter/ H. Dekeyser, De totstandkoming en draagwijdte van open source licenties’, Computerrecht 2004/5, pp. 216-220. 11

93


gramma).13 Ook vindt men wel dat de term besmetting een te negatieve lading heeft.14 De angst voor de GPL wordt nog eens vergroot door de onduidelijkheid met betrekking tot de inhoud en reikwijdte van het begrip afgeleid werk.15 Zo wordt verdedigd dat het begrip afgeleid werk (derivative work) een zodanig ruime strekking heeft, dat reeds het combineren of samenwerken van een (zelfstandig ontwikkeld) programma met een GPL-programma tot gevolg heeft dat het oorspronkelijk programma onder de GPL zou komen te vallen. Wij komen op de reikwijdte van het begrip afgeleid werk (en daarmee de copyleft-voorwaarde) in de GPL hieronder terug.

6.1.2

Non-copyleft licenties

Het bekendste voorbeeld van een non-copyleft licentie is de BSD-licentie.16 Non-copyleft licenties laten toe dat de OSS, net zoals het geval is bij de copyleft licenties, onbeperkt wordt gekopieerd, gebruikt, bewerkt en verder gedistribueerd. Anders dan geldt voor copyleft licenties is het bij dit type licenties echter niet verplicht om de verkregen OSS (of afgeleide werken) ook in broncode-vorm ter beschikking te stellen. Het programma of daarvan afgeleide werken, mag of mogen ook onder andere (licentie)voorwaarden verder worden verspreid.17 Dit betekent dat een BSD-programma (of delen daarvan) in een ander programma kan (kunnen) worden opgenomen en dat dat programma (met aanpassingen) ver-

13

Vgl. bijvoorbeeld L. Rosen, General Public License, Explained, te vinden op: en C. De Preter/ H. Dekeyser, De totstandkoming en draagwijdte van open source licenties’, Computerrecht 2004/5, pp. 216-220. De FSF spreekt zelf bij voorkeur over het ‘liberating’ effect van de GPL. 14 BSD staat voor Berkeley Systems Development. Deze licentie vond zijn oorsprong op de Universiteit van Californië (Berkeley). Andere voorbeelden van non-copyleft-open source licenties zijn de MIT licentie (afkomstig van het Massachusetts Institute of Technology) en de Apache Versie 1.1 (afkomstig van de Apache Software Foundation). 15 Dit is in overeenstemming met de open source definition. Punt 3 van de OSD bepaalt immers slechts dat ‘The license must allow modifications and derived works and it must allow them to be distributed under the same terms as the License of the original software.’ 16 Zo is BSD code opgenomen in onder meer Windows NT en Mac OS X. 17 Een vroegere versie van de BSD-licentie kende de voorwaarde dat al het advertentiemateriaal met betrekking tot de BSD-software een vermelding van de bijdrage van de oorspronkelijke licentiegevers moest bevatten. In de huidige versie van de BSD-licentie is die voorwaarde geschrapt. De universiteit van Berkeley heeft in 1999 medegedeeld dat gebruikers deze verplichting niet langer in acht hoeven te nemen voor software die onder de oude BSD-voorwaarden ter beschikking is gesteld. De BSD-licentie kan echter ook als modellicentie door andere licentiegevers gebruikt zijn. Het is niet uit te sluiten dat deze andere licentiegevers geen afstand hebben gedaan van de hiervoor bedoelde voorwaarde.

94


volgens mag worden gedistribueerd onder andere (licentie)voorwaarden.18 De verkrijger is volledig vrij in de keuze van de voorwaarden waaronder hij het BSD-programma verder verspreidt. Door het ontbreken van een copyleft-beding kunnen de aanpassingen, verbeteringen of andere afgeleide werken van een BSD-programma door de auteurs proprietary worden gehouden; ze hoeven niet te worden vrijgeven. De BSD-licentie verbindt als enige voorwaarde aan de verdere verspreiding van het BSD-programma dat er een copyright notice wordt opgenomen in de programmatuur, met enkele andere notice bepalingen, alsmede een bepaling die de aansprakelijkheid van de licentiegevers, dus van alle auteurs, uitsluit en bepaalt dat het programma zonder garanties wordt verstrekt.19 Het ontbreken van een copyleft-voorwaarde houdt verband met de filosofie die aan dit type licenties ten grondslag ligt. De eerste licenties van dit type vonden hun oorsprong in de academische wereld.20 Aldaar was men van mening dat de vruchten van wetenschappelijke productie moesten worden toegevoegd aan de public commons, om zo ten goede te komen aan de gemeenschap en te kunnen bijdragen aan de verdere ontwikkeling van kennis en ideeën. Er gold echter niet de verplichting dat in ruil voor de kennis iets teruggegeven zou moeten worden aan de gemeenschap. Hiertegen richt zich dan ook het belangrijkste bezwaar van de copyleft-aanhangers: onder een non-copyleft licentie kan en mag iedereen (door andere ontwikkelde) non-copyleft OSS exploiteren, zonder dat daarvoor evenwel een tegenprestatie terugvloeit naar de oorspronkelijke ontwikkelaar(s), dan wel de public commons. Afhankelijk van het perspectief dat men kiest, zijn ofwel de copyleft licenties of de non-copyleft licenties de ‘meest vrije’ OSS-licenties. De copyleft aanhangers verdedigen de copyleft methode omdat deze methode de voortdurende vrijheid van de OSS garandeert en voorkomt dat de bewerkte software op enig moment

18

Rosen duidt deze categorie van licenties dan ook aan als de academische licenties. Zie L. Rosen, Open Source Licensing, Upper Saddle River (New Jersey), 2004, pp. 67 en 73 – 102. 19 Zie: D.M. Kennedy, A Primer on Open Source Licensing Legal Issues: Copyright, Copyleft and Copyfuture, Saint Louis University Public Law Review, October 2001; L. Rosen, Open Source Licensing, Upper Saddle River (New Jersey), 2004, p. 104; J. Michaelson, Open Source Licensing: What Every OEM should know, A Wasabi Systems white paper, te vinden op; http://www.wasabisystems.com/gpl/opensource.html, M.H. Webbink, Open Source Software, 2004, te vinden op:
95


uit het public commons wordt gehaald door het proprietary te maken. Anderen bestempelen daarentegen juist de non-copyleft licenties als de meest vrije licentievorm, nu die licenties de gebruikers in beginsel geheel vrijlaten in de wijze waarop en voorwaarden waaronder de OSS mag worden verder verspreid. Bovendien worden gebruikers van de OSS niet gedwongen om aanpassingen en andere afgeleide werken vrij te geven bij verdere distributie. Met name om die laatste reden worden non-copyleft licenties als meer geschikt voor commerciële open source projecten beschouwd dan copyleft licenties.21

6.1.3

Beperkt copyleft licenties

De beperkt copyleft licenties kunnen worden beschouwd als een tussenvorm van de twee eerdergenoemde typen van OSS-licenties. Voorbeelden zijn de Mozilla Public License (MPL) en de Common Public License (CPL). Veel van dit type licenties zijn ontwikkeld door of vanuit commerciële ondernemingen. Zo zijn de MPL en CPL opgesteld door respectievelijk Netscape en IBM. Ook zijn er varianten ontwikkeld die niet een commerciële achtergrond kennen. Hoe dan ook, dit type licenties wordt veelal beschouwd als een goed compromis tussen de eerdergenoemde twee categorieën en geschikt geacht als model voor commerciële OSS-projecten.22 In het algemeen is dit type licenties gedetailleerder en duidelijker geformuleerd dan de GPL- en de BSD-licenties. Dit komt met name doordat deze licenties veelal geschreven zijn door juristen, in plaats van door computerprogrammeurs zoals bij de GPL en de BSD het geval was. Kenmerkend voor beperkt copyleft OSS-licenties is dat zij weliswaar een copyleft-beding bevatten op grond waarvan aanpassingen op en andere afgeleide werken van de OSS moeten worden vrijgegeven, maar dat de reikwijdte met betrekking tot hetgeen moet worden vrijgegeven minder ruim is dan bij copyleft licenties het geval is. De meeste beperkt copyleft licenties beschrijven ook preciezer wat de omvang van de copyleft-voorwaarde is dan de GPL doet.Het gebruik van OSS onder dergelijke licenties brengt daarom minder risico’s met

21

Het is ook toegestaan om eigen versies van de MPL te creëren (zie artikel 6.3 MPL). Een voorbeeld daarvan is de door Nokia ontwikkelde Nokia open Source License, zie: . 22 Zie L. Rosen, Open Source Licensing: Software Freedom and Intellectual Property Law, Upper Saddle River (New Jersey), 2004, p. 143. De MPL werd door Netscape ontwikkeld in overleg met een aantal belangrijke personen in de open source gemeenschap, waaronder Linus Torvalds, Eric Raymond en Bruce Perens. Zie over het Mozilla project en de ontwikkeling van de MPL: Jim Hamerly e.a., Free the Source, The Story of Mozilla, in: Open Sources: Voices from the Open Source Revolution, te vinden op: <www.oreilly.com/catalog/opensources/book/netrev.html>.

96


zich dan GPL-sofware. Door de beperkte werking van de copyleft-voorwaarde in dit type licentie, hebben deze licenties geen ‘virale’ werking in de zin dat zelfstandige programma’s door de licentie worden ‘besmet’. De precieze wijze waarop hieraan gestalte wordt gegeven, verschilt evenwel per licentie. Als voorbeeld gaan wij in op de MPL, aangezien dat de bekendste beperkt copyleft licentie is. Eind jaren negentig dreigde Netscape Communicator het van Microsoft’s Internet Explorer te verliezen. In een poging het tij te keren, besloot Netscape om haar programma Netscape Communicator vrij te geven onder een OSS-licentie. Netscape concludeerde dat de GPL niet geschikt was, onder meer omdat de GPL niet verenigbaar was met Netscape Communicator. Dit omdat het programma reeds proprietary software van derden bevatte, die onder de GPL zou moeten worden vrijgegeven. Bovendien was men bevreesd dat de GPL commerciële partijen zou afschrikken vanwege het gevreesde virale effect van de GPL. Netscape was bovendien zelf ook bang dat het onder de GPL gedwongen zou worden om de Communicator code vrij te geven die in andere Netscape producten werd gebruikt. Daartegenover stond dat de BSD evenmin geschikt werd geacht, omdat men niet wilde dat aanpassingen door derden van de Communicator code proprietary zouden worden gehouden en niet zouden worden vrijgeven aan de Netscape Communicator gemeenschap. Netscape besloot daarop haar eigen OSS-licentie te ontwikkelen. Deze specifiek voor Netscape Communicator ontwikkelde OSS-licentie, vormde de basis voor de MPL. De MPL is zeer geschikt om gebruikt te worden voor (commerciële) OSS-projecten.23 De MPL wordt algemeen beschouwd als de belangrijkste beperkt copyleft licentie. Zij heeft model gestaan voor vele andere beperkt copyleft OSS-licenties die daarna zijn ontwikkeld.24 De copyleft-voorwaarde van de MPL geldt slechts voor de zogenaamde Covered Code. Deze term hanteert de MPL om de grens van de copyleft-voorwaarde aan te geven. Covered Code omvat de code die is opgenomen in de bestanden die de oorspronkelijk onder de MPL ter beschikking gestelde code of aanpassingen daarop bevatten. Code die niet in die bestanden (files) is opgenomen, ook al maakt die deel uit van hetzelfde programma, valt derhalve niet onder de copyleft-voorwaarde. Uitdrukkelijk bepaalt de MPL dat het is toegestaan de Covered Code op te nemen in een programma (Larger Work) dat zowel Covered Code bevat als code waarop een andere licentie van toepas-

23

Vgl. Artikel 3.7 MPL. De verspreiding moet dus conform de MPL zijn, maar op de verspreide code mogen vervolgens andere voorwaarden van toepassing worden verklaard. Zie hiervoor artikelen 3.1-3.5 MPL.

24

97


sing.25 Als de verspreiding in de vorm van object code geschiedt (al dan niet als onderdeel van een Larger Work), mag de Covered Code onder van de MPL afwijkende voorwaarden worden verspreid, mits de daarbij behorende voorwaarden in de MPL in acht worden genomen,26 en duidelijk is vermeld dat de broncode van de Covered Code beschikbaar is onder de MPL-voorwaarden. De broncode met betrekking tot de Covered Code mag uitsluitend onder de MPL worden verspreid. In de MPL strekt de copyleft-voorwaarde zich derhalve niet uit tot een programma waarin de Covered Code is opgenomen. Door de duidelijke definities van Covered Code en daaraan gerelateerde begrippen in de MPL is bovendien goed vast te stellen welke code wel en welke niet onder de MPL valt, waardoor aan het gebruik van MPL software niet de onzekerheid is verbonden waarvan bij de GPL sprake is. Samengevat ziet het voorgaande er in een schema als volgt uit. GPL (voorbeeld van copyleft)

MPL (voorbeeld van beperkt copyleft)

BSD (voorbeeld van noncopyleft)

J

J

N

J Vrijgeven van eigen code (anders dan wijziging OSScode) verplicht?

N (mits geen Covered Code is opgenomen in de ‘eigen’ files)

N

Andere voorwaarden toege- N staan op OSS-broncode?

N (wel bij uitgifte op basis van multiple licensing)

J

Andere voorwaarden toege- N staan op OSS-objectcode?

J (mits broncode OSS-code wordt vrijgegeven)

J

Vrijgeven van wijzigingen OSS-code verplicht (copyleft)

25

Zie ook hoofdstuk 7. Zo bestempelt de FSF de MPL als een met de GPL onverenigbare licentie. Om het gebruik van MPL code in combinatie met GPL of LGPL mogelijk te maken, voorziet de MPL evenwel in de mogelijkheid van multiple licensing. Dit komt er op neer dat de licentiegever aan licentienemers de mogelijkheid kan geven om de MPL code ook onder een van de andere in Exhibit A van de MPL aangeduide licenties te distribueren (art. 13 MPL) Zie: .

26

98


6.2

Onderlinge verenigbaarheid van OSS-licenties27

Na de typering van de verschillende OSS-licenties, is het tijd geworden stil te staan bij de volgende vraag die bij OSS-projecten van groot belang is: kan een programma waarop een bepaalde OSS-licentie van toepassing is, worden gebruikt in combinatie met een programma waarop een andere OSS-licentie van toepassing is? Men spreekt in dit verband ook wel van de verenigbaarheid (compatability) van OSS-licenties. Kan bijvoorbeeld GPL-code worden opgenomen in een programma dat bedoeld is te worden verspreid onder een BSD-licentie? Dit is van groot belang voor projecten waarbij men software wil combineren die onder verschillende OSS-licenties is verspreid:. Met het toenemend gebruik van OSS en de vele uiteenlopende licenties is een conflict bepaald niet denkbeeldig. Naar haar aard mag code waarop een copyleft-voorwaarde van toepassing is, alleen onder diezelfde copyleft voorwaarde worden verspreid: de keten kan niet worden verbroken. Een copyleft licentie is derhalve niet verenigbaar met een andere (beperkt) copyleft licentie. Bijvoorbeeld de GPL verplicht de distributeur het gehele programma waarin de GPL code is opgenomen uitsluitend onder de GPL te verspreiden. Indien dat programma ook MPL code bevat, mag die code weer uitsluitend onder de MPL worden verspreid. Beide licenties komen dan dus in conflict met elkaar.28 De distributeur kan dan niet aan beide voorwaarden tegelijk voldoen en zou dus strikt genomen moeten afzien van distributie, wat onwenselijk is als het een nuttige ontwikkeling betreft. Bij code waarop een beperkt copyleft licentie van toepassing is, zoals de MPL, zal het van de specifieke licentievoorwaarden afhangen of het mogelijk is code, waarop die licentie van toepassing is, op te nemen in een programma dat tevens code bevat waarop een andere beperkt copyleft licentie of een non-copyleft licentie van toepassing is. De MPL laat immers ruimte voor verdere verspreiding onder deels afwijkende voorwaarden. Non-copyleft code mag onder iedere licentie verder worden verspreid. In beginsel kan non-copyleft code derhalve worden opgenomen in een programma dat onder een andere OSS-licentie wordt verspreid. Er kunnen echter beperkingen van andere aard voortvloeien uit de voorwaarden die de andere OSS-licentie stelt,

27

L. Rosen, Open Source Licensing: Software Freedom and Intellectual Property Law, Upper Saddle River (New Jersey), 2004, p. 250. Zie over de verenigbaarheid van open source licenties nader: Rosen, p. 241-253. 28 Zie Apache License v.2.0 and GPL Compatibility, te vinden op: .

99


die toch maken dat bijvoorbeeld code waarop een non-copyleft beding van toepassing is, niet in een programma waarop een andere open source licentie van toepassing is kan worden opgenomen. Zo wijst Rosen er op dat op grond van de CPL (Common Public License) slechts code kan worden opgenomen waarmee het CPL-programma wordt aangepast of aangevuld, indien die code door de bewerker zelf is geschreven.29 Het bovenstaande geeft slechts een aantal algemene richtlijnen. Bovendien moet bedacht worden dat de copyleft voorwaarde (of juist het ontbreken daarvan) niet uitsluitend bepalend is voor de vraag of OSS-licenties onderling verenigbaar zijn. Zo wordt de vroegere BSD-licentie vanwege de toenmalige voorwaarde, dat in advertenties melding moest worden gemaakt van de bijdrage van de oorspronkelijke licentiegevers, onverenigbaar geacht met bijvoorbeeld de GPL. Een ander voorbeeld is de door de FSF gestelde onverenigbaarheid van de Apache Software License, versie 2.0 met de GPL vanwege een afwijkende wijze van omgaan met beëindiging van octrooilicenties.30 Een gedetailleerd onderzoek van de toepasselijke licentievoorwaarden in het licht van het voorgenomen gebruik zal derhalve noodzakelijk zijn om vast te stellen of zodanig gebruik verenigbaar is met de OSS-licentie die op de betreffende software van toepassing is. Overigens zouden potentiële conflicten soms kunnen worden opgelost door voor het combineren van de verschillende OSS expliciet toestemming te vragen van de respectievelijke ‘beheerders’ van de OSS en/of de licenties.31

6.3

Het begrip ‘afgeleid werk’ en de reikwijdte van de copyleft-voorwaarde in de GPL

Hierna zal in meer detail worden ingegaan op de inhoud en reikwijdte van het begrip afgeleid werk in de GPL en in samenhang daarmee de copyleft-voor-

29

Met ‘beheerders’ doelen wij op de organisaties of personen die geacht worden de licentie te beheren (interpretaties te geven, nieuwe versies te vervaardigen, de daaronder vallende software te administreren, of schending van de licentie tegen te gaan). De exacte status van zulke personen (vaak de auteurs) of organisaties wisselt per licentie. 30 Zie hierover ook uitvoerig: L. Rosen, Open Source Licensing: Software Freedom and Intellectual Property Law, Upper Saddle River (New Jersey), 2004, pp. 103 – 130. C. De Preter en H. Dekeyser, ‘De totstandkoming en draagwijdte van open source licenties’, Computerrecht 2004/5, pp. 216-220. Zie ook A. Guadamuz González, Viral Contracts or Unenforceable Documents? Contractual Validity of Copyleft Licenses, EIPR 2004/8, pp. 331-339. Zie voor Duits recht: U. Wuermeling/ Thies Deike, Open Source Software: Eine juristische Risikoanalyse, Computerrecht [Duitse versie] 2003/2, pp. 87-91. GNU General Public License and the Distribution of Derivative Works, te vinden op: http://www.soberit.hut.fi/ ~insvalima/gpl_derivative.pdf. 31 J.H. Spoor/D.W.F. Verkade/D. Visser, Auteursrecht, Deventer 2005, p. 130.

100


waarde in de GPL.32 Dit is van belang voor degenen die, bijvoorbeeld in de praktijk van softwareontwikkeling, met de GPL geconfronteerd worden en de reikwijdte van de ‘virale werking’ moeten bepalen. Bij een onjuiste inschatting daarvan zou het gevolg kunnen zijn dat een proprietary programma vrij moet worden gegeven. Dit kan met name desastreus uitpakken voor bedrijven die van de licentie-inkomsten van hun programmatuur afhankelijk zijn.

6.3.1

Het begrip ‘afgeleid werk’

De bepaling die de copyleft-voorwaarde bevat en die tot virale werking leidt, is artikel 2 van de GPL. Dit artikel bepaalt: ‘You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions a) (…) b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this [GPL] License’ c) (…).’ [nadruk toegevoegd; auteurs]

In Artikel 0 van de GPL wordt een ‘work based on a Program’ gedefinieerd als ‘either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language’.

Wat betekent dit begrip ‘derivative work’, in het Nederlands, ‘afgeleid werk’? Men kan twee interpretaties onderscheiden: de auteursrechtelijke uitleg, versus de uitleg van de FSF en anderen. Art. 0 van de GPL verwijst voor het begrip ‘afgeleid werk’ naar het auteursrecht, hetgeen wijst op een auteursrechtelijke uitleg van dit begrip. Men zal dit begrip dan moeten uitleggen naar het op de concrete casus toepasselijke auteursrecht.

32

In die zin bijvoorbeeld C. De Preter/ H. Dekeyser, De totstandkoming en draagwijdte van open source licenties’, Computerrecht 2004/5, pp. 216-220. In dat verband wordt vaak gewezen op het feit dat in artikel 0 van de GPL wordt verwezen naar een ‘work based on the Program under copyright’. Vgl. voor het Amerikaanse auteursrecht artikel 17 U.S. Code 101 (de Amerikaanse Auteurswet), die ‘derivative work’ definieert als: ‘a work based one or more preexisting works, such as a translation, musical, arrangement, dramatization, fictionalization, motion picture abridgement, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a ‘derivative work’.’

101


Als we uitgaan van de toepasselijkheid van Nederlands auteursrecht, geldt het volgende. De Nederlandse Auteurswet kent het begrip ‘afgeleid werk’ als zodanig niet. In het handboek van Spoor, Verkade en Visser wordt voor het begrip afgeleid werk gedoeld op een werk waarin delen uit een ander, origineel werk zijn overgenomen (al dan niet in gewijzigde vorm).33 Auteursrechtelijk gezien is sprake van een bijzonder geval van een ‘verveelvoudiging al dan niet in gewijzigde vorm’ (artikelen 1 en 10 lid 2 Aw). De rechthebbende op het originele werk kan zo’n verveelvoudiging verbieden. Wat betekent dit nu voor de GPL? Indien een GPL-programma wordt aangepast, blijft de GPL op dat aangepaste programma van toepassing. Een dergelijk aangepast programma is een afgeleid werk, zowel op grond van de GPL als in auteursrechtelijke zin naar Nederlands recht. Immers, het is een verveelvoudiging in gewijzigde vorm (in de zin van artikel 10 lid 2 Aw) van het GPL-programma. De GPL laat zo’n verveelvoudiging van het afgeleide werk alleen toe onder de condities van de GPL. Indien GPL-code in een ander programma wordt opgenomen, is ook duidelijk, dat dat gehele programma opnieuw een afgeleid werk is en daarom onder de GPL valt. Ook dan is het een verveelvoudiging in gewijzigde (en vermeerderde) vorm. In het geval dat een systeem echter wordt vervaardigd door een oorspronkelijk proprietary programma te koppelen aan GPL-code, wordt dat oorspronkelijke deel niet een afgeleid werk in auteursrechtelijke zin: het is immers een zelfstandige schepping, los van GPL-code. In een auteursrechtelijke uitleg van de GPL zou dus alleen sprake zijn van een ‘afgeleid werk’ als er GPL-code wordt overgenomen in auteursrechtelijke zin. Deze uitleg wordt door diverse auteurs verdedigd, mede op basis van het Amerikaanse auteursrecht, dat een vergelijkbare definitie van ‘afgeleid werk’ hanteert.34 Een ruimere uitleg wordt verdedigd door de FSF. In deze uitleg zou in sommige gevallen wel door het ‘combineren’ van twee programma’s een afgeleid werk ontstaan. Een voorbeeld is een stuurprogramma (driver) voor hardware dat

33

http://www.gnu.org/licenses/gpl-faq.html. Vgl. L. Rosen, Open Source Licensing: Software Freedom and Intellectual Property Law, Upper Saddle River (New Jersey), 2004 en P. Albert, A Consumer’s Review of the General Public License, Linux Insider, July 20, 2004 te vinden op: http://www.technewsworld.com/story/35193.htm. De FSF suggereert overigens zelf dat haar ruime interpretatie spoort met de betekenis die het begrip afgeleid werk heeft onder het Amerikaanse auteursrecht. 34

102


bedoeld is met het Linux besturingssysteem samen te werken, en samen met Linux verspreid wordt. In de FAQ die door de FSF zijn gepubliceerd, staat over zulke gevallen:35 ‘However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program. The difference between this ‘incorporating’ the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can’t treat them as two separate programs. So the GPL has to cover the whole thing.’

Elders staat in de FAQ dat: ‘What constitutes combining two parts into one program. This is a legal question, which ultimately judges decides. We believe that a proper criteria depends both on the mechanism of communication (exec, pipes, rpc, function falls with a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged.’

Het in de FAQ gesuggereerde criterium dat de rechter zou moeten hanteren, is een (ingewikkeld) technisch criterium, niet een auteursrechtelijk criterium. Ook de vermelding in artikel 2, slot, van de GPL naar ‘can be reasonably considered independent and separate works in themselves’ is geen auteursrechtelijk criterium. Ook een voorwoord bij een gedichtenbundel is bijvoorbeeld geen onafhankelijk, zelfstandig werk (want is bedoeld om met de bundel te worden verspreid), maar het is auteursrechtelijk uiteraard geen afgeleid werk, als er geen stukken uit de gedichten zijn overgenomen. Als het begrip afgeleid werk in auteursrechtelijke zin moet worden uitgelegd, zijn de in de FAQ gesuggereerde technische criteria niet richtinggevend. Er staan derhalve twee interpretaties van het begrip afgeleid werk tegenover elkaar: de ruime interpretatie van de FSF (en vele andere GPL-aanhangers) en de beperkte auteursrechtelijke interpretatie. Het verschil draait er om of ‘afgeleid werk’ ophoudt bij het auteursrechtelijke begrip, of ook ‘lossere’ vormen van ‘afleiding’ tellen. Voor beide interpretaties geldt als grens, dat een programma niet reeds ‘besmet’ wordt door de GPL uitsluitend omdat het samen met een GPL-programma wordt

35

Zie hierover nader C. De Preter/ H. Dekeyser, De totstandkoming en draagwijdte van open source licenties’, Computerrecht 2004/5, pp. 216-220.

103


verspreid. In dit verband kan worden gewezen op het slot van artikel 2 van de GPL, dat expliciet aangeeft dat ‘mere aggregation’ er niet toe leidt dat een ander werk onder de GPL moet worden gebracht. Er moet een nauwer verband zijn dan de enkele gezamenlijke verspreiding van twee zelfstandige programma’s op één medium, of het installeren op één PC. Verder is ook algemeen aanvaard dat door het enkel samenwerken van twee zelfstandige werken het ene programma geen afgeleid werk wordt van het originele programma, zoals het geval is bij het ‘draaien’ van een proprietary applicatie op een Linux (besturings)programma. Er zijn ook andere interpretaties, die tussen de auteursrechtelijke en de FSF interpretatie liggen. Binnen de GPL-gemeenschap heerst geen consensus.36 Als illustratie van dit laatste kan worden genoemd het feit dat zelfs de auteurs van de GPL, Richard Stallman en Eben Moglen, op een aantal (belangrijke) punten van mening verschillen.37 Verder heeft Linus Torvalds, de grondlegger van Linux, een eigen uitleg gegeven aan het begrip afgeleid werk met betrekking tot besturingsprogrammatuur (drivers) die dynamisch gelinkt worden aan de Linux kernel.38 Hij is van oordeel dat een programma dat draait ‘op’ de kernel niet onder de GPL valt, niet omdat er een uitzondering zou gelden, maar omdat dit programma gewoon de standaard ‘interfaces’ van de kernel gebruikt en daarom geen afgeleid werk is.39

6.3.2

Afgeleid werk en ‘linken’

Het verschil tussen beide interpretaties komt in het bijzonder tot uiting bij een veelgebruikte technische vorm van ‘combineren’ van verschillende stukken van

36

Er lijkt sprake te zijn van een wijziging van standpunten in de tijd, mede verband houdende met het gegeven dat aanvankelijk de beschikbare hardware drivers onafhankelijk van Linux waren vervaardigd, terwijl nieuwere drivers gemaakt zouden zijn om goed te functioneren met Linux. Zie hierover: en . De huidige versie van Linux maakt er bij het opstarten er melding van als het systeem besmet (tainted) is door proprietary software drivers. Nieuwe drivers moeten GPL-drivers zijn om in de Linux kernel te worden opgenomen. Overigens is de interpretatie van Torvalds niet bindend, nu hij niet de enige auteur is van Linux. 37 Zie: . De mythische ‘binary exception clause’ bestaat dus volgens hem niet; er is niet meer dan een verduidelijking dat programmatuur geen van de kernel afgeleid werk is. 38 De vraag of linking resulteert in een afgeleid werk kwam onder meer aan de orde in de zaak Progress Software Corp. V. MySQL AB, Civil Action No. 01-11031 PBS. Deze zaak is evenwel geschikt zodat de rechter zich niet hierover heeft hoeven uitspreken. Zie over deze zaak: Court Evaluates Meaning of ‘Derivative Work’ in an Open Source License, te vinden op: . 39 Zie over linking en libraries: . Voor de goede orde melden wij dat hier te bespreken ‘linken’ niet verward moet worden met het gebruik van hyperlinks op internet.

104


programmatuur: het ‘linken’. De discussie rond de vraag, wanneer sprake is van een afgeleid werk in de zin van de GPL, spitst zich met name toe op de vraag of door het combineren van een oorspronkelijk programma met subroutines uit een GPL bibliotheek (library) door middel van linken een combined work ontstaat dat een afgeleid werk is, en daarmee onder de GPL moet worden gebracht.40 Hierover bestaan misverstanden, waardoor ten onrechte wordt aangenomen dat linken altijd of juist nooit een afgeleid werk zou opleveren. Dit geldt ook als men uitgaat van een auteursrechtelijke uitleg. Daarom is het nodig in te gaan op het technische fenomeen linken.41 Om een programma in staat te stellen gebruik te maken van bepaalde standaard hulpfuncties die in een bibliotheek zijn opgenomen, dienen er verwijzingen (links) in het programma naar de bibliotheek te worden aangebracht. 42 Dit linken kan op verschillende manier gebeuren. Allereerst kunnen er vaste verwijzingen naar de objectcode van de library subroutines worden aangebracht. Een gangbare werkwijze is de volgende. De compiler vertaalt de broncode tot object code, die slechts losse verwijzingen naar de library functies bevat. Vervolgens gaat een speciaal programma, de linker, deze verwijzingen ‘oplossen’ (resolve). Voor elke verwijzing haalt de linker het bijbehorende stukje objectcode van de functie uit de bibliotheek, plakt dit aan de objectcode van het programma, en past de verwijzing aan om naar dat aangeplakte stukje te verwijzen. Het resulterende geheel, de objectcode van programma plus gebruikte hulpfuncties, wordt samengevoegd tot één in zijn geheel uitvoerbaar bestand (executable). Dit zijn statische links.43

40

Een bibliotheek (library) is een verzameling van veelgebruikte hulpfuncties (in de vorm van ‘subroutines’); de programmeur hoeft die functie dan niet zelf te programmeren. Een voorbeeld van een library is een verzameling van hulpfuncties voor het printen op verschillende printers. Zie . 41 C. De Preter/H. Dekeyser, ‘De totstandkoming en draagwijdte van open source licenties’, Computerrecht 2004/5, p. 219 verwarren dit met het volledig integreren van de bibliotheek functies in broncode vorm. 42 Bepaalde subroutines worden vaak door vele applicaties worden gebruikt. Indien door iedere applicaties steeds de object code van de subroutine zou worden ingekopieerd, zou dit betekenen dat meerdere kopieën van dezelfde subroutine worden opgeslagen, wat nodeloos veel geheugenruimte vergt. Dynamisch linken doet dit niet, en maakt derhalve efficiënter gebruik van de beschikbare geheugenruimte. 43 Zie bijvoorbeeld: Matt Asay, The GPL: Understanding the License that Governs Linux, te vinden op: . Lawrence Rosen, GPL, legally speaking, in: Open, April 2001, p. 39 – 40, te vinden op: . In zijn boek stelt Rosen echter dat linking geen derivative works creëert, doch hooguit een collective work (verzamelwerk). In dat verband stelt hij verder dat de GPL ‘will ultimately be read by the courts to mean that derivative works are subject to the GPL’s reciprocity [copyleft] provisions, but collective works are not’ (L. Rosen, Open Source Licensing: Software Freedom and Intellectual Property Law, Upper Saddle River (New Jersey), 2004, p. 120). Zijn standpunt miskent echter dat in ieder geval bij static linking een afgeleid werk ontstaat (executable).

105


Een andere methode van linken bestaat eruit, dat pas op het moment dat het die functie daadwerkelijk nodig heeft, via een verwijzing het programma een hulpfunctie aanroept. Meestal wordt het besturingssysteem van de computer gevraagd om deze functie te traceren en uit te voeren. De objectcode van de subroutine wordt dus niet gekopieerd in de executable.44 De library en het programma blijven gescheiden van elkaar. Dit wordt dynamisch linken genoemd. Voorbeelden zijn zogenaamde DLL’s (Dynamic Link Libraries) in Windows. Het is algemeen aanvaard dat in geval van static linking de executable een afgeleid werk is, omdat de code van de bibliotheek in de executable is overgenomen.45 Er is sprake van een verveelvoudiging van de OSS-code in auteursrechtelijke zin. Dit geldt echter alleen voor de executable, niet voor de broncode. Voordat de executable wordt gecreëerd is er geen sprake van een afgeleid werk in auteursrechtelijke zin. Immers, op dat moment is er geen code van de bibliotheek overgenomen in de broncode van het programma (dat gebeurt pas bij het maken van de executable). Evenmin is de broncode van het programma dat een statische link bevat aan te merken als een afgeleid werk van de bibliotheek, enkel omdat er een link is aangebracht. De link in de broncode is immers slechts een verwijzing, geen kopie. Vergelijk de voetnoot die naar een ander werk verwijst, wat op zichzelf evenmin een verveelvoudiging in auteursrechtelijke zin is van dat andere werk. Dat de broncode toch moet worden vrijgegeven onder de GPL, komt doordat voor de distributie van het gecombineerde afgeleide werk (de executable) auteursrechtelijke toestemming vereist is. De vraag of door dynamisch linken het programma een afgeleid werk wordt, is meer omstreden. Het programma en de bibliotheek blijven immers geheel afzonderlijk bestaan; er wordt slechts verbinding gemaakt bij het uitvoeren en er wordt geen code van de bibliotheek in het programma overgenomen. In auteursrechtelijke zin wordt het programma dat dynamisch linkt geen afgeleid werk van de bibliotheek. De FSF stelt zich niettemin op het standpunt dat het resultaat van het linken is dat het programma dat aan een GPL-library linkt (ongeachte de methode) een afgeleid werk wordt van de bibliotheek. In de benadering van de FSF wordt het resultaat van het linken als een soort van ‘gezamenlijk programma’ gezien, dat een

44

Richard Stallman, Why you shouldn’t use the Library GPL for your next library, te vinden op: . Oorspronkelijk was de Lesser GPL ook Library GPL genoemd, maar vanwege de bedenkingen daartegen heeft men hem hernoemd in Lesser GPL. 45 Zie .

106


afgeleid werk is. Vanuit gebruikers- en technisch perspectief is dit op zichzelf niet zo een vreemde gedachte. Immers, de methoden van linking zijn weliswaar verschillend, maar het resultaat is feitelijk hetzelfde. In de visie van de FSF heeft het programma geen zelfstandig bestaansrecht: het heeft immers de bibliotheek nodig om te kunnen functioneren. Dan zou dus ook de broncode van het programma zelf al een afgeleid werk zijn, niet slechts de executable. Dit is echter een functionele, en geen auteursrechtelijke benadering. In deze uitleg kan de werking van het copyleft-beding niet worden afgedwongen louter op basis van vereiste auteursrechtelijke toestemming (zie hierna, par. ‘Juridische werking’). Verder zou deze uitleg tot gevolg hebben dat de distributie van de broncode op zichzelf al zou verplichten tot vrijgave onder de GPL. Dat strookt echter niet met het slot van art. 2 GPL, waar staat dat een stuk dat niet is afgeleid van OSS en dat afzonderlijk wordt gedistribueerd, niet onder de GPL hoeft te worden gebracht. Een alternatieve verdediging van het FSF-standpunt zou op het volgende kunnen zijn gebaseerd. Om een programma te laten linken naar een bepaalde bibliotheek, moet men daar in het ontwerp van het programma rekening mee hebben gehouden. Zo moet het programma bijvoorbeeld de subroutines met de juiste waarden en invoerwaarden aanroepen, die in de bibliotheek zijn gedefinieerd (in zogenaamde header files), die in zekere zin worden geïncorporeerd in de gecompileerde object code. In die zin kan men dus zeggen dat het programma ‘gebaseerd’ is op de bibliotheek. Naar onze mening kan dit ‘baseren op’ echter in het algemeen niet worden aangemerkt als het overnemen van auteursrechtelijk beschermde trekken van de bibliotheek, zodat dit niet tot gevolg heeft dat het programma om die reden als een afgeleid werk dient te worden beschouwd. In bijzondere gevallen zou dit evenwel anders kunnen zijn. Het lijkt er dan ook op dat de FSF-interpretatie onjuist is. Geheel zeker is dit evenwel niet.

6.3.3

Lesser GPL en andere uitzonderingen op de GPL

Uit het voorgaande volgt dat GPL-bibliotheken vaak ongeschikt zijn voor gebruik voor ontwikkeling van proprietary applicaties. Ten eerste zal bij het statisch linken de applicatie zonder meer onder de GPL moeten worden gebracht. Ten tweede is er onzekerheid over de vraag of ook dynamisch linken met GPLbibliotheken leidt tot het ontstaan van een afgeleid werk. Dit leidde tot terughoudendheid in het gebruik van GPL bibliotheken voor proprietary applicaties. Om dit gebruik toch aan te moedigen is een variant op de GPL ontwikkeld, te weten de Lesser GPL (LGPL).

107


Met de LGPL wordt een midden gevonden tussen twee wensen. Enerzijds is er het verlangen de doelstelling van de OSS-beweging om software vrij te houden overeind te houden. Daarvoor wordt nog steeds bedongen dat de LGPL en wijzigingen daarvan enkel onder de LPGL mogen worden (verder) gedistribueerd. Anderzijds is er de wens om OSS aantrekkelijk te laten zijn als basis voor commerciële software-ontwikkeling. Hiervoor geeft de LGPL aan dat het dynamisch of statisch linken naar een LGPL-library er niet toe verplicht dat het linkende programma onder de LGPL moet worden vrijgegeven. Er staan overigens wel andere verplichtingen tegenover, mede afhankelijk van het soort linken. Voor de exacte wijze waarop dit is geregeld verwijzen wij naar de tekst van de LGPL. Inmiddels lijkt de FSF overigens terug te komen van de wenselijkheid van de LGPL variant. Zo is Richard Stallman van mening dat door libraries uitsluitend beschikbaar te stellen onder de GPL, de leden van aan de open source gemeenschap elkaar kunnen helpen programma’s te ontwikkelen die beter zijn dan de proprietary alternatieven, waardoor de OSS-gedachte aan populariteit zal winnen.46 Een andere afwijking op de GPL waarmee de FSF instemt, heeft betrekking op programma’s waarmee nieuwe programma’s kunnen worden gemaakt. Een voorbeeld zijn compilers. Dit zijn programma’s die broncode vertalen in object code. Bij het compileren wordt soms een deel van de code van de compiler in het nieuwe programma opgenomen. Indien de GPL strikt zou worden toegepast, zou het gehele gecompileerde programma onder de GPL vallen. Dit zou tot gevolg hebben dat de compiler niet geschikt zou zijn voor het ontwikkelen van proprietary programma’s. Om die reden zou men hiervoor een uitzondering kunnen maken op de GPL licentie. Dit komt ook daadwerkelijk voor. Men dient er echter op bedacht te zijn dat dergelijke uitzonderingen geen deel uitmaken van de GPL. Het is aan de licentiegevers om al dan niet een uitzondering toe te passen. Men zal dus steeds moeten controleren of zo’n uitzondering van toepassing is verklaard op het specifieke programma en de specifieke versie die men wenst te gebruiken. Een aardig voorbeeld hiervan zien we in de zaak Computer Associates v Quest Software. (US District Court, Northern District of Illinois 6 juni 2004, zaak 02 C 4721). Dit betrof een procedure die Computer Associates instelde omdat ex-

46

Merk op dat de MPL voor zulke gevallen minder ver gaat: zij vergt slechts dat de broncode van eventueel gewijzigde MPL-bestanden wordt vrijgegeven.

108


medewerkers broncode zouden hebben gebruikt voor een product van Quest. Onder II.A.2.a, ‘Valid copyrights’ bespreekt de rechtbank een verweer van Quest, dat inhield dat ook Computer Associates het auteursrecht op deze werken niet bezat. De code bevatte de vermelding ‘GNU Bison version 1.25’, waaruit zou blijken dat het een afgeleid werk was van het onder de GPL-licentie vallende programma Bison. De rechtbank verwerpt dit betoog. Allereerst wordt er geen auteursrecht geclaimd op het programma Bison. Daarnaast stelt de rechtbank vast dat uitvoer van Bison niet valt onder de GPL. Hiervoor is vanaf versie 1.24 een uitdrukkelijke uitzondering gemaakt.47 Zonder die uitzondering op de GPL zou de uitvoer kennelijk wel onder de GPL vallen.

6.3.4

De juridische werking van de verervende copyleftvoorwaarde

Een laatste opmerking betreft de wijze waarop de verervende copyleft-voorwaarde van de GPL juridisch kan worden afgedwongen, hetgeen van belang kan zijn bij de juridische afdwingbaarheid van een ruimere interpretatie van het begrip ‘afgeleid werk’ in de GPL. In het geval van een programma dat GPL-code bevat, kan de copyleft-voorwaarde eenvoudig worden afgedwongen. Voor de distributie van het programma met de GPL-code is immers de auteursrechtelijke toestemming van de auteursrechthebbenden op de GPL-code nodig. Die toestemming verleent de GPL alleen onder de voorwaarde dat ook de broncode van de overige delen van het programma wordt vrijgegeven onder de GPL. Men kan artikel 2 van de GPL lezen alsof zij slechts op deze basis de voorwaarde wenst af te dwingen, wat strookt met een beperkte, auteursrechtelijke interpretatie van het begrip afgeleid werk.48 Dit is vergelijkbaar met het geval dat een uitgever toestemming nodig heeft van de auteur van een artikel, als hij een boek wil uitgeven waarin dat artikel is opgenomen. Als men evenwel in navolging van de FSF een ruimere definitie van het begrip afgeleid werk verdedigt, kan de copyleft-voorwaarde niet langs deze weg worden afgedwongen. Dit geldt in het bijzonder bij een programma dat auteursrechtelijk niet een afgeleid werk is van de GPL-code, zoals bij een dynamisch gelinkte

47

Verschillende Amerikaanse rechtbanken lijken de vraag wat een derivative work is met betrekking tot computerprogramma’s niet eenduidig te beantwoorden. Vgl. Dan Ravicher, Software Derivative Work: A Circuit Dependent Determination, te vinden op: . 48 We beperken ons hierbij tot de auteursrechtlicentie ten aanzien van OSS.

109


GPL-bibliotheek. Er is dan immers geen sprake van openbaarmaking van een auteursrechtelijk afgeleid werk, dus is er voor de verspreiding van het eigen programma geen auteursrechtelijke toestemming nodig van de auteursrechthebbenden op de GPL-code. Toch kan ook een ruimere uitleg van het begrip afgeleid werk worden afgedwongen. In een OSS-licentie kan aan een begrip als afgeleid werk iedere betekenis worden gegeven die de opsteller wenst. Als het eigen programma wordt verspreid tezamen met de GPL-code (zoals een programma met een dynamisch gelinkte GPL-bibliotheek) is de grond waarop de licentie wordt afgedwongen dan niet dat er een afgeleid werk in auteursrechtelijke zin wordt verspreid, maar dat er voor de verspreiding van de OSS-code zelf toestemming nodig is. Dit is vergelijkbaar met de situatie dat een auteur slechts toestemming geeft om zijn artikel uit te geven, als de uitgever ook een tekst van een ander gratis verspreidt. Deze argumentatie past evenwel minder goed bij de formulering van artikel 2 GPL, die lijkt uit te gaan van het geval dat GPL-code wordt opgenomen in een groter werk, niet slechts samen wordt gedistribueerd. Zelfs is theoretisch mogelijk dat de copyleft-voorwaarde kan worden afgedwongen als het programma wordt gedistribueerd zonder GPL-code: dat zou dan moeten berusten op de omstandigheid dat de ontwikkelaar de OSS binnen de onderneming heeft gebruikt en daar de licentie voor heeft aanvaard. De GPL geeft evenwel aan dat voor intern gebruik geen toestemming (en dus geen aanvaarding van de GPL) is vereist, zodat dit geval zich in feite niet voordoet. Indien de ruime interpretatie die de FSF en andere GPL-aanhangers hanteert al juist is, kan deze ‘virale werking’ van de GPL alleen gerealiseerd worden langs een verbintenisrechtelijke weg, namelijk doordat voor een andere handeling (het openbaren van de GPL-code naast de code zelf) toestemming is vereist, waarbij het begrip afgeleid werk een ruimere invulling heeft dan de auteursrechtelijke uitleg van dat begrip. Daarbij merken wij nog wel op dat de FSF zelf suggereert dat haar interpretatie overeenkomt met het auteursrechtelijke begrip.

6.4

Besluit

Een belangrijk verschil tussen de verschillende OSS-licenties is gelegen in het copyleft-principe. Dit is met name van belang voor de beoordeling van de geschiktheid van een bepaald stuk OSS voor commercieel gebruik. Daarnaast

110


zijn er andere kleine verschillen, die het combineren van verschillende stukken OSS zouden kunnen beletten. Wat de juiste interpretatie is van het begrip ‘afgeleid werk’ in de GPL, is op dit moment onzeker. Uitgaande van de huidige tekst van de GPL heeft de auteursrechtelijke uitleg van dit begrip onze voorkeur, mede nu de tekst zelf in die richting wijst, en die norm objectief bepaalbaar is. Overigens erkennen wij dat zelfs bij een auteursrechtelijke uitleg de onduidelijkheid en derhalve onzekerheid nog niet geheel verdwenen is. Dit is onder meer het gevolg van het feit dat er nog weinig jurisprudentie bestaat over de betekenis van het begrip afgeleid werk met betrekking tot computerprogramma’s.49 Alhoewel het ‘virale’ karakter van de GPL naar onze mening lang niet zo ver gaat als door sommigen wordt gesteld, blijft de exacte uitleg vooralsnog onzeker. Indien men bereid is het eigen ontwikkelde programma vrij te geven onder de GPL, is die onzekerheid geen bezwaar. Indien men een programma echter proprietary (of onder een andere OSS-licentie) wil houden en toch wil verspreiden, zal men van geval tot geval moeten nagaan of er een risico bestaat dat het programma onder de GPL zal moeten worden vrijgegeven. In dat geval zal men zich uiteraard ervan moeten vergewissen dat code van derden die men in het programma opneemt, niet onder de GPL valt. Dit is echter relatief eenvoudig en in wezen niet anders dan bij het gebruik van welke software van derden dan ook. Immers, men zal altijd moeten nagaan of men de rechten heeft om de software van derden voor het beoogde doel te gebruiken en of men de daaraan verbonden licentievoorwaarden aanvaardbaar acht. Indien men geen GPL-code opneemt in een programma, maar het programma wel tezamen met GPL code distribueert, of als het programma bedoeld is om te werken met een GP-programma (en dus niet geheel onafhankelijk en zelfstandig is), is er vanwege de onzekerheid over de uitleg van de GPL twijfel of dit tot gevolg heeft dat het programma wordt ‘besmet’ door het GPL-programma. In zulke gevallen lijkt het beter om een andere, veiligere oplossing te zoeken, zoals het afzien van gezamenlijke distributie.

49

Dit hoofdstuk is deels gebaseerd op het artikel: E.P.M. Thole/W. Seinen, Open Source Software: een civielrechtelijke analyse, Computerrecht 2004/5, pp. 221-225.

111

7

Een vermogensrechtelijke verkenning van OSS-licentiëring Martine Boonk, Arno van Hekesen, Walter van Holst, Wouter Seinen, Elisabeth Thole, Eric Tjong Tjin Tai en Eva Visser

De opkomst van OSS gaat onvermijdelijk gepaard met de vraag naar de rechtsgeldigheid van de daarvoor gehanteerde licentievoorwaarden.1 Belangrijke vraag daarbij is hoe deze licentie(voorwaarden) naar Nederlands recht te kwalificeren zijn. Verschillende visies komen aan de orde: de licentie als (onderdeel van) een contractuele relatie of als het eenzijdig ‘afstand’ doen van een recht. Indien ervan wordt uitgaan dat sprake is van een contract, rijst als vervolgvraag hoe deze rechtsverhouding totstandkomt, en wie daarbij partij zijn, vooral omdat bij de ontwikkeling en distributie van OSS veel verschillende partijen betrokken zijn. Nog een ander relevant aspect hierbij is of de OSS-licentievoorwaarden algemene voorwaarden zijn in de zin van het Burgerlijk Wetboek, en zo ja, op welk moment deze rechtsgeldig van toepassing zijn verklaard. Alvorens op deze vragen in te gaan, wordt eerst kort uiteengezet hoe OSS feitelijk ter beschikking wordt gesteld.2

7.1

De feitelijke terbeschikkingstelling van OSS

Verspreiding van OSS vindt vooral plaats via het internet op verschillende elektronische uitwisselingsplatforms.3 Verschillende verspreidingsmethoden zijn te onderscheiden: a de afnemer downloadt een kant-en-klare executable of een gecomprimeerd bestand via een web- of ftp-site die hij – eventueel na het uitpakken van het bestand – direct kan gebruiken;

1

Bijvoorbeeld: < http://sourceforge.net > en:< http://www.ososs.nl>. Scripts worden aangeboden in een scripting taal, bijvoorbeeld PHP of Javascript. Scripting talen zijn computertalen die geïnterpreteerd worden in plaats van gecompileerd. Als zodanig is scripting software bijna per definitie gelijk aan de broncode. Veel van de scripts worden integraal op webpagina’s aangeboden. Soms met de licentie tussen commentaartekens erbij vermeld. De ontvanger wordt geacht met een knip- en plakfunctie in zijn browser het script op het doelsysteem te installeren. Met name op discussiefora over specifieke technische onderwerpen vindt een levendige uitwisseling van dergelijke te interpreteren code plaats. Het downloaden vindt plaats door het bezoeken van de desbetreffende webpagina. 3 Zie bijvoorbeeld voor Perl modules of voor een Linux distributie waarvan de programmatuur op deze wijze verspreid wordt. 2

113


b de afnemer kopieert een script van een webpagina en neemt de gekopieerde code over in zijn eigen systeem;4 c de afnemer downloadt één of meerdere bestanden die door middel van de nodige technische handelingen, zoals compilatie en installatie, in het doelsysteem wordt geïmplementeerd; d de afnemer downloadt een bestand dat eerst na activering met de installatieprocedure start; e de afnemer krijgt een CD-ROM met OSS toegestuurd; f de afnemer downloadt een programma waarmee reeds bij de afnemer in gebruik zijnde software (automatisch) wordt aangepast of uitgebreid (ook wel exentension of plugin genoemd) op bestaande software, bijvoorbeeld een Mozilla plugin die advertenties blokkeert of een functiebibliotheek voor een programmeertaal.5 De gekozen verspreidingsmethode zal mede afhangen van de aard van de software en het (technische) kennisniveau van de personen die de OSS ter beschikking stellen en hun ‘doelgroep’. In de regel wordt OSS steeds tezamen met de broncode onder een licentie verstrekt.6 Al naar gelang de gekozen verspreidingsmethode, varieert ook de wijze waarop de toepasselijke licentievoorwaarden worden aangeboden. Bij het downloaden van een gecomprimeerd bestand (methode sub a) zal de licentie doorgaans als een klein tekstbestand in het gecomprimeerde bestand zijn opgenomen. Veelal heeft een dergelijk bestand een naam als ‘LICENSE.TXT’ of ‘COPYING’. Bij het rechtstreeks overnemen van scripts uit een internetpagina (methode sub b) worden aparte licentievoorwaarden in de regel niet automatisch mee gekopieerd.

4

Op grond van Section 2 van de open source definition (OSD) is het niet verplicht om de source code tegelijkertijd met de software ter beschikking te stellen. Voorwaarde is slechts dat de source code tegen maximaal de reproductiekosten te verkrijgen is, bij voorkeur door de source code gratis op het internet aan te bieden. De OSD is te vinden op: . 5 Mirror sites bevatten een kopie van (een gedeelte) van een bepaalde website, die wordt aangeboden vanaf een andere computer dan de oorspronkelijke website. Zie voor een algemene beschrijving van de verschillende verschijningsvormen en motieven voor ‘mirroring’ < http://encyclopedia.thefreedictionary.com/Mirror+Sites >. Naast het ‘spiegelen’ van hele internetpagina’s zijn andere veelgebruikte distributievormen op het internet het aanbieden door derden van specifieke bestanden op hun eigen website en het verspreiden van (Open Source) software via zogenaamde peer-to-peer systemen. 6 Zie over de shrink-wrap licentie onder meer: R. Westerdijk/F.A.M. van der Klaauw-Koops, De shrink-wrap licentie, Computerrecht 1991/1, pp. 18-14; F.A.M. van der Klaauw-Koops, ‘Shrink-wrap overeenkomst’, in: Automatiseringscontracten, D.1.5 (januari 1996); en F.W. Grosheide, Mass-market exploitation of digital information by the use of shrinkwrap en click-wrap licenses; A Dutch perspective on article 2B UCC, in: F.W. Grosheide/K. Boele-Woelki (red.), Europees Privaatrecht, Opstellen over Internationale Transacties en Intellectuele Eigendom, Molengrafica 1998, pp. 263-319; M.W. Scheltema en T.F.E. Tjong Tjin Tai, Overeenkomst sluiten door openen en klikken?, Computerrecht 2003/4, pp. 244-248.

114

Een vermogensrechtelijke verkenning van OSS-licentiëring

Soms maken (verwijzingen naar) licentievoorwaarden wel deel uit van de script c.q. codetekst. Als dan kunnen deze voorwaarden door de afnemer worden mee overgenomen Onderstaande figuur is een voorbeeld van programmacode, die rechtstreeks met behulp van ‘knippen en plakken’ van het internet kan worden overgenomen en geïncorporeerd in het doelsysteem, zonder dat daarbij evenwel een verwijzing naar licentievoorwaarden is opgenomen.

Bij het downloaden van code die nog gecompileerd of anderszins geïmplementeerd moet worden (methode sub c). wordt er daarnaast vaak tevens een (tekst)bestand meegeleverd met daarin de licentievoorwaarden. Tevens is het mogelijk dat de licentievoorwaarden als ‘commentaarregels’ in de broncode zelf zijn opgenomen. Gaat het om het downloaden van een grafische installer of de aanschaf van een CD-ROM (methoden sub d en e), dan worden de licentievoorwaarden daarentegen veelal aan de afnemer gepresenteerd tijdens het installatieproces. Onderstaande figuur illustreert dit.

115


Als sprake is van plugins of extensions (methode sub f), dan wordt het presenteren of bijsluiten van de licentievoorwaarden vaak achterwege gelaten. Meestal wordt volstaan met de vermelding dat een bepaalde open source licentie van toepassing is zonder de licentievoorwaarden zelf ter beschikking te stellen. Zo staat er bijvoorbeeld: ‘This software shall be subject to the GPL License’, zonder dat zelfs maar een link naar die betreffende licentie is opgenomen. Soms presenteert het programma bij het eerste gebruik de licentievoorwaarden op het scherm aan de afnemer. Zoals hiervoor is aangegeven kan OSS op uiteenlopende wijzen worden verkregen. De licentievoorwaarden worden in veel gevallen wel op enigerlei wijze beschikbaar gesteld, maar de afnemer wordt slechts in een beperkt aantal gevallen daadwerkelijk verplicht om de licentievoorwaarden middels een bepaalde (technische) handeling uitdrukkelijk te aanvaarden. In veel gevallen kan dus niet zonder meer worden vastgesteld of bij het verkrijgen van de software de toepasselijkheid van de daarbij gaande licentie voorwaarden ook echt is overeengekomen.

7.2

Aanschaf en licentiëring van OSS

Uit de hierboven genoemde methoden volgt dat de aanschaf van OSS doorgaans zowel het verkrijgen van de betreffende computerbestanden (meestal in digitale vorm) als de installatie daarvan op de computer van de afnemer omvat. Degene die de OSS downloadt, hoeft echter niet steeds degene te zijn die zelf gebruik gaat maken van de OSS. Tegelijk hoeft degene die de OSS ter beschikking stelt, niet steeds tevens de licentiegever te zijn. Veel OSS wordt bijvoorbeeld 116


op zogenaamde ‘mirror sites’7 aangeboden door sympathisanten van de programmatuur, maar ook door andere belanghebbenden. Denk aan internet service providers, die efficiënter gebruik maken van hun netwerkcapaciteit door bestanden vanaf hun eigen server aan te bieden, in plaats van deze steeds opnieuw ‘op te halen’ bij de aanbieder. Goed verdedigbaar lijkt dat bij de aanschaf van OSS achtereenvolgens twee (juridisch) relevante momenten zijn te onderscheiden. In de eerste plaats het moment waarop de OSS feitelijk wordt aangeschaft, en in de tweede plaats het moment waarop een gebruiksrecht wordt verkregen. Deze ‘tweetrapsraket’ vertoont enigszins gelijkenis met de situatie dat software op basis van een shrink wrap licentie wordt verspreid.8 Alsdan wordt de software (opgeslagen op een fysieke gegevensdrager) aangeschaft bij een detaillist. Op dat moment komt er een koopovereenkomst tot stand tussen de koper en de detaillist. De separate licentieovereenkomst komt pas later tot stand, en wel tussen de eindgebruiker en de softwareproducent. Dit louter door het openen van de verpakking. De meningen zijn echter verdeeld over de vraag of deze gang van zaken ook steeds leidt tot de totstandkoming van een licentieovereenkomst, waarop de bijgesloten voorwaarden van toepassing zijn. Bij OSS zijn eveneens de twee verschillende momenten van de feitelijke aanschaf en licentiëring te onderscheiden. Niet geheel duidelijk is hoe het eerste moment, de aanschaf van de OSS, juridisch gekwalificeerd moet worden. Hebben we hier te maken met het totstandkomen van een overeenkomst of slechts feitelijke handelingen, bestaande uit de verstrekking en de ontvangst van de instructie hoe de OSS kan worden verkregen (bijvoorbeeld door het aanklikken van de ‘download knop’)? Het meest waarschijnlijk lijkt dat met de aanschaf van de OSS-bestanden slechts feitelijke handelingen gemoeid zijn. Veelal zal een verkrijger wanneer hij OSS downloadt er niet vanuit gaan dat hij op dat moment een overeenkomst sluit. Overigens is het feit dat men geen weet heeft dat er op dat moment mogelijk (reeds) een overeenkomst totstandkomt, op zichzelf nog niet doorslaggevend. Doorslaggevend

7

Zie over het onderscheid tussen contracten en andere afspraken onder meer: J.H. Nieuwenhuis, Promises, promises. Over contracten en andere afspraken, NJB 2001, pp. 1795-1799. 8 Hier zou mogelijk aansluiting gevonden kunnen worden bij de uitspraak inzake Netwise/NTS (Voorzieningenrechter Rechtbank Rotterdam, 5 december 2002, KG 2003, 15; LJN: AF 2059). Door gedaagde waren verschillende zoekopdrachten op de website van eiseres verricht voor het ‘oogsten’ van e-mailadressen. Volgens de rechter had de gedaagde door deze handelwijze de algemene voorwaarden die op de website van eiseres ter beschikking waren gesteld (via een button) aanvaard. Kennelijk is de rechter er vanuit gegaan dat door het oogsten van de e-mailadressen een overeenkomst is totstandgekomen tussen de partijen, waarop de algemene voorwaarden van toepassing zijn.

117


is of de verkrijger en de ontvanger de wil hadden die gericht is op het rechtsgevolg dat een overeenkomst (tot levering) totstandkomt (artikel 3: 33 BW).9 Deze wil is niet bij iedere verkrijging van OSS aanwijsbaar. Dit zal bijvoorbeeld wel het geval zijn bij de aanschaf van een CD-ROM met daarop OSS, maar niet indien sprake is van het louter downloaden van een OSS-bestand van het internet. Dat neemt niet weg dat het downloaden van OSS bestanden soms wel als een (aanschaf)overeenkomst gekwalificeerd kan worden. Dit kan bijvoorbeeld het geval zijn indien de OSS-bestanden worden verkregen na aanvaarding door het aanklikken van een acceptatiebutton, of indien de OSS-bestanden beschikbaar zijn gesteld op een website waarop een gebruiksovereenkomst van toepassing is verklaard. 10 Het voorwerp van de (aanschaf)overeenkomst zou alsdan zijn het ter beschikking stellen van de OSS-bestanden ‘om niet’.11 De instructie ter verkrijging van de OSS c.q. het ‘uploaden’ van de OSS naar een internet- of ftp-pagina is in deze visie te beschouwen als een gratis openbaar aanbod, dat aanvaard wordt zodra men overgaat tot het downloaden van de OSS. Wat hier verder ook van zij, vanuit juridisch optiek is nog interessanter de vraag naar de kwalificatie van de rechtsverhouding die ontstaat nadat eenmaal verkregen OSS (wordt geïnstalleerd en) in gebruik wordt genomen. Deze rechtsverhouding is immers vooral bepalend voor de juridische positie van de afnemer(s) en de verspreider van de OSS.

7.3

Kwalificatie van de licentiëring van OSS naar civiel recht

Heeft men eenmaal de beschikking gekregen over de OSS, dan betekent dit niet zonder meer dat men de betreffende programmatuur vervolgens ook mag gebruiken. Dit geldt ongeacht of er reeds een leveringsovereenkomst is afgesloten. Het

9

Mochten de feitelijke handelingen rondom de aanschaf van OSS inderdaad als een obligatoire overeenkomst te kwalificeren zijn, dan zou deze overeenkomst mogelijk als schenking in de zin van artikelen 7: 175-188 BW kunnen worden gekwalificeerd. In die zin naar Duits recht onder meer: G. Jakob, Freiheit und Software, p. 76 e.v.: ‘In Deutschland wird der Vertrieb von Software unter der GPL überwiegend als Schenkung gesehen.’ ; en J. Siepmann, Lizenz- und haftungsrechtliche Fragen bei der kommerziellen Nutzung Freier Software, . Aan de kwalificatie van schenking in dit verband kan echter tegengeworpen worden dat er geen sprake is van een daadwerkelijke vermogensverschuiving. De verstrekker behoudt ook nog steeds de beschikking over de OSS-bestanden. Mogelijk is om die reden niet voldaan aan de elementen van schenking, te weten verrijking van de begiftigde “ten koste van het eigen vermogen” van de schenker. 10 Ook als de OSS in bijvoorbeeld scripttaal ter beschikking wordt gesteld, is de OSS vatbaar voor auteursrechtelijke bescherming. Immers, de wijze waarop de OSS is vastgelegd, is irrelevant. Zie P.C. van Schelven/H. Struik, Softwarerecht, Deventer, 1995, p. 18. 11 Overigens laat artikel 45j Auteurswet alleen het maken van verveelvoudigingen toe. Het openbaarmakingsrecht blijft aan de auteursrechthebbende op de software voorbehouden.

118


gebruik van software, en dus ook van OSS, is immers aan te merken als een verveelvoudigingshandeling in de zin van artikel 45i Auteurswet, zodat hiervoor in principe de voorafgaande toestemming van de rechthebbende nodig is.12 Bij gebreke van een contractuele licentie, zal het gebruik van de OSS uitsluitend zijn toegestaan zijn indien een beroep kan worden gedaan op een wettelijke licentie. Wil de afnemer een beroep kunnen doen op de wettelijke licentie van artikel 45j Auteurswet, dan zal hij een ‘rechtmatige verkrijger’ moeten zijn van een ‘exemplaar’ van de software. Bovendien moet de verveelvoudiging noodzakelijk zijn voor het met die software ‘beoogde gebruik’.13 Omdat aan het gebruik van OSS naar haar aard – in overeenstemming met de open source definition – (vrijwel) geen beperkingen zijn gebonden, zal in beginsel elk gebruik van OSS als ‘beoogd gebruik’ aan te merken zijn.14 Lastiger te beantwoorden is de vraag of ook sprake is van rechtmatige verkrijging van een exemplaar van de OSS. Algemeen wordt aangenomen dat degene die een (fysiek) exemplaar van de software krachtens een (koop- of licentie)overeenkomst bij de auteursrechthebbende of diens licentienemer heeft betrokken, een rechtmatige verkrijger is in de zin van artikel 45j Auteurswet.15 Ook de opvolgende verkrijger van hetzelfde (fysieke) exemplaar van de software kan op basis van de uitputtingsleer een

12

Zo bepaalt de open source definition (OSD) dat de licentie in principe geen restricties mag bevatten ten aanzien van het aanpassen en (her)distribueren van de OSS. Evenmin is een beperking van gebruik tot een bepaald ‘field of endeavor’ (zoals voo niet-commerciële doeleinden) toegestaan. Zie . 13 Zie o.a. G. Brunt/E.A.W. Schippers, Intellectuele Eigendom, commentaar bij artikel 45j Auteurswet, en aldaar aangehaalde literatuur en rechtspraak. 14 Vgl. D.W.F. Verkade, T&C, Intellectuele Eigendom, aantekening 1 bij artikel 45j Auteurswet, alsmede dezelfde auteur, Intellectuele eigendom, in: Franken/Kaspersen/De Wild (red.), Recht en computer, Deventer, 2001, p. 225. 15 Het lijkt er alleszins erop dat men indertijd bij het opstellen van artikel 5 lid 1 Softwarerichtlijn (en Overweging 17) en artikel 45j Auteurswet uitsluitend heeft gedacht aan een specifieke versie van de software vastgelegd op een fysieke gegevensdrager. In lijn met de Softwarerichtlijn is zelfs de term “dat werk” uit artikel 45j Auteurswet van het oorspronkelijke Nederlandse wetsvoorstel vervangen door “exemplaar” (vgl. kamerstukken 22.531, nrs. 1, 11, 14 en 15), hetgeen een fysieke drager lijkt te veronderstellen. Een toelichting op dit punt ontbreekt evenwel. Zie voorts over de richtlijn: B. Czarnota/R.J. Hart, Legal Protection of Computer Programs in Europe – A Guide to the EC Directive, Butterworths, London/Dublin/Edinburgh/Munich, 1991, p. 64. Zij spreken over “physical support on which the program is fixed”. De wettelijke licentie van artikel 45j Aw is nauw verwant met de uitputtingsleer. Naar algemeen wordt aangenomen, beperkt de uitputting zich tot stoffelijke exemplaren (zie o.a. de Auteursrichtlijn, Pb EG L 167 van 22 juni 2001, Overwegingen 28 en 29, en artikel 4.2). Het ligt daarom in de reden de wettelijke licentie eveneens nog steeds te limiteren tot een stoffelijke drager, ook al strookt dit wellicht niet geheel meer met de huidige stand der techniek. Ook M.W. Scheltema en T.F.E. Tjong Tjin Tai menen dat onder exemplaar in artikel 45j Aw uitsluitend fysieke exemplaren zijn begrepen (zie: Overeenkomsten sluiten door openen en klikken? Computerrecht 2003/4, pp. 245 en 247).

119


rechtmatige verkrijger zijn.16 Daarmee mag verondersteld worden dat de verkrijging van OSS zonder geldige aanschaf c.q. geldig aanschafcontract in ieder geval geen rechtmatige verkrijging oplevert. Daarnaast geldt dat indien de OSS online wordt verkregen (hetgeen doorgaans het geval is), van toepassing van artikel 45j Auteurswet al helemaal geen sprake kan zijn, nu deze bepaling alleen van toepassing is op de verkrijging van een stoffelijk exemplaar van de software.17 Artikel 45j Auteurswet kan de afnemer van OSS-bestanden daarmee dan ook nauwelijks soelaas bieden. Gelet op het feit dat het gebruik van OSS aan te merken is als een auteursrechtelijk relevante handeling en de wettelijke licentie van artikel 45j Auteurswet slechts beperkt uitkomst kan bieden voor de afnemer, is het verkrijgen van een (expliciete) licentie die de afnemer het recht geeft de OSS te gebruiken in principe noodzakelijk. In de Nederlandse literatuur zijn tot nu toe twee opvattingen verdedigd ten aanzien van de kwalificatie van de (auteursrecht)licentie die met betrekking tot de OSS wordt verschaft.18 Een benadering beschouwt deze licentie als een eenzijdige verklaring tot ‘afstand’ van recht door de rechthebbende(n). Het andere standpunt gaat er van uit dat sprake is van een obligatoire overeenkomst tussen de licentiegever(s) en de licentienemer(s), waarvan de (auteursrecht)licentie onderdeel uitmaakt.19 Achtereenvolgens bespreken wij beide visies. OSS-licentie als ‘afstand’ van recht Strikt genomen laat het systeem van onze Auteurswet het doen van afstand van het auteursrecht, dus het laten vervallen van dit recht vóórdat de wettelijke termijn verstreken is, niet toe. Niettemin kent het Nederlandse recht verschillende mogelijkheden om een vrijwel identiek resultaat te bewerkstelligen.20 In dit verband zou men onder de term ‘afstand’ kunnen verstaan de eenzijdige niet-gerichte rechtshandeling, bestaande uit het (geheel of gedeeltelijk) instem-

16

Zie over de beide visies: W.H. van Holst/N.K. van Mullem, De (on)geldigheid van de GPL, JAVI, juni 2004/3, pp. 9499, alsmede V.A. de Pous, Open Source Software is interessant business model met soms complexe juridische constructies, Newsware 2004/2. 17 In die zin onder meer over de auteursrechtlicentie in het algemeen: N. van Lingen, Auteursrecht in hoofdlijnen, Groningen 2002, pp. 180-183. 18 Zie J.H. Spoor/D.W.F. Verkade/D.J.G. Visser, Auteursrecht, Deventer 2005, pp. 551-555. 19 Vgl. R.P.J.L. Tjittes, Afstand van recht, Monografieën Nieuw BW, A6a, Deventer 1992, p 26. 20 Zie voor de te onderscheiden soorten verbintenissen onder meer: C. Asser/A.S. Hartkamp, Verbintenissenrecht, Deel 4, I, De verbintenis in het algemeen, Deventer 2004, pp. 15-17.

120


men met auteursrechtelijk relevante gedragingen door een onbepaald aantal anderen, al dan niet onder bepaalde voorwaarden. Met andere woorden: de rechthebbende op de OSS geeft (bij voorbaat) aan zijn auteursrecht niet te zullen uitoefenen jegens een onbepaalde groep die gebruik gaat maken van de OSS. Daarmee is de ‘OSS-situatie’ enigszins te vergelijken met het geval dat een rechthebbende op door hem in het verkeer gebrachte exemplaren van zijn auteursrechtelijk beschermd werk de schriftelijke mededeling aanbrengt: ‘overname mits met bronvermelding toegestaan’.21 In overeenstemming met artikel 3: 37 lid 3 BW is voor het afstand doen van een recht in principe slechts noodzakelijk dat de afstandverklaring, dus de licentie, de afnemer heeft bereikt.22 Daarmee komt de licentie reeds tot stand op het moment dat de afnemer de OSS heeft gedownload of anderszins heeft verkregen, bijvoorbeeld per e-mail in zijn inbox. Aanvaarding of zelfs kennisneming van de licentie is dan niet nodig. Wel zou de licentie nog kunnen worden ingetrokken door een tweede verklaring, die de afnemer eerder of gelijktijdig met de verklaring inhoudende de licentie bereikt (artikel 3: 37 lid 5 BW). Aangezien de meeste OSS-licenties evenwel geen uitingen bevatten die erop wijzen dat de licentiegever de bedoeling heeft (gehad) afstand te doen van zijn auteursrecht, ligt het meer voor de hand de licentieverhouding als een wederkerige overeenkomst te beschouwen. OSS-licentie als (onderdeel van) een overeenkomst Gaat men ervan uit dat de OSS (auteursrecht)licentie te beschouwen is (als onderdeel van) een obligatoire (licentie)overeenkomst tussen de licentiegever(s) en licentienemer(s), dan bestaat de licentie van de zijde van de licentiegever(s) uit een verbintenis om niet te doen.23 Krachtens deze verbintenis heeft de licen-

21

De meeste OSS-licenties verschaffen geen duidelijkheid over de vraag op welk moment de licentieovereenkomst precies geacht wordt tot stand te komen. Alleen de GPL bevat een bepaling inzake de aanvaarding van de licentie: ‘You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (.), you indicate your acceptance of this License to do so, and all its terms and conditions (.).’ (artikel 5 GPL). 22 HR 13 maart 1981, NJ 1981, 635. Zie ook de conclusie van A-G D.W.F. Verkade, nr. 3.3-3.4 bij HR 20 juni 2003, LJN AF7536, zaak C02/230HR, JOL 2003, 342 (Columbus Automatiseringsgroep). 23 Overigens is met betrekking tot veel OSS-licenties wel de nodige achtergrondinformatie over de (totstandkoming van de) licenties en de uitleg van bepaalde bepalingen daarvan beschikbaar op het internet. Vgl. onder meer de FAQ met betrekking tot licenties die te vinden zijn op met betrekking tot de GPL, en met betrekking tot de MPL.

121


tiegever zich verplicht om te dulden dat aan de licentienemer bepaalde auteursrechtelijke bevoegdheden toekomen. Met andere woorden: de licentie verschaft de contractuele toestemming aan de licentienemer om de OSS op de overeengekomen wijze openbaar te maken en/of te verveelvoudigen. De licentieverlening is niet aan bepaalde vormvereisten gebonden. In overeenstemming met artikel 6: 217 BW geldt dat de OSS-licentieovereenkomst totstandkomt zodra sprake is van aanvaarding van een aanbod.24 Dit geldt ook voor OSS-licentieovereenkomsten die langs elektronische weg totstandkomen. Wat betreft de uitleg van de inhoud van een dergelijke licentieovereenkomst kan – evenals ten aanzien andere contracten – aansluiting gezocht worden bij de bekende Haviltex-formule.25 Volgens deze formule komt het aan op de bedoeling van partijen en hoe partijen de tekst mochten begrijpen. Bij OSS doet zich echter de complicatie voor dat partijen geen (precontractueel) overleg hebben gevoerd.26 Een meer objectiverende uitleg lijkt daarom op zijn plaats naar analogie van de jurisprudentie van de Hoge Raad over de uitleg van CAO’s.27 In een latere uitspraak heeft de Hoge Raad bovendien aangegeven dat het bij uitleg van contracten aankomt op een vloeiende overgang tussen de ‘Haviltex’ en de ‘CAO’ benadering: ‘bij de uitleg van een schriftelijk contract [zijn] telkens van beslissende betekenis (…) alle omstandigheden van het concrete geval, gewaardeerd naar hetgeen de maatstaven van redelijkheid en billijkheid meebrengen’.28 Daarop geeft de Hoge Raad in september 2004 ervan blijk dat de tekst van het contract daarbij vaak wel van groot belang is. Zo stelde hij vast: “Deze uitleg dient niet plaats te vinden op grond van alleen maar de taalkundige betekenis van de bewoordingen waarin het contract is gesteld, maar in praktisch opzicht is de taalkundige betekenis die deze bewoordingen, gelezen in de context van dit geschrift als geheel in de desbetreffende kring van het maatschappelijk verkeer hebben, vaak wel van groot belang.29

24

Zie onder meer HR 17 september 1993, NJ 1994, 173; HR 24 september 1993, NJ 1994, 174 en HR 31 mei 2002, NJ 2003, 110. 25 HR 20 februari 2004, nr. C02/219, RvdW 2004, 34. 26 Hoge Raad 17 september 2004, nr. C03/100HR, JOL 2004, 455 (Wessanen/Nutricia). 27 Wel geldt hierbij dat deze discussies vaak ideologisch getint zijn, zodat de verkondigde interpretaties van licentievoorwaarden veelal onderling tegenstrijdig zijn 28 Wet van 13 mei 2004, Stb. 2004, 210. In het bijzonder de artikelen 3: 15d e.v. en 6: 227a e.v. BW. Wordt met een consument gecontracteerd, dan is tevens relevant de Wet Overeenkomsten op Afstand (Wet van 21 december 2000, Stb. 2000, 617). 29 Onder een dienst van de informatiemaatschappij moet worden verstaan ‘elke dienst die gewoonlijk tegen vergoeding (…)’ wordt verricht. Uit de wetsgeschiedenis bij artikel 3: 15d BW volgt dat deze eis niet betekent dat ook steeds voor de dienst moeten worden betaald. Doorslaggevend is slechts of sprake is van een economische activiteit. Memorie van Toelichting bij de Aanpassingswet richtlijn inzake elektronische handel, Kamerstukken (II) 28.197, nr. 3, p. 12.

122


Toegepast op de OSS-situatie levert een en ander op dat het ontbreken van rechtstreeks (voor)overleg tussen partijen een factor kan zijn die in de richting van een objectievere uitleg wijst. Uit de verwijzing naar de redelijkheid en billijkheid volgt dat tevens betekenis toekomt aan de maatschappelijke opvattingen (zie ook artikel 3:12 BW). Tegelijkertijd geldt daarbij dat aan de tekst van de licentie zelf, zoals die gelezen wordt binnen de OSS-gemeenschap, zeker ook belang gehecht moet worden.30

7.4

Aanpassingswet richtlijn elektronische handel

Zoals gezegd, komt de OSS-licentieovereenkomst vormvrij tot stand. In de gevallen dat de OSS-licentieovereenkomst langs elektronische weg (op afstand) tot stand komt, gelden mogelijk op grond van de Aanpassingswet richtlijn elektronische handel een aantal bijzondere vereisten.31 De verstrekking van OSS kan als ‘dienst van de informatiemaatschappij’ in de zin van de Aanpassingswet (artikel 3: 15d BW) worden beschouwd als daarbij sprake is van een economische activiteit.32 Wordt de OSS bijvoorbeeld door een particulier online gratis ter beschikking gesteld, dan zal vermoedelijk geen sprake zijn van een economische activiteit. Indien de OSS daarentegen door een onderneming wordt aangeboden, zal in de regel wel sprake zijn van economische activiteit, ook als het geen betaalde dienst betreft. Alsdan kan de Aanpassingswet van toepassing zijn.33

30

De toepasselijkheid van de Aanpassingswet is overigens niet altijd eenvoudig te bepalen. Stel dat een softwareontwikkelaar werkzaam bij een IT-onderneming de door hem zelf ontwikkelde OSS op het internet ter beschikking stelt. Als zijn werkgever krachtens artikel 7 Auteurswet aan te merken is als de auteursrechthebbende op de OSS, dan is aannemelijk dat het aanbieden van de OSS door de werkgever te beschouwen is als een economische activiteit. Wordt de programmeur daarentegen aangemerkt als de rechthebbende, dan blijft toepassing van de Aanpassingswet mogelijk achterwege. 31 Zie over de click wrap overeenkomst o.a.: M.W. Scheltema/T.F.E. Tjong Tjin Tai, Overeenkomsten sluiten door openen en klikken?, Computerrecht 2003/4 p. 247, alsmede P.H. Blok/T.J.M. de Weerd, Shrink-wrap en click-wraplicenties zijn aanvaardbaar, met naschrift van Scheltema en Tjong Tjin Tai, Computerrecht 2004/3, pp. 126-128. Zie verder ook: R.J.J. Westerdijk, Open en klikken: overeenkomst gesloten, met een naschrift van Scheltema en Tjong Tjin Tai, Computerrecht 2004/6, pp. 280-284. 32 Bij b2b transacties kunnen partijen afspreken dat de orderbevestiging achterwege blijft. De E-commerce richtlijn die, anders dan de Aanpassingswet, uitsluitend verwijst naar “partijen die niet als consument handelen” (artikel 11 lid 1), geeft daarnaast ook de ruimte voor andersluidende bedingen tussen een bedrijf en een overheidsorganisatie (b2g). Aannemelijk is dat de Richtlijntekst hier doorslaggevend is. Niet onbelangrijk hier gezien het feit dat OSS zeker ook bij overheden in trek is. 33 Ofschoon de OSS-licenties naar hun aard bedoeld zijn om als ‘standaardvoorwaarden’ te worden gebruikt, komt het ook voor dat sommige OSS-licenties (zoals de BSD-licentie) vereisen een OSS-licentieformulier wordt ‘ingevuld’, door onder meer daarin de naam van de bewerker en een copyright notice op te nemen.

123


Wat zijn nu de consequenties van de mogelijke toepassing van de Aanpassingswet op OSS-licentieovereenkomsten? Wordt de licentieovereenkomst op basis van een zogenaamde click-wrap overeenkomst gesloten, dan is aannemelijk dat die overeenkomst rechtsgeldig tot stand komt door het aanklikken van de acceptatieknop door de licentienemer.34 Sterker nog, zonder de klik zal de licentienemer de OSS veelal zelfs niet kunnen gebruiken, simpelweg omdat hem dan de feitelijke toegang daartoe (technisch) wordt geweigerd. Vervolgens zal iedere licentiegever van de OSS de aanvaarding van de licentie in principe zo spoedig mogelijk langs elektronische weg moeten bevestigen (vgl. artikel 6:227c BW).35 In de praktijk zal de licentiegever evenwel vrijwel nooit in staat zijn om aan deze bevestigingseis te voldoen, omdat het feitelijke contact tussen de licentiegever(s) en de licentienemer(s) nu eenmaal doorgaans ontbreekt. Het ontbreken van een bevestiging staat echter aan de totstandkoming van de licentieovereenkomst(en) als zodanig niet in de weg, nu de bevestigingseis geen constitutief vereiste is voor de totstandkoming van het contract. Ook zonder de bevestiging komt (komen) de licentieovereenkomst(en) tot stand. Wel kan de licentienemer, zolang de licentiegever(s) de aanvaarding van de licentie niet heeft (hebben) bevestigd, de licentieovereenkomst ontbinden (vgl. artikel 6:227c lid 2 BW). Zodra de licentienemer het beoogde gebruiksrecht evenwel verkrijgt (ook zonder voorafgaande bevestiging), vervalt de ontbindingsbevoegdheid. Immers, uit Overweging 34 van de E-commerce richtlijn volgt dat de ontvangstbevestiging ook kan bestaan in de online levering van de ‘betaalde dienst’. Aannemelijk is dat hiertoe ook het online ter beschikking stelling van een (gratis) licentie kan worden gerekend. In de praktijk zal het risico van ontbinding evenwel waarschijnlijk nauwelijks problemen opleveren, nu een afnemer weinig te winnen zal hebben bij het ontbinden van de licentieovereenkomst. Immers, in dat geval verliest hij recht om de OSS te gebruiken. Daar waar hij niet betaald heeft voor de OSS, krijgt hij er bovendien niets meer voor terug.

34

Zie hierover onder meer: C. Asser/A.S. Hartkamp, Verbintenissenrecht; 4 deel II Algemene leer der overeenkomsten, Deventer 2001, pp. 359-360. 35 Zie Hoge Raad 19 september 1997, NJ 1998, 6 (Lottoformulieren) en Hoge Raad 21 februari 2003, JOR 2003, 13/ LJN-nummer AF1563/Zaaknummer: C01/337HR (Stichting Parkwonen Hoge Weide). Een kritische reactie op het eerstgenoemde arrest is gegeven door: M.L. Hendrikse/M. van Zijst, Heeft het kernbeding nog inhoud? WPNR 6303 (1998), pp.145-147. Zie in dit verband ook Hof Den Haag 22 maart 2005, Rolnummer 03/1463 (HCC/Dell), overweging 33.

124


7.5

OSS-licentieovereenkomsten en de Wet algemene voorwaarden

OSS-licentieovereenkomsten worden steeds als standaardcontracten aan de gebruiker voorgelegd.36 Beantwoord moet worden de vraag of hier sprake is van algemene voorwaarden, dan wel of het gaat om kernbedingen in de zin van artikel 6: 231 BW. Op algemene voorwaarden zijn de regels van afdeling 6.5.3 BW van toepassing. Dergelijke voorwaarden zijn snel van toepassing, maar zijn onderworpen aan een strenge inhoudelijke toetsing. Kernbedingen daarentegen zijn uitgezonderd van de afdeling 6.5.3 BW. Volgens de parlementaire geschiedenis zijn kernbedingen bedingen die ‘van zo wezenlijk belang (zijn) dat de overeenkomst zonder dit beding niet tot stand zou zijn gekomen of zonder dit beding niet van wilsovereenstemming omtrent het wezen van de overeenkomst sprake zou zijn’.37

Als voorbeelden noemt de parlementaire geschiedenis onder meer de door de wederpartij te betalen prijs, de hoeveelheid en de kwaliteit van de verkochte soortzaken. Niet voldoende is dat het beding een voor partijen belangrijk punt regelt. Aan de hand van objectieve maatstaven moet worden vastgesteld of sprake is van een kernbeding. In beginsel kunnen partijen zelf niet bedingen tot kernbedingen bestempelen om deze zodoende aan de werking van de Wet algemene voorwaarden (afdeling 6.5.3) te onttrekken. Ondanks kritiek in de literatuur heeft de Hoge Raad deze restrictieve uitleg in een tweetal arresten aanvaard. 38 In overeenstemming met deze restrictieve uitleg kan mogelijk de auteursrechtelijke toestemming, met andere woorden: de licentie in de OSS-voorwaarden, als kern van de prestatie van de licentiegever worden beschouwd.39 Zoals eerder aangegeven, verkrijgt de gebruiker immers niet op andere wijze toestemming om de OSS te gebruiken. Het feit dat de auteursrechtelijke toestemming een essentieel onderdeel is in de OSS-licentievoorwaarden, maakt ons inziens echter niet dat

36

In die zin bijvoorbeeld: K. Koelman, Terug naar de bron: open source en copyleft, Informatierecht/AMI oktober 2000/8, p. 152. 37 Zie hierover onder meer ook R.E. van Esch/Chr. P.G. Bramer, Algemene voorwaarden en informatieplicht in cyberspace, CR 2000/6, pp. 283-288. 38 De variant van artikel 6:234 lid 1 sub b BW doet zich slechts voor als terhandstelling redelijkerwijs niet mogelijk is. 39 Alleen grote bedrijven kunnen geen beroep doen op het feit dat de informatieplicht niet is vervuld (artikel 6: 235 lid 1 BW). Hetzelfde geldt voor de wederpartij, die vaker overeenkomsten met dezelfde leverancier heeft afgesloten op basis van dezelfde of nagenoeg dezelfde algemene voorwaarden (artikel 6:235 lid 3 BW).

125


de licentievoorwaarden integraal als kernbedingen te beschouwen zijn. Nu de licentieovereenkomst bovendien voorziet in een onbeperkt recht om de software te gebruiken, wijzigen en distribueren, lijkt de vraag of de licentie een kernbeding is weinig relevant te zijn voor de toetsing van de licentie. Wat hier ook van zij, de overige bedingen uit de OSS-licentievoorwaarden zijn zeker geen kernbedingen. Het valt niet te verdedigen dat bijvoorbeeld een beperking van aansprakelijkheid kan worden opgevat als een kernbeding. Te dien aanzien moet dan ook worden voldaan aan de aan algemene voorwaarden gestelde eisen. Een beding in algemene voorwaarden is vernietigbaar als de wederpartij niet een redelijke mogelijkheid is geboden van de algemene voorwaarden kennis te nemen (artikel 6:233 sub b BW). 40 Dit moet in beginsel41 door ter hand stelling vóór of bij het sluiten van de overeenkomst (art. 6:234 lid 1 sub a BW), dan wel door deze vóór of bij het langs elektronische weg sluiten van de overeenkomst langs elektronische weg aan de afnemer te verstrekken (art. 6:234 lid 1 sub c BW). Ook moet in principe de mogelijkheid worden geboden om de voorwaarden op te slaan, zodat de afnemer daar later nog kennis van kan nemen.42 Toepassing van deze regels levert op dat de licentievoorwaarden in ieder geval tijdig verstrekt zijn indien zij vóór (het afronden van) de installatie van de OSS ter beschikking worden gesteld. Dit is het geval indien de afnemer zich op dat moment bewust is van de toepasselijkheid van de voorwaarden en hij ook in de gelegenheid is geweest hiervan kennis te nemen en hij deze voorwaarden ook heeft kunnen opslaan.

40

Vgl. bijvoorbeeld het onderdeel ‘How to Apply These Terms to Your New Programs’ in de GPL en de artikelen 3.5 en 3.6 van de MPL. De GPL vereist dat indien het een interactief programma betreft, dat alsdan een korte tekst op het scherm verschijnt met onder meer een copyright notice en een mededeling dat het free software betreft (zonder overigens de uitdrukkelijke vermelding dat het GPL software betreft), waarna door het indrukken van een bepaalde toetscombinatie nadere informatie op het scherm verschijnt. De OSL en AFL-licenties bepalen uitdrukkelijk dat degene de OSS ter beschikking stelt aan derden ‘must make a reasonable effort under the circumstances to obtain the express assent of recipients to the terms of this License’. 41 Zie ook de uitspraak Netwise/NTS (Voorzieningenrechter Rechtbank Rotterdam, 5 december 2002, KG 2003, 15; LJN: AF 2059). Daarin bepaalde de rechter dat het slechts tonen van een button, genaamd ‘voorwaarden’ op een website voldoende was voor de toepasselijkheid van de onderhavige algemene voorwaarden. Wel was daarbij mede relevant dat het een professionele wederpartij betrof die zou moeten begrijpen dat de voorwaarden waarvan hij op eenvoudige wijze kennis kon nemen, (onder meer) voorwaarden betroffen die op hem van toepassing zouden zijn. 42 Dit vereist vanzelfsprekend dat deze licentievoorwaarden niet alleen relatief eenvoudig te vinden moeten zijn, maar ook dat de afnemer weet om welke OSS-licentievoorwaarden het gaat. Steun voor deze benadering kan gevonden worden in het arrest Geurtzen/Kampstaal (HR 1 oktober 1999, RvdW 1999, 136C). Daarin overwoog de Hoge Raad dat een redelijke en op de praktijk afgestemde uitleg meebrengt dat de wederpartij zich niet op de vernietigbaarheid van de algemene voorwaarden kan beroepen, wanneer hij ten tijde van het sluiten van de overeenkomst met het beding bekend was of geacht kon worden daarmee bekend kon zijn. In zijn conclusie noemt A-G Hartkamp uitdrukkelijk als voorbeeld dat verwezen wordt naar algemene voorwaarden die op het internet kunnen worden geraadpleegd.

126


Sommige OSS-licenties bevatten voorschriften of suggesties omtrent de toepasselijkheidsverklaring van de licentievoorwaarden bij verdere distributie.43 Gebruikelijker is echter dat de afnemer pas na installatie kan vaststellen welke OSS-licentie van toepassing is. Verschillende benaderingen zijn nu mogelijk ter beantwoording de vraag wanneer de algemene voorwaarden in het kader van OSS rechtsgeldig ter beschikking zijn gesteld. Zo zou men bijvoorbeeld kunnen stellen dat de voorwaarden steeds uitdrukkelijk aan de afnemer (op zijn beeldscherm) moeten worden getoond voor of bij het sluiten van de overeenkomst. Dit kan worden bereikt door de afnemer te verplichten om door de licentievoorwaarden heen te scrollen. In plaats hiervan zou mogelijk ook het aanbieden van de licentievoorwaarden via bijvoorbeeld een hyperlink voldoende moeten zijn.44 Ten slotte zou men kunnen stellen dat van een OSS-afnemer verwacht mag worden dat hij zelf op het internet op zoek gaat naar de toepasselijke licentievoorwaarden, zodat alsdan met een enkele verwijzing naar de licentievoorwaarden zou kunnen worden volstaan.45 Wat hier verder ook van zij, als men zekerheid wenst, is in ieder geval de veiligste manier om te werken met een click wrap licentie, hetzij op de website voordat het downloaden mogelijk is, hetzij bij het installatieproces. Voordeel van het op correcte wijze hanteren van de click wrap variant is dat aan de hand daarvan niet alleen kan worden aangetoond dat de licentievoorwaarden tijdig zijn verstrekt, maar ook dat ze rechtsgeldig zijn overeengekomen. Uit het gebruik van de programmatuur is dan af te leiden dat de licentienemer de licentievoorwaarden gezien heeft, en de toepasselijkheid daarvan heeft aanvaard of althans moet hebben aanvaard door de acceptatieknop aan te klikken.

43

Een andere benadering van de licentiestructuur kan zijn dat de verstrekker van de OSS een sublicentie verleent aan de opvolgende verkrijger. Volgt men dit standpunt, dan zou zijn sprake van een licentieverhouding tussen (slechts) twee partijen, op basis van een ‘ketting’ van sublicenties. Hoewel niet alle OSS voorwaarden op dit punt uitsluitsel geven en rechtspraak hierover ontbreekt, menen wij dat doorgaans eerder sprake is van de door ons beschreven rechtstreekse licenties tussen alle bewerkers en alle opvolgende verkrijgers, in plaats van de ‘sublicentie-constructie’. 44 Zie voor de term ‘verervend’: Chr. de Preter/H. Dekeyser, De totstandkoming en draagwijdte van open source licenties, Computerrecht 2004/5, pp. 216-220. Zie verder ook: T. Jaeger, ‘Einmal GPL, immer GPL?’, Linux-Magazin 2001-1, . 45 Aangezien het vrijwel onmogelijk is wijzigingen in een programma aan te brengen zonder de beschikking over de source code te hebben, zal B in het algemeen over de source code van de door A geprogrammeerde code beschikken, zodat C voor de source code ook bij B terecht kan.

127


7.6

Wie zijn partij bij de OSS-licentieovereenkomst?

Een complicerende factor ten opzichte van het voorgaande is het feit dat OSS veelal door verschillende personen (tegelijk) kan zijn ontwikkeld. Dit leidt niet alleen tot de vraag wie partij zijn bij de OSS-licentieovereenkomst, maar ook wat de rechten en verplichtingen van de betrokken verspreiders en verkrijgers van de OSS zijn. Van belang daarbij is dat per gekozen licentievorm de voorwaarden met betrekking tot de verdere verspreiding van de software voor de verspreiders kunnen verschillen. De BSD-licentie verplicht de licentienemers bijvoorbeeld slechts bij doorgifte van het programma een copyright-notice en de in de licentie genoemde exoneratieclausule en voorwaarden te vermelden, terwijl bijvoorbeeld de General Public License (GPL) – en in mindere mate ook de Mozilla Public License (MPL) – een verstrekkend ‘kettingbeding’ bevat (vgl. de artikelen 1 en 3 GPL). Doel van zo een ‘kettingbeding’ is iedere (volgende) licentienemer van de OSS te verplichten om de bundel van licenties en daaruit voortvloeiende rechten en verplichtingen door te geven aan iedere opvolgende licentienemer. In het geval van de GPL en MPL wil dat – vrij vertaald – zeggen dat de licentienemer bij verdere verspreiding erop moet wijzen dat (i) sprake is van OSS; (ii) wie het product ontwikkeld heeft/hebben; (iii) dat de licentievoorwaarden van toepassing zijn; en (iv) waar de broncode beschikbaar is. Ieder die heeft bijgedragen aan de ontwikkeling van de OSS geldt in principe als de (gezamenlijk) auteursrechthebbende op de (door hem) geschreven programmaregels.Vanuit die hoedanigheid verleent iedere auteursrechthebbende steeds aan alle afnemers een licentie en neemt dus het aantal licentiegevers steeds verder toe naarmate de OSS wordt doorontwikkeld. Een afnemer van OSS verkrijgt een geldig gebruiksrecht doordat aan hem door iedere rechthebbende een licentie wordt verleend. Daartoe komt steeds tussen iedere auteursrechthebbende en elke opvolgende licentienemer een separate licentieovereenkomst tot stand. Om dit fenomeen te duiden, maakt de MPL onderscheid tussen de ‘Initial Developer’ en de ‘Contributor’, die beiden een licentie verschaffen ten aanzien van het door hen vervaardigde gedeelte van de OSS. De GPL en daarvan afgeleide licentiemodellen spreken op hun beurt over ‘copyright holders’ in het meervoud. Ook kan worden gewezen op artikel 6 van de GPL, waarin staat: “Each time you redistribute the Program (….), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions (…)”.

128


Deze bepaling ondersteunt het standpunt dat steeds sprake is van rechtstreekse individuele licentieovereenkomsten tussen iedere bewerker en alle opvolgende verkrijgers van het GPL programma.46 Nog gecompliceerder wordt het wanneer een opvolgende verkrijger besluit de door hem bewerkte OSS te gaan verspreiden onder een andere licentie, dan waaronder hij zelf de OSS heeft verworven. In het geval van toepassing van een licentie met een sterk ‘verervend’ karakter, zoals de GPL, is verspreiding onder een andere licentie in strijd met de licentievoorwaarden.47 De BSD-licentie laat daarentegen het verspreiden van de software onder een andere licentie toe. Stel nu dat een maker A een programma onder de BSD-licentie verspreidt aan afnemer B, die het programma aanpast en vervolgens onder de GPL verder verspreidt aan afnemer C. Aangezien de aldus ontstane programmatuur in ieder geval GPL-code bevat (de aanpassingen van B), mag B het door hem aangepaste programma alleen nog verder verspreiden onder de GPL. Maar of daarmee ook tussen A en C ten aanzien van de door A geprogrammeerde code in het aan C geleverde programma eveneens een GPL-licentieverhouding tot stand is gekomen, is de vraag. A heeft immers geen aanbod gedaan om een GPL-licentieverhouding aan te gaan. Wat hier ook van zij, A behoudt vanzelfsprekend het recht om zijn code verder te verspreiden onder de BSD-licentie. Eveneens behouden de andere licentienemers van A die aanspraken die zij hadden jegens A onder de BSDlicentie. Ervan uitgaande dat A gebonden zou worden aan een GPL-overeenkomst met C, dan leidt dit tot de volgende merkwaardige situatie. Op A rusten – louter als gevolg van de handelwijze van B – als licentiegever alle de in de GPL genoemde verplichtingen, zoals het verstrekken van de source code bij een executable, te rusten.48 Dit terwijl A onder de BSD licentie niet verplicht was zijn sources vrij te geven. Het behoeft geen twijfel dat tussen B en C een GPL-overeenkomst is ontstaan. B verspreidt het door hem bewerkte programma van A. Als verkrijger van het door

46

De twee uitspraken in deze zaak zijn te vinden op: . Zie voorts ook: 47 Zie: http://www.jbb.de/html/?page=news&id=32. 48 Zie: H. Struik, Softwarelicenties in faillissement, TvI 2002/Special – Softwarelicenties, p. 283, en aldaar aangehaalde literatuur in voetnoot 22. Anders: B.C. Wentink, De licentie in het vermogensrecht, Studiepockets Privaatrecht nr. 51, Deventer 1995, pp. 22 en 104-105, alsmede Hof Den Haag 20 november 2003, Computerrecht 2004/3, p. 134 inzake IST/Van der Schraaf (met noot van E.D.C. Neppelenbroek), ofschoon niet expliciet.

129


B ‘geGPLde’ programma kan C aan B om een exemplaar van de source code verzoeken. B zal vanzelfsprekend slechts aan dit verzoek kunnen voldoen, indien hij zelf beschikt over de sources van de door A ontwikkelde programmatuur.

7.7

Verspreiding OSS zonder geldige licentie

Ten slotte bespreken wij de situatie dat de OSS wordt gebruikt in strijd met de toepasselijke licentie, met andere woorden wordt gebruikt zonder geldige licentie. In dat geval ontbreekt de noodzakelijke toestemming voor het gebruik van de programmatuur en pleegt de afnemer auteursrechtinbreuk. Illustratief in dit verband is de Duitse kortgeding uitspraak inzake Netfilter/Sitecom.49 De Duitse vestiging van het (Nederlandse) bedrijf Sitecom had (schijnbaar onbewust) open source (netwerk) software verspreid bij door haar geëxploiteerde apparatuur, zonder daarbij te wijzen op de toepasselijkheid van de GPLlicentievoorwaarden en de sources mee te leveren. Onder last van een boete legde de rechtbank te München aan Sitecom GmbH op 2 april 2004 als voorlopige voorziening een verbod op om de genoemde OSS nog langer te verspreiden en/of te verveelvoudigen zonder uitdrukkelijk te wijzen op de toepasselijkheid van de GPL voorwaarden en de sources bij te sluiten. Op 19 mei 2004 is deze voorlopige voorziening door dezelfde rechter bekrachtigd. Wereldwijd zou dit de eerste rechtszaak zijn waarin de rechtsgeldigheid van de GPL licentievoorwaarden zou zijn erkend.50 Inmiddels is volgens Sitecom Europe B.V., de Nederlandse moedermaatschappij, gehoor gegeven aan de uitspraak. Hoe moeten we het gebruik van OSS zonder geldige licentie naar Nederlands recht zien? De kans dat een afnemer het gebruik van de software met een beroep op artikel 45j Auteurswet kan rechtvaardigen, is, zoals gezegd, gering. De mogelijkheden voor een beroep op derdenbescherming zijn eveneens beperkt. Volgens de algemeen geldende opvatting is een licentie geen beperkt recht, maar een vorderingsrecht.51 Daarmee onttrekt de verstrekking van een licentie zich aan de toe-

49

Op basis van andere argumentatie meent Koelman eveneens dat de opvolgende verwerver van OSS geen beroep kan doen op de derdenbescherming. Zie: K.J. Koelman, Terug naar de bron: open source en copyleft, Informatierecht/AMI oktober 2000/8, p. 152. 50 Zie in dit verband artikel 4 van de GPL licentie dat uitdrukkelijk bepaalt dat zolang partijen de licentievoorwaarden in acht nemen, zij gerechtigd blijven het GPL programma te gebruiken op basis van de GPL. 51 In het gekozen voorbeeld zijn alle partijen gemakshalve, ofschoon dit in de praktijk bij OSS niet vaak zal voorkomen, in Nederland gevestigd. Hierdoor worden complicaties als gevolg van mogelijke IPR-vragen uit de weg gegaan.

130


passing van artikelen 3:86 en 3:88 BW.52 Genoemde bepalingen beschermen uitsluitend een derde die een zaak of een goed van een beschikkingsonbevoegde ‘overgedragen’ heeft gekregen. De verlening van een licentie (in de kwalificatie van een vorderingsrecht) behoort daartoe niet. Voor de afnemer rest slechts een beroep te doen op de algemene norm van artikel 3:36 BW. Verdedigd zou dan kunnen worden dat de afnemer, gelet op het karakter van OSS dat vrije verspreiding voorstaat, ervan mocht uitgaan dat hij gebruik van de OSS mocht maken, ook al heeft hij deze zonder licentie verkregen. Puur praktisch gezien zou de afnemer zich overigens ook alsnog aan de (op het internet gepubliceerde) licentievoorwaarden kunnen conformeren en zodoende de toestemming van de rechthebbende(n) kunnen verkrijgen c.q behouden.53

52

Gekozen is voor toepassing van de BSD licentievoorwaarden, omdat deze licentie, in tegenstelling tot bijvoorbeeld de GPL voorwaarden, commerciële exploitatie van OSS toestaat. 53 Deze bepalingen zijn ontleend aan de FENIT-voorwaarden.

131

8

Aansprakelijkheid en open source software Arend Lagemaat en Eliane de Vilder

Evenals het geval is bij de toepassing van ‘closed source software’ kan ook de inzet van open source software (OSS) leiden tot aansprakelijkheid van daarbij betrokken partijen. Met name indien OSS wordt toegepast voor bedrijfskritische processen, kan uitval daarvan ernstige (financiële) gevolgen hebben. Hetzelfde kan zich voordoen wanneer OSS wordt geïntegreerd in commerciële softwareproducten. Juist in dit soort gevallen rijst de vraag naar wie aansprakelijk is voor de eventuele schade. Voor het bezien van de aansprakelijkheidsvragen in het licht van OSS zal rekening moeten worden gehouden met de specifieke kenmerken van deze software. Daarbij valt onder meer te denken aan het grote aantal makers van OSS, de ingewikkelde (internationale) distributieketens, de ver verwijderde band tussen OSS-licentiegever en -nemer en de bijzondere inhoud die men in de meeste OSS-licenties aantreft (waaronder de ‘gratis’ licentieverlening en de vergaande exoneratiebedingen). In dit hoofdstuk zal aan de hand van een casus de mogelijke aansprakelijkheid van zowel de leverancier/licentiegever van OSS, als die van de OSS-dienstverlener onder de loep worden genomen. De aansprakelijkheid van de OSS-gebruiker/ licentienemer laten wij buiten beschouwing.

8.1

Inleiding

Net als bij closed source (‘proprietary’) software zijn bij OSS verschillende grondslagen voor aansprakelijkheid bij ondeugdelijke programmatuur denkbaar. Dergelijke aansprakelijkheid zal veelal gebaseerd moeten worden op het niet deugdelijk nakomen door de rechthebbende van zijn verplichtingen uit hoofde van de licentieovereenkomst. Ook kan aansprakelijkheid ontstaan indien een contractuele relatie ontbreekt, maar er sprake is van onrechtmatig handelen. Eveneens zijn aanspraken gebaseerd op productenaansprakelijkheid denkbaar.

133


Ter illustratie een casus. Het in Amsterdam1 gevestigde IT-bedrijf Power heeft het softwarepakket Powerful ontwikkeld waarbij zij gebruik heeft gemaakt van door haar aangepaste OSS. Vervolgens heeft zij Powerful, waarvan de OSS deel uitmaakt, verspreid via het internet en daarop de BSD-voorwaarden van toepassing verklaard.2 Powerful blijkt een groot succes. Veelvuldig wordt het programma van het internet gedownload, verder aangepast, uitgebreid en voor uiteenlopende doeleinden gebruikt. Iedere ontwikkelaar stuurt op de daartoe voorgeschreven wijze de BSDvoorwaarden mee. Powerful wordt ook gedownload door de in Leeuwarden gevestigde distributeur Kant & Klaar. Kant & Klaar voegt Powerful samen met door haar zelf ontwikkelde programmatuur en biedt deze aan consumenten aan als een totaaloplossing om foto’s te verwerken op de pc. Daarbij verklaart Kant & Klaar, naast haar eigen algemene voorwaarden, de BSD-voorwaarden op de voorgeschreven wijze van toepassing. Kant & Klaar heeft in haar eigen voorwaarden van de BSD-voorwaarden afwijkende aansprakelijkheids- en garantiebepalingen opgenomen. Zo garandeert Kant & Klaar in haar algemene voorwaarden dat de totaaloplossing gedurende een periode van drie maanden na aflevering geen fouten zal bevatten en verklaart zij dat de software geschikt is om foto’s te verwerken.3 In het geval er fouten optreden gedurende de eerste drie maanden biedt Kant & Klaar gratis foutherstel aan. Kant & Klaar beperkt haar aansprakelijkheid wegens toerekenbare tekortkoming in de nakoming van de overeenkomst tot vergoeding van de directe schade tot maximaal de factuurwaarde en sluit haar aansprakelijkheid uit voor alle overige schade. In de algemene voorwaarden wordt geen aandacht besteed aan de verhouding tussen de BSD-voorwaarden en de eigen algemene voorwaarden van Kant & Klaar. De heer Jansen schaft de totaaloplossing voor privé doeleinden via de website van Kant & Klaar aan, op welke overeenkomst eveneens de BSD-voorwaarden en de afwijkende algemene voorwaarden van Kant & Klaar op de juiste wijze van toepassing zijn verklaard. Bij het gebruik van de totaaloplossing raakt Jansen helaas al zijn prachtige vakantiefoto’s kwijt en ook de andere software op zijn PC wordt onherstelbaar beschadigd. De oorzaak van het probleem blijkt in Powerful te liggen. Jansen begroot zijn schade op € 5.000. Zijn schade bestaat uit het

1

Zie bijvoorbeeld de artikelen 11 en 12 van de General Public License, de artikelen 7 en 9 van de Mozilla Public License versie 1.1 en de artikelen 7 en 8 van de Apache License versie 2.0. 2 Vgl. HR 14 juni 2002, NJ 2003, 112 (Bramer/Colpro). 3 HR 19 mei 1967, NJ 1967, 261 (Saladin/HBU), HR 20 februari 1976, NJ 1976, 486 (Pseudo-vogelpest) en HR 25 april 1986, NJ 1986, 714 (Smilde).

134

Aansprakelijkheid en open source software

opnieuw moeten aanschaffen van de beschadigde software en immateriële schade verband houdende met het verloren gaan van al zijn vakantiefoto’s. Bij wie kan Jansen de door hem geleden schade verhalen?

8.2

Posities

In de bovenstaande casus zijn de volgende drie posities te onderscheiden. Allereerst is er de positie van Power, de leverancier/licentiegever die een bijdrage heeft geleverd aan de OSS. Zij zal mogelijk aansprakelijk kunnen worden gehouden voor het (door)leveren van OSS waarin fouten zitten. In de tweede plaats is er de positie van distributeur Kant & Klaar. Ten slotte is er de positie van de consument Jansen, de gebruiker van OSS. Jansen zal willen onderzoeken of en in hoeverre hij zijn schade kan verhalen op Power en/of op Kant & Klaar. Hieronder zal eerst worden ingegaan op de mogelijke aansprakelijkheid van Power, als licentiegever/leverancier, jegens respectievelijk Kant & Klaar en Jansen. Daarna komt de aansprakelijkheid van Kant & Klaar als licentiegever jegens Jansen aan bod.

8.3

De aansprakelijkheid van Power

8.3.1

De aansprakelijkheid van Power jegens Kant & Klaar

Tussen Power en Kant & Klaar is een contractuele relatie ontstaan, die bestaat uit een licentieovereenkomst waarop de BSD-voorwaarden van toepassing zijn. Daarnaast zijn er licentieovereenkomsten ontstaan tussen Kant & Klaar en alle voorgaande makers van de OSS waaruit Powerful is opgebouwd. Hier is dus sprake van een bundel van licenties. Indien Kant & Klaar aantoont dat Power is tekortgeschoten in de nakoming van één of meer verplichtingen uit hoofde van de (BSD-)licentie is Power in principe verplicht de schade die Kant & Klaar daardoor lijdt te vergoeden, tenzij Power een beroep op overmacht kan doen. De schade van Kant & Klaar bestaat uit de schadevergoeding die zij aan Jansen dient te betalen wanneer Jansen met succes Kant & Klaar kan aanspreken voor de door hem geleden schade. De aansprakelijkheid van Kant & Klaar jegens Jansen wordt besproken in paragraaf 4 van dit hoofdstuk. Teneinde een beroep op overmacht te kunnen doen dient Power te bewijzen dat de tekortkoming niet is te wijten aan haar schuld, noch krachtens de wet, rechtshandeling of in het verkeer geldende opvattingen voor haar rekening komt.

135


Bij de vaststelling of Power toerekenbaar tekort is geschoten in de nakoming van haar verplichtingen jegens Kant & Klaar dient allereerst te worden vastgesteld welke eisen kunnen worden gesteld aan het softwareprogramma Powerful. Daarvoor is niet alleen de inhoud van de licentieovereenkomst/licentievoorwaarden bepalend, maar ook hetgeen voortvloeit uit de wet, de gewoonte of eisen van redelijkheid en billijkheid. Aangezien bij OSS-licentievoorwaarden altijd sprake is van een standaardtekst zonder specifieke informatie over de aard van de sofware zal uit die licentievoorwaarden weinig blijken ten aanzien van de specifieke eisen die aan de software zouden kunnen worden gesteld. Naast de inhoud van de licentievoorwaarden kunnen, normaal gesproken, mededelingen in het voortraject ook een rol spelen bij de vaststelling van de verplichtingen van de licentiegever. Ook daarvan zal echter meestal geen sprake zijn bij OSS omdat er tussen de licentiegever en de licentienemer doorgaans sprake is van een ver verwijderde band en er daarom tussen hen geen communicatie plaatsvindt. Daarenboven zullen de prijs die de licentienemer voor de software dient te betalen en de wijze waarop en het doel waarvoor de gebruiker de software zal gebruiken ook relevant zijn. Een bijzonder kenmerk van OSS is dat het gratis wordt geleverd. In het geval van Power en Kant & Klaar heeft er geen communicatie plaatsgevonden en Power heeft evenmin een vergoeding ontvangen voor Powerful. Power weet niet voor welke doeleinden Powerful zal worden gebruikt, nu het uiteenlopende toepassingsmogelijkheden heeft. Een belangrijk aspect van Powerful – en van OSS in het algemeen – is voorts dat er sprake is van een groot aantal makers dat aan de ontwikkeling er van heeft bijgedragen. Nu Powerful een fout blijkt te bevatten, zal moeten worden achterhaald door wiens toedoen de bewuste fout precies is ontstaan. Het is zeer wel mogelijk dat de fout is gelegen in (een deel van) de OSS die door Power van derden is verkregen. Gelet op al deze omstandigheden is er een gerede kans dat Power met succes zal kunnen beargumenteren dat de fout in Powerful niet aan haar kan worden toegerekend. Indien de toerekenbaarheid van de fout aan Power wel zou komen vast te staan, heeft Power wellicht nog de mogelijkheid een beroep te doen op de volgende uitsluiting van garantie en aansprakelijkheidsbepalingen in de BSD-voorwaarden: ‘This software is provided by copyright holders and contributors ‘as is’ and any express or implied warranties, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event shall the copyright owner or contributors be liable for any (…) damages (…) arising in any way out of the use of this software, even if advised of the possibility of such damage’

136


Een dergelijke exoneratieclausule is in min of meer dezelfde bewoordingen in de meest gangbare OSS-licentievoorwaarden opgenomen.4 Welke mogelijkheden heeft Kant & Klaar wanneer Power een beroep doet op deze exoneratieclausule? In dit verband is het van belang om vast te stellen of er sprake was van opzet/ bewuste roekeloosheid aan de zijde van Power. In geval van opzet zal Power in ieder geval geen succesvol beroep op de exoneratieclausule kunnen doen en bij bewuste roekeloosheid zal het van de ernst van de roekeloosheid afhangen. Van bewuste roekeloosheid zou bijvoorbeeld sprake kunnen zijn indien Power wist dat Powerful een programmeerfout bevat. In het hiernavolgende wordt er vanuit gegaan dat hiervan geen sprake was. Exoneratieclausules in OSS-licentievoorwaarden, zijnde algemene voorwaarden, kunnen gelet op de aard en de overige inhoud van de overeenkomst, de wijze waarop de voorwaarden tot stand zijn gekomen, de wederzijds kenbare belangen van partijen en de overige omstandigheden van het geval onredelijk bezwarend zijn voor de opdrachtgever. Op grond hiervan zou Kant & Klaar mogelijk de exoneratieclausule kunnen vernietigen (artikel 6: 233 sub a BW) mits de opdrachtgever geen jaarrekening heeft gepubliceerd (artikel 6:235 lid 1 sub a BW), minder dan 50 werknemers in dienst heeft (artikel 6:235 lid 1 sub b BW) en er geen sprake is van een internationale handelsbetrekking (artikel 6:247 lid 2 BW). Algemene voorwaarden zijn ingevolge artikel 6:231 sub a BW één of meer schriftelijke bedingen die zijn opgesteld teneinde in een aantal overeenkomsten te worden opgenomen, met uitzondering van bedingen die de kern van de prestaties aangeven, zoals de prijs. De grijze lijst (artikel 6:237 BW) bevat voorbeelden van bedingen in de algemene voorwaarden die niet de kern van de prestatie aangeven, zoals de exoneratieclausule die onder f wordt genoemd. OSS-licentievoorwaarden, waaronder begrepen exoneratieclausules, zijn opgesteld met het oogmerk om veelvuldig te worden overeengekomen en kunnen derhalve worden aangemerkt als algemene voorwaarden. Power zou ter verdediging kunnen aanvoeren dat het beding niet onredelijk bezwarend is. De software is door haar gratis ter beschikking gesteld en er heeft geen communicatie plaatsgevonden tussen haar en Kant & Klaar, waardoor de doeleinden waarvoor Kant & Klaar Powerful zou gebruiken niet bekend waren en er evenmin verwachtingen zijn gewekt omtrent de gebruiksmogelijkheden van

4

Zie Asser-Hartkamp 4-I, De verbintenis in het algemeen, Kluwer, Deventer, 2004, nr. 434.

137


Powerful. Onder deze omstandigheden zal de exoneratieclausule waarschijnlijk niet als onredelijk bezwarend kunnen worden aangemerkt. Naast vernietiging van de exoneratieclausule op grond van artikel 6:233 sub a BW kan Kant & Klaar aanvoeren dat de exoneratieclausule buiten toepassing moet blijven omdat deze clausule in de gegeven omstandigheden naar maatstaven van redelijkheid en billijkheid onaanvaardbaar is (artikel 6:248 lid 2 BW). Kant & Klaar kan op beide bepalingen een beroep doen.5 De Hoge Raad heeft in verschillende arresten uitgewerkt welke omstandigheden een rol kunnen spelen bij de toetsing of een exoneratieclausule naar maatstaven van redelijkheid en billijkheid onaanvaardbaar is.6 De volgende omstandigheden zijn daarbij geformuleerd: de aard en de verdere inhoud van de overeenkomst waarin het beding voorkomt, de maatschappelijke positie en de onderlinge verhouding van partijen, de wijze waarop het beding tot stand is gekomen, de mate waarin de wederpartij zich de strekking van het beding bewust is geweest en de zwaarte van de schuld, mede in verband met de aard en de ernst van de bij enige gedraging betrokken belangen. Power zal waarschijnlijk met succes kunnen aanvoeren dat Kant & Klaar als professionele partij niet had mogen verwachten dat zij bij eventuele fouten in Powerful verhaal zou kunnen halen bij Power, nu Powerful gratis ter beschikking is gesteld; Kant & Klaar had kunnen weten dat Power haar aansprakelijkheid voor eventuele schade heeft beperkt, nu alle OSS-licentievoorwaarden standaard dergelijke uitsluitingen van aansprakelijkheid bevatten. Het feit dat er geen contact is geweest tussen partijen en er derhalve over en weer geen verwachtingen zijn gewekt speelt ook een rol. Voor het geval Power niet met succes een beroep kan doen op de exoneratieclausule zou zij nog kunnen aanvoeren dat de gevorderde schade niet voor vergoeding in aanmerking komt nu die in een zodanig ver verwijderd verband staat met de tekortkoming dat zij haar, mede gezien de aard van de aansprakelijkheid en van de schade, als gevolg van de tekortkoming niet kan worden toegerekend (artikel 6:98 BW). Hierbij speelt een rol dat in geval van aansprakelijkheid gebaseerd op schuld eerder toerekening zou kunnen plaatsvinden dan wanneer er geen sprake is van schuld. In casu is er geen sprake van schuld. Bovendien zal in beginsel de schade door dood en letsel eerder worden

5

Vgl. in dit verband bijvoorbeeld artikel 2 van de MPL. Er zouden echter ook licentievoorwaarden kunnen worden gehanteerd waarbij door iedere bewerker van de software een sublicentie wordt verstrekt aan de opvolgende verkrijger. Er ontstaat dan geen rechtsverhouding tussen de verkrijger en de (overige) rechthebbenden. Zie ook hoofdstuk 7. 6 In deze afdeling is de Europese richtlijn inzake de aansprakelijkheid voor producten met gebreken (PbEG 7.10.85, nr. L 210/29), die op 25 juli 1985 werd vastgesteld, geïmplementeerd.

138


toegerekend dan zaakschade en zaakschade eerder dan vermogenschade, en geleden verlies eerder dan gederfde winst.7 Aangezien de gevorderde schade vermogenschade is, zou ook dit verweer van Powerful moeten slagen. Kortom, Kant & Klaar zal hoogstwaarschijnlijk haar schade niet kunnen verhalen op Power.

8.3.2

De aansprakelijkheid van Power jegens Jansen

8 3.2.1 Contract Indien aangetoond kan worden dat de door Jansen geleden schade te wijten is aan een gebrek in de door Power geleverde OSS, zal Jansen er mogelijk voor willen kiezen Power rechtstreeks aan te spreken. Wij veronderstellen dat Jansen als gebruiker van de OSS van iedere rechthebbende, en dus ook van Power, een rechtstreekse licentie heeft verkregen.8 In principe zou Jansen Power dus op vergelijkbare wijze kunnen aanspreken zoals Kant & Klaar Power kan aanspreken. Voor een analyse hiervan verwijzen wij naar de bespreking van de relatie tussen Kant & Klaar en Power. Alle argumenten die Power jegens Kant & Klaar kan aanvoeren zal zij in principe ook jegens Jansen kunnen aanvoeren. Het verschil is evenwel, dat Jansen een consument is en de exoneratieclausule ingevolge artikel 6:237 sub f BW vermoed zal worden onredelijk bezwarend te zijn. Power zal dit vermoeden willen weerleggen en zal daartoe aanvoeren dat de software door haar gratis is verstrekt, dat het haar niet bekend was waarvoor de software gebruikt zou worden en dat er geen rechtstreeks contact is geweest met Jansen, terwijl dat contact wel heeft plaatsgevonden tussen Jansen en Kant & Klaar en Kant & Klaar derhalve, in tegenstelling tot Power, op de hoogte was van de risico’s verbonden aan het gebruik dat door Jansen van Powerful zou worden gemaakt. Al deze argumenten zullen worden gewogen. Hoogstwaarschijnlijk zal Power met succes kunnen weerleggen dat de exoneratieclausule onredelijk bezwarend is.

7

Zie in dit verband onder meer R.J.J. Westerdijk, Produktenaansprakelijkheid voor software. Beschouwingen over de aansprakelijkheid voor informaticaprodukten, Deventer, 1995. 8 Zie bijvoorbeeld artikel 27 van de FENIT-voorwaarden: ‘Indien en voorzover leverancier programmatuur van derden aan cliënt ter beschikking stelt, zullen, mits dat door leverancier schriftelijk aan cliënt is meegedeeld, voor wat betreft die programmatuur de voorwaarden van die derden van toepassing zijn met terzijdestelling van het bepaalde in deze voorwaarden. Cliënt aanvaardt de bedoelde voorwaarden van derden. Deze voorwaarden liggen voor cliënt ter inzage bij leverancier en leverancier zal deze voorwaarden aan cliënt op zijn verzoek kosteloos toezenden. Indien en voorzover de bedoelde voorwaarden van derden in de verhouding tussen cliënt en leverancier om welke reden dan ook geacht worden niet van toepassing te zijn of buiten toepassing worden verklaard, geldt het bepaalde in deze algemene voorwaarden onverkort.’

139


8.3.2.2 Aansprakelijkheid op grond van onrechtmatige daad Los van de mogelijke contractuele relatie tussen Power en Jansen, kan Power, als maker van (een onderdeel van) onder een open source licentie geleverde software wellicht op grond van onrechtmatig handelen aansprakelijk worden gehouden voor de schadelijke gevolgen van gebreken in die software. Die schade zal dan wel aan Power toegerekend moeten kunnen worden en ook zal de onrechtmatigheid van de gedraging(en) van de maker moeten vaststaan. Daarbij geldt dat onder omstandigheden het enkele in het verkeer brengen van ondeugdelijke software, dat wil zeggen software die niet voldoet aan de eisen van het gebruik waarvoor het bestemd is, reeds onrechtmatig kan zijn tegenover derden. Of van onrechtmatig handelen sprake is, zal telkens afhangen van de concrete feiten en omstandigheden van het individuele geval. In de onderhavige casus, waarin ondeugdelijke OSS in het verkeer is gebracht, is het van belang vast te stellen of de fout is gelegen in het door derden vervaardigde en door Power hergebruikte deel van Powerful, dan wel of de fout is gelegen in de programmaregels die Power zelf heeft gemaakt. In het laatste geval zal een strenger aansprakelijkheidsregiem gelden dan in het geval een andere programmeur verantwoordelijk is voor het optreden van de fout in Powerful. 8.3.2.3 Productenaansprakelijkheid Ook de regeling van de derde afdeling van boek 6 BW9, waarin de risicoaansprakelijkheid van de producent voor de schadelijke gevolgen van gebrekkige producten is vastgelegd, zou mogelijk de grondslag kunnen vormen voor de aansprakelijkheid van Power, als producent van ondeugdelijke software die onder een open source licentie is geleverd, jegens Jansen. Vanzelfsprekend komt men aan toepassing van deze regeling slechts toe indien software kan worden gekwalificeerd als een product in de zin van deze regeling. Wij zien hierbij geen verschillen tussen closed source software en OSS. Artikel 6:187 lid 1 BW bepaalt dat onder ‘product’ wordt verstaan een roerende zaak, ook nadat deze een bestanddeel is gaan vormen van een andere roerende of onroerende zaak, alsmede elektriciteit. Of software, en dus ook open source software, onder deze definitie kan worden gebracht, is een nog niet uitgemaakte zaak10. Mocht dit het geval zijn, dan dient te worden bedacht dat op grond van de

9

J.G.J. Janssen/W.F.R. Rinzema/D.W.F. Verkade, Modelcontracten automatisering: handleiding met modellen, 1991. Algemene voorwaarden van de Federatie van Nederlandse Ondernemingen in de Informatietechnologie FENIT, gedeponeerd bij de griffie van de Rechtbank ’s-Gravenhage onder nummer 60/2003. De FENIT is ontstaan uit een fusie van de COSSO en het onderdeel informatica van de VIFKA. Inmiddels is de FENIT gefuseerd met Nederland ICT en gaat nu onder de naam ICT~Office door het leven.

10

140


productenaansprakelijkheidsregeling alleen aansprakelijkheid bestaat voor schade door dood of lichamelijk letsel en voor schade aan privé-zaken. De schade komt alleen voor vergoeding in aanmerking indien deze een drempel van € 500 overschrijdt. Jansen zal dus, indien zijn beroep op de toepasselijkheid van de productenaansprakelijkheidsregeling zou worden gehonoreerd, uitsluitend de eventueel aan zijn PC toegebrachte materiële schade kunnen verhalen en bovendien alleen dan voorzover deze schade voornoemd bedrag overschrijdt. Van dergelijke zaakschade is in de onderhavige casus evenwel geen sprake, zodat de productenaansprakelijkheidsregeling hier niet van toepassing is. Omdat het echter zeer wel denkbaar is dat het gebruik van OSS leidt tot schade aan privé-zaken of zelfs tot lichamelijk letsel (te denken valt aan de toepassing van OSS in embedded systems die door een verkeerde aansturing materiële schade of persoonlijk letsel veroorzaken), zal hieronder nader worden ingegaan op de wettelijke productenaansprakelijkheidsregeling. De producent mag zijn aansprakelijkheid voor gebrekkige producten niet uitsluiten of beperken. Power kan in dit verband dus geen beroep doen op de aansprakelijkheidsuitsluiting zoals opgenomen in het door haar gebruikte OSS-licentiemodel. Bij toepassing van de productenaansprakelijkheidsregeling op open source software kan de maker daarvan rechtstreeks door de gebruiker worden aangesproken voor de schadelijke gevolgen van gebreken daarin. Artikel 6:187 lid 2 BW bepaalt dat onder ‘producent’ wordt verstaan de fabrikant van een eindproduct, de producent van een grondstof of de fabrikant van een onderdeel. Iedere programmeur die heeft bijgedragen aan de ontwikkeling van de programmatuur kan dus aansprakelijk worden gesteld. Daarnaast wordt als producent ook beschouwd de ‘naamgever’, dat wil zeggen hij die zich naar buiten toe presenteert als producent door een naam, merk of ander onderscheidingsteken op het product aan te brengen. Voorts wordt ook de importeur die een product in de Europese Economische Ruimte invoert om het te verkopen of te verhuren als producent beschouwd. Als restcategorie wordt ten slotte ook de leverancier als producent beschouwd indien niet kan worden vastgesteld wie de producent of de EERimporteur van het product is. De productenaansprakelijkheidsregeling biedt een aantal aanknopingspunten voor een producent van OSS, voor het voeren van verweer tegen aansprakelijkstelling door een consument. Op de eerste plaats zij in dit verband verwezen naar artikel 6:186 lid 1, aanhef en sub b BW, dat bepaalt dat een product als gebrekkig moet worden beschouwd, indien het niet de veiligheid biedt die men daarvan

141


mag verwachten, alle omstandigheden in aanmerking genomen en in het bijzonder het redelijkerwijs te verwachten gebruik van het product. In veel gevallen zullen producenten van OSS zich er op kunnen beroepen dat zij geen enkele kennis dragen of konden dragen van de verschillende wijzen waarop de door hen ontwikkelde code door de gebruikers ervan wordt toegepast. Op de tweede plaats bepaalt artikel 6:185 lid 1, aanhef en sub c BW, dat de producent aansprakelijk is voor de schade veroorzaakt door een gebrek in zijn product, tenzij het product niet is verspreid met een economisch doel en de vervaardiging of verspreiding daarvan niet heeft plaatsgevonden in het kader van de uitoefening van beroep of bedrijf. Veel OSS wordt gratis verspreid en de vervaardiging en verspreiding geschiedt in de praktijk lang niet altijd in het kader van de uitoefening van beroep of bedrijf. Op de derde plaats kan de maker wellicht een beroep doen op het feit dat het voor hem op grond van de stand van de wetenschappelijke en technische kennis op het tijdstip waarop hij de software in het verkeer bracht, onmogelijk was het bestaan van het gebrek te ontdekken (artikel 6:185 lid 1, aanhef en sub e BW). Ten slotte zal de producent van een onderdeel van de programmatuur wellicht kunnen aanvoeren dat het gebrek is te wijten aan het ontwerp van de programmatuur waarvan zijn onderdeel een bestanddeel vormt (artikel 6:185 lid 1, aanhef en sub f BW). Gezien het bovenstaande zal een producent, zo al vast staat dat het ondeugdelijke deel van de OSS door hem is geproduceerd, wellicht ter verdediging kunnen aanvoeren dat hij de OSS niet heeft ontwikkeld ten behoeve van verspreiding met een economisch doel, aangezien hij het pakket via het internet gratis ter beschikking van derden heeft gesteld, mits hij tevens kan aantonen dat hij de OSS niet heeft ontwikkeld of verspreid in het kader van de uitoefening van zijn beroep of bedrijf.

8.4

De aansprakelijkheid van Kant & Klaar

8.4.1

Contractuele aansprakelijkheid van Kant & Klaar jegens Jansen

Anders dan bij de in de paragrafen 3.1 en 3.2 beschreven posities heeft Kant & Klaar in dit geval haar algemene verkoop- en leveringsvoorwaarden van toepassing verklaard en is er tussen Kant & Klaar en Jansen contact geweest over de gebruiksdoeleinden van de software. De inhoud van de overeenkomst tussen Kant & Klaar en Jansen is echter niet duidelijk; zij heeft immers nagelaten een

142


rangordebepaling op te nemen tussen de BSD-voorwaarden en haar algemene voorwaarden. Allereerst moet worden vastgesteld of er sprake is van een toerekenbare tekortkoming. Kant & Klaar zal willen betogen dat er geen sprake is van een toerekenbare tekortkoming nu de fout in Powerful zat, hetgeen bij haar niet bekend was. Jansen zal echter aanvoeren dat de fout weliswaar niet is te wijten aan de schuld van Kant & Klaar maar wel voor haar rekening dient te komen nu Kant & Klaar had moeten onderzoeken of er geen fout in de software zat. Kant & Klaar heeft uitdrukkelijk verklaard dat de software geschikt is om foto’s te verwerken en heeft voor de verkoop een vergoeding ontvangen. Deze omstandigheden zijn waarschijnlijk doorslaggevend voor de vaststelling dat er sprake is van een toerekenbare tekortkoming van Kant & Klaar. Kant & Klaar heeft twee exoneratieclausules waarop zij een beroep zou kunnen doen, waarbij haar voorkeur uiteraard zal uitgaan naar de exoneratieclausule in de BSD-voorwaarden omdat haar aansprakelijkheid daarin geheel is uitgesloten. Aangezien er geen rangordebepaling is opgenomen, is onduidelijk welke exoneratieclausule getoetst dient te worden. Hierbij zal onderzocht moeten worden welke mededelingen zijn gedaan in het voortraject. Indien Kant & Klaar niet uitdrukkelijk heeft vermeld dat Powerful een apart product is waarvoor aparte voorwaarden gelden11, kan Jansen wellicht met succes aanvoeren dat de exoneratieclausule uit de BSD-voorwaarden niet van toepassing is. Aangezien Jansen consument is, zal de exoneratieclausule vermoed worden onredelijk bezwarend te zijn. De argumenten die Power jegens Jansen kon aanvoeren (vergelijk paragraaf 3.2.1) zal Kant & Klaar niet kunnen aanvoeren; zij wist immers waarvoor de software gebruikt zou worden en zij heeft een vergoeding ontvangen. Een argument in het voordeel van Kant & Klaar zou kunnen zijn dat het beding uit haar algemene voorwaarden niet onredelijk bezwarend is, nu Kant & Klaar aansprakelijkheid voor directe schade aanvaardt tot de factuurwaarde; gelet op de risico’s verbonden aan het gebruik van de software, kan van een leverancier niet worden verlangd dat hij ook gevolgschade accepteert, mede omdat de omvang daarvan uiterst onzeker is. Het is moeilijk te voorspellen wie in het gelijk zal worden gesteld. Jansen zou ook nog een beroep kunnen doen op artikel 6:248 lid 2 BW. De omstandigheden die hiervoor zijn opgesomd, komen ook daarbij aan de orde. Waarschijnlijk zal de uitkomst hetzelfde zijn.

11

Zie voor uitvoerige besprekingen van de FENIT-voorwaarden: H.S.M. Kruijer, De exoneratieclausules in de algemene voorwaarden van de Federatie van Nederlandse ondernemingen in de informatietechnologie (FENIT), ITeR reeks nr. 33, Kluwer, Deventer 2000; J.M.A. Berkvens/A.H.J. Kuus, FENIT-voorwaarden 6: the next generation?, Computerrecht 2003/6, pp. 346-349; T.J. de Graaf, Cliënt niet beter af met de nieuwe FENIT-voorwaarden, Contracteren 2004/1, pp. 11-20; W.H. van Holst, Nieuwe FENIT-voorwaarden benadelen afnemer, Computable, 10 oktober 2003, p. 55.

143


Daarenboven zou Jansen kunnen betogen dat er sprake is van consumentenkoop en dat hem daarom een extra vernietigingsgrond toekomt ingevolge artikel 7:6 BW. Voor het geval Kant & Klaar niet met succes haar exoneratieclausule kan inroepen, zal zij nog willen betogen dat de gevorderde schade niet voor vergoeding in aanmerking komt, nu die in een zodanig verband staat met de tekortkoming dat zij haar, mede gezien de aard van de aansprakelijkheid en de schade, als gevolg van de tekortkoming niet kan worden toegerekend. Het feit dat in casu geen sprake is van schuld van Kant & Klaar pleit in haar voordeel. De schade die voortvloeit uit beschadiging van de programmatuur maakt een goede kans om voor vergoeding in aanmerking te komen, in tegenstelling tot de immateriële schade. Indien Kant & Klaar wel met succes haar exoneratieclausule kan inroepen, zal onduidelijkheid bestaan over de vraag of de door Jansen gevorderde schade directe schade of gevolgschade is. Het begrip directe schade heeft naar Nederlands recht geen eenduidige betekenis. Schade aan de totaaloplossing zelf zal worden aangemerkt als directe schade. Het is echter onduidelijk of het beschadigen van de andere software op de PC van Jansen ook zal worden aangemerkt als directe schade. De immateriële schade zal in ieder geval niet als directe schade worden aangemerkt.

8.4.2

Productenaansprakelijkheid

Zoals reeds werd vermeld in paragraaf 3.2.3 kan de leverancier van een gebrekkig product als producent in de zin van de derde afdeling van boek 6 BW worden beschouwd, indien niet kan worden vastgesteld wie de producent of de EERimporteur van het product is. De leverancier kan aan aansprakelijkheid ontkomen als hij binnen een redelijke termijn de identiteit onthult van de producent of van degene die hem het product heeft geleverd. Afgezien van het feit dat in de onderhavige casus geen sprake is van zaakschade die op grond van de productenaansprakelijkheidsregeling voor vergoeding in aanmerking komt, heeft Kant & Klaar de BSD-voorwaarden op de voorgeschreven wijze van toepassing verklaard op de met Jansen gesloten overeenkomst. Aangezien Jansen dus bekend was met de namen van de producenten, zal Kant & Klaar niet op grond van de wettelijke productenaansprakelijkheidsregeling aansprakelijk kunnen worden gesteld voor schade als gevolg van gebreken in de delen van de OSS die niet door haar zijn vervaardigd. Voor deze schade zal Kant & Klaar Jansen immers kunnen ‘doorver-

144


wijzen’ naar haar voorgangers in de ontwikkelketen van de betreffende programmatuur.

8.5

Conclusie

Licentienemers van OSS die door gebruik van OSS door hen geleden schade trachten te verhalen op een OSS-licentiegever/leverancier zullen, afhankelijk van de omstandigheden van het geval, hun aansprakelijkstelling kunnen baseren op onrechtmatig handelen aan de zijde van de licentiegever/leverancier, op de wettelijke productenaansprakelijkheidsregeling of op een tekortschieten in de nakoming van contractuele verplichtingen door de licentiegever/leverancier. In het laatste geval zullen zij veelal worden geconfronteerd enerzijds met de onduidelijkheid aan wie een fout in de OSS kan worden toegerekend en anderzijds met verstrekkende exoneratieclausules. Het bijzondere kenmerk van OSS dat het meestal gratis wordt verstrekt, maakt het niet eenvoudig om een beroep op een exoneratieclausule met succes aan te vechten. Aangezien tussen de OSS-licentiegevers en de OSS-licentienemers meestal geen communicatie plaatsvindt, is het voor de licentiegevers niet bekend waarvoor de licentienemers de OSS willen gebruiken. Het feit dat de licentiegever derhalve geen verwachtingen heeft gewekt over de mogelijkheden van de OSS werkt in zijn voordeel. Indien de licentienemer OSS (als geïntegreerd onderdeel van andere software) licentieert van een distributeur, zal hij meer kans maken op het vergoed krijgen van zijn schade nu het kenmerkende aspect van de gratis verstrekking ontbreekt. Bovendien heeft een distributeur in die situatie veelal verwachtingen gewekt ten aanzien van de mogelijkheden van de programmatuur en is hij wellicht bekend met het doel waarvoor de licentienemer de OSS wenst te gebruiken.

145

9

Levering van open source software onder de BiZa-modelcontracten of de FENIT-voorwaarden Walter van Holst, Arend Lagemaat en Edward de Lange

In de IT-praktijk wordt veel gebruik gemaakt van de zogenaamde BiZa-modelcontracten1 en de FENIT-voorwaarden2. Zowel voor de BiZa-modelcontracten als de Fenit-voorwaarden geldt dat deze voor diverse typen transacties zijn ontwikkeld, zoals de ontwikkeling en levering van standaardprogrammatuur en het verrichten van onderhoud. In deze modellen staan onder meer clausules inzake de intellectuele eigendomsrechten op programmatuur, de omvang van het aan de gebruiker toekomende gebruiksrecht, de aansprakelijkheid van de leverancier en de door de leverancier verstrekte garanties en vrijwaringen. Bovendien kennen de BiZa-modelcontracten en de FENIT-voorwaarden een rechtskeuze- en een forumkeuzebeding. Omdat de toepassing van de BiZa-modelcontracten en de FENIT-voorwaarden zo wijd verbreid is, ligt het in de rede te onderzoeken in hoeverre deze modellen afwijken van de daarmee corresponderende bepalingen in de verschillende open source licentie modellen. Hierbij beperken wij ons tot de General Public License (GPL), de Mozilla Public License (MPL), de Apache licentie en de BSD licentie. In de praktijk kan het bijvoorbeeld voorkomen dat open source software (in combinatie met closed source software) wordt geleverd onder een BiZa-modelcontract of de FENIT-voorwaarden. Zowel voor leveranciers als voor gebruikers kan het daarom nuttig zijn een vergelijking te maken tussen deze verschillende bepalingen. In dit hoofdstuk wordt een aanzet gegeven voor deze vergelijking. Hierbij zal niet uitputtend worden stilgestaan bij de inhoud en de verschillen tussen de hiervoor genoemde open source licentiemodellen.

1

Dit addendum is te vinden op de website van OSOSS: . Voor een uitvoerige vergelijking van de FENIT-voorwaarden met de BiZa-modelcontracten zij verwezen naar meer algemene publicaties over dit onderwerp buiten de OSS-context. Bijvoorbeeld: E.C. Voskamp, Checklist FENIT algemene voorwaarden en BiZa modelcontracten, een artikelsgewijze vergelijking, Checklisten Informatiemanagement, nr. 48, april 2004, pp. 1-63.

2

147


9.1

Inleiding

De FENIT-voorwaarden stammen af van de COSSO-voorwaarden en zijn in 2003 voor het laatst vernieuwd.3 De FENIT-voorwaarden zijn door de ICT brancheorganisatie opgesteld en daarmee specifiek ter bescherming van de positie van de ICT-leverancier geredigeerd. Een tegengeluid van de zijde van de afnemers kon niet uitblijven. Begin jaren negentig verschenen standaardcontracten zoals deze uitgegeven zijn door het Ministerie van Binnenlandse Zaken: de BiZamodelcontracten. Hiervan stamt de laatste editie uit 1995, al liggen een aantal vernieuwde modellen in de planning. Inmiddels is er, in verband met het toenemende gebruik van OSS, een addendum verschenen.4 Nu de opkomst van OSS een nieuw hoofdstuk lijkt in te luiden in de machtsverhouding tussen afnemers en leveranciers van software, is het nuttig te bezien hoe de reeds langer gehanteerde standaardovereenkomsten zich verhouden tot de meest gebruikte OSS-licenties. De overeenkomsten en verschillen tussen deze standaardovereenkomsten en OSS-licenties zullen achtereenvolgens worden behandeld aan de hand van de navolgende onderwerpen:5 – intellectuele eigendomsrechten; – omvang van het gebruiksrecht; – aansprakelijkheid van de leverancier; – garanties van de leverancier; – vrijwaringen; – rechts- en forumkeuze. Daarbij wordt ingegaan op de situatie waarin de FENIT-voorwaarden danwel een BiZa-modelcontract van toepassing worden c.q. wordt verklaard op de levering van OSS (in combinatie met closed source software).

9.2

Intellectuele eigendomsrechten

Zowel de BiZa-modelcontracten als de FENIT-voorwaarden en de OSS-licenties bepalen uitdrukkelijk bij wie de intellectuele eigendomsrechten op de geleverde programmatuur berusten. De BiZa-modelcontracten maken daarbij onderscheid

3

Zie bijvoorbeeld artikel 11 van het BiZa-modelcontract ‘Ontwikkelingsovereenkomst Maatwerkprogrammatuur’. Zie artikel 6 lid 1, eerste volzin van de FENIT-voorwaarden. 5 Deze bepaling luidt als volgt: ‘Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients’ exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.’. 4

148

Levering van open source software onder de BiZa-modelcontracten of de FENIT-voorwaarden

tussen standaardprogrammatuur en maatwerkprogrammatuur. De intellectuele eigendomsrechten op onder BiZa-modelcontracten geleverde standaardprogrammatuur blijven bij de leverancier (of de producent) berusten, terwijl de intellectuele eigendomsrechten op door de leverancier vervaardigde maatwerkprogrammatuur worden overgedragen aan de afnemer.6 Indien programmatuur wordt geleverd onder de FENIT-voorwaarden blijven daarentegen steeds alle intellectuele eigendomsrechten berusten bij de leverancier, diens licentiegevers of diens toeleveranciers, ongeacht of sprake is van standaard- of maatwerkprogrammatuur.7 Programmatuur die wordt geleverd onder de OSS-licenties blijft ook de eigendom van de maker. Indien standaardprogrammatuur wordt geleverd die geheel of gedeeltelijk bestaat uit onder een OSS-licentie geleverde componenten, zal er voor wat de intellectuele eigendomsrechten betreft dus geen sprake zijn van onderlinge strijdigheid tussen de OSS-licenties, de BiZa-modelcontracten en de FENIT-voorwaarden. In alle gevallen blijven de intellectuele eigendomsrechten bij de maker c.q. leverancier berusten. Wel zal de leverancier de door hem geleverde standaardprogrammatuur, als deze moet worden beschouwd als een bewerking van door hem onder een OSS-licentie verkregen software, aan zijn afnemers ter beschikking moeten stellen onder de voorwaarden van die OSS-licentie. In geval van levering onder een BiZa-modelcontract inzake maatwerkprogrammatuur die deels bestaat uit onder een OSS-licentie verkregen en deels uit door de leverancier zelf vervaardigde componenten, kan op het eerste oog strijdigheid met de OSS-licentie ontstaan. Op grond van de BiZa-modelcontracten dienen de intellectuele eigendomsrechten op de maatwerkprogrammatuur immers te worden overgedragen aan de afnemer. Indien de door de leverancier geleverde maatwerkprogrammatuur moet worden beschouwd als een bewerking van door hem onder de OSS-licentie verkregen programmatuur, blijven echter de bepalingen van de OSS-licentie van toepassing op het geheel, inclusief de maatwerkcomponenten. Het contracteren op basis van de BiZa-modelcontracten over de levering van die maatwerkcomponenten zal evenwel geen problemen opleveren. Het overdragen van de intellectuele eigendomsrechten op de door de leverancier ontwikkelde maatwerkcomponenten aan de afnemer kan immers niet worden gezien als een restrictie in de zin van de OSS-licenties (zoals bijvoorbeeld bedoeld in artikel 6

6

Zie bijvoorbeeld artikel 2 van het BiZa-modelcontract ‘Overeenkomst tot beschikbaarstelling van Standaardprogrammatuur’. 7 Vgl. artikel 5.3 van het BiZa-modelcontract ‘Overeenkomst tot beschikbaarstelling van Standaardprogrammatuur’.

149


van de GPL8), zodat het gebruik van de BiZa-modelcontracten op dit punt geen strijdigheid oplevert met de OSS-licenties. Op grond van de FENIT-voorwaarden blijven, zoals gezegd, ook in geval van maatwerkprogrammatuur de intellectuele eigendomsrechten berusten bij de leverancier. Indien onder de FENIT-voorwaarden maatwerkprogrammatuur wordt geleverd waarin OSS-componenten zijn opgenomen, ontstaat er ten aanzien van de intellectuele eigendomsrechten derhalve geen strijdigheid tussen de FENITvoorwaarden en de OSS-licenties.

9.3

Omvang van het gebruiksrecht

Krachtens de BiZa-modelcontracten verleent de leverancier aan de afnemer een niet-exclusief, eeuwigdurend en onherroepelijk recht tot het gebruik van de standaardprogrammatuur.9 Het gebruiksrecht is beperkt tot (alle verveelvoudigingen en openbaarmakingen benodigd dan wel redelijkerwijs wenselijk voor) het ‘normaal gebruik’ van de standaardprogrammatuur. Onder dit ‘normaal gebruik’ verstaan de BiZa-modelcontracten in ieder geval ook het aan derden in beheer geven van de standaardprogrammatuur, het door derden doen onderhouden en/of wijzigen van de standaardprogrammatuur, het maken van kopieën voor backup-doeleinden en voor continuïteitsplanning, alsmede het opnemen en integreren van de programmatuur in andere systemen van afnemer. In de regel zal het gebruiksrecht niet overdraagbaar zijn. De broncode van de standaardprogrammatuur wordt niet aan de afnemer overgedragen. In plaats daarvan dient de afnemer met de leverancier een escrowregeling voor de broncode van de standaardprogrammatuur af te sluiten.10 De omvang van het gebruiksrecht op de programmatuur wordt in de FENIT-voorwaarden in verschillende bepalingen geregeld. Artikel 6.1 luidt, voorzover hier relevant, als volgt: ‘Cliënt verkrijgt uitsluitend de gebruiksrechten die bij deze voorwaarden en de wet uitdrukkelijk worden toegekend. Ieder ander of verdergaand recht van cliënt tot verveelvoudiging van programmatuur is uitgesloten. Een aan cliënt toekomend recht tot gebruik is niet-exclusief en nietoverdraagbaar aan derden.’

8

Zie voor een bespreking van de belangrijkste typen OSS-licenties hoofdstuk 6 van dit preadvies. Zie artikel 12 van de GPL (Version 2, June 1991), artikel 9 van de MPL 1.1 en artikel 8 van de Apache License (Version 2.0). 10 Zie voor een nadere bespreking van (de houdbaarheid van) exoneratieclausules in OSS-licenties de hoofdstukken 7 en 8 van dit preadvies. 9

150


In lid 4 van dit artikel wordt het de afnemer verboden kopieerbeveiligingen te omzeilen en in lid 5 worden restricties opgelegd aan het aantal reservekopieën dat de afnemer mag maken. Verder bepaalt lid 6 dat er een recht op foutherstel bestaat, onder bepaalde restrictieve voorwaarden. Daarnaast bevat artikel 23 van de FENIT-voorwaarden nog een aantal beperkte gebruiksrechten. In lid 2 van dit artikel staat dat het gebruiksrecht beperkt is tot de verwerkingseenheden en/of gebruikers waarvoor het gebruiksrecht is verstrekt, terwijl in lid 3 van dit artikel het volgende over de broncode is vermeld: ‘[…] De broncode van de programmatuur en de bij de ontwikkeling van de programmatuur voortgebrachte technische documentatie worden niet aan cliënt ter beschikking gesteld, ook niet indien cliënt bereid is voor deze terbeschikkingstelling een financiële vergoeding te voldoen. Cliënt erkent dat de broncode een vertrouwelijk karakter heeft en dat deze bedrijfsgeheimen van leverancier bevat.’

Indien programmatuur geleverd wordt onder een OSS-licentie verkrijgt de afnemer een veel ruimer gebruiksrecht, dan genoemd in de BiZa-modelcontracten en de FENIT-voorwaarden. In beginsel is het de afnemer onder een OSS-licentie toegestaan de programmatuur onbeperkt te gebruiken, te wijzigen, te verveelvoudigen en openbaar te maken, mits aan een aantal voorwaarden is voldaan. De belangrijkste voorwaarde is dat de broncode van de programmatuur beschikbaar gesteld wordt.11 Alleen de BSD licentie vormt hierop een uitzondering. Deze OSS-licentie bevat weinig meer dan de eis van vermelding van de oorspronkelijke auteur. Anders wordt het in het geval van de MPL (versie 1.1). Deze eist in artikel 3.1 dat bij verdere verspreiding de broncode onder dezelfde voorwaarden wordt verspreid als opgenomen in de MPL. De MPL kent in artikel 2.1 onder a en in artikel 2.2 aan de afnemer onder meer het recht toe de programmatuur te gebruiken, te verveelvoudigen, tentoon te stellen, uit te voeren, door te licentiëren en openbaar te maken.

11

De BiZa-modelcontracten kennen geen equivalent van artikel 27 van de FENIT-voorwaarden. Artikel 27 van de FENIT-voorwaarden luidt als volgt: ‘Indien en voorzover leverancier programmatuur van derden aan cliënt ter beschikking stelt, zullen, mits dat door leverancier schriftelijk aan cliënt is meegedeeld, voor wat betreft die programmatuur de voorwaarden van die derden van toepassing zijn met terzijdestelling van het bepaalde in deze voorwaarden. Cliënt aanvaardt de bedoelde voorwaarden van derden. Deze voorwaarden liggen voor cliënt ter inzage bij leverancier en leverancier zal deze voorwaarden aan cliënt op zijn verzoek kosteloos toezenden. Indien en voorzover de bedoelde voorwaarden van derden in de verhouding tussen cliënt en leverancier om welke reden dan ook geacht worden niet van toepassing te zijn of buiten toepassing worden verklaard, geldt het bepaalde in deze algemene voorwaarden onverkort.’

151


Ook de Apache-licentie (versie 2.0) kent een dergelijke verplichting; in artikel 4 wordt de verplichting opgelegd om dezelfde licentie te hanteren bij verdere distributie. Toevoegingen en wijzigingen mogen evenwel onder een andere licentie worden verspreid. De GPL kent eveneens verstrekkende bevoegdheden aan de afnemer toe, en verbiedt tevens het opleggen van verdere beperkingen aan de verkrijger van de programmatuur. Dit geldt ook ten aanzien van wijzigingen en toevoegingen welke door de verkrijger worden aangebracht. Artikel 6 van de GPL luidt daartoe als volgt: ‘Each time you distribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients’ exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.’

Uit het voorgaande volgt dat in geval van levering van programmatuur, die geheel of gedeeltelijk bestaat uit door de leverancier onder een OSS-licentie verkregen componenten of wanneer de door de leverancier geleverde programmatuur moet worden beschouwd als een ‘bewerking’ van door hem onder een OSS-licentie verkregen programmatuur, het aan de afnemer toekomende gebruiksrecht op grond van de BiZa-modelcontracten en op grond van de FENIT-voorwaarden te beperkt is en in strijd is met de toepasselijke OSS-licentie (met uitzondering van de BSD-licentie). De leverancier zal de door hem te leveren programmatuur aan zijn afnemers ter beschikking moeten stellen onder de voorwaarden van de toepasselijke OSS-licentie, waardoor de daarmee strijdige bepalingen uit de BiZamodelcontracten of de FENIT-voorwaarden terzijde worden gesteld. De afnemer van de programmatuur verkrijgt aldus een (veel) ruimer gebruiksrecht dan het geval zou zijn geweest bij toepasselijkheid van de BiZa-modelcontracten of de FENIT-voorwaarden.

9.4

De aansprakelijkheid van de leverancier

Bij toepassing van de BiZa-modelcontracten accepteert de leverancier aansprakelijkheid voor schade als gevolg van niet-nakoming van zijn verplichtingen uit de overeenkomst, zij het dat een beperking van die aansprakelijkheid is opgenomen. Daarbij wordt een onderscheid gemaakt tussen directe en indirecte schade. Indirecte schade wordt in de BiZa-modelcontracten ook aangeduid als gevolgschade. De aansprakelijkheid voor directe schade is beperkt tot een maximumbedrag. In de praktijk wordt de aansprakelijkheid voor indirecte schade veelal uitgesloten, 152


maar vanzelfsprekend kan ook deze tot een nader te bepalen bedrag worden gemaximeerd. Het komt er vooral op aan duidelijk te definiëren wat onder directe/indirecte schade wordt verstaan. Er kan voor worden gekozen de directe schade limitatief te definiëren en alle overige schade als indirecte schade of gevolgschade te beschouwen, ofwel de indirecte schade limitatief te definiëren en alle overige schade als directe schade aan te duiden. De typen schade die in de BiZa-modelcontracten als directe schade worden gedefinieerd, zijn zodanig uitgebreid dat ook schadeposten die in een (tamelijk) ver verwijderd verband staan ten opzichte van de schadeveroorzakende gebeurtenis, als directe schade worden aangeduid. De beperkingen van aansprakelijkheid komen te vervallen in geval van schade als gevolg van dood of letsel, in geval van opzet of grove schuld van de leverancier en/of diens personeel en in geval van schending van intellectuele eigendomsrechten. Bij toepassing van de BiZa-modelcontracten aanvaardt de leverancier dus een betrekkelijk vergaande aansprakelijkheid voor schade als gevolg van zijn (eventuele) wanprestatie. In de FENIT-voorwaarden wordt de aansprakelijkheid van de leverancier in vergaande mate beperkt. De totale aansprakelijkheid van de leverancier als gevolg van niet nakoming van de overeenkomst is beperkt tot vergoeding van directe schade en tot een bepaald bedrag. Wat onder directe schade moet worden verstaan is limitatief en beperkt omschreven. De maximale vergoeding is beperkt tot het bedrag van de overeenkomst of het totaal van de vergoedingen bedongen in één jaar in geval van een duurovereenkomst. In geen geval zal de totale vergoeding meer bedragen dan EUR 500.000,–. Het door de leverancier te vergoeden bedrag voor schade door dood of lichamelijk letsel of materiële beschadiging van zaken bedraagt nimmer meer dan EUR 1.250.000,–. De aansprakelijkheid voor indirecte schade wordt volledig uitgesloten. Bij toepassing van een van de OSS-licenties accepteert de leverancier daarentegen geen enkele aansprakelijkheid voor schade als gevolg van niet-nakoming van zijn verplichtingen uit de overeenkomst of welke andere oorzaak dan ook.12 In geval er schade optreedt als gevolg van het gebruik van de programmatuur, is de positie van de afnemer die de programmatuur verkreeg onder een OSS-licentie dus lastiger. Dit is slechts anders indien de afnemer zich gerechtvaardigd op het standpunt kan stellen dat de in de OSS-licentie opgenomen beperking of uitsluiting van aansprakelijkheid nietig of vernietigbaar is. Of dit het geval is, hangt

12

Zie bijvoorbeeld artikel 7 van het BiZa-modelcontract ‘Overeenkomst tot beschikbaarstelling van Standaard programmatuur met maatwerk aanpassingen’.

153


onder meer af van het op de overeenkomst toepasselijke recht en de omstandigheden van het geval. Naar Nederlands recht is het mogelijk dat geoordeeld wordt dat een leverancier geen beroep kan doen op de in de OSS-licentie opgenomen exoneratieclausule.13 De vraag is nu wat de status is van de in de BiZa-modelcontracten en de FENITvoorwaarden opgenomen beperkingen en uitsluitingen van aansprakelijkheid, indien deze van toepassing zijn verklaard in geval van levering van programmatuur, die geheel of gedeeltelijk bestaat uit door de leverancier onder een OSSlicentie verkregen componenten. Indien de leverancier met succes een beroep kan doen op de toepasselijkheid van de in de OSS-licentie opgenomen exoneratieclausule, zou de afnemer zich op het standpunt kunnen stellen dat niettemin de in de FENIT-voorwaarden of de BiZamodelcontracten opgenomen aansprakelijkheidsbeperkingen van toepassing zijn. Deze zijn – opmerkelijk genoeg – in feite een uitbreiding van de rechten van een afnemer van OSS. Het recht op schadevergoeding van de afnemer wordt immers verruimd. Dit is niet in strijd is met het bepaalde in de OSS-licenties. Indien de FENIT-voorwaarden van toepassing zijn verklaard, zou de leverancier evenwel kunnen betogen dat de bepalingen van de OSS-licentie prevaleren, aangezien artikel 27 van de FENIT-voorwaarden bepaalt dat in geval van levering van programmatuur van derden voor wat die programmatuur betreft de voorwaarden van die derden van toepassing zijn met terzijdestelling van de FENIT-voorwaarden.14 Indien het beroep van de leverancier op de toepasselijkheid van de in de OSSlicentie opgenomen exoneratieclausule niet slaagt, zou de afnemer zich ook op het standpunt kunnen stellen dat hij zijn schade volledig kan verhalen op de leverancier. De leverancier zal zich in dat geval op zijn beurt willen beroepen op de in de FENIT-voorwaarden danwel de BiZa-modelcontracten opgenomen beperkingen of uitsluitingen van aansprakelijkheid. Ook dan zal dus moeten worden vastgesteld welke voorwaarden prevaleren. Voor wat de FENIT-voorwaarden betreft, dient dit wederom mede aan de hand van artikel 27 te worden gedaan. Bij het niet van toepassing zijn van de in de OSS-licentie opgenomen exoneratieclausule zou de toepasselijkheid van de FENIT-voorwaarden dan wel de BiZa-

13

Zie bijvoorbeeld artikel 1.1 van het BiZa-modelcontract ‘Overeenkomst tot beschikbaarstelling van Standaard programmatuur met maatwerk aanpassingen’. 14 Zie bijvoorbeeld artikel 11.6 van het BiZa-modelcontract ‘Overeenkomst tot beschikbaarstelling van Standaard programmatuur met maatwerk aanpassingen’.

154


modelcontracten op grond van een grammaticale interpretatie in feite een beperking van de rechten van de afnemer meebrengen en strijdigheid met het bepaalde in de OSS-licenties. Wie de OSS-licenties als de GPL, de MPL en de Apache licentie teleologisch interpreteert, zal dit niet als problematisch ervaren, immers, het was de kennelijke bedoeling van de auteurs van deze OSS-licenties om de aansprakelijkheid van de maker zoveel mogelijk in te perken. Indien de wijze waarop zij dit hebben gedaan naar Nederlands recht niet rechtsgeldig moet worden geoordeeld, zou kunnen worden gesteld dat het hanteren van een minder vergaande beperking van aansprakelijkheid in dat geval niet in strijd is met de strekking van de OSS-licenties. Wie de laatste uitlegmethode volgt, zal dus tot de conclusie komen dat de leverancier, indien zijn beroep op de in de OSS-licentie opgenomen exoneratie niet slaagt, zich in ieder geval nog kan beroepen op de in de FENIT-voorwaarden dan wel de BiZa-modelcontracten opgenomen beperking of uitsluiting van aansprakelijkheid.

9.5

De door de leverancier verstrekte garanties

Bij toepassing van de BiZa-modelcontracten garandeert de leverancier dat de programmatuur over een aantal in de overeenkomst nader aangeduide eigenschappen beschikt.15 Indien wordt geconstateerd dat dit niet het geval is, is de leverancier gedurende de garantieperiode verplicht de geconstateerde gebreken in de programmatuur zo spoedig mogelijk te verhelpen. De FENIT-voorwaarden kennen een voor de afnemer (veel) minder gunstige garantieregeling: gedurende de garantieperiode is de leverancier slechts gehouden naar beste vermogen eventuele fouten in de programmatuur te herstellen, waarbij ook nog eens uitdrukkelijk is bepaald dat de leverancier niet garandeert dat de programmatuur zonder onderbreking of fouten zal werken of dat alle fouten zullen worden verbeterd. Indien de programmatuur ter beschikking wordt gesteld onder een OSS-licentie, wordt deze geleverd ‘as is’. Enige garantie met betrekking tot de afwezigheid van fouten of het voldoen aan bepaalde technische normen wordt door de rechthebbende niet gegeven. Zo vermeldt artikel 11 van de GPL bijvoorbeeld:

15

Artikel 12.2 van de FENIT-voorwaarden luidt als volgt: ‘Geschillen welke tussen leverancier en cliënt mochten ontstaan naar aanleiding van een tussen leverancier en cliënt gesloten overeenkomst dan wel naar aanleiding van nadere overeenkomsten die daarvan het gevolg zijn, worden beslecht door middel van arbitrage overeenkomstig het Arbitragereglement van de Stichting Geschillenoplossing Automatisering te Den Haag, een en ander onverminderd het recht van partijen een voorziening in arbitraal kort geding te vragen en onverminderd het recht der partijen tot het treffen van conservatoire rechtsmaatregelen.’

155


‘[…] The entire risk as to the quality and performance of the program is with you. Should the program prove defective, you assume the cost of all necessary servicing, repair or correction.’

Wat is nu de status van de in de BiZa-modelcontracten en de FENIT-voorwaarden opgenomen garantieregelingen indien deze van toepassing zijn verklaard in geval van levering van programmatuur, die geheel of gedeeltelijk bestaat uit door de leverancier onder een OSS-licentie verkregen componenten of die moet worden beschouwd als een bewerking van door hem onder een OSS-licentie verkregen programmatuur? Hoewel de leverancier in deze gevallen de voorwaarden van de toepasselijke OSS-licentie zal moeten hanteren, zou de afnemer zich ook op het standpunt kunnen stellen dat niettemin de in de FENIT-voorwaarden of de BiZa-modelcontracten opgenomen garantieregeling van toepassing is, omdat daarmee een uitbreiding van de rechten van de afnemer van OSS wordt bewerkstelligd. In feite betreft dit een soortgelijke situatie als ten aanzien van de aansprakelijkheid. Indien de FENIT-voorwaarden van toepassing zijn verklaard, geldt opnieuw dat de leverancier met een beroep op artikel 27 van die voorwaarden zou kunnen betogen dat de bepalingen van de OSS-licentie prevaleren en dat de afnemer wat de OSS betreft geen beroep toekomt op de garantieregeling uit de FENIT-voorwaarden. Voor de BiZA-modelcontracten geldt dat de garantiebepalingen betrekking hebben op het algemene begrip ‘Programmatuur’, dat is gedefinieerd als het geheel van Standaard en Maatwerkprogrammatuur, inclusief Documentatie en Materialen.16 In deze definitie wordt geen onderscheid gemaakt tussen programmatuur van de leverancier zelf, programmatuur van derden of OSS. Indien de leverancier niet uitdrukkelijk heeft bepaald de OSS niet valt onder het begrip Programmatuur of anderszins heeft bepaald dat de garantiebepalingen uit de BiZa-modelcontracten niet van toepassing zullen zijn op de te leveren OSS, lijkt een beroep door een afnemer op de garantiebepalingen ook voor OSS zeer wel verdedigbaar.

9.6

Vrijwaringen

De BiZa-modelcontracten bepalen uitdrukkelijk dat de leverancier van standaardprogrammatuur gehouden is de afnemer te vrijwaren tegen aanspraken van derden ter zake van inbreuk op intellectuele eigendomsrechten van derden.17

16 17

In hoofdstuk 10 wordt nader ingegaan op vragen van internationaal privaatrecht en OSS. Zie in die zin ook hoofdstuk 7.

156


Van min of meer soortgelijke orde is de vrijwaring van artikel 6.7 van de FENITvoorwaarden, zij het dat deze vrijwaring beperkter is. Dit artikel vrijwaart afnemers van programmatuur tegen aanspraken op grond van (vermeende) inbreuken op intellectuele eigendomsrechten van derden. Bij programmatuur die onder een traditionele licentie wordt verspreid, is het gebruikelijk dat de leverancier zelf ook een dergelijke vrijwaring verkrijgt van de voorgaande leverancier in de keten en men er langs deze weg voor tracht te zorgen dat uiteindelijk de producent van de programmatuur verantwoordelijk kan worden gehouden voor (vermeende) inbreuken die het gebruik van de programmatuur veroorzaakt. De OSS-licenties kennen geen vrijwaringsbepaling. Deze zijn zodanig ingericht dat de verantwoordelijkheden van de licentiegever zoveel mogelijk worden beperkt. Indien de afnemer van de programmatuur wordt geconfronteerd met een claim van een derde als gevolg van het (beweerdelijk) inbreukmakende karakter van de aan hem geleverde programmatuur, zal hij in geval van toepasselijkheid van een OSS-licentie niet door zijn leverancier worden gevrijwaard. Indien de leverancier OSS levert onder de BiZa-modelcontracten of de FENITvoorwaarden, ontvangt hij dus zelf geen vrijwaring ten aanzien van de OSS van zijn (toe)leverancier. Een afnemer kan zich evenwel op het standpunt stellen dat de BiZa-modelcontracten of de FENIT-voorwaarden de bepalingen van de OSSlicentie op dit punt aanvullen en dat de leverancier hem ook dient te vrijwaren tegen claims van derden als gevolg van het (beweerdelijk) inbreukmakende karakter van de aan hem geleverde OSS. Indien een dergelijk beroep in rechte slaagt, ontstaat er dus een juridisch risico voor de leverancier. Gelet op het algemene karakter van de vrijwaringsbepaling uit de BiZa-modelcontracten lijkt een beroep op de vrijwaringsbepaling door een afnemer ook voor OSS een goede kans van slagen te hebben. Voor wat de FENIT-voorwaarden betreft, dient dit wederom rekening te worden gehouden met artikel 27 van die voorwaarden. Nu de OSS-licenties geen vrijwaringsbepaling kennen, kan een afnemer in geval van een inbreuk daarop geen beroep doen. Indien dit in rechte onaanvaardbaar wordt geoordeeld, prevaleert op grond van artikel 27 van de FENIT-voorwaarden de vrijwaringsregeling van de FENIT-voorwaarden. Derhalve is aannemelijk dat een afnemer op goede gronden een kan beroep doen op de in de FENIT-voorwaarden opgenomen vrijwaringsbepaling.

157


9.7

Rechts- en forumkeuze

De BiZa-modelcontracten bepalen dat zij worden beheerst door Nederlands recht en dat geschillen bij uitsluiting dienen te worden voorgelegd aan de rechter in het arrondissement Den Haag. De FENIT-voorwaarden bepalen eveneens dat de overeenkomst tussen leverancier en afnemer wordt beheerst door Nederlands recht en dat geschillen – kort gezegd – zullen worden beslecht door een arbitragepanel van de Stichting Geschillenoplossing Automatisering (SGOA).18 De MPL bepaalt dat zij wordt beheerst door het recht van de staat Californië en dat bij geschillen, indien ten minste één van de partijen Amerikaans is, de federale rechter van het Northern District of Californië bevoegd is. De andere OSSlicentiemodellen kennen geen rechtskeuze- en/of forumkeuzebeding. Ook in dit geval zou een afnemer zich op het standpunt kunnen stellen dat, indien de BiZa-modelcontracten of de FENIT-voorwaarden mede van toepassing zijn op de tussen hem en de leverancier gesloten overeenkomst, de bepalingen van de toepasselijke OSS-licentie (niet zijnde de MPL) op dit punt worden aangevuld door de BiZa-modelcontracten of de FENIT-voorwaarden. Dit zou dan kunnen betekenen dat eventuele geschillen met betrekking tot de geleverde OSS naar Nederlands recht dienen te worden beslecht door de bevoegde rechter te Den Haag dan wel een arbitragepanel van de SGOA. Indien de OSS wordt geleverd onder de MPL is het mogelijk om bij licentieverlening een afwijkende rechts- en forumkeuze (bijvoorbeeld voor Nederlands recht en de Nederlandse rechter) overeen te komen.19

9.8

Conclusie en aanbeveling voor de praktijk

Na vergelijking van zowel de FENIT-voorwaarden als de BiZa-modelcontracten met de OSS-licentiemodellen kan worden geconcludeerd dat tussen deze verschillende typen standaardvoorwaarden structurele verschillen bestaan en dat de OSS-licenties niet altijd in de mal van de ‘klassieke’ licentievormen passen.

18

Verdrag inzake het recht dat van toepassing is op verbintenissen uit overeenkomst, Rome 19 juni 1980, Trb. 1980, 156 (rectificatie Trb. 1991, 109). 19 Wij hanteren hierbij als uitgangspunt dat de OSS-licentie rechtsgeldig tot stand is gekomen. De rechter gaat bij de beoordeling hiervan uit van het recht dat krachtens het EVO van toepassing zou zijn geweest op de (geldige) overeenkomst, conform de verwijzingsregels van het EVO. Indien een partij beweert dat er geen overeenkomst tot stand is gekomen, dan wel hij niet heeft ingestemd met de betreffende voorwaarden, kan hij ten bewijze daarvan zich ook beroepen op het recht van het land waar hij zijn gewone verblijfplaats heeft (artikel 8 EVO).

158


Zowel bij toepasselijkheid van de FENIT-voorwaarden als bij toepasselijkheid van de BiZa-modelcontracten in combinatie met OSS zullen partijen telkens moeten nagaan welke voorwaarden ten aanzien van welk deel van de geleverde programmatuur prevaleren en – in samenhang daarmee – tot hoever de eventuele aanvullende of beperkende werking van de FENIT-voorwaarden dan wel de BiZa-modelcontracten zich uitstrekt. In de praktijk kan dit leiden tot onduidelijkheden en onzekerheden tussen afnemers en leveranciers over hun rechten en verplichtingen ten aanzien van het gebruik van OSS. Aandachtspunten voor een afnemer van OSS onder een OSS-licentie zijn vooral de uitgebreidere reikwijdte van het gebruiksrecht op OSS, de uitsluiting van aansprakelijkheid en het ontbreken van vrijwaringen. Voor een afnemer betekent toepasselijkheid van een OSS-licentie kort samengevat dat enerzijds de uitsluiting van aansprakelijkheid en het ontbreken van vrijwaringen dient te worden geaccepteerd maar anderzijds wel een uitgebreide licentie wordt verkregen. Het is voor een afnemer om die reden van belang duidelijkheid te verkrijgen over de licentievoorwaarden die van toepassing zijn op de levering en het gebruik van OSS. Voor een leverancier zijn juist de verdergaande garantiebepalingen, aansprakelijkheidsbepalingen en vrijwaringsbepalingen uit de BiZa-modelcontracten of de FENIT-voorwaarden een risico indien deze ook van toepassing worden geacht op het gebruik van OSS. Het is voor een leverancier om die reden van belang duidelijkheid te scheppen over de verhouding tussen de BiZa-modelcontracten of de FENIT-voorwaarden enerzijds en de OSS-voorwaarden anderzijds. Het is immers niet zonder meer duidelijk of de door hem gebruikte contractuele voorwaarden wel of niet van toepassing zijn op de levering en het gebruik van OSS. Ten aanzien van intellectuele eigendomsrechten spelen er slechts enkele aandachtspunten een rol bij de levering van OSS onder een BiZa-modelcontract of onder de FENIT-voorwaarden. Ten eerste is aan de orde gesteld de situatie waarin sprake is van de levering van een combinatie van bestaande OSS met maatwerk. In de tweede plaats is gewezen op het ontbreken van vrijwaringsbepalingen voor inbreuken in OSS-licenties, terwijl deze wel in de FENIT-voorwaarden en BiZa-modellen zijn opgenomen. Het verdient aanbeveling om in de overeenkomst duidelijk te maken dat gebruik wordt gemaakt van OSS componenten en de corresponderende OSS-licentie te benoemen als ‘bijzondere voorwaarden’ welke van toepassing zijn op die OSScomponenten. In het bijzonder is dit van belang indien er sprake is van tegenstrijdigheid van de verschillende voorwaarden. 159

10

OSS vanuit internationaal privaatrechtelijk perspectief Jean-Paul Sars, Bartosz Sujecki en Irene Verheijen

De verspreiding van OSS vindt veelal plaats in een internationale context. Meer nog dan bij closed source software het geval is, zijn gebruiker en maker van OSS vaak in verschillende landen gevestigd. Dit roept evidente rechtsvragen op, zoals: welk recht is van toepassing op de verspreiding van OSS, welke rechter is bevoegd in een geschil betreffende OSS en hoe kan een verkregen vonnis ook in het land van de wederpartij erkend en ten uitvoer gelegd worden? Deze vragen liggen op het terrein van het internationaal privaatrecht. Het internationaal privaatrecht verschaft de verwijzingsregels naar onder meer het toepasselijke recht en de bevoegde rechter. Deze bijdrage beoogt aan de hand van een aantal casus een indruk te geven van aspecten die volgens het internationaal privaatrecht zoals dat naar Nederlands recht geldt, een rol spelen bij de distributie en het gebruik van OSS. Daarbij zal in deze bijdrage worden ingegaan op de door de benadeelde partij in te stellen actie op grond van de contractuele relatie tussen de gebruiker(s) en de maker(s) van de OSS alsmede op grond van onrechtmatige daad en inbreuk op het auteursrecht.

10.1

Inleiding

Bij de totstandkoming van een OSS-licentieovereenkomst kunnen vele partijen betrokken zijn. Ieder die heeft bijgedragen aan de ontwikkeling van de OSS geldt in principe als auteursrechthebbende op de OSS. Tussen iedere auteursrechthebbende en elke opvolgende licentienemer komt een separate licentieovereenkomst tot stand.1 Gelet op de verspreiding van OSS, die veelal plaatsvindt via het internet, is er bij de licentieverlening van OSS doorgaans sprake van veel verschillende internationale rechtsverhoudingen.

1

Naast objectief-geografische aanknopingspunten kunnen ook andere (minder feitelijke) aspecten van de rechtsverhouding een rol spelen bij de vaststelling van het internationale karakter, zoals juridische aspecten van de rechtsverhouding, zie: L. Strikwerda, Inleiding tot het Nederlandse Privaatrecht, Kluwer 2002, p. 5.

161


In sommige OSS-licenties staat een rechtskeuze. Zo staat bijvoorbeeld een rechtskeuze voor het recht van Californië (USA) in artikel 11 van de Mozilla Public License (1.1), artikel 13.7 van de Apple Public Source License (2.0) en in de X.Net License. Artikel 11 Academic Free License (2.1) verklaart daarentegen het recht van de plaats van vestiging van de licentiegever van toepassing. Op zijn beurt verwijst artikel 7 Common Public License naar het recht van de staat New York (USA) en de Q Public License naar – opvallend genoeg – dat van Noorwegen. In een aantal OSS-licenties, zoals bijvoorbeeld de Mozilla Public License en de Apple Public Source License, wordt een rechtskeuze gemaakt waarbij tegelijk de IPR-conflictenregels van het gekozen recht buiten toepassing worden verklaard. Deze regels zouden anders via verwijzing juist weer een ander rechtsstelsel van toepassing kunnen verklaren. In OSS-licenties zijn forumkeuzes slechts incidenteel opgenomen: overeenkomsten betreffende de bevoegde rechtbank zijn te vinden in artikel 11 van de Mozilla Public License, in artikel 13.6 van de Apple Public Source License alsmede in de Q Public License. Schematisch kan een en ander als volgt worden weergegeven: OSS-licentie

Rechtskeuze

Mozilla Public License (1.1)

Recht van Californië, USA, Federale rechtbank van het (artikel 11), tenzij toepasse- noordelijk district van Californië, USA (artikel 11), lijk recht anders uitwijst. mits een van de partijen een Amerikaans ingezetene is.

Apple Public Source License (2.0)

Recht van Californië, USA (artikel 13.7)

Rechtbank van het noordelijk district van Californië, USA (artikel 13.6)

X.Net License

Recht van Californië, USA

–

Academic Free License (2.1)

Recht van de plaats van – vestiging van de licentiegever

Common Public License

Recht van de staat New York, USA (artikel 7)

–

Q Public License

Recht van Noorwegen

Rechtbank van de stad Oslo, Noorwegen

162

Forumkeuze

OSS vanuit internationaal privaatrechtelijk perspectief

In de meeste OSS-licenties ontbreekt echter een expliciete rechts- dan wel forumkeuze, en dient te worden teruggevallen op de algemene verwijzingsregels in het internationaal privaatrecht. De contractpartijen hebben daarnaast de mogelijkheid aanvullend een rechts- en/of forumkeuze te maken door middel van een separate overeenkomst of in algemene voorwaarden. Ook wanneer er sprake is van een onrechtmatige inbreuk op de rechten van een maker, dient te worden teruggevallen op de algemene verwijzingsregels in het internationaal privaatrecht, tenzij de betrokken partijen achteraf alsnog de keuze maken voor het toepasselijke recht en de bevoegde rechter. Dit hoofdstuk behandelt voor de OSS-situatie achtereenvolgens de drie ‘klassieke’ IPR-vragen met betrekking tot het toepasselijke recht, de bevoegde rechter en de tenuitvoerlegging van rechterlijke uitspraken. Daarbij zal onderscheid worden gemaakt tussen de situatie waarbij de OSS-licentieovereenkomst niet is nageleefd (wanprestatie) en die waarbij er sprake is van inbreuk op een recht (onrechtmatige daad), of meer specifiek van een inbreuk op een recht van intellectuele eigendom (auteursrecht) op de OSS. Dit zal geschieden aan de hand van een drietal casusposities. Casus 1 De in Duitsland woonachtige softwareprogrammeur Helmut heeft software ontwikkeld op basis van OSS die ontwikkeld is door de in de USA woonachtige Michael. Helmut stelt de door hem ontwikkelde software op zijn beurt ook weer als OSS op het internet beschikbaar. De in Nederland gevestigde onderneming Cheesco B.V. past deze software toe in één van haar producten en verspreidt het verder als closed source software. Het wordt een commercieel succes. In de OSS-licentievoorwaarden is geen rechtskeuze noch forumkeuze bepaling opgenomen.

Casus 2 De in België gevestigde onderneming Belgaco is zeer onder de indruk van het succes van Cheesco en sluit een exclusieve licentieovereenkomst met Cheesco voor het vervaardigen en distribueren van de betreffende software.

Casus 3 Ook het in China gevestigde WooPing Ltd. is onder de indruk van het succes van Cheesco. WooPing weet de hand te leggen op de source code van de software van Cheesco en besluit de software na te maken.

163


10.2

Toepasselijk recht

A

De contractssituatie

Welk recht van toepassing is op (geschillen voortvloeiend uit) de internationale licentieverlening dan wel het gebruik van OSS, dient – vanuit Nederlands perspectief – te worden beoordeeld aan de hand van het Europees Verbintenissenverdrag (het EVO).2 Het EVO is van toepassing op overeenkomsten die een internationaal karakter dragen en waarbij uit het recht van verschillende landen moet worden gekozen (artikel 1 lid 1 EVO). Dit wordt ook wel aangeduid als het internationaliteitsvereiste.3 De verwijzingsregels van het EVO worden door de rechters in de verdragsluitende Staten op alle overeenkomsten met een internationaal karakter toegepast. In casus 1 kan het internationale karakter van de rechtsverhouding(en) worden vastgesteld aan de hand van objectief geografische aanknopingspunten, die enerzijds wijzen in de richting van Duitsland, anderzijds in de richting van Nederland.4 Ook overeenkomsten die zijn aangegaan via het internet, kunnen worden beoordeeld aan de hand van de regels van internationaal privaatrecht in het EVO. Dit is hier van belang, nu veel OSS-licentieovereenkomsten totstandkomen via het internet. Het zal voor OSS-licentieovereenkomsten echter vaak moeilijk zijn om aan de hand van objectief-geografische aanknopingspunten het internationale karakter van de betreffende overeenkomst te kunnen bepalen. Overeenkomsten die via het internet worden gesloten, hebben niet per definitie een internationaal karakter – twee partijen in hetzelfde land kunnen immers ook via internet een overeenkomst sluiten – en het is voor partijen bij een overeenkomst via het internet niet altijd duidelijk wat de concrete fysieke locatie is van de andere partij. De plaatsen waar de servers dan wel de service providers zich bevinden, zijn vaak willekeurig gekozen en vormen daarom in het algemeen geen bruikbaar (geografisch) aanknopingspunt voor de plaats van vestiging van de contractanten.5

2

S. van der Hof, Internationale on-line overeenkomsten, Sdu 2002, p. 124-125. S. van der Hof, aangehaald werk, p. 150. 4 L. Strikwerda, Inleiding tot het Nederlandse Internationaal Privaatrecht, Kluwer 2000, p. 164. 5 Het EVO heeft universele werking; indien op grond van de verwijzingsregels van het EVO het recht van toepassing wordt verklaard van een staat die geen partij is bij het EVO, dan is ingevolge artikel 2 EVO toch dat recht van toepassing. Daarentegen zijn uitsluitend de rechters van de verdragsluitende staten gebonden aan de verwijzingsregels van het EVO. 3

164


Indien online-overeenkomsten kunnen worden herleid tot en kunnen worden geplaatst in de fysieke wereld (bijvoorbeeld doordat de levering plaatsvindt daar waar de afnemer zich bevindt)6, kan aan de hand van de fysieke vestigingsplaats van de contractspartijen worden bepaald in hoeverre is voldaan aan het internationaliteitsvereiste; het feit dat de transactie langs elektronische weg plaatsvindt, verandert niets daaraan. In casus 1 hebben twee online transacties plaatsgehad: Helmut heeft een licentieovereenkomst gesloten met Michael en op haar beurt heeft Cheesco twee (parallelle) licentieovereenkomsten gesloten met Helmut respectievelijk Michael. De partijen bij al deze overeenkomsten bevinden zich in verschillende landen, zodat deze als ‘internationaal’ kunnen worden aangemerkt en aan de hand van het EVO kan worden bepaald welk recht daarop van toepassing is. Het staat partijen bij een overeenkomst vrij om het recht te kiezen dat zij van toepassing willen laten zijn op de overeenkomst. Volgens het EVO kan een dergelijke rechtskeuze expliciet worden gemaakt door opneming van een rechtskeuzeclausule in de overeenkomst, maar ook stilzwijgend, gebaseerd op de overige bepalingen van de overeenkomst of de omstandigheden van het geval. A.1 Rechtskeuze In het internationale contractenrecht wordt een ruime leer gehanteerd met betrekking tot de rechtskeuzebevoegdheid.7 Partijen kunnen ieder rechtsstelsel kiezen, ongeacht of er een aanknopingspunt is tussen dat recht en de betreffende overeenkomst. Zo kan in een OSS-licentie tussen een Duitse en een Nederlandse partij een keuze zijn gemaakt voor bijvoorbeeld Frans recht of zelfs voor Chinees recht.8 Ook kan een partiële rechtskeuze worden gemaakt, waarbij op een deel van de overeenkomst ander recht van toepassing is dan op een ander deel van de overeenkomst.9 Dit brengt mee dat in beginsel iedere bewerker van de software bij verdere verspreiding voor zijn deel zijn eigen rechtskeuze mag toevoegen en opleggen aan opvolgende gebruikers. Op iedere afzonderlijke rechtsverhouding kan dus weer een ander recht van toepassing zijn.

6

L. Strikwerda, aangehaald werk, p. 170. L. Strikwerda, aangehaald werk, p. 171. 8 Uitzonderingen zijn dwingendrechtelijke bepalingen betreffende consumentenovereenkomsten (artikel 5 lid 2 EVO) en arbeidsovereenkomsten (artikel 6 lid 1 EVO). Een uitzondering vormen ook de voorrangsregels en regels in internationale verdragen (artikel 7 en artikel 21 EVO). 9 S. van der Hof, aangehaald werk, p. 124-125 en p. 150-152. 7

165


De gebruiker/distributeur van OSS dient zich er van bewust te zijn dat bij de aanvaarding van de licentievoorwaarden mogelijk ook een rechtskeuze wordt aanvaard. Het is partijen op grond van artikel 3 lid 2 EVO weliswaar toegestaan om af te wijken van de afspraken die zij eerder bij overeenkomst hebben gemaakt, maar uitsluitend indien beide partijen daarmee instemmen. De wijziging in de rechtskeuze door partijen ná de totstandkoming van een overeenkomst is niet van invloed op de formele geldigheid van de overeenkomst en doet geen afbreuk aan rechten van derden.10 Stel dat in casus 1 een rechtskeuze zou staan in de OSSlicentie voor Duits recht, dan zouden partijen er om hun moverende redenen en in onderling overleg voor kunnen kiezen om later alsnog Nederlands (of enig ander recht) op de door hen gesloten (deel)overeenkomst van toepassing te laten zijn. Of dit reëel is voor OSS-situaties kan men zich afvragen, nu de maker en gebruiker vrijwel nooit contact met elkaar zullen hebben en er doorgaans evenmin onderhandelingen plaatsvinden. Aan de ruime rechtskeuzebevoegdheid van de partijen bij de overeenkomst worden echter wel beperkingen gesteld. Van belang is het internationaliteitsvereiste. De rechtskeuze mag er niet toe leiden dat bij overeenkomsten, die niet een internationaal karakter dragen, de keuze voor een buitenlands recht de dwingende bepalingen van het recht van het land waarmee de overeenkomst uitsluitend is verbonden buiten toepassing laat. Rechtskeuze met betrekking tot niet-internationale overeenkomsten is niet verboden, maar kan dwingendrechtelijke bepalingen (zoals bepalingen ter bescherming van consumenten of werknemers) van het nationale recht niet uitsluiten. Wanneer het gaat om een rechtskeuze ten aanzien van een internationale overeenkomst is dat wel het geval, uitzonderingen daargelaten.11 Vanuit de Nederlandse situatie geredeneerd zal op een OSS-licentie waarin een rechtskeuze is opgenomen het recht van het aldus gekozen land van toepassing zijn. Dat is zelfs het geval wanneer de OSS-licentie tussen twee Nederlanders zou zijn gesloten, met dien verstande dat in dat geval (ook) Nederlandse dwingendrechtelijke bepalingen van toepassing zijn op de rechtsverhouding. Gelet op het feit dat het internationale karakter van een overeenkomst niet altijd evident is, geeft een rechtskeuzebeding geen volledige rechtszekerheid over de op de rechtsverhouding toepasselijke rechtsregels.12 Hoewel het de rechtszeker-

10 11 12

S. van der Hof, aangehaald werk, p. 127-128. L. Strikwerda, aangehaald werk, p. 172. S. van der Hof, aangehaald werk, p. 149.

166


heid zou dienen indien alle online overeenkomsten per definitie beschouwd zouden kunnen worden als een internationaal contract, lijkt dit niet verenigbaar met artikel 3 lid 3 EVO.13 Ook bij online gesloten overeenkomsten zal dus steeds moeten worden nagegaan of naast het gekozen recht niet ook dwingendrechtelijke regels uit een ander rechtsstelsel gelden, omdat niet aan het internationaliteitsvereiste is voldaan. A.2 Geen rechtskeuze Indien partijen geen rechtskeuze maken – zoals in casus 1 het geval is –, dan gelden de verwijzingsregels zoals vastgelegd in artikel 4 EVO. Hierbij is het uitgangspunt dat de overeenkomst wordt beheerst door het recht van het land waarmee zij het nauwst is verbonden. In eerste instantie wordt aangenomen dat dat het recht betreft van het land waar de contractspartij op het tijdstip van het sluiten van de overeenkomst woont of gevestigd is, die de voor de overeenkomst karakteristieke prestatie moet verrichten. Dit vermoeden kan echter worden weerlegd.14 In het geval van een OSS-licentie lijkt het op het eerste gezicht voor de hand te liggen dat de licentiegever zal worden beschouwd als degene die de karakteristieke prestatie levert. De licentieverlening is in beginsel immers kenmerkend voor de overeenkomst. Doorgaans is de karakteristieke prestatie niet de prestatie die bestaat uit de betaling van een geldsom. Daar komt nog bij dat in het geval van OSS-licentieverlening hier niet of nauwelijks een geldelijke tegenprestatie tegenover staat. Betoogd kan echter ook worden dat de OSS-licentiegever niet altijd degene is die de karakteristieke prestatie levert. Dit kan bijvoorbeeld anders zijn, indien de verplichting tot handhaving en bescherming van op de software rustende intellectuele eigendomsrechten bij de licentienemer komt te liggen.15 In het geval van de OSS-licenties kan wellicht een rol spelen dat de verkrijger van de licentie in voorkomend geval tevens de verplichting heeft om een afgeleid werk opnieuw conform dezelfde licentievoorwaarden aan derden ter beschikking te stellen. In ons voorbeeld in casus 1 zou in de rechtsverhouding tussen Helmut en Cheesco dus zowel Duits als Nederlands recht van toepassing kunnen zijn.16

13

De beantwoording van de vraag wie kan worden aangemerkt als degene die de karakteristiek prestatie verricht, is afhankelijk van de specifieke feiten en omstandigheden. 14 L. Strikwerda, aangehaald werk, p. 172. 15 Deze vermelding staat aan het einde van de GNU GPL. Bovendien wordt ook op de website van het GNU-project hiernaar verwezen. Vergelijk . Overigens zij opgemerkt dat, zelfs indien de (e-mail) adresgegevens van een programmeur zijn vermeld in de source code of licentietekst, daarmee niet altijd diens feitelijke woon- of verblijfplaats kan worden vastgesteld. 16 L. Strikwerda, aangehaald werk, p. 173 e.v.

167


Voor de hand ligt ons inziens dat Helmut hier de karakteristieke prestatie verricht en dat daarmee dus Duits recht van toepassing is. Een complicerende factor is dat in het geval van een OSS-licentie er wel honderden licentiegevers kunnen zijn, zodat – althans in theorie – vele rechtsstelsels naast elkaar van toepassing kunnen zijn op de (bundel van parallelle) licentie(s) ter zake van een OSS-product. Daarentegen zou, op praktische gronden, kunnen worden verdedigd dat op de hele bundel van licenties één en hetzelfde rechtstelsel van toepassing is. Bijvoorbeeld het recht van de woon- of vestigingsplaats van de ‘oudste’ licentiegever (de developer). Volgt men deze optiek, dan zou in casus 1 het Amerikaanse recht van toepassing zijn. Eventueel kan op een deel van de OSS-licentie het recht van een ander land worden toegepast. Voorwaarde hiervoor is dat dat deel van de overeenkomst kan worden afgescheiden van de rest van de overeenkomst, en dat dit deel nauwer verbonden is met het land waarvan het recht wordt toegepast.17 Denkbaar is dat onder een OSS-licentie een afgebakend deel van de software kan worden beschouwd te zijn gemaakt of ontwikkeld door een andere softwareontwikkelaar dan het overige deel van de software. Op dit deel zou dan een ander recht van toepassing kunnen zijn dan op de rest van de overeenkomst, zelfs als hiervoor een rechtskeuze is gemaakt. In casus 1 betekent dit dat op een deel van de OSS Amerikaans recht van toepassing kan zijn en op een ander deel Duits recht. Bij de verspreiding van OSS via internet zal het naast het bepalen van wie de ‘karakteristieke prestatie’ levert, ook lastig zijn om vast te stellen wat de woondan wel vestigingsplaats is van de partij die de karakteristieke prestatie verricht. In de GNU-GPL-licentievoorwaarden is hiervoor de volgende oplossing bedacht. In die voorwaarden wordt de maker geadviseerd de software te voorzien van informatie die het mogelijk maakt om via de elektronische of conventionele weg contact met hem op te nemen.18 Daarnaast kan men er soms op rekenen dat de afzonderlijke programmeurs binnen de OSS-beweging elkaar kennen, zodat de vaststelling van hun identiteit mogelijk is.19 Ten slotte kunnen de contractanten ook overwegen uitsluitend OSS te downloaden die voldoende informatie bevat

17

S. van der Hof, aangehaald werk, p. 202. Als zodanig kunnen worden beschouwd semipubliekrechtelijke (gemeenschapsbeschermende) voorschriften, op bijvoorbeeld het gebied van mededinging, milieu en monetaire regelgeving; zie L. Strikwerda, aangehaald werk, p. 70 e.v. 19 L. Strikwerda, aangehaald werk, p. 13. 18

168


over de makers/licentiegevers om hun identiteit en verblijfplaats te kunnen vaststellen. Voor een aantal categorieën van overeenkomsten bestaat een uitzondering op de hoofdregel van artikel 4 EVO (nauwste verbondenheid). Zo geldt op basis van artikel 5 lid 3 EVO bij overeenkomsten met consumenten, waarbij geen rechtskeuze is gemaakt, in voorkomende gevallen als uitgangspunt het recht van het land waar de consument zijn gewone verblijfplaats heeft.20 Conform een ruime uitleg vallen ook online overeenkomsten met consumenten onder artikel 5 EVO.21 Met name bij online overeenkomsten, en daarmee ook bij veel OSSlicentieovereenkomsten, kan er sprake zijn van onduidelijkheid over de hoedanigheid van de partijen bij de overeenkomst. Indien één van de partijen kan worden beschouwd als een consument (dat wil zeggen een persoon, die de OSS niet bedrijfs- of beroepsmatig zal gebruiken), kunnen krachtens artikel 5 EVO op de overeenkomst de bijzondere bepalingen van de consumentenovereenkomst van toepassing zijn. Dat betekent dat, onder omstandigheden, de OSS-licentieovereenkomst beheerst kan worden door het (dwingende) recht van het land waar de licentienemer/consument zijn gewone verblijfplaats heeft. De rechter kan op grond van artikel 7 EVO onder omstandigheden en ongeacht een eventuele rechtskeuze door partijen, ook gebonden zijn aan voorrangsregels. Dit zijn dwingendrechtelijke bepalingen die in acht dienen te worden genomen, ook wanneer de rechtsverhouding voor het overige door een ander rechtsstelsel wordt beheerst.22 Daarnaast kunnen ook specifieke regels van het gemeenschapsrecht voorrang hebben (artikel 20 EVO), alsmede regels in internationale verdragen waarbij een verdragsluitende staat partij is of zal worden (artikel 21 EVO). Of dit het geval is, dient te worden beoordeeld aan de hand van de specifieke voorzieningen die de betreffende verdragen daartoe bieden.23 Denkbaar is bijvoorbeeld samenloop met het Weens koopverdrag24 en de Richtlijn inzake elek-

20

Verdrag van de Verenigde Naties van 11 april 1980 inzake internationale koopovereenkomsten betreffende roerende zaken (Weens koopverdrag), Trb. 1986, 61. 21 Richtlijn 2000/31/EG van het Europees Parlement en de Raad van 8 juni 2000 betreffende bepaalde juridische aspecten van de diensten van de informatiemaatschappij, met name de elektronische handel in de interne markt (Richtlijn inzake elektronische handel), PbEG 2000, L 178/1, gepubliceerd en in werking getreden op 17 juli 2000. Zie: S. van der Hof, aangehaald werk, p. 156 e.v. 22 Bijvoorbeeld Mozilla Public License, Academic Free License. 23 E.P.M. Thole, Internationaal privaatrecht en e-commerce, in: E.P.M. Thole/A.E. Dekhuijzen (red.), 50 vragen over ecommerce, Kluwer 2001, pag. 221 e.v. Opgemerkt zij in dit verband dat sommige OSS-licenties toepassing van het Weens Koopverdrag expliciet uitsluiten. 24 Wet van 11 april 2001, Stb.2001, 190; Kamerstukken 26 608.

169


tronische handel25, 26 Aan de hand van het specifieke geval zal moeten worden beoordeeld of de regels van het EVO op basis van de voorrangsregels, dan wel regels in internationale verdragen, moeten wijken. Hierbij zal wederom van belang zijn of de overeenkomst wordt gesloten met een consument dan wel met een professionele partij en of er al dan niet sprake is van een on-line overeenkomst.

B

Onrechtmatige daad

Van de hiervoor omschreven situaties dient te worden onderscheiden de situatie waarin geen sprake is van een overeenkomst, maar iemand gebruik maakt van OSS, zonder de daarbij behorende voorwaarden in acht te nemen. In dat geval kan er sprake zijn van inbreuk op het auteursrecht van de (vele) maker(s) van de OSS. In ons voorbeeld (casus 2) kan de actie van de Amerikaanse en de Duitse programmeurs gebaseerd zijn op het onrechtmatig handelen van de Belgische onderneming, die inbreuk maakt op de rechten van Michael en Helmut. Wanneer er sprake is van grensoverschrijdend onrechtmatig handelen, kunnen de betrokken partijen (achteraf) een rechtskeuze maken. Dit kan op dezelfde wijze geschieden als in het geval van een rechtskeuze op basis van een overeenkomst. De betrokken partijen kunnen hun rechtskeuze mondeling overeenkomen of vastleggen in een (vaststellings)overeenkomst.27 In hoeverre dit een reële optie is, gelet op het karakter van de verkijging van OSS, veelal via internet, en het grote aantal partijen dat bij het maken en verspreiden ervan betrokken kan zijn, zal de praktijk moeten uitwijzen. Als geen rechtskeuze wordt gemaakt, wordt een vordering uit onrechtmatige daad in beginsel beheerst door het recht van het land waar de onrechtmatige daad heeft plaatsgevonden (‘lex loci delicti’). Van dit uitgangspunt gaat ook de Wet conflictenrecht onrechtmatige daad uit.28 Deze wet geeft een algemene regeling van het (internationale) conflictenrecht betreffende verbintenissen uit onrechtmatige daad.29 De vraag doet zich echter voor waar en wanneer, in de complexe

25

E.P.M. Thole, aangehaald werk, pag. 221 e.v. K. Koelman, Brothers in arms: open source en auteursrecht, Computerrecht 2004, 36, p. 230 e.v. 27 E.P.M. Thole, aangehaald werk, p. 232. 28 K. Koelman, aangehaald werk, p. 230 ev.; M.M.M. van Eechoud, Choice of law in copyright and related rights, alternatives to the lex protectionis, Kluwer; London 2003, p. 121-124. 29 Vergelijk met betrekking tot de voordelen van de overeenkomsten betreffende de bevoegde rechtbank P. Vlas, Burgerlijke Rechtsvorderingen (suppl. 292), artikel 23, aant. 1. Omtrent de problemen bij de bepaling van de bevoegdheid van rechtbanken m.b.t. handelsverkeer over internet zie: T. Jaeger, A. Metzger, Open Source Software, München 2002, p. 88; S. van der Hof, aangehaald werk, p. 35 e.v.; S. van der Hof, Internationaal privaatrechtelijke aspecten van open source licenties, in: Staden ten Brink/Goudkade/Elseman (red.), E-Commerce: Juridische knelpunten praktisch belicht, Nijmegen 2005, p. 141 e.v. 26

170


situatie die de verspreiding van OSS via internet meebrengt, de onrechtmatige daad plaatsvindt. Genoemde wet biedt op dat punt geen duidelijkheid. Verdedigbaar is dat de onrechtmatige daad plaatsvindt op het moment van downloaden van de OSS, zonder dat daarbij de licentievoorwaarden in acht worden genomen. Denkbaar is ook dat het moment van bewerking of het verder verspreiden van de OSS in closed software bepalend is voor de vraag waar de inbreuk plaatsvindt. Voor het bepalen van de ‘locus delicti’ kan worden aangesloten bij de plaats van vestiging van de overtreder (in casus 2 is dan dus de plaats van vestiging van Belgaco bepalend en is Belgisch recht van toepassing), dan wel bij de plaats waar de bewerkte OSS als closed software wordt aangeboden en de schadelijke invloed plaatsvindt. Dat kan in beginsel overal zijn. In casus 2 ligt voor de hand dat Nederlands dan wel Belgisch recht van toepassing is.

C

Inbreuk op auteursrecht

In het geval van inbreuk op een auteursrecht, is de gangbare opvatting dat naar het recht van het land waar de bescherming wordt ingeroepen, moet worden beoordeeld wie de auteursrechthebbende is (‘lex protectionis’).30 Vaak is dat het recht van het land waar de schade ten gevolge van de inbreuk wordt ondervonden. Op die manier kunnen rechthebbenden bescherming inroepen tegen inbreuken, zonder dat de oorsprong van de inbreukmakende handelingen een rol speelt.31 Per land dient te worden beoordeeld of er daadwerkelijk sprake is van inbreuk op de rechten van de rechthebbende. In casus 3 kan de Chinese inbreukmaker de software overal ter wereld aanbieden. Steeds zal per land moeten worden bezien of de Amerikaanse Michael c.q. de Duitse Helmut naar het in het desbetreffende land geldende recht als rechthebbenden kunnen worden beschouwd en of er inbreuk wordt gemaakt op hun rechten. Een andere opvatting is wel dat de plaats waar de OSS is gemaakt, dan wel voor het eerst is gepubliceerd, als uitgangspunt dient te worden genomen (‘lex originis’).32 Conform deze benadering is op casus 3 Amerikaans respectievelijk Duits recht van toepassing.

30

Verder richt de internationale bevoegdheid zich naar internationale overeenkomsten die hier vanwege van de beperkte omvang niet zullen worden behandeld. 31 Verordening (EG) nr. 44/2001 van de Raad van 22 december 2000 betreffende de rechterlijke bevoegdheid, de erkenning en de tenuitvoerlegging van beslissingen in burgerlijke en handelszaken (PbEG 2001, L012). 32 Het bestaan van de woonplaats resp. vestigingsplaats van de gedaagde richt zich hierbij naar artikelen 59 en 60 EEX – Vo; zie hierover P. Vlas, Herziening EEX: van verdrag naar verordening, WPNR 2000, (6421).

171


10.3

Bevoegde rechter

A

De contractssituatie

In het bijzonder bij het online verspreiden van OSS kunnen interpretatieverschillen bij de vaststelling van de bevoegde rechtbank ontstaan, dan wel zouden verscheidene rechtbanken zich bevoegd kunnen verklaren. Door het bepalen van de bevoegde rechtbank in een OSS-licentie kunnen partijen omtrent deze kwestie duidelijkheid scheppen en daarmee de rechtszekerheid verhogen.33 Bij gebrek aan een forumkeuze, dient de bevoegde rechter volgens de nationaal geldende wettelijke bepalingen vastgesteld te worden. De bepaling van de internationale bevoegdheid van de rechter vindt in het Nederlandse recht plaats op grond van de regels die per 1 januari 2002 in de artikelen 1 – 14 van het Wetboek van Rechtsvordering (Rv) zijn opgenomen.34 Deze regels verwijzen, voor wat internationale geschillen betreft, naar de regels zoals vastgelegd in de EEX-Verordening (EEX-Vo).35 De EEX-Vo is ingevolge artikel 4 van de Verordening van toepassing, indien een van de gedaagden zijn domicilie respectievelijk vestigingsplaats36 in een lidstaat heeft.37 De Verordening heeft rechtstreekse werking. Wij beperken ons in deze bijdrage tot een nadere beschouwing van de EEX-Vo en laten de regels van het Wetboek van Rechtsvordering verder buiten beschouwing, daar deze grotendeels op de EEX-Vo zijn gebaseerd.38

33

Ten aanzien van de positie van Denemarken vergelijk P. Vlas, Burgerlijke Rechtsvorderingen (suppl. 292), artikel 1 aant. 10; P. Vlas, Herziening EEX: Van verdrag naar verordening, WPNR 2000, (6421), p. 747. 34 P. Vlas/F. Ibili, De nieuwe commune regels inzake de rechtsmacht van de Nederlandse rechter, WPNR 2003, (6527), p. 310; vergelijk ook MvT, Kamerstukken II, 1999 – 2000, Nr. 3, p. 33; H.J. Snijders/ M. Ynzonides,/G.J. Meijer, Nederlands burgerlijk procesrecht, Deventer 2002, p. 80. 35 Vergelijk met betrekking tot overeenkomst betreffende de bevoegde rechtbank J. Kropholler, Europäisches Zivilprozessrecht, 7. druk, Heidelberg 2002, artikel 23, Rn. p. 40 e.v.; S. van der Hof, Internationale on-line overeenkomsten, p. 38 e.v.; S. van der Hof, Internationaal privaatrechtelijke aspecten van open source licenties, in: Staden ten Brink/Goudkade/ Elseman (red.), aangehaald werk p. 141; P. Vlas/F. Ibili, aangehaald werk, p. 312 e.v. E.P.M. Thole, aangehaald werk, p.235 e.v. 36 HvJ EG 14.12 1976 – Rs. 24/76, NJ 1977, 446; P. Vlas, Burgerlijke Rechtsvorderingen (suppl. 292), artikel 23 EEX – Vo, aant. 7.1. 37 J. Kropholler, aangehaald werk, artikel 23, aant. 35. 38 Een verdere eis voor de overeenkomst betreffende de bevoegde rechtbank conform artikel 23 lid 5 EEX – Vo is dat door deze niet de in artikel 22 EEX – Vo genoemde exclusieve bevoegdheden worden bedongen. Met betrekking tot de voorwaarden van artikel 23 EEX – Vo: P. Vlas, Burgerlijke Rechtsvorderingen (suppl. 292), artikel. 23 EEX – Vo, aant. 1; S. van der Hof, Internationaal privaatrechtelijke aspecten van open source licenties, in: Staden ten Brink/Goudkade/Elseman (red.), aangehaald werk, p. 140.

172


A.1 Forumkeuze De contractpartijen kunnen in beginsel conform artikel 23 EEX-Vo in hun overeenkomsten enerzijds de bevoegdheid van een (anders) onbevoegde rechtbank (zgn. prorogatie) en anderzijds de onbevoegdheid van een (anders) bevoegde rechtbank (zgn. derogatie) vastleggen. Voorwaarde voor een forumkeuze in de zin van de EEX-Vo is allereerst dat een van de contractpartijen zijn woonplaats respectievelijk plaats van vestiging in een van de lidstaten heeft, ongeacht of hij gedurende de verdere procedure als eiser of als gedaagde op zal treden (artikel 23). Bovendien kan uitsluitend een gerecht van een lidstaat worden aangewezen. Verder dient de overeenkomst naar reeds ontstane of toekomstige rechtsgeschillen te verwijzen die uit een bepaalde rechtsverhouding voortvloeien, conform het bepaalbaarheidsvereiste en in overeenstemming met het internationaliteitsvereiste. Op grond van artikel 23 lid 1 EEX-Vo dienen forumkeuzes schriftelijk te worden gemaakt. De elektronische vorm is ingevolge artikel 23 lid 2 EEX-Vo gelijk aan de schriftelijke vorm, indien daardoor de overeenkomst duurzaam wordt geregistreerd en de contractpartijen op een later tijdstip de gegevens terug kunnen halen.39 Er is hiervoor geen uitdrukkelijke overeenkomst vereist; veeleer kunnen forumkeuzes ook in de algemene voorwaarden worden vastgelegd.40 Voorwaarde is dan dat in de door beide partijen getekende contracttekst uitdrukkelijk naar de algemene voorwaarden wordt verwezen en de partijen deze vóór het sluiten van de overeenkomst kunnen inzien.41 De maker van OSS kan derhalve een bepaling betreffende de bevoegde rechtbank in zijn eigen algemene voorwaarden opnemen en vóór het begin van het downloaden van de software hiernaar verwijzen. Ten slotte dienen forumkeuzes aan bepaalde formele voorschriften te voldoen.42

39

E.P.M. Thole/W. Seinen, Open source-softwarelicenties: een civielrechtelijke analyse, Computerrecht 2004/5, p. 221, 223. 40 Vgl. de toevoeging aan de GPL: How to apply these terms to your new programs, verkrijgbaar op . 41 Voorts kan in het geval van een aankoop van Open Source Software door een consument de internationale bevoegdheid conform artikel 15 EEX-Vo worden bepaald. Een uitgebreide uiteenzetting over de bevoegdheid in consumentenzaken valt echter buiten het kader van deze bijdrage. Zie derhalve met betrekking tot problemen bij de bevoegdheid van consumentenzaken: G. Spindler, Internationales Verbraucherschutzrecht im Internet, Multimedia und Recht 2000, p.18 e.v. 42 Zie voor dit probleem: Chr. De Preter/H. Dekeyser, De totstandkoming en draagwijdte van open source-licenties, Computerrecht 2004/5, p. 216; S. van der Hof, Internationaal privaatrechtelijke aspecten van open source licenties, in: Staden ten Brink/Goudkade/Elseman (red.), aangehaald werk, p. 143; F.A. Koch, Urheber- und kartellrechtliche Aspekte der Nutzung von Open-Source-Software (I), Computer und Recht 2000, p. 273, 279; Open Source Software, München 2002, p. 28 e.v.; G. Spindler, Rechtsfragen bei Open Source, Köln 2004, C. aant. 18f.

173


Een forumkeuze zou overigens in een OSS-licentie kunnen worden opgenomen, die in principe ook als algemene voorwaarde wordt beschouwd.43 De toelaatbaarheid van een dergelijke forumkeuze lijkt nochtans problematisch, daar in het geval van bijvoorbeeld de GNU GPL het sluiten van een contract reeds bij het begin van het downloaden van de OSS tot stand komt en op dat moment überhaupt niet expliciet naar de GNU GPL wordt verwezen. Hoewel artikel 5 GNU GPL een aanvaarding van de GNU GPL ook op een latere tijdstip door de verandering of een ander gebruik van de software toelaat en de tekst van de GNU GPL dan in de broncode van de software is opgenomen,44 is dat voor wat betreft een forumkeuzebeding niet verenigbaar met de eisen van artikel 23 EEX-Vo. Er wordt immers noch uitdrukkelijk naar de licentie verwezen, noch aan de andere partij de mogelijkheid geboden om vóór het sluiten van het contract de inhoud van de licentie in te zien. Artikel 23 lid 1 onder b en c EEX-Vo maakt het echter mogelijk dat forumkeuzes ook in een vorm kunnen worden opgesteld die overeenkomt met de usances tussen de partijen, of in de internationale handel overeenkomt met een handelsgewoonte die de partijen kennen of dienen te kennen en die de partijen uit overeenkomsten in de betreffende handelsbranche in het algemeen kennen en regelmatig nakomen. Bij de distributie van OSS is de opname van de licenties, gebruikelijk en algemeen aanvaard. Het gevolg daarvan is dat forumkeuzes niet per se in separate contracten of algemene voorwaarden moeten zijn vastgelegd, maar ook in de OSS-licentie mogen worden opgenomen. A.2 Geen forumkeuze Indien de contractanten geen forumkeuze hebben vastgelegd, wordt de internationale bevoegdheid volgens de bevoegdheidsregels van de EEX-Vo bepaald. In het geval van de distributie van OSS is voor de bepaling van de internationale bevoegdheid allereerst de algemene regeling van artikel 2 lid 1 EEX-Vo van betekenis. Daarnaast dienen voor de bepaling van de internationaal bevoegde rechtbank arikel. 5 lid 1 EEX-Vo (vorderingen uit overeenkomst) en artikel 5 lid 3 EEX-Vo (eisen vanwege onrechtmatige daad) in acht te worden genomen.45

43

Zie E.P.M. Thole, aangehaald werk, p. 237. Vergelijk P. Vlas, Burgerlijke Rechtsvorderingen (Suppl. 292), artikel 5 EEX – Vo, aant. 10; S. van der Hof, Internationaal privaatrechtelijke aspecten van open source licenties, in: Staden ten Brink/Goudkade/Elseman (red.), aangehaald werk, p. 143 e.v. 45 Vergelijk HvJ EG 6.10.1976, Rs. Tessili, NJ 1977, 169; P. Vlas, Burgerlijke Rechtsvorderingen (Suppl. 292), artikel 5 EEX – Vo, aant. 6; J. Kropholler, aangehaald werk, artikel 5, aant. 22 e.v.; S. van der Hof, Internationaal privaatrechtelijke aspecten van open source licenties, in: Staden ten Brink/Goudkade/Elseman (red.), aangehaald werk, p. 144. 44

174


Volgens de algemene bevoegdheidsregeling van artikel 2 lid 1 EEX-Vo zijn in internationale geschillen de rechtbanken bevoegd van de lidstaat, waar de gedaagde zijn domicilie respectievelijk vestigingsplaats heeft. Bij de distributie van OSS zou de bepaling van de forumkeuze nochtans problematisch kunnen zijn. Bij het downloaden van OSS is het vaak niet geheel duidelijk, wie als auteur respectievelijk contractant kan worden beschouwd, daar dikwijls de namen niet worden vermeld maar slechts de pseudoniemen. Hierdoor is het ook moeilijk de woonplaats respectievelijk vestigingsplaats van de gedaagde(n) vast te stellen. Bovendien kan alleen met moeite worden gereconstrueerd, welke auteur voor welk gedeelte van de broncode verantwoordelijk is. Dit geldt met name voor grote ‘communities’ die met de ontwikkeling van een programma bezig zijn.46 In ons voorbeeld (casus 1) is bij een geding jegens de Nederlandse onderneming in beginsel de Nederlandse rechter bevoegd. Voor vorderingen uit overeenkomst is in artikel 5 lid 1 EEX-Vo een bijzondere bevoegdheidsregeling van kracht. Volgens deze regeling is bij procedures met betrekking tot een overeenkomst dan wel vorderingen uit een overeenkomst naast de conform artikel 2 lid 1 EEX-Vo bevoegde rechtbank ook de rechtbank van de plaats van levering bevoegd, zodat de eiser onder omstandigheden een keuze heeft.47 Bij de beoordeling van de plaats van levering bevat artikel 5 lid 1 onder b EEX-Vo een gemeenschappelijk autonome bepaling van de plaats van levering. Volgens deze geldt bij overeenkomsten over de koop van roerend goed en dienstverlening als plaats van levering de plaats in een lidstaat, waar het object volgens de overeenkomst is geleverd of had moeten worden geleverd, dan wel de dienst is verleend of had moeten worden verleend.48 Voor het overige wordt de plaats van levering conform artikel 5 lid 1 onder a EEX-Vo door de zogenaamde Tessili-formule bepaald. Ingevolge deze jurisprudentie wordt de plaats waar de verbintenis moet worden uitgevoerd bepaald aan de hand van het materiële recht, dat volgens het IPR van de aangezochte rechter op de overeenkomst van toepassing is.49 Allereerst dient te worden gecontroleerd of OSS überhaupt als roerend goed kan worden gekwalificeerd. In beginsel wordt software slechts dan eigenschappen van een roerend goed toegekend, indien de software op een fysieke informatiedrager is opgeslagen en met deze is verbonden. Wordt aldus OSS op een fysieke

46 47 48 49

E.P.M. Thole/W. Seinen, aangehaald werk, p. 221-222. Vergelijk P. Vlas, Burgerlijke Rechtsvorderingen (suppl. 292), artikel 4 EEX – Vo, aant.20. Zie E.P.M. Thole, aangehaald werk, p. 239 e.v. Vergelijk M. Rehbinder, Urheberrecht, 13. druk, München 2004, aant. 29 e.v.

175


informatiedrager verkocht, dan wordt de plaats van levering conform artikel 5 lid 1 onder b EEX-Vo bepaald. Bij het downloaden van OSS over het internet wordt software in het algemeen niet als roerend goed beschouwd. In dat geval wordt de overeenkomst tot verkrijging van OSS gekwalificeerd als licentieovereenkomst.50 Dan wordt de plaats van levering niet conform artikel 5 lid 1 onder b EEX-Vo, maar conform artikel 5 lid 1 onder a EEX-Vo volgens de Tessiliformule bepaald. Voor het bepalen van de bevoegde rechter in ons voorbeeld (casus 1) moet dan eerst het op de licentieovereenkomst toepasselijke recht moet worden vastgesteld. Aan de hand daarvan kan dan de plaats van levering, en daarmee de bevoegde rechter worden bepaald.

B

Onrechtmatige daad

De rechtbank die bevoegd is kennis te nemen van geschillen voortvloeiend uit verbintenissen uit onrechtmatige daad, wordt overeenkomstig artikel 5 lid 3 EEX-Vo bepaald door de plaats, waar de schade is ontstaan. Als plaats van ontstane schade komt zowel de plaats van handeling als de plaats van prestatie in aanmerking.51 In casus 2 zou dit betekenen dat zowel de Nederlandse als de Belgische rechter bevoegd kan zijn.

C

Inbreuk op auteursrecht

Een bijkomende speciale bevoegdheidsregeling vloeit voort uit vorderingen met betrekking tot overtreding van het auteursrecht.52 Voor overtredingen van het auteursrecht geldt op grond van het ‘lex loci’-principe overeenkomstig artikel 5 lid 3 EEX-Vo dat geen onderscheid wordt gemaakt tussen de plaats van handeling en de plaats van prestatie.53 Veeleer dient bij overtredingen van het auteursrecht in belangrijke mate de litigieuze handeling zelf in acht te worden genomen. Derhalve is de rechtbank van die plaats bevoegd, waar de overtreding werd begaan.54 Voor de distributie van OSS via internet geldt dat zowel de terbeschik-

50

Vergelijk G. Spindler, Rechtsfragen bei Open Source, Köln 2004, C. aant. 148. Vergelijk T. Jaeger, A. Metzger, aangehaald werk, p. 91; G. Spindler, aangehaald werk, aant. 149. 52 De vraag of een kort geding kan worden aangemerkt als een voorlopige en bewarende maatregel in de zin van artikel 31 EEX Vo, is onder andere in het arrest Van Uden/Deco Line, NJ 1999,339 en Mietz/ Interschip, NJ 2001,90 nader uitgewerkt. 53 Buiten beschouwing wordt gelaten de executie van een vaststellingsovereenkomst nadat, bijvoorbeeld, een mediation-traject door partijen is afgelegd. 54 Verdrag over de erkenning en tenuitvoerlegging van buitenlandse scheidsrechtelijke uitspraken, New York, 10 juni 1958, Trb. Syst. 1959, 58. 51

176


kingstelling als het uploaden of downloaden van OSS via internet als doorslaggevende litigieuze handeling kan worden beschouwd. Derhalve zijn de rechtbanken van al die staten bevoegd, waar de terbeschikkingstelling dan wel de afname heeft plaatsgevonden.55 Daarom hebben de Duitse en de Amerikaanse programmeur in ons voorbeeld (casus 3) de keuze om het geding voor een rechter in China, dan wel in enig land waar de door WooPing vervaardigde software wordt afgenomen, te brengen.

10.4

Tenuitvoerlegging van rechterlijke uitspraak

Executie van gerechtelijke of scheidsrechtelijke vonnissen is een onderwerp van algemene aard. Het is derhalve niet van belang of het een OSS-situatie betreft en of het daarbij gaat om wanprestatie, onrechtmatige daad of inbreuk op een auteursrecht. Aan de hand van algemene theorie zullen wij niettemin enkele veel voorkomende aspecten van de ‘tenuitvoerlegging van vonnissen’ benoemen en verduidelijken, uitgaande van de situatie waarbij er sprake is van een inbreuk op het auteursrecht van een rechthebbende.

A

Uitgangspunten

Civielrechtelijke uitspraak of scheidsrechtelijke uitspraak In het geval dat een rechthebbende hier te lande wordt geconfronteerd met een inbreuk op een intellectueel-eigendomsrecht zal veelal direct in een (civielrechtelijk) kort geding actie worden geëntameerd. Een via deze weg verkregen ‘positieve’ uitspraak zal de rechthebbende vervolgens ten uitvoer willen leggen.56 Ook is het mogelijk dat, in plaats van een procedure via de civiele (voorzieningen)rechter, een scheidsrechtelijke (spoed)procedure wordt gevolgd. Dit laatste doet zich voor indien de rechthebbende en de inbreukmaker een contractuele band met elkaar hebben of hebben gehad (bijvoorbeeld een samenwerkingsover-

55

Echter, indien diezelfde uitspraak van de Belgische rechter niet zou zien op het bestaan van het merkenrecht, maar bijvoorbeeld zou zien op een ‘veroordeling tot staking van een inbreukmakend gebruik’ of ‘tot betaling van een schadevergoeding aan de rechthebbende’ dan doet voornoemde specifieke regel van erkenning géén opgeld. 56 De in Nederland toepasselijke EEX Verordening is een zogenaamde traite double; het regelt zowel de erkenning en de executieprocedures alsook de bevoegdheidsregels. Het toepassingsgebied van de Verordening is voor wat betreft de erkenning en tenuitvoerlegging (alle beslissingen gegeven door een gerecht van een lidstaat worden bestreken) ruimer geformuleerd dan ter zake de bevoegdheidsregels (verweerder moet wonen of gevestigd zijn op het grondgebied van een lidstaat).

177


eenkomst tot doorontwikkeling van software), waarbij contractueel is vastgelegd dat geschillen langs een dergelijke (scheidsrechtelijke) weg zullen worden beslecht.57 Extraterritoriale aspecten In beide gevallen (uitspraak van de civiele rechter dan wel die van de arbiter) kan de inbreukkwestie een internationale component bevatten. Zo kan de inbreukmaker in het buitenland zijn gevestigd (zoals in ons voorbeeld van casus 3 in China), of kan de inbreukmakende handeling (mede) in het buitenland plaats hebben gehad (bijvoorbeeld een ‘internationale’ site waarop inbreukmakende diensten en producten worden aangeboden en/of verkocht of gelicentieerd). Verdragen Wanneer onderzocht wordt in hoeverre een buitenlands vonnis voor erkenning in het aangezochte land in aanmerking komt zal, voor alles, bezien moeten worden in hoeverre toepasselijke verdragen tussen de betreffende landen voorzien in regelgeving terzake erkenning en tenuitvoerlegging van vonnissen. Die regelgeving kan zien op slechts de erkenning en tenuitvoerlegging (traite simple), maar dergelijke regelgeving kan daarenboven voorzien in regels van internationaal bevoegdheidsrecht (traite double). Afgezien van de voornoemde specifieke regelgeving kan de extraterritoriale werking van vonnissen ook geregeld zijn in ‘overige regelgeving’ die niet specifiek gericht is op tenuitvoerleggingen van vonnissen (zie hieronder). Overige wetgeving, niet zijnde een executieverdrag Hoewel met betrekking tot de tenuitvoerlegging van vonnissen in Europa met name de EEX-Vo en het Verdrag van New York58 van belang zijn, kunnen ook specifieke (intellectueel-eigendomsrechtelijke) bepalingen een beslissende invloed hebben op de wijze waarop de tenuitvoerlegging ter hand moet worden genomen. Zo geeft bijvoorbeeld de Benelux Merkenwet regels voor het geval

57

Ex artikel 985 Rv. is de rechtbank relatief bevoegd a) waar tenuitvoerlegging wordt verlangd; dan wel b) waar gerekwestreerde woonplaats heeft. In het geval het vonnis een ‘doen of laten’ inhoudt zal veelal exequatur worden verzocht alwaar gedaagde woonplaats heeft. In het geval dat een incasso van een veroordeling in een geldsom wordt verlangd kan optie a) uitkomst bieden. Met betrekking tot arbitrale uitspraken gelden de artikelen 1075 e.v. RV wanneer een beslissing wordt bestreken door een verdragsrechtelijke regel (bijvoorbeeld het verdrag van NY), of anders de artikelen 1076 e.v RV, zijn de bepalingen van artikel 985 Rv. e.v. van toepassing. Opmerkelijk daarbij is dat in Nederland náást de artikel 1075 Rv. procedure eveneens de synchrone procedure ex artikel 1076 Rv. gevolgd mag worden. Redengevend hiervoor is dat het verdrag van New York een zogenaamd ‘most-favourable right provision’ (artikel VII. 2) kent. 58 Java 2 Enterprise Edition.

178


waarin een (lidstaat)rechter uitspraak doet over het bestaan, de geldigheid en de eigendom van een merkenrecht. Een dergelijke uitspraak in bijvoorbeeld België gewezen, heeft onvoorwaardelijke gelding in de gehele Benelux, zonder dat hiervoor nog een afzonderlijke procedure tot erkenning van het Belgische vonnis doorlopen hoeft te worden wanneer werking van het vonnis in Nederland zou worden beoogd.59 Normaliter zal een vonnis echter, alvorens extraterritoriale werking te hebben, voorzien moeten zijn van een zogenaamd exequatur.

B

Het exequatur

Indien het exequatur wordt gevraagd op een beslissing van een rechter van een lidstaat (EEX), dan gelden de regels van artikel 38 e.v. EEX Verordening (de ‘eenvoudige’, niet-inhoudelijke procedure).60 Indien het exequatur wordt gevraagd op een beslissing gegeven door een rechter van een niet-lidstaat (EEX), waarvan de beslissing niet bestreken wordt door een andere (verdragsrechtelijke) regel, dan gelden de regels van artikel 431 e.v. Rv. (de ‘inhoudelijke’ procedure). Wordt exequatur gevraagd op een beslissing gegeven door een rechter van een niet-lidstaat (EEX), maar is de beslissing uitvoerbaar krachtens een andere (verdragsrechtelijke) regel, dan gelden de exequaturregels van artikel 985 e.v. Rv.61 Executie en erkenningsverdragen stellen (vaak zeer gelijkende) voorwaarden aan erkenning dan wel tenuitvoerlegging van beslissingen. Terugkerende onderwerpen zijn dat de beslissing door een bevoegde rechter / autoriteit is gegeven; dat de beslissing in het land van herkomst uitvoerbaar moet zijn (of er mag geen voorziening meer tegen open staan); en de tenuitvoerlegging van de buitenlandse beslissing niet in strijd mag komen met de openbare orde van het land van de aangezochte rechter. Fundamenteel voor de EEX-Vo (en afwijkend van andere traite doubles) is dat schending van bevoegdheidsregel in beginsel geen reden oplevert om erkenning en tenuitvoerlegging van de desbetreffende beslissing te weigeren. Met andere woorden: de bevoegdheid van de rechter die is aangezocht wordt niet getoetst in de erkenning en executieprocedure. Wordt nu in een lidstaat een beslissing gege-

59

De GNU Lesser General Public License (LGPL) is een variant op de GPL. Deze licentie, die is ontwikkeld door de Free Software Foundation, richt zich met name op zogenaamde softwarebibliotheken (libraries), maar wordt ook gebruikt voor andere software. 60 . 61 .

179


ven, dan wordt deze beslissing dus in beginsel in de overige lidstaten zonder vorm van (inhoudelijk)proces in de vorm van een exequatur erkend. Indien de erkenning door een belanghebbende partij wordt betwist, dan dient dit bezwaar kenbaar te worden gemaakt tijdens de verleningsprocedure van de aanvrager van het exequatur. Ter illustratie lichten wij het vorenstaande toe aan de hand van de navolgende casus. Casus 4 Een Duitse (D) en een Russische (R) onderneming nemen het plan op tot (door) ontwikkeling van bepaalde OSS. De overeenkomst waarin de samenwerking wordt geregeld kent een zogenaamde ‘snuffel-periode’. In deze periode geven partijen elkaar gedoseerd en onder de werking van een strenge geheimhoudingsverklaring informatie over techniek en over de afzet- en licentiepotentie. Nog gedurende de snuffelperiode constateert D dat R, in strijd met de geheimhoudingsverklaring, gebruik maakt van door haar verstrekte informatie.

In de contractuele relatie tussen partijen is een arbitrage- en een boetebeding opgenomen. In de scheidsrechtelijke procedure is D in het gelijk gesteld en is R veroordeeld tot betaling van een geldbedrag. D voorziet ‘praktische’ problemen bij de executie in Rusland; is onbekend met het feit dat zich vermogensbestanddelen van de R in Duitsland bevinden en vermoedt dat de R (betalende) afnemers in Nederland, België en Frankrijk heeft. D zal in een dergelijk geval kunnen constateren dat een exequaturprocedure ex artikel 985 Rv. in Nederland tot de mogelijkheden behoort. Immers Duitsland en Rusland zijn beide partij bij het Verdrag van New York. Via een schakelbepaling is aldus artikel 985 Rv. van toepassing. Toepasselijkheid van artikel 985 Rv. veronderstelt echter dat D voor uitwinning beschikbare vermogensbestanddelen van R moeten kunnen lokaliseren in Nederland. Om hieromtrent zekerheid te verkrijgen zou D derdenbeslag kunnen leggen onder de afnemer van R. Indien het beslag doel treft zal D de exequaturprocedure in Nederland met succes in gang kunnen zetten. Op het Nederlandse exequatur kan vervolgens exequatur worden verzocht in België en Frankrijk, volgens de ‘eenvoudiger weg’ van de EEX-Vo.

180


10.5

Conclusie

Wat betreft het toepasselijke recht geldt dat, wanneer partijen geen rechtskeuze maken, de verwijzingsregels van het IPR niet eenduidig zijn. Gelet op de complexe situatie, waarbij de verspreiding van OSS veelal plaatsvindt via internet en vele partijen in diverse landen betrokken kunnen zijn, kunnen in vele gevallen in beginsel meerdere rechtsstelsels van toepassing zijn. Dit kan voor degene die de procedure aanspant zowel een voordeel als een nadeel zijn. Voorzover wenselijk, kunnen partijen in overleg bepalen welk recht van toepassing is. Het opnemen van een rechtskeuze in de OSS-licentieovereenkomst, waarin een aantal OSSlicenties voorziet, lijkt dan ook de meeste (rechts)zekerheid te bieden. Bij het vaststellen van de bevoegde rechter binnen een OSS-geschil rijst een aantal vragen. In eerste instantie is het van belang of een forumkeuze bestaat en of deze bestanddeel van de OSS-licentieovereenkomst is geworden. In het bijzonder bij het verspreiden van OSS via internet moet op de pagina, waar de OSS wordt aangeboden, in ieder geval een duidelijke verwijzing naar de OSS-licenties plaatsvinden, opdat de forumkeuze dan in beginsel bestanddeel van de overeenkomst wordt. Bij het niet (op juiste wijze) overeenkomen van een forumkeuze is het aantal makers binnen een OSS project, alsmede hun identiteit vaak moeilijk vast te stellen. Daardoor is het niet eenvoudig de bevoegde rechter aan te wijzen. Tevens speelt de kwalificatie van de aanschaf van OSS (koop of anderszins) een belangrijke rol voor het bepalen van het bevoegde gerecht. Hierover bestaat echter geen rechtspraak en in de literatuur is hierover evenmin een duidelijke lijn te vinden. Met betrekking tot de tenuitvoerlegging van vonnissen en andere uitspraken is het van weinig belang of sprake is geweest van OSS of ’proprietary’ software; de uitspraak ligt er en die moet geëxecuteerd worden onafhankelijk van het onderliggende geschil. Ter zake de executie van uitspraken kan geconstateerd worden dat dit een vak apart is. Echter, het succes ervan wordt niet zozeer beïnvloed door de inhoud van de uitspraak alswel door de toepasselijkheid van verdragen en het al of niet aanwezig zijn van vermogensbestanddelen van de bij uitspraak veroordeelde partij.

181

11

Geschillen over Open Source Software Walter van Holst, Vincent Soek, Bartosz Sujecki en Eva Visser

In 2004 heeft de Duitse rechter als eerste rechterlijke instantie ter wereld in de zogenaamde Sitecom-zaak een uitspraak gedaan over de rechtsgeldigheid van sommige GPL bepalingen. Naast deze zaak hebben ook de Amerikaanse SCOzaken in de media veel aandacht gekregen. Deze zaken worden in dit hoofdstuk nader toegelicht. Omdat er verder nog weinig andere relevante jurisprudentie bestaat, wordt hierna ook een aantal schikkingen inzake OSS-geschillen besproken. De schikkingen en de tot zover bekende uitspraken inzake de OSS-geschillen zullen in chronologische volgorde worden behandeld.

11.1

OSS-schikkingen

Alvorens in te gaan op de relevante jurisprudentie met betrekking tot OSS, wordt eerst stil gestaan bij een aantal schikkingen. Op zichzelf mag de precedentwerking van schikkingen miniem zijn, toch kan het nuttig zijn hiervan kennis te nemen doordat zij een beeld kunnen geven van de kansen die partijen zichzelf toedichten in een geschil.

11.1.1

Apache vs. JBoss

Inzet van het geschil Apache vs. JBoss vormden de vermeende inbreuken op het auteursrecht van JBoss Group door de Apache Software Foundation (ASF). Broncode uit het ASF-product Geronimo, een J2EE1 omgeving van ASF, zou overeenkomsten vertonen met broncode uit Jboss, een andere J2EE omgeving, verspreid onder de LGPL.2 Het vrijgeven van LGPL-broncode onder een Apache-licentie zou inderdaad een inbreuk betekenen, gezien de eisen die de LGPL stelt aan de licentiëring van afgeleide werken en die afwijken van hetgeen de Apache-licentie bepaalt. Het verstrekken van LGPL-programmatuur of daarvan afgeleide werken onder een Apache-licentie zou in strijd zijn met de LGPL. Na verloop van tijd bleek echter, dat de JBoss broncode afkomstig was uit het ASFproduct Geronimo in plaats van andersom. ASF bleek dus niet de inbreukmaker,

1 2

. .

183


maar JBoss zelf! Uiteindelijk is het geschil geschikt, zonder dat evenwel de details daarvan bekend zijn gemaakt.

11.1.2

Netfilter-schikkingen

Eén van de eerste schikkingen met betrekking tot het Netfilter-Project is die met het bedrijf Allnet GmbH.3 Dit betrof een geschil waarbij Netfilter Allnet inbreukmakend gebruik van auteursrechtelijk beschermd materiaal verweet. Allnet bood twee producten aan, welke beide door Netfilter ontwikkelde software bevatte. Daarbij zou Allnet niet aan de verplichtingen van de GNU GPL voldaan hebben welke aan de Netfilter-software verbonden waren, in het bijzonder de verplichting om de GPL bij doorlevering van toepassing te verklaren. Allnet heeft uiteindelijk toegezegd zich aan alle bepalingen uit de GPL te houden en haar klanten te informeren over de rechten en verplichtingen van de GPL. Verder heeft Allnet beloofd zich in de toekomst te onthouden van het verspreiden van op Netfilter gebaseerde producten zonder herlicentiëring onder de GPL. Ook was Allnet verplicht tot betaling van een significante donatie aan de ‘Free Software Foundation Europe’ en de ‘Foundation of a Free Information Infrastructure’.

11.1.3

TOMTOM Go

Een voorbeeld dichter bij huis betreft de schending van de bepalingen van de GPL door het Nederlandse bedrijf TOMTOM B.V., fabrikant van navigatieapparatuur.4 TOMTOM bracht software op de markt (TOMTOM Go), welke software open source componenten bevatte waarop de voorwaarden van de GPL van toepassing zijn. TOMTOM leefde deze voorschriften van de GPL voor het totaalproduct echter niet na door na te laten de broncode van de software openbaar te maken, met inbegrip van door TOMTOM aangebrachte wijzigingen. Het zogenoemde GPL-violations.org project dat een initiatief is van Harald Welte, heeft door TOMTOM hier op aan te spreken ervoor gezorgd dat de verspreiding van de TOMTOM Go software in overeenstemming werd gebracht met de bepalingen van de GPL. Dit project is gestart om aandacht te schenken aan schendingen van de GPL en tegelijkertijd om deze schendingen tegen te gaan. In de TOMTOM zaak betekende dit dat TOMTOM zich uiteindelijk committeerde

3 4

. Civil Action No. 01-11031, ingediend 15 juni 2001, Federal Court te Massachusetts, USA.

184

Geschillen over Open Source Software

aan de GPL.5 Als onderdeel van de schikking heeft TOMTOM bovendien een donatie gedaan aan een hackersorganisatie als blijk van haar waardering voor de open source beweging.6

11.1.4

Drew Technologies vs. Society of Automotive Engineers

De eerste aanhangig gemaakte rechtszaak in de Verenigde Staten waarin de GPL daadwerkelijk inhoudelijk aan de orde is gekomen voordat partijen tot een schikking kwamen, is die tussen Drew Technologies (DrewTech) en de Society of Automotive Engineers (SAE). Het geschil was enigszins complex, mede doordat een aantal aan de rechter in Michigan voorgelegde vragen een sterk mededingingsrechtelijk karakter hadden. De SAE is een organisatie op het gebied van standaarden in de automobielindustrie en heeft in die hoedanigheid een aantal standaarden geformuleerd voor de onderlinge communicatie tussen computersystemen aan boord van auto’s. Bedrijven in de automobielindustrie zijn van overheidswege verplicht zich aan deze standaarden te conformeren. DrewTech had een aantal van deze standaarden geïmplementeerd in haar software en deze vervolgens onder de GPL verspreid. De SAE stelde zich op het standpunt dat gezien haar rol in de totstandkoming van deze standaarden haar het auteursrecht op deze standaarden toekomt en dat uit de op haar website gehanteerde ‘intellectual property policy’ voortvloeit dat aan haar het auteursrecht op de software-implementatie van de standaarden was overgedragen. De SAE vorderde dan ook een licentievergoeding van DrewTech en van andere gebruikers van de software. DrewTech op haar beurt vorderde schadevergoeding van de SAE wegens inbreuk op haar auteursrecht en schending van de GPL, aangezien de SAE de desbetreffende software zelf had verspreid onder andere, meer restrictieve, licentievoorwaarden dan de GPL. In het geschil voor de rechter waren onder meer de volgende vragen aan de orde. Zijn standaarden vatbaar voor auteursrecht? Kan een zogenaamde ‘browsethrough’-licentie op een document (i.c. de standaard) leiden tot een overdracht van auteursrechten? In het geval een van de voorgaande vragen negatief beantwoord dient te worden, is de GPL dan een rechtsgeldige licentie op grond waar-

5

E.N.M. Visser, ‘GNU General Public License – All rights reversed?’, Computerrecht 2004/5, p. 226. Planetary Motion Inc. vs. Techsplosion Inc., 261 F.3d 1188 (S.D. Fla 2001). Zie: .

6

185


van DrewTech de SAE mag verbieden de software onder een andere licentie dan de GPL te verspreiden? Kennelijk is de SAE gaandeweg de rechtszaak minder overtuigd geraakt van de kracht van haar eigen argumenten: de zaak is – nog voordat de volledige ‘discovery’ was afgerond – geschikt. Opmerkelijk daarbij is dat de tekst van de schikking openbaar is gemaakt.7 Afgesproken is dat SAE 75.000 USD aan DrewTech betaalt en dat DrewTech op haar beurt de helft van deze schadevergoeding aan de SAE doneert.

11.2

OSS-rechtszaken

Inmiddels is er wereldwijd een aantal aan OSS gerelateerde uitspraken gedaan. De uitspraken die hierna behandeld zullen worden, zijn niet in Nederland gewezen, maar geven toch inzicht in een aantal aan OSS gerelateerde rechtsvragen, hetgeen ook voor de Nederlandse rechtspraktijk relevantie kan hebben.

11.2.1

Progress vs. MySQL

Er bestaat nauwelijks jurisprudentie met betrekking tot het gebruik van de GPL. De eerste zaak ter wereld waarin de GPL ter sprake kwam en waarin de rechter tot een uitspraak kwam, is de zaak Progress Software Corp. versus MySQL AB.8 In deze zaak speelden de volgende feiten. Het Amerikaanse softwarebedrijf Progress distribueerde open source software van MySQL in combinatie met closed source software. Op de MySQL-software waren de voorwaarden van de GPL van toepassing, maar Progress verzuimde de broncode vrij te geven van de closed source software. Dit is in strijd met artikel 3 van de GPL. Progress beschuldigde MySQL onder meer van contractbreuk en oneerlijke concurrentie. Daarop is MySQL met een tegenvordering gekomen, inhoudende merkinbreuk en schending van de GPL. De rechtbank te Massachusetts ging echter niet in op de rechtsgeldigheid van de GPL toen zij op 28 februari 2002 een voorlopige voorziening in deze zaak trof.9 De rechtbank verbood Pro-

7

. München heeft twee rechtbanken vandaar deze aanduiding. Zie over deze zaak ook: E.N.M. Visser, Netfilter versus Sitecom. Noot bij de uitspraak van Rechtbank te München 19 mei 2004, JAVI 2004/5, pp. 186-188. 9 Zie , publicatie 17 februari 2004 en , publicatie 25 maart 2004. 8

186


gress uiteindelijk de MySQL-software te distribueren en het merk MySQL te gebruiken.

11.2.2

Planetary Motion Inc. vs. Techsplosion Inc.

In deze zaak daagde Planetary Motion, een software- en telecommunicatiebedrijf, Techsplosion voor de rechter, het United States Court of Appeals for the Eleventh Circuit, in verband met schending en verwatering van het ongeregistreerde merk ‘CoolMail’ en oneerlijke mededinging.10 Techsplosion, althans haar rechtsvoorganger, ontwikkelde mailsoftware en verspreidde die software onder de GPL. De rechter oordeelde dat de distributie van software onder de GPL niet de ‘eigendom’ op het merk van het product beëindigt. Met andere woorden: ‘Software distributed pursuant to such a license is not necessarily ceded to the public domain and the licensor purports to retain ownership rights.’11

Helaas geeft de rechter geen diepere analyse van open source software.

11.2.3

Netfilter (Welte) vs. Sitecom

De eerste uitspraak ter wereld over de rechtsgeldigheid van de GNU General Public License (GPL) is op 19 mei 2004 gedaan door de rechtbank I te München in de zaak tussen Netfilter en Sitecom.12 Hoewel de GPL daarin getoetst is naar Duits recht, is deze uitspraak ook relevant voor Nederland, gelet op het toenemende gebruik van de GPL voor de verspreiding van OSS. Kern van de uitspraak is dat de rechter de essentie van OSS respecteert en aanneemt dat er geen afstand wordt gedaan van het auteursrecht. Daarnaast worden de bepalingen van de GPL aangemerkt als algemene voorwaarden en verklaart de rechter de bepalingen van de GPL die voorwaarden stellen aan de verspreiding van OSS, rechtsgeldig naar Duits recht. Het geschil tussen Netfilter en Sitecom heeft betrekking op de distributie van de zogenaamde Netfilter-software. Deze OSS wordt, ten behoeve van verdere ontwikkeling, op de website van Netfilter aangeboden onder de voorwaarden van de GPL. Sitecom heeft van de Netfilter-software gebruik gemaakt en heeft deze

10

Zie voor de uitspraak: . 11 http://www.jbb.de/urteil_lg_muenchen_gpl.pdf>. Zie voor een onofficiële Engelse versie: . 12 No. 02 C 4721, United States District Court, Northern District of Illinois, 24 juni 2004.

187


software vervolgens in combinatie met andere software op haar eigen website ter beschikking van het publiek gesteld. De website van Sitecom maakte echter geen melding van de GPL, noch bevatte de website een verwijzing naar de tekst van de GPL. Evenmin werd de broncode van de Netfilter-software aangeboden. Door deze handelwijze handelde Sitecom in strijd met de artikelen 2 en 3 van de GPL, aldus een van de verantwoordelijken voor het Netfilter open source project. Netfilter besloot daartegen actie te ondernemen. Overigens had Netfilter in vergelijkbare gevallen al eerder opgetreden tegen handelen in strijd met de GPL. Deze geschillen werden echter steeds geschikt.13 Zo niet bij Sitecom. Een gerechtelijke (kort geding) procedure volgde. Op 2 april 2004 gelastte de rechtbank I te München Sitecom om de distributie van de Netfilter-software gestaakt te houden, indien zij niet tegelijkertijd overeenkomstig de GPL een verwijzing aanbrengt naar de GPL, de licentievoorwaarden bijvoegt, alsmede de broncode openbaar maakt zonder daarvoor een licentievergoeding te vragen.14 Sitecom legde zich echter niet neer bij deze uitspraak en ging in beroep. Overigens werd dit beroep op formele gronden ingesteld. Sitecom stelde dat Netfilter niet de juiste partij heeft aangezocht en zij daarom niet als gedaagde kan worden aangemerkt in het onderhavige geding. Volgens Sitecom zou zij geen zelfstandige distributieafdeling hebben en zich derhalve ook niet zelfstandig bezig hebben gehouden met de verspreiding van de Netfilter-software. Bovendien zou het de moedermaatschappij Sitecom Europe zijn die de software ter beschikking stelt aan het publiek. De rechter maakt hier echter korte metten mee door te oordelen dat alleen het adres van Sitecom AG wordt aangeduid bij de Duitstalige versie van de website. De rechtbank merkt bovendien op dat zelfs indien de webpagina zou moeten worden toegeschreven aan de moedermaatschappij, Sitecom AG nog moet worden beschouwd als mede-inbreukmaker, omdat zij de distributie van de software bevordert. Het aardige van deze stelling van Sitecom was nu juist dat de kans bestond dat dit geschil voor de Nederlandse rechter zou worden beslecht, aangezien de moedermaatschappij van Sitecom haar zetel in Nederland heeft. Zover is het uiteindelijk niet gekomen. Op 19 mei 2004 bekrachtigde de rechter gemotiveerd de eerder door haar uitgesproken voorlopige voorziening.15 Hoewel de Sitecom-zaak kan worden beschouwd als de eerste zaak waarin de rechter inhoudelijk is ingegaan op de rechtsgeldigheid van de GPL, moet worden

13

. Een parser is een computerprogramma (of een component daarvan) dat de grammaticale structuur van input analyseert (vergelijkbaar met het proces van grammaticale ontleding van tekst). . 15 No. 02 C 4721, United States District Court, Northern District of Illinois, 24 juni 2004, p. 13. 14

188


opgemerkt dat nog tal van GPL-bepalingen in dit vonnis onbesproken zijn gebleven. Denk hierbij bijvoorbeeld aan de garantie- en aansprakelijkheidsbepalingen, waarin verregaande exoneraties zijn opgenomen. Evenmin geeft de rechter antwoord op de vraag of de GPL als overeenkomst tussen partijen tot stand is gekomen. Er wordt slechts gezegd dat de GPL als een set van algemene voorwaarden kan worden aangemerkt en als zodanig van toepassing is op een eventuele contractuele relatie tussen Sitecom en Netfilter. Voor de uitkomst van deze zaak maakt dit geen verschil, aangezien Sitecom in beide situaties inbreuk zou maken op het auteursrecht van Netfilter. Het Sitecom-vonnis zag voornamelijk op de voorwaarden waaraan voldaan moet zijn bij verspreiding van open source software onder de bepalingen van de GPL.

11.2.4

Computer Associates International vs. Quest Software Inc.

Op 24 juni 2004 gaf rechter James B. Moran te Illinois zijn oordeel in het geschil tussen Computer Associates International (CA) en Quest Software Inc. (Quest) c.s.16 De achtergrond van dit geschil is de volgende. CA nam Platinum Technology International Inc (Platinum) in 1999 over, waarbij een aantal werknemers van Platinum op straat kwam te staan en/of zelf besloot om Platinum te verlaten. Een aantal van deze werknemers (medegedaagden in deze procedure) werkten aan bepaalde software (EDBA), waarvan zij een kopie meenamen naar hun nieuwe baan bij Quest. Dit ondanks een door Quest opgelegd verbod, inhoudende dat het de nieuwe medewerkers verboden was om vertrouwelijke informatie of door intellectuele eigendomsrechten beschermde werken met zich te brengen. In oktober 2001 lanceerde Quest de eerste versie van Quest Central for DB2 (QCDB2), een database administration programma voor DB2. Daarna werden er nog een aantal keren nieuwere versies uitgebracht. Vroeg in het jaar 2000 verkreeg CA informatie dat Quest delen van de broncode van EDBA in haar bezit had. Quest ontkende deze aantijging. In februari 2002 ontving CA een niet ondertekende brief, waarin tot in detail het gebruik van de EDBA broncode door Quest werd beschreven. Uiteindelijk leidde (mede) deze brief tot een rechtszaak. Rechter Moran oordeelde dat Quest het bij het rechte eind had, waar Quest stelde dat – voorzover zij al bestaande werken reproduceerde die zich in het publieke domein bevonden – CA geen recht had om derden het reproduceren van werken

16

Deze consent decree luidde het einde van het monopolie van AT&T op telefoniediensten in de VS in. Als gevolg hiervan vervielen de restricties waar AT&T als telecommunicatiemonopolist op andere markten aan onderworpen was, zo ook het verbod om zich op de softwaremarkt te begeven.

189


behorend tot het publieke domein te verbieden. De EDBA-broncode bevatte duidelijk enkele elementen die waren ontwikkeld door andere partijen en die elementen behoorden tot het publieke domein. Waar CA niet het recht had om Quest (of welke andere software-ontwikkelaar dan ook) het gebruik van deze in het publieke domein vallende delen van de broncode te beletten, had CA wel het auteursrecht op de modificaties die door haar waren ontwikkeld en welke door derden (Quest) als broncode waren opgenomen in het eindproduct – de complete EDBA-broncode. De EDBA-broncode bevatte een reeks welke duidelijk maakte, dat gebruik werd gemaakt van ‘GNU Bison version 1.25’. Bison is een open source programma ontwikkeld door de Free Software Foundation en verspreid onder de GPL.17 Quest was van mening, dat CA de GPL voorwaarden schond door auteursrecht voor te behouden op de EDBA-programmatuur waarin Bison-broncode was opgenomen. De rechter ging hier niet in mee en oordeelde dat CA geen auteursrecht op de Bison-broncode claimde, maar dat zij gebruik maakte van het Bison utility programma om broncode van een parser te genereren voor gebruik in haar EDBA-programmatuur. Om dat te bereiken wijzigde CA het Bison-programma.18 De GPL – welke het CA niet toestond om aanspraak te maken op de gewijzigde Bison-programmatuur – beperkte niet het gebruik van de uitvoer van die Bison-programmatuur (broncode van een parser), dit was namelijk de creatie van CA. Ergo, de Free Software Foundation stond het gebruik van met haar Bison-programmatuur gegenereerde broncode in software uitdrukkelijk toe, ook als dat geen OSS betrof: ‘As a special exception, when this file is copied by Bison into a Bison output file, you may use that output file without restriction. This special exception was added by the Free Software Foundation in version 1.24 of Bison’.19

Er bestond geen enkele indicatie dat (ex-)werknemers van CA noch van Platinum een oudere versie van Bison dan versie 1.24 gebruikte.

17

FreeBSD, NetBSD, OpenBSD en Apple OS X. Voor een uitvoerige stamboom van al deze varianten zij verwezen naar de Unix timeline (http://www.levenez.com/unix/). 18 Linus Torvalds heeft hierbij gebruik gemaakt van Minix als ontwikkelomgeving van Linux, wat weer een bron van een andere controverse is geweest. In een publicatie van het Alex de Tocquevilleinstituut is uitgebreid gesuggereerd dat Linux op Minix gebaseerd zou zijn geweest. Dit is weersproken door zowel Linus Torvalds als Andy Tanenbaum, de auteur van Minix en hoogleraar informatica aan de Vrije Universiteit in Amsterdam. 19 .

190


11.3

De SCO-zaken

De meest in het oog springende rechtszaken rond OSS zijn wellicht die van SCO tegen IBM en diverse andere wederpartijen. Wat deze Amerikaanse rechtszaken met elkaar gemeen hebben, is dat de SCO Group van mening is dat Linux substantiële stukken code bevat waarop zij rechthebbende is. Om enig inzicht te krijgen in deze complexe en onderling afhankelijke groep van rechtszaken is het noodzakelijk om eerst in te gaan op zowel de geschiedenis van het besturingssysteem Unix als die van de SCO Group, een vennootschap naar het recht van de Amerikaanse staat Utah.

11.3.1

Geschiedenis van Unix

Het besturingssysteem Unix is ontstaan als onderzoeksproject van Ken Thompson en Dennis Ritchie, beiden werkzaam bij Bell Laboratories. Unix wordt algemeen beschouwd als opvolger van Multics, een experimenteel besturingssysteem van MIT, Bell Laboratories en General Electric. De eerste versies van Unix stammen uit 1970. In 1973 werd het besturingssysteem herschreven zodat het ‘portable’ werd in de zin dat het betrekkelijk eenvoudig aangepast kon worden voor andere typen apparatuur dan waar het oorspronkelijk voor bedoeld was. Voor die tijd was dat een revolutionair concept. Omdat het toenmalige Bell (nu AT&T) als monopolie geen commerciële activiteiten buiten de telecommunicatiesector mocht ontplooien, werd Unix (vrijwel) kosteloos ter beschikking gesteld aan andere partijen, met inbegrip van de broncode. Vanaf 1979 werd de broncode niet langer meegeleverd en na het onder mededingingsexperts fameuze consent decree van 1983 had AT&T de vrije hand om Unix commercieel te exploiteren.20 Inmiddels was er door verschillende andere partijen, in het bijzonder de universiteit van Berkeley, het nodige bijgedragen aan de oorspronkelijke broncode en had er om technische redenen een opsplitsing in verschillende versies plaatsgevonden. De AT&T-code leeft nog steeds voort in de zogenaamde System V-familie, terwijl de afsplitsing van Berkeley voortleeft in de BSD-familie van besturingsystemen.21 In 1995 werkte SCO samen met IBM om een 64-bits Unix te ontwikkelen voor 64-bit Intel processoren. De samenwerking werd door beide bedrijven aangeduid als ‘project Monterey’. SCO was in die tijd een rechtsopvolger van AT&T met betrekking tot de exploitatierechten op Unix System V na deze in 1995 te hebben verworven van Novell. Project Monterey eindigde in mei 2001

20 21

. .

191


zonder concrete resultaten en SCO was inmiddels in 2000 overgenomen door Caldera, een Linux-distributeur.

11.3.2

Geschiedenis van Linux

In tegenstelling tot wat weleens gedacht wordt, is Linux geen variant van Unix maar een aparte implementatie van dezelfde concepten als waar Unix op gebaseerd is. De reden hiervoor was dat Linus Torvalds als student in 1991 wel kon beschikken over een computer met een Intel 80386 processor, maar niet over een besturingssysteem dat aan zijn eisen voldeed. Doordat Richard Stallman’s GNUproject alle elementen van een besturingssysteem behalve de eigenlijke kern (kernel), al beschikbaar had gemaakt, was het voor Torvalds mogelijk om met een eigen kernel te gaan experimenteren zonder daarbij gedwongen te zijn alle elementen vanuit het niets te bouwen.22

11.3.3

Caldera, SCO en de SCO Group

Na de overname van SCO door Caldera ontstond een vennootschapsrechtelijke stoelendans. Het oude Caldera werd omgedoopt tot SCO Group23, het oude SCO ging verder onder de naam Tarantella Systems.24 Laatstgenoemde is intussen overgenomen door Sun Microsytems.25 Caldera was van alle Linux-distributeurs altijd degene geweest die wat haar bedrijfsmodel betreft het meeste op meer conventionele leveranciers van besturingssystemen leek en was als speler in de Linux-markt niet bijster succesvol geweest.

11.3.4

SCO Group vs. IBM

De SCO Group heeft IBM op 7 maart 2003 gedagvaard wegens contractbreuk en inbreuken op haar intellectuele eigendommen en bedrijfsgeheimen. De initiële eis was 1 miljard dollar, deze is later verhoogd naar 3 miljard dollar en op het moment van schrijven van dit hoofdstuk is de eis 5 miljard dollar. De SCO Group baseert haar eisen op het feit dat IBM code verwerkt heeft in de Linux-kernel en deze vervolgens onder de bepalingen van de GPL heeft verspreid. De SCO Group

22

Zie S.J. Vaughan-Nichols, SCO stands defiant, German court grants preliminary injunction, http://linuxtoday.com/ developer/2003053001926NWLLDV, publicatie 30 mei 2003. 23 . 24 . 25 .

192


is van mening dat IBM de toestemming nodig had van de SCO Group voor het bijdragen aan de desbetreffende code. Daarbij lijkt het deels te gaan om code die van oorsprong afkomstig is uit de AT&T Unix System V kernel, deels om code die in het kader van het eerder genoemde project Monterey ontwikkeld is en deels om een volgens de SCO Group uit een eerdere samenwerkingsovereenkomst voortvloeiende opvatting over wat tussen partijen als van Unix afgeleid werk beschouwd dient te worden. IBM heeft in reconventie de SCO Group beschuldigd van octrooi-inbreuk en in een later stadium van de procedure van een schending van haar auteursrecht op al haar bijdragen aan Linux. De SCO Group verspreidt immers de Linux-kernel, terwijl zij zich tegelijkertijd op het standpunt stelt dat de GPL ongeldig is (en dus geen geldige licentie heeft). Deze kwestie is aan een rechter in de staat Utah voorgelegd. Intussen heeft IBM haar eisen met betrekking tot octrooi-inbreuken laten vallen om de zaak te bespoedigen.

11.3.5

SCO Group vs. Novell

Novell heeft kort nadat IBM door SCO was gedagvaard publiekelijk betwijfeld of bij de overdracht van de Unix-activiteiten aan SCO (nu Tarantella) de intellectuele eigendomsrechten op Unix overgedragen zijn. Dit standpunt is later enigszins genuanceerd, maar desondanks verschillen partijen dusdanig met elkaar van mening op dit punt dat de SCO Group Novell heeft gedagvaard wegens laster. Net als de zaak tegen IBM is deze kwestie aan een rechter in de staat Utah voorgelegd.

11.3.6

SCO vs. Univention GmbH

In Duitsland heeft de rechtbank te Bremen in de zaak van Univention GmbH tegen de Duitse divisie van SCO geoordeeld dat SCO, op verbeurte van een dwangsom, geen uitlatingen mag doen waaruit volgt dat Linux op illegale wijze verkregen Unix-code zou bevatten. Univention betoogde dat deze onbewezen stellingen van SCO het imago van Linux schaden.26 In een uiterst beknopte voorlopige voorziening oordeelde de rechter dat het SCO niet toegestaan was om publiekelijk te beweren dat Linux op onrechtmatige wijze intellectuele eigendommen van SCO zou bevatten en/of dat eindgebruikers hiervoor aansprakelijk

26

193


gehouden zouden kunnen worden. Partijen hebben vervolgens een schikking getroffen die openbaar is gemaakt en die de voorlopige voorziening bevestigde.

11.3.7

Red Hat vs. SCO Group

De bekende Linux distributeur Red Hat zag zich – na alle publiciteit rond de zaak SCO Group vs. IBM – geconfronteerd met vragen van (potentiële) afnemers. Voor Red Hat was dit aanleiding om de SCO Group te dagvaarden wegens ongeoorloofde mededinging. Deze kwestie is voorgelegd aan de rechter in de staat Delaware. Deze heeft de zaak aangehouden totdat de rechter in Utah uitspraak heeft gedaan inzake SCO vs. IBM. Beide partijen zijn verplicht iedere negentig dagen verslag te doen aan de rechter in Delaware over de status van laatstgenoemde zaak.

11.3.8

SCO Group vs. Autozone

Een opmerkelijke zaak is die van SCO Group vs. Autozone, omdat in deze zaak eindgebruikers worden aangesproken. Autozone is een schokdemperfabrikant in de staat Nevada die voor haar automatisering gebruik maakte van SCO Unix maar overstapte op Linux. De SCO Group heeft Autozone gedagvaard op basis van haar (vermeende) auteursrecht op delen van Linux. De SCO Group heeft zich op het standpunt gesteld dat nu Autozone gebruik maakt van een ongeautoriseerd verspreide versie van Unix, Autozone inbreuk maakt op haar auteursrecht. Deze kwestie is voorgelegd aan een rechter in Nevada die de zaak heeft aangehouden hangende de uitkomst in de zaak SCO Group vs. IBM.

11.3.9

SCO Group vs. DaimlerChrysler

Een soortgelijk geschil speelt in SCO Group vs. DaimlerChrysler. DaimlerChrysler, een gebruiker van SCO’s OpenServer product en Linux, is door de SCO Group benaderd met een beroep op een auditclausule in haar licentie op OpenServer. Opmerkelijk was dat DaimlerChrysler tevens werd verzocht melding te maken van de mate waarin zij gebruik maakt van Linux. DaimlerChrysler honoreerde dit verzoek niet binnen de in de licentieovereenkomst vermelde 30 dagen, wat voor de SCO Group aanleiding was om DaimlerChrysler aan te spreken op schending van de licentieovereenkomst. Intussen zijn vrijwel alle eisen van de SCO Group in deze zaak afgewezen nu DaimlerChrysler heeft aangetoond in welke mate zij gebruik maakt van de SCO producten (te weten, geen). Deze zaak

194


was voorgelegd aan een rechter in Michigan, maar wordt vooralsnog niet voortgezet door de SCO Group.

11.3.10 De kernvraag en analyse De kern van deze wirwar van zaken is dat de SCO Group van mening is dat (i) zij rechthebbende is op de Unix System V systeemprogrammatuur en (ii) Linux een daarvan afgeleid werk is en dat daaruit voortvloeit dat Linux distributeurs en gebruikers inbreuk maken op de rechten van de SCO Group. De SCO Group baseert deze opvatting op de volgende stellingnames: – zij is rechtsopvolger van AT&T met betrekking tot het auteursrecht op Unix of althans de controle op de commerciële exploitatie van Unix; – de oorspronkelijke licentiëring van Unix door AT&T vond plaats op basis van een licentieovereenkomst, die een ruimer begrip van afgeleid werk hanteert dan in het auteursrecht gebruikelijk is; – IBM heeft code toegevoegd aan AIX (haar eigen, op Unix System V gebaseerde versie van Unix) en op grond van het ruimere begrip van afgeleid werk van de licentieovereenkomst met AT&T, komt het auteursrecht op deze code toe aan de auteursrechthebbende van System V; – de SCO Group is, op basis van de overname van de Unix activiteiten van Novell door SCO (nu Tarantella), auteursrechthebbende met betrekking tot Unix System V; – IBM heeft door functionaliteit van AIX te porteren, die oorspronkelijk niet aanwezig was in Unix System V naar Linux een van Unix System V afgeleid werk opgenomen in de Linux-kernel; – de door SCO gevorderde schadevergoeding staat in verhouding tot de daadwerkelijk door SCO geleden schade. Er zijn redenen om aan te nemen dat de SCO Group weinig kansen heeft om haar vorderingen tegen de diverse partijen toegewezen te krijgen, voorzover Nederlandse juristen zich aan voorspellingen kunnen wagen. Als eerste is haar stelling dat de AT&T Unix System V licentieovereenkomst tot een extensieve interpretatie van het begrip afgeleid werk moet leiden. Dit ruime begrip zou er toe leiden dat het auteursrecht op deze afgeleide werken bij de SCO Group zou berusten. Deze stelling laat zich moeilijk verenigen met de vormvereisten voor overdracht van auteursrecht van Chapter 2 van de U.S. Copyright Act die in hoge mate overeenkomen met de eisen in artikel 2 van de Nederlandse Auteurswet. Daarnaast zijn er inmiddels getuigenverklaringen afgelegd door leden van de toenmalige

195


AT&T top dat een dergelijke overdracht nooit de bedoeling was van de licentieovereenkomst. Alvorens aan de vraag of de IBM-code als een afgeleid werk van Unix System V beschouwd moet worden toe te komen, zal de SCO Group achtereenvolgens aan moeten tonen dat Novell de auteursrechten op Unix System V aan SCO (nu Tarantella) heeft overgedragen en deze rechten vervolgens weer aan de SCO Group zijn overgedragen. Uit de processtukken van het geschil tussen Novell en de SCO Group blijkt dat in de overeenkomst tussen Novell en SCO deze laatste zich weliswaar een optie heeft verworven op de overdracht van auteursrechten, maar tot nu toe is nog niet aangetoond dat een daadwerkelijke overdracht van auteursrechten heeft plaatsgevonden. Tot slot zal de SCO Group aan moeten tonen dat, nu zij zelf Linux met inbegrip van de gewraakte code, onder de GPL heeft verspreid (zelfs tot na de dagvaarding van IBM), zij überhaupt nog kan spreken van inbreukmakende gedragingen van IBM.

11.4

Afsluitende opmerkingen

In Nederland zijn voorzover bekend nog geen rechterlijke uitspraken die aan OSS zijn gerelateerd. De bestaande jurisprudentie uit het buitenland met betrekking tot OSS laat nog veel vragen open. De Duitse Sitecom-zaak heeft uiteindelijk maar een beperkt aantal aspecten van OSS-licenties belicht. Belangrijke vragen over hoe een OSS-licentie nu tot stand komt als licentieovereenkomst zijn voorzover bekend nog nergens voor een rechter aan de orde gesteld, net zo min als aansprakelijkheidsvraagstukken rond OSS. Specifiek aan OSS is het diffuse karakter van de gemeenschap van makers, namelijk dat het bij veel OSS moeilijk is om aan te wijzen welke partij specifiek aangesproken zou moeten worden. Dit probleem is in nog geen enkele zaak naar voren gekomen. Een ander punt wat in de toekomst mogelijk aan de orde zal worden gesteld, is de vraag of de mogelijkheid om bij OSS kennis te nemen van de broncode een verschuiving in de informatieplicht van de afnemer oplevert. Verveelvoudigen van een werk houdt in ‘iedere gehele of gedeeltelijke bewerking of nabootsing in gewijzigde vorm, welke niet als een nieuw, oorspronkelijk werk moet worden aangemerkt’, aldus artikel 13 Auteurswet. Met betrekking tot computerprogramma’s breidt artikel 45i Auteurswet het begrip verveelvoudigen van artikel 13 Auteurswet uit met ‘het laden, in beeld brengen, de uitvoering, de transmissie of de opslag, voorzover voor deze handelingen het verveelvoudigen

196


van dat werk noodzakelijk is.’ Zie hierover ook P.C. van Schelven /H. Struik, Softwarerecht, Deventer 1995, p.77. De onzekerheid over de vraag wanneer er sprake is van een ‘derivative work’ wordt nota bene door de FSF zelf treffend geïllustreerd door de opmerking ‘What constitutes combining two parts into one program? This is a legal question, which ultimately judges decide.’ in de antwoorden (!) bij de FAQ met betrekking tot de GPL, te vinden op: . Een ander voorbeeld is de zin ‘The threshold for this to be true is not precisely defined by law.’ in art. 6 Lesser GPL (LGPL). Een en ander doet ook denken aan het ‘Open Content’ initiatief van Creative Commons die verschillende licenties heeft opgesteld om bepaald gebruik van auteursrechtelijk werk toe te staan. Zie , , en . Echter, in geval van Creative Commons is geen sprake van het eenzijdig doen van afstand van recht, maar worden er expliciet licentieovereenkomsten afgesloten. Zo volgt indirect uit de website, waarop de modellen van de licentiecontracten zijn te vinden. Juist binnen de OSS-beweging speelt het aspect van de erkenning van het auteurschap een grote rol.

197

Open Source Software: Een verkenning naar de juridische aspecten van open source software

Recommend Documents