Deze bijdrage onderzoekt het concept van Open Source Software, oorspronkelijk een alternatieve vorm van softwarelicentiëring, die recentelijk een onmiskenbare plaats heeft ingenomen op de markt van softwareontwikkeling. Ingevolge de toenemende populariteit van deze software op de markt van niet-gespecialiseerde gebruikers ontstaat er een spanningsveld tussen enerzijds de “lichte” concepten van vrije intellectuele creatie en afwezigheid van aansprakelijkheid die de grondslag vormen van het systeem, en anderzijds het recht, dat er klassiek op gericht is om zowel (intellectuele) eigendom als gebruikers van software te beschermen. Dit spanningsveld komt het duidelijkst naar voor bij het bestuderen van de GNU General Public License, de licentievorm die de markt van vrije software duidelijk overheerst, maar die ook de meest radicale kenmerken bevat, en waarover - mede door haar onduidelijke redactie - een aantal mythes en misverstanden bestaan. Deze bijdrage tracht een globaal overzicht van de problematiek te geven, voornamelijk vanuit het oogpunt van de gebruiker van deze software.

RESUME

La présente contribution analyse le concept de Logiciels Open Source, originairement une forme alternative de licence de logiciel, qui a récemment pris une place indéniable sur le marché du développement de logiciels. En raison de la popularité grandissante de ce logiciel sur le marché des utilisateurs non spécialisés, une zone de tension est née entre d'une part, les concepts “légers” de liberté de création intellectuelle et d'absence de responsabilité qui forment la base du système, et d'autre part, le droit, dont le rôle classique est de protéger tant la propriété (intellectuelle) que les utilisateurs de logiciels. Cette tension apparaît le plus clairement lors de l'étude du GNU General Public License, la forme de licence qui domine clairement le marché du logiciel libre, mais qui contient également les caractéristiques les plus radicales et à propos de laquelle - notamment en raison de sa rédaction peu claire - il existe un certain nombre de mythes et malentendus. La présente contribution tente de donner un aperçu global de la problématique, principalement du point de vue de l'utilisateur de ce logiciel.

Open Source Software (OSS) en andere vormen van vrije software [2] bestaan reeds geruime tijd, maar winnen sinds enkele jaren aan aandacht. Het succes van de formule is waarneembaar in een aantal succesvolle producten, een groeiende belangstelling van gebruikers in de privésector en publieke sector en een groeiend aanbod van de grote ondernemingen uit de IT-sector. Tevens bewijst de discussie aangaande softwareoctrooien, die nog niet definitief is afgesloten, dat het gedachtegoed van de beweging op grote schaal gesteund wordt. Open Source Software wordt meer visibel voor het grote publiek, terwijl deze software reeds lang wordt aangewend, voornamelijk in de infrastructuur van het internet [3] en in industriële toepassingen. Wanneer idealen op een grotere schaal worden toegepast, worden ook een aantal zwakke schakels duidelijk, volgen er discussies en stijgt de behoefte aan organisatie en regulering. Dit gebeurde met het internet, en dit gebeurt ook met het ondraaglijk lichte concept van de vrije intellectuele creatie.

Basisbegrippen

1.Onder Open Source Software (OSS) verstaat men meestal software die aan gebruikers ter beschikking wordt gesteld onder de vorm van zijn broncode (source code), en die vrij distribueerbaar en wijzigbaar is. Het begrip heeft een technische component, de fysieke terbeschikkingstelling van broncode, en een juridische component, met name een licentie die aan de licentienemer zeer ruime gebruiksrechten toekent. De broncode is de leesbare vorm van programma-instructies die in een bepaalde computertaal aan een computer gegeven worden; deze code is transparant voor personen die de ideeën en werking van een programma willen bestuderen, en kan gewijzigd worden voor de correctie van gebreken of een aanpassing aan gewijzigde omstandigheden [4]. Commerciële software wordt gewoonlijk niet in de vorm van zijn broncode overgemaakt, doch in de vorm van zijn object code. Dit is de gecompileerde, binaire vorm van de broncode; na de bewerking met een compiler is deze code slechts “machine-readable”, niet transparant voor derden, en is deze slechts door reverse engineering technieken leesbaar en bewerkbaar [5]. Broncode wordt slechts zelden aan licentienemers overgemaakt, vanuit de optiek dat software intellectuele eigendom is van de producent en wijzigingen niet worden toegelaten. Door de geheimhouding van de broncode heeft de producent een monopolie op de aanpassing van zijn software.

Op grond van het auteursrecht [6] beschikt de auteursrechthebbende over de vermogensrechten van reproductie, vertaling, bewerking, aanpassing, arrangement, en van verspreiding (art. 5 Softwarewet). Klassiek verleent de auteursrechthebbende aan licentienemers slechts een beperkt recht tot gebruik van de object code, en dit voor “zuiver intern gebruik”, vaak beperkt tot een bepaald aantal gebruikers of bepaalde hardware, en zonder wijzigingsrechten, verspreidingsrechten of exploitatierechten. Daarnaast kent de Softwarewet aan de gebruiker een recht toe om een reservekopie te nemen en om software te reproduceren en te wijzigen wanneer dit noodzakelijk is om deze te gebruiken voor het beoogde doel en fouten te verbeteren [7]. Wettelijk beschikt de gebruiker ook over beperkte reproductierechten en wijzigingsrechten, eventueel via reverse engineering, om de compatibiliteit tussen programma's tot stand te brengen (art. 7 Softwarewet), een problematiek die steeds belangrijker wordt naarmate software meer en meer geïntegreerd wordt met andere software. Uitgezonderd het recht om noodzakelijke wijzigingen voor het gebruik of foutcorrectie aan te brengen, zijn deze rechten van dwingend recht (art. 8 Softwarewet). Een wettelijk recht tot aanpassing heeft de gebruiker dus alleen in beperkte omstandigheden [8]. Wanneer software wordt ontwikkeld op maat, wordt het auteursrecht soms overgedragen aan de verkrijger-opdrachtgever. Uitzonderlijk wordt dan ook de broncode overgedragen zodat de verkrijger zelf aanpassingen kan uitvoeren; gewoonlijk blijft de terbeschikkingstelling van broncode echter beperkt tot een source code escrow [9]. De rechtspraak heeft nooit bevestigd dat de gebruiker van software een recht zou hebben op overdracht van broncode, zelfs al wordt software in eigendom overgedragen [10]. Gebruikers van software zijn dus afhankelijk van hun leveranciers, en niet iedereen vindt dit een ideale situatie. Bepaalde gebruikers die over de nodige middelen beschikken, wensen meer mogelijkheden om de software autonoom te kunnen aanpassen aan hun wijzigende noden. Door een radicale breuk met de beperkende principes van het auteursrecht komt de OSS-beweging hieraan tegemoet.

“Copyleft” versus “copyright”

2.OSS, dat niet verward mag worden met verwante begrippen [11], is een product van een beweging die reeds een lange geschiedenis kent [12]. Software is jarenlang een onbeschermd bijproduct geweest van hardware, dat weinig betekende tot IBM einde jaren '60 overging tot het “unbundling” van hardware en software. In de jaren '70 werd software een belangrijk op zichzelf staand product, dat beschermd werd via intellectuele eigendomsrechten en “trade secrets”-bepalingen. De OSS-beweging ontstond toen R. Stallman begin jaren '80 dit eigendomsrecht op software verwierp, en het GNU-systeem bedacht om een vrij besturingssysteem uit te brengen dat compatibel zou zijn met het Unix-systeem. Aldus werd een community gecreëerd waarin de gemeenschappelijke bijdragen van alle leden tot een versnelde verbetering van de software zouden leiden. De software werd uitgebracht onder het principe van copyleft [13] als antagonist van copyright. Het copyleft principe stelt dat iedereen het recht heeft om software te gebruiken, te kopiëren, te wijzigen, en om gewijzigde versies te verspreiden, op voorwaarde dat de broncode mede verspreid wordt of minstens beschikbaar is. Bovendien, en dat is cruciaal, kan niemand beperkingen invoeren op de verdere verspreiding en het gebruik van de software, ook al is hij de auteur van een gewijzigde versie (afgeleid werk). Niemand kan zich een afgeleide van de vrije software toeëigenen. Indien “eigen” software door een licentienemer toegevoegd wordt of zodanig gecombineerd wordt dat er sprake is van een afgeleid werk, is dit afgeleid werk ook “copylefted”. Dit “besmettingseffect” zullen we verder uitgebreid bespreken (infra, randnrs. 10 e.v.). Aan de volgende licentienemers moet via een kettingbeding dezelfde licentievoorwaarden worden opgelegd. Het copyleft-principe werd vertaald in de GNU General Public License (GPL), die nog steeds de belangrijkste OSS-licentie is, en o.m. voor Linux wordt gebruikt. De programma's werden succesvol en in 1985 werd de Free Software Foundation (FSF) opgericht als een algemene beweging voor de verspreiding van vrije software. Parallel met de GPL-licentie ontstond de soepeler BSD-licentie die ook een vrije ontwikkeling benadrukt, maar die niet verhindert dat BSD-code geïncorporeerd wordt in andere, zelfs commerciële software [14]. Deze flexibele licentie is het type-voorbeeld van de zogenaamde non-copyleft-licentie.

Waar de FSF geen alternatief besturingssysteem kon ontwikkelen, slaagde de Fin Linus Torvalds daar wel in, door een combinatie van eigen ontwikkelingen aan de zgn. kernel [15] en andere bestaande componenten. Dit werd door de community verder ontwikkeld tot het vrije besturingssysteem Linux, verspreid onder de GPL-licentie. De ontwikkelingsmethode via de gedecentraliseerde “bazaar”-methode, tegenhanger van de gecentraliseerde “kathedraalmethode”, met medewerking van vrijwilligers die als beloning een zeker prestige of “gewoon fun” zoeken, spreekt aan [16]. Via het downloaden van software van het internet werden de mogelijkheden tot losse samenwerking sterk vereenvoudigd. Het ontwikkelingsproces verloopt trouwens minder chaotisch dan soms wordt voorgehouden [17]. In 1998 werd door een andere groep ontwikkelaars, minder dogmatisch dan de FSF, de term “open source” bedacht voor hun toepassing van het systeem van vrije ontwikkeling. De nadruk lag meer op het vrijgeven van broncode om praktische redenen dan op de echte “copyleft”-gedachte. De Mozilla-licentie van 1998, uitgebracht voor Netscape's webbrowser, was de eerste bekende licentie die door deze stroming werd uitgebracht. Deze licentie had een steviger juridische omkadering en poogde voornamelijk om commerciële vereisten te verzoenen met het principe van vrije broncode [18]. De “Open Source”-beweging werd gestructureerd onder de Open Source Initiative organisatie (OSI), die een Open Source Definition heeft opgesteld en die over een eigen certificatieprogramma beschikt.

Definities en criteria

3.Onder de noemers “vrije software” en “Open Source”-software worden zeer verschillende licentievormen begrepen, die een klassificatie van de verschillende licentievormen moeilijk maakt [19]. De begripsverwarring neemt ook toe wanneer een radicale groep als de FSF haar specifieke software aanduidt als “Free Software” om het onderscheid met OSS te benadrukken. (Om verwarring te voorkomen zullen wij deze software GPL-software noemen). Aan de kant van de “gesloten” software en hybriede vormen worden begrippen gehanteerd als proprietary software, private software, commercial software, closed software, enz. Wij gebruiken verder de term “privatieve” software voor software waarvan de broncode gesloten blijft en de verspreiding of wijziging verboden of beperkt wordt.

De basisprincipes van OSS betreffen het vrije gebruik van software, vrije verspreiding, toegang tot broncode, het recht om software te bestuderen, te wijzigen en het recht om gewijzigde software te verspreiden. Deze basisprincipes komen tot uiting in elk systeem van Free Software of OSS. Er bestaan nochtans ernstige verschillen wat de modaliteiten van deze rechten betreft, iets waarvan vele gebruikers zich geenszins bewust zijn.

4.De dogmatische FSF ontwikkelde de Free Software Definition die met 4 karakteristieke vrijheden een definitie geeft van Free Software [20]:

de vrijheid om de software te gebruiken (“running”), voor eender wel gebruik (freedom 0);
de vrijheid om te bestuderen hoe de software werkt, en deze aan te passen aan de noden (freedom 1). Toegang tot de broncode is hiervoor een voorwaarde, en is het meest karakteristieke kenmerk van alle vormen van vrije software;
de vrijheid om kopies te verpreiden (freedom 2);
de vrijheid om het programma te verbeteren en de verbeteringen in het publiek te verspreiden (freedom 3). Toegang tot broncode is ook hiervoor een voorwaarde.

Het copyleft-principe betekent daarenboven dat wie de software verspreidt, geen beperkingen aan de vrijheden van de volgende gebruikers mag opleggen. Dit is een verplichting, die ook deel zou moeten uitmaken van de definitie. We zullen de GPL-licentie, hét voorbeeld van deze licentievorm, verder bespreken.

Het OSS-begrip is ruimer en minder dogmatisch dan Free Software (dat volgens de OSS-definitie een deelcategorie van OSS is). De beweging wenst eerder een pragmatische aanpak van softwareontwikkeling en richt zich voornamelijk op de beschikbaarheid van de broncode. De Open Source Initiative, OSI, heeft geen type-licentie [21] maar certifieert wel “erkende” licenties die de standaard, de Open Source Definition (OSD), naleven. In tegenstelling tot de GPL, aanvaardt men dat licentienemers aan verkrijgers gebruiksbeperkingen opleggen [22]. De verplichting tot vrijgave van afgeleide code en het “besmettingsprincipe” zoals opgelegd in de GPL zijn niet karakteristiek voor de OSD. Ook de soepeler BSD-familie wordt aanzien als overeenstemmmend met de OSD. In het algemeen onderscheidt men aldus binnen de OSS de families van “copyleft” en “non-copyleft”-licenties. In de tekst die volgt gebruiken we de term OSS als ruim begrip, waarvan Free Software (GPL-software) een deelcategorie is [23].

Ten onrechte wordt soms gedacht dat OSS gratis moet zijn [24]. Wel is het zo dat de software in de praktijk vaak goedkoop of gratis is, en dat de terbeschikkingstelling van de broncode op zich niet afhankelijk mag zijn van een prijs [25].

Recente ontwikkelingen

5.Sinds enkele jaren hebben topbedrijven als IBM, Sun Microsystems, Novell, Apple en zelfs Microsoft, zich toegelegd op OSS, alhoewel het soms eerder om een marketingzet gaat dan een echte toepassing. Aan de aanbodzijde merkt de softwaresector hoe goedkope, aanpasbare software een bedreiging vormt. Het grote voorbeeld van succes was de doorbraak van Linux als een stabiel OSS-besturingssysteem, waarvoor meer en meer applicatiesoftware wordt ontwikkeld. Nieuwe businessmodellen ontstaan in het bewustzijn dat het mogelijk is om aan OSS te verdienen [26]. Aan de afnemerszijde wordt meer en meer geopteerd voor OSS. De interoperabiliteit, openheid en flexibele aanpassingsmogelijkheden van de software waarborgen een grotere continuïteit en zijn aldus primaire vereisten geworden voor de gebruikers van de private en de publieke sector. Deze voordelen verkrijgt men aan een lage prijs. Opmerkelijk is vooral het succes van OSS (en open standaarden in het algemeen) in het kader van overheidsinformatisering en e-Government [27]. In talrijke landen zijn richtlijnen of wetgeving uitgevaardigd die OSS voor de overheid als eerste keuze voorschrijven. Ook in België zijn richtlijnen opgesteld voor overheidsbesturen inzake het gebruik van open standaarden, die gedeeltelijk verwijzen naar OSS [28]. Deze tendens werd in België onderstreept in de wet van 10 augustus 2005 tot oprichting van het Phenix-informatiesysteem, dat cruciaal zal zijn voor de werking van hoven en rechtbanken. In artikel 30 van de wet wordt voorgeschreven dat de in het systeem gebruikte “protocollen en formaten voor het mededelen en bewaren” uitsluitend gegrond zullen zijn op open standaarden. De open standaard wordt gedefinieerd als een standaard die gratis beschikbaar is op het internet en geen juridische beperkingen kent wat de verspreiding en het gebruik ervan betreft [29]. Naast deze successen werd de filosofie van creatieve vrijheid ook toegepast in andere domeinen dan software; de “Creative Commons”-licentie is een bekend voorbeeld [30].

6.Anderzijds wordt de ontwikkeling van het fenomeen OSS enigszins afgeremd door een aantal negatieve krachten, zoals de discussie rond de octrooieerbaarheid van software [31], de vraagtekens aangaande de veiligheid van OSS t.a.v. inbreuken op de intellectuele rechten van derden en de afwezigheid van garanties dienaangaande (zie randnr. 30), de problematiek van de “besmetting” met GPL-software (zie randnrs. 11 e.v.), en een aantal gerechtelijke procedures in de VS in de sfeer van Linux [32]. Bovendien mag men niet uit het oog verliezen dat OSS geen afgewerkt product is. Het blijkt dat een aantal gebruikers van OSS na de eerste euforie teleurgesteld zijn in de kwaliteit en niet in staat zijn om de onvoorziene problemen die vaak inherent zijn aan dit product, op te lossen. De afwezigheid van voldoende ondersteuning doet zich soms gevoelen. Geconfronteerd met de afwezigheid van garanties en een volledige uitsluiting van aansprakelijkheid, dient men zich af te vragen of de markt voldoende beschermd is tegen deze risico's (randnrs. 25 e.v.).

De GPL-licentie

7.We hebben reeds de radicale opvattingen aangestipt van de Free Software Foundation, die gebaseerd zijn op het copyleft-principe en die in de bekendste vorm voorkomen in de GNU-General Public Licence ofwel GPL [33], waaronder de GNU-software en Linux worden verspreid. Deze licentie is zo belangrijk voor de praktijk dat we hierna de licentie als type-voorbeeld zullen hanteren voor de bespreking van de voornaamste problemen die aan OSS gerelateerd zijn [34]. Het is een tekst met een all-or-nothing-concept, eerder als een manifest dan een precieze juridische tekst geschreven [35]. Onnodige herhalingen van principes, die bovendien qua formulering van elkaar afwijken, en onduidelijkheden leiden tot interpretatieproblemen, zoals we verder zullen zien [36]. Belangrijk is in elk geval dat een Duitse rechtbank de geldigheid van de licentie heeft erkend (infra, randnr. 17).

5.1.

Verbatim-kopies en verspreiding

8.De GPL bepaalt dat elke verkrijger van de software door zijn loutere handelingen, met name de wijziging en verspreiding van de verkregen software, automatisch een licentie bekomt van de oorspronkelijke auteur en de opvolgende auteurs in de keten [37]. De GPL § 1 geeft de licentienemer op zijn beurt het recht om ongewijzigde “verbatim”-kopies van de broncode te maken en te verspreiden in om het even welk medium, op voorwaarde dat de kopies de gepaste copyright notices en de clausule van afwezigheid van garantie (warranty disclaimer) bevatten. De tekst van de licentie moet worden bijgevoegd [38]. Uitzonderlijk mag de licentienemer op zijn beurt, en tegen een vergoeding, garanties bieden jegens opvolgende verkrijgers van de software. Overeenkomstig § 1 mag hij ook een vergoeding aanrekenen voor de “fysieke overdracht” van een kopie.

§ 1 handelt alleen over de overdracht van de broncode, maar men mag een programma ook verspreiden in zijn object code (executable form) indien de broncode ter beschikking wordt gesteld onder de voorwaarden van § 3 GPL. Men moet dan de broncode bijvoegen [39] of een schriftelijke garantie geven dat deze gedurende minimum drie jaar verkrijgbaar is tegen de kostprijs van de fysieke terbeschikkingstelling. Indien men zelf slechts zulke garantie bekomen heeft, mag men zich uitzonderlijk beperken tot de mededeling van zulke informatie. § 3 beschrijft verder wat onder de volledige broncode begrepen wordt.

Verspreiding van OSS is meestal mogelijk in elk medium (zie bv. § 1 GPL). Dit betekent dat de software, al dan niet gewijzigd of gecombineerd met andere software, kan opgenomen worden in computerhardware (bv. als een voorgeïnstalleerd besturingssysteem), in industriële apparaten zoals robots, meetapparatuur, medische toestellen, of in verbruiksgoederen zoals mobiele telefoons en onderdelen van auto's [40].

5.2.

Wijzigingsrecht (voor eigen gebruik)

9.Krachtens § 2 GPL heeft de gebruiker het recht om zijn kopie van het programma te wijzigen. Principieel heeft men dus het recht om een afgeleid werk te creëren. Het programma kan aldus afgestemd worden op de specifieke noden van de gebruiker.

De eenvoudige wijziging van de broncode brengt geen verplichtingen met zich. Meer bepaald is de gebruiker onder de GPL niet verplicht om zijn wijzigingen te publiceren of de broncode ter beschikking te stellen, zolang hij de software niet verspreidt [41]. Ook wanneer de gebruiker eigen privatieve software met deze software combineert, heeft hij terzake geen “disclosure”-verplichtingen [42].

5.3.

Verspreiding van gewijzigde code

5.3.1. Algemeen

10.Wanneer de gebruiker de software op zijn beurt in gewijzigde vorm verspreidt [43], spelen de echte copyleft-regels van de GPL. Deze zijn zeer belangrijk, maar ook complex en verwarrend in de praktijk en worden vaak op een tegenstrijdige wijze uitgelegd.

De GPL bepaalt in § 2b als hoofdregel: “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 License.” In § 2 zijn aanvullende bepalingen opgenomen die zeer verwarrend werken en die we verder zullen bespreken. Voor de goede orde dient er op gewezen dat het programma mag gewijzigd en verspreid worden, maar dat de tekst van de GPL-licentie zelf ongewijzigd dient te blijven [44].

De voorwaarden voor de toelating tot verspreiding zijn:

men moet aangeven dat men de software gewijzigd heeft, met de datum van de wijziging [45];
men moet er voor zorgen dat bij de lancering van het programma een copyright notice verschijnt, met de warranty disclaimer (of tegengesteld, dat men wel degelijk een persoonlijke garantie geeft), met de mededeling dat de gebruiker onder deze voorwaarden een verspreidingsrecht heeft en met weergave van de wijze waarop de GPL-licentie kan gelezen worden;
men moet het “gehele werk” verspreiden onder de GPL-licentie.

11.Deze laatste voorwaarde van § 2b is cruciaal: ze verhindert dat wanneer een afgeleid werk wordt gecreëerd waarin GPL-code wordt opgenomen, de auteur van het afgeleide werk zich de GPL-code kan toeëigenen als privatieve code. Een afgeleid werk is in dit geval een werk dat bestaat uit nieuwe code, maar dat tevens gebaseerd is op GPL-code, doordat het GPL-code overneemt [46]. Auteursrechtelijk is het afgeleid werk het resultaat van het adaptatierecht, dat een vorm is van het reproductierecht dat aan de auteur van het oorspronkelijke werk toekomt [47]. Voor de creatie van een afgeleid werk is diens toestemming nodig. Anderzijds komt het auteursrecht op de wijziging, op de nieuwe code, toe aan de auteur van het afgeleid werk. De rechten op “het geheel” van het afgeleid werk komen toe aan beide auteurs. De GPL geeft a priori aan eenieder de toelating om een afgeleid werk te creëren, maar bepaalt dat de verspreiding van het afgeleid werk als geheel alleen onder de GPL mag geschieden. Dit is de kern van het copyleft-principe, dat agressief geformuleerd is, aangezien dit impliceert dat de auteur van het afgeleid werk als “geheel” dan ook zijn eigen privatieve code zal moeten vrijgeven zoals bepaald in de GPL. Volgens critici “onteigent” de bepaling van § 2b aldus privatieve code [48], of “besmet” deze bepaling privatieve code met het statuut van OSS. Dit effect wordt door de commerciële concurrenten en non-copyleft-ontwikkelaars het “besmettende”, “virale” effect van de GPL genoemd [49]. Daarbij worden schrikbeelden voorgespiegeld van een mogelijk verlies van intellectuele eigendom en een verplichte openlegging van jarenlang opgebouwde know-how [50].

Deze sfeerschepping moet in de juiste context worden geplaatst. De terbeschikkingstelling van eigen broncode wordt alleen vereist wanneer het afgeleid werk verspreid wordt [51], niet wanneer een afgeleid werk zuiver voor eigen gebruik wordt aangewend. Bovendien betwijfelen we of de rechter in de praktijk gemakkelijk een verplichte vrijgave van broncode zal bevelen wanneer de regels van de GPL niet worden nageleefd. Ons inziens zal de sanctie meestal beperkt blijven tot een verbod tot verdere verspreiding van inbreukmakende software (zie randnrs. 16-17). Voorstanders stellen dat niemand verplicht is om GPL-software te gebruiken, en dat de naleving van de gestelde spelregels de enige voorwaarde is om goedkoop gebruik te maken van bestaande software. Het effect van de GPL moet volgens gematigde commentatoren dus gerelativeerd worden, en dezen spreken dan ook eerder over de verervende werking van de GPL [52] of het wederkerigheidsbeginsel [53]. Anderzijds is het wel zo, dat een té ver doorgedreven interpretatie van deze principes en vooral een te ruime opvatting van het begrip “afgeleid werk”, negatief werkt. Indien men elke software die voor zijn werking gecombineerd wordt met GPL-software, zonder dat GPL-code echt wordt overgenomen, onder een verplicht GPL-statuut wil brengen, dan is de term “besmetting” niet overdreven. Zoals we verder bespreken, gaat de FSF hier inderdaad te ver. De angst dat software die zelfs maar “in aanraking komt” met GPL-code, besmet zou worden, verhindert vele programmeurs om software te ontwikkelen die compatibel is met GPL-software, ook al zouden ze zeker geen afgeleid werk creëren.

12.Gelet op de vérgaande draagwijdte van § 2 GPL, is het spijtig dat een verwarrende redactie van de tekst tot grote onzekerheden leidt. De verplichting tot licentiëring onder de GPL zoals vermeld in § 2b is toepasselijk gemaakt op het gehele werk, doch dit wordt op twee verschillende wijzen omschreven: enerzijds als een “work based on the Program” in de aanvang van § 2, anderzijds als “any work that in whole or in part contains or is derived from the Program” in § 2b. Het begrip “a work based on the Program” is gedefinieerd in § 0 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”. Met het “derivative work under copyright law”, verwijst men naar het Amerikaanse begrip van het afgeleid werk, dat wettelijk gedefinieerd wordt als een werk “gebaseerd op” een voorafbestaand werk [54]. In West-Europese landen wordt voor het begrip “afgeleid werk” explicieter de nadruk gelegd op een incorporatie, een overnemen van oorspronkelijke elementen van een voorafbestaand werk. In België wordt het omschreven als een werk met een zekere originaliteit, doch waarvan de originaliteit afhankelijk is van een eerder bestaand werk waarvan bepaalde oorspronkelijke elementen worden overgenomen [55]. De Franse en Duitse definities zijn gelijkaardig [56]. Het auteursrecht op software biedt bescherming als een werk van letterkunde, en betreft voornamelijk de code als “geschreven tekst”, zowel in de vorm van broncode als object code. Men kan veralgemenend stellen dat voor het “afgeleid werk” een volledige of gedeeltelijke overname van de originele programmacode vereist is [57]. Daarbij zal in concreto nagegaan worden of de overgenomen code auteursrechtelijk beschermd is. Naar Belgisch recht mag in geval van een letterlijke overname van code geen afweging van de kwaliteit of kwantiteit daarvan gebeuren. Het feit dat oorspronkelijke elementen worden overgenomen is voldoende [58]. Is de overname niet letterlijk, maar gedeeltelijk of gewijzigd, dan wordt onderzocht of het werk “in zodanige mate de auteursrechtelijk beschermde trekken van het eerdere werk vertoont dat de totaalindrukken die beide werken maken te weinig verschillen voor de beoordeling van het werk als een zelfstandig werk” [59]. In het Amerikaanse recht wordt in dezelfde zin gezocht naar een “substantial similarity” tussen computerprogramma's, meestal aan de hand van de zgn. AFC-test, waarmede men de verschillende diepte-niveau's van de programma's analyseert, de niet-beschermbare elementen uitfiltert en de overblijvende beschermbare elementen van beide programma's vergelijkt [60].

De GPL is echter dubbelzinniger waar in § 0 het begrip “a work based on the Program” wordt omschreven 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” [61]. Aldus geeft de GPL in het “that is to say”-gedeelte een eigen interpretatie van het “afgeleid werk”, die verder gaat dan het wettelijke begrip. De uitdrukking “containing a portion of it” impliceert dat zelfs de overname van triviale of onbeschermbare GPL-code [62] resulteert in een “work based on the Program”. Dit strookt niet met het Europese en Amerikaanse auteursrecht, dat minstens de overname van oorspronkelijke elementen eist. Volgens sommigen gaat het hier om een contractuele uitbreiding van het begrip afgeleid werk tot creaties die zelfs triviale of andere onbeschermbare code incorporeren, en zij aanvaarden dit op grond van de “contractuele werking” van de GPL [63]. Ook al gaat men hier het wettelijk begrip van het afgeleid werk te buiten, dan zou de uitbreiding van het begrip toch gelden overeenkomstig het verbintenissenrecht. Dit is niet correct. Op basis van de verklaringen van de FSF, auteur van de GPL, is het duidelijk dat de GPL alleen verwijst naar het wettelijk begrip van het afgeleid werk zoals gedefinieerd onder het toepasselijke nationale recht. Het “that is to say” gedeelte is niet bindend. Evenmin is de interpretatie van de GPL door de FSF, weergegeven in de Frequently Asked Questions, bindend [64]. Bovendien is de overname van niet-beschermbare code niet onderworpen aan contractuele voorwaarden. Wie triviale code overneemt, hoeft daarvoor de GPL zelfs niet te aanvaarden en is er dus niet door gebonden. Aldus accepteert de meerderheid van auteurs dat de zuivere incorporatie van (niet-triviale en oorspronkelijke) GPL-code met zich brengt dat de GPL van toepassing is op het gehele afgeleide werk, inclusief de delen die nieuw gecreëerd zijn en waarvan de nieuwe auteur de auteursrechten heeft [65].

5.3.2. “Deel van een geheel” en combinaties van software

13.Waar § 2b verwijst naar een werk dat GPL-code bevat (contains) of ervan afgeleid is (derived from), en dit op zich nog bevattelijk is, hebben de auteurs van de GPL het helaas nodig geacht om de problematiek nog eens “aan te snijden”, en in andere bewoordingen, in § 2, leden 2 tot 4. Hier wordt eerst bevestigd dat de GPL toepasselijk is op het gehele afgeleide werk als “één geheel”. Dan volgt een zeer verwarrende passage van lid 2, waarvan de exacte inhoud voor niemand duidelijk is [66]. Blijkbaar was het de bedoeling om hier te benadrukken dat er ook sprake kan zijn van “één geheel” wanneer afzonderlijke programma's geen code van elkaar overnemen, maar sterk met elkaar verweven zijn. Wanneer een privatief programma als een afzonderlijk bestand gescheiden is van GPL-software, maar voor zijn werking wel afhankelijk is van GPL-software die in een afzonderlijk bestand is opgenomen, dan vormt dit volgens de FSF een virtueel of functioneel geheel, en dient dit geheel verspreid te worden onder de GPL. Het privatieve programma is dan “based on the GPL-Program”, alhoewel het een afzonderlijk bestand is dat geen GPL-code overneemt, en het is dan geen “independent and separate work' [67]. Dit geldt a fortiori wanneer het privatieve bestand en het GPL-bestand tesamen verspreid worden. Anderzijds stelt lid 4 dan dat het loutere naast elkaar aanbrengen van onafhankelijke programma's op eenzelfde drager als een DVD-rom, niet automatisch leidt één geheel waarop de GPL toepasselijk is (“mere aggregation”) [68]. Kan men niet zeggen wat lid 2 precies inhoudt, dan kan men tenminste zeggen wat het niet inhoudt. Op grond van lid 4 kan men privatieve programma's met GPL-programma's op éénzelfde drager aanbrengen en verspreiden, waarbij de prijs van de privatieve software vrij kan bepaald worden [69].

Op internetforums en in juridische literatuur wordt door programmeurs en juristen hevig gedebateerd over de vraag of er sprake kan zijn van een “afgeleid werk” in de zin die de FSF suggereert, met name wanneer een privatieve module geen GPL-code bevat, maar wel op een functionele, ideële of tijdelijke wijze verenigd zou worden met GPL-code. Het probleem stelt zich voor allerlei vormen waarin privatieve code en GPL-code gecombineerd wordt. In de praktijk is het bijvoorbeeld zeer belangrijk te weten of privatieve software gebruik mag maken van externe GPL-libraries [70] zonder dat de software daardoor “besmet wordt” met het GPL-statuut en de privatieve broncode zou moeten vrijgegeven worden. Wanneer de code van een GPL-library letterlijk in het privatieve programma geïncorporeerd wordt, zal de GPL toepasselijk zijn op het gehele programma, wat betekent dat ook de broncode van de nieuw geschreven code zal moeten overgelegd worden [71]. Wanneer het privatieve programma de library niet incorporeert, maar tijdens zijn werking de library als een extern bestand “aanroept” wanneer dit nodig is (een methode die “dynamisch linken” wordt genoemd), dan zal het volgens een enge opvatting van het “afgeleid werk” geen GPL-code incorporeren, en moet de privatieve broncode niet vrijgegeven worden. Volgens de ruime FSF-opvatting is het programma echter functioneel afhankelijk van de GPL-library, zodat het één functioneel geheel vormt dat als een afgeleid werk van de library moet beschouwd worden, waardoor de broncode van de privatieve software wel dient vrijgegeven [72]. Het gebruik van GPL-libraries is noodzakelijk om programma's te ontwikkelen die compatibel zijn met GPL-programma's - het betreft hier wel degelijk een ernstig praktisch probleem. De FSF heeft dit begrepen en heeft een specifieke licentie uitgewerkt die een vlottere combinatie tussen privatieve software en vrije libraries toelaat, de LGPL [73].

14.De combinatietheorie van de FSF wordt door een aantal auteurs aanvaard. Sommigen schijnen dit te aanvaarden als een ruime opvatting van het begrip “afgeleid werk” - waarbij het begrip “overneming van bestaande code” niet alleen verwijst naar een fysische incorporatie, maar ook naar een ideële of functionele incorporatie [74]. Dit is echter niet correct. Het auteursrecht houdt geen rekening met technische afhankelijkheden of functionaliteit (zoals een octrooi), maar met de vormgeving, de expressie van de functionaliteit, in geschreven code. Het begrip “afgeleid werk” verwijst wel naar een zekere afhankelijkheid van een ander werk, maar in een formele zin, als een werk dat concrete elementen van een ander werk fysisch overneemt [75]^, [76].

Sommigen geven toe dat de GPL het wettelijk begrip van het afgeleid werk overschrijdt, maar aanvaarden het combinatie-principe op grond van de contractuele werking van de GPL [77]. Hoger hebben we echter reeds aangehaald dat de FSF alleen verwijst naar het wettelijk begrip, zoals toegepast door de rechter [78]. Hieruit volgt a fortiori dat de opvattingen van de FSF niet kunnen beschouwd worden als gebruiken in de zin van de artikelen 1135 en 1160 B.W., een standpunt dat nochtans soms verdedigd wordt [79]. En zelfs indien men principieel zou aanvaarden dat de GPL een contractuele uitbreiding beoogt van het “afgeleid werk”, dan kan nog gesteld worden dat de GPL als toetredingscontract dermate onduidelijk is opgesteld, dat de doorsnee programmeur niet kan geacht worden te hebben ingestemd met deze bepalingen, a fortiori niet met de interpretatie daarvan door de FSF [80]. Bovendien zullen de licentievoorwaarden, die verder gaan dan wat auteursrechtelijk als afgeleid werk beschermd wordt, dan de toetsing van rechtsmisbruik moeten doorstaan [81].

Samengevat, mag men dus stellen dat de GPL slechts op privatieve code dient toegepast te worden wanneer er sprake is van een “afgeleid werk” volgens de criteria van het toepasselijk nationale recht, en niet volgens contractuele criteria noch “gebruiken”. Dit betekent dat er slechts sprake is van een afgeleid werk wanneer dit werk concrete en niet-triviale GPL-code overneemt. Combinaties met GPL-code zonder concrete overname, zoals dynamisch linken, leiden niet tot verplichte overlegging van de privatieve broncode. Het gaat dan om een eenvoudig gebruik van GPL-code, en dit gebruik is vrij. Of de verschillende standpunten altijd moreel of markteconomisch gerechtvaardigd zijn, is een andere vraag. Het is uiteraard begrijpelijk dat de FSF wil verhinderen dat commerciële ontwikkelaars parasiteren op GPL-software. Maar volstaat hiervoor geen verbod van overname van GPL-code sensu stricto? Het verhinderen van de ontwikkeling van compatibele programma's door een overdreven combinatietheorie, is niet aanvaardbaar voor een systeem dat de “enige echte vrijheid” propageert. Door het virale effect van de GPL volledig te richten op het begrip afgeleid werk (daarenboven op een onhandige wijze), hebben de auteurs van de GPL technisch-juridisch gefaald in hun opzet. Toch moet men tegelijkertijd vaststellen dat het systeem in de praktijk wel werkt, gelet op het beperkt aantal rechtszaken. Wellicht kan er sprake zijn van een ontradende onduidelijkheid, en niet-juridische factoren zoals de vrees voor aanvallen uit de hackerswereld in geval van overtreding van de GPL.

5.3.3. Sanctionering

15.De sanctionering van de miskenning van de GPL-voorwaarden is niet geheel duidelijk. De GPL stelt in § 4: “You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License (...)”. De contractuele sanctie is dus de beëindiging van de toegekende ruime rechten, wat naar Belgisch recht een uitdrukkelijk ontbindend beding vormt [82]. Na de ontbinding zal de gebruiker op grond van het auteursrecht de ruime rechten niet meer mogen uitoefenen, want hij heeft hiervoor niet meer de toelating van de auteursrechthebbenden [83]. Paradoxaal moet men uiteindelijk een beroep doen op het “verdoemde” auteursrecht om de schending van het copyleft-principe te sanctioneren...

De beëindiging heeft tot gevolg dat men de GPL-code niet meer mag kopiëren, verspreiden of wijzigen, aangezien voor deze handelingen de toelating van de auteur nodig is en de GPL hiervoor de aanvaarding van de licentie voorschrijft. Voor het louter intern gebruik van de software is dit niet het geval. De GPL bepaalt in § 0 lid 2 dat andere handelingen dan kopiëren, verspreiden en wijzigen niet door de licentie beheerst worden; bovendien is het louter gebruik (“the act of running the Program”) niet beperkt. Logischerwijze zal een beëindiging van de licentie dus geen invloed hebben op het recht om de software te gebruiken [84].

16.Sommigen menen dat er voor de eigenaar van privatieve software die door de incorporatie van GPL-code “besmet wordt” met de GPL, een risico bestaat tot gedwongen openbaarmaking van zijn privatieve broncode indien hij zijn code niet vrijwillig vrijgeeft en aldus de GPL overtreedt [85]. Men kan zich voorstellen dat een dergelijke ongewilde openbaarmaking van know-how drastische gevolgen heeft, en dat de overtreder in dat geval beter af is met de ontbinding van de licentie, zonder meer. Auteursrechtelijk zien we niet in hoe privatieve code door besmetting automatisch zou kunnen veranderen in GPL-code. Een wijziging van het statuut veronderstelt een overeenkomst waarin de eigenaar van de privatieve software uitdrukkelijk rechten overdraagt of toekent [86]. Zou men anderzijds kunnen stellen dat wie GPL-code in eigen code incorporeert, verbintenisrechtelijk gedwongen kan worden tot overlegging van de eigen broncode, eventueel met een dwangsom? Naar Belgisch recht kan een contractant in geval van contractuele tekortkoming van zijn medecontractant naar zijn keuze de gedwongen uitvoering of ontbinding van de overeenkomst eisen (art. 1184 B.W.). De GPL formuleert zelf in § 4 als sanctie de automatische ontbinding van de licentie. Maar zelfs wanneer een uitdrukkelijk ontbindend beding stelt dat de ontbinding “automatisch” of “van rechtswege” optreedt, kan de eiser nog steeds opteren voor de gedwongen uitvoering [87]. Sommigen stellen dat men aldus de gedwongen overlegging van broncode kan eisen [88].

Hier speelt echter opnieuw een merkwaardige dualiteit tussen enerzijds het auteursrecht en anderzijds de contractuele werking van de licentie. Volgens een restrictieve opvatting, die de nadruk legt op het auteursrechtelijke aspect, bevat de GPL geen echte verbintenis om eigen broncode vrij te geven. De GPL geeft volgens die opvatting wel een “auteursrechtelijke toelating” om een afgeleid werk te verspreiden op voorwaarde dat men het onder de GPL-voorwaarden licentieert, wat de vrijgave van broncode impliceert [89]. Verspreidt men het werk met miskenning van de voorwaarde, dan handelt men foutief, zonder de vereiste toelating van de auteursrechthebbende. De onrechtmatige verspreiding wordt dan opgevat als een inbreuk op het auteursrecht, eerder dan een verbintenisrechtelijke tekortkoming. In de praktijk zou het billijk zijn dat de overtreder in dat geval eerst aangemaand wordt om ofwel zijn inbreuk te corrigeren (de broncode in kwestie vrij te geven), ofwel de verspreiding van het dubieuze “geheel” te staken, en indien geen van beide alternatieven wordt nageleefd, de ontbinding van de overeenkomst vast te stellen wegens inbreuk op de licentie en het auteursrecht. Zo krijgt de overtreder, die niet noodzakelijk te kwader trouw is, de kans om de inbreuk te corrigeren. Deze oplossing [90] lijkt ons redelijker dan een gedwongen overlegging van eigen broncode.

Anderzijds geven we toe dat de voorwaarde tot overlegging van eigen broncode evenzeer in contractuele zin kan uitgelegd worden als een verbintenis die de gebruiker automatisch aangaat door het enkele feit van de verspreiding van het afgeleid werk. Volgens deze opvatting is het “besmettingsprincipe” een essentiële spelregel van de GPL, die de gebruiker zou moeten kennen en naleven. Strikt genomen, is dit dan een verbintenis die vatbaar is voor gedwongen uitvoering (art. 1184 B.W.). Deze opvatting heeft niet onze voorkeur, en ze gaat ook in tegen een algemene tendens van rechterlijke (en administratieve) overheden om het geheime karakter van broncode, als waardevolle know-how, te beschermen tegen onnodige vrijgave [91]. Nochtans is het niet uitgesloten dat de rechter een gedwongen overlegging zou bevelen indien de omstandigheden zulks zouden rechtvaardigen, bijvoorbeeld wanneer derden-gebruikers het OSS-gedeelte alleen nuttig kunnen aanwenden indien ook de broncode van de privatieve component beschikbaar is. Dit is a fortiori denkbaar wanneer het OSS-gedeelte een essentiële component vormt van het gehele afgeleide werk. In elk geval komt het ons voor dat de eiser in een vordering tot gedwongen uitvoering een bijzonder belang zal moeten aantonen opdat de vordering niet als rechtsmisbruik zou beschouwd worden [92]. Het belang van de licentiegever is immers in de eerste plaats de eerbiediging van de licentievoorwaarden, en dit zal meestal voldoende beschermd worden door de ontbinding van de licentie en het verbod van verdere verspreiding. De eis tot gedwongen overlegging lijkt dan een eis die de belangen van de inbreukmaker op een onevenredige wijze schaadt.

17.In Duitsland werd in 2004 in de zaak Netfilter/Sitecom [93] voor het eerst een belangrijke rechterlijke uitspraak gedaan aangaande overtreding van de GPL [94]. Kort samengevat, betrof deze zaak de verspreiding, via een internetwebsite, van “firmware” door Sitecom waarin GPL-software geïntegreerd was die ontwikkeld was door Netfilter. Daarbij werd echter niet gewezen op de aanwezigheid van GPL-code in het product, noch werd gewezen op de GPL-licentie, noch was de broncode van de software beschikbaar. De rechtbank legde het verbod op, onder verbeurte van een dwangsom, om de software nog te verspreiden en/of te verveelvoudigen zonder kennisgeving van de GPL-voorwaarden of terbeschikkingstelling van de broncode. De grondslag van de beslissing was de overtreding van de rechten die Sitecom als gebruiker toekwamen. In deze zaak werd de GPL erkend als een geldige en afdwingbare licentie, die zich inderdaad uitstrekt tot een afgeleid werk, en werd de theorie van de “herneming” van het auteursrecht ingevolge de ontbinding van de licentie erkend. De sanctie die werd toegepast was dus een verbodssanctie onder verbeurte van een dwangsom, en geen gedwongen uitvoering (maar dit werd ook niet in rechte gevraagd).

5.3.4. Derden-verkrijgers

18.Indien een gebruiker een afgeleid werk verspreidt met miskenning van de GPL, stelt zich de vraag hoe de rechthebbenden tegen derden-verkrijgers van deze software kunnen optreden indien dezen geen kennis genomen hebben van de GPL-voorwaarden. De GPL stelt in § 4, in fine, dat derden die de software verkregen hebben van een licentienemer die de GPL heeft miskend, niet noodzakelijk hun rechten verliezen. Zolang zijzelf in overeenstemming zijn met de GPL, behouden ze de ruime gebruiksrechten. Soms wordt gesteld dat derden zich kunnen beroepen op een bezit te goeder trouw, ook al voldoen ze niet aan de GPL, indien aan hen geen enkele licentie werd medegedeeld bij de overhandiging van de software. Ten onrechte, want deze derden hebben een werk ontvangen waarvan men normalerwijze zou moeten weten of vermoeden dat het auteursrechtelijk beschermd is, en dat men niet kan kopiëren, wijzigen en verspreiden zonder toelating. De auteursrechthebbende kan zich dus beroepen op het auteursrecht om verder gebruik en verdere verspreiding van de inbreukmakende software te verhinderen [95].

5.3.5. Kettingsysteem

19.De GPL-licentienemer heeft het recht om de software verder te verspreiden, al dan niet in een gewijzigde versie, op voorwaarde dat hij het werk onder de GPL verspreidt. Een volgende verkrijger zal de software dus met open broncode en de GPL-licentie ontvangen, en de licentie zal automatisch gelden ingevolge handelingen van de verkrijger die de aanvaarding van de licentie doen vermoeden [96]. De verplichting om verbatim-kopies of een afgeleid werk onder de GPL te verspreiden (§ 1 en 2b GPL), geldt jegens de volgende verkrijger in eerste lijn. Deze verkrijger moet op zijn beurt de GPL eerbiedigen wanneer hij zelf verbatim-versies of gewijzigde versies verspreidt. Bovendien bepaalt § 2c dat bij de verspreiding van een afgeleid werk, de software bij het interactief opstarten een kennisgeving moet weergeven op het scherm (dan wel moet afprinten), waarin de verkrijger wordt medegedeeld dat hij het programma onder de GPL-condities verder kan verspreiden. De licentienemer die de software verder verspreidt, mag geen verdere restricties opleggen t.a.v. de rechten die zijn verkrijger kan uitoefenen krachtens de GPL (§ 6). Zo ontstaat een “downstream”-ketting [97] van software die onder de GPL wordt uitgebracht en, al dan niet gewijzigd of gecombineerd met andere software, steeds opnieuw onder de GPL verder verspreid wordt. Ingevolge het “besmettingseffect” zal de GPL een dominerende werking hebben telkens wanneer de GPL-software in dit downstream proces gemengd wordt met software die onder non-copyleft-licenties is uitgebracht. Deze dominantie wordt bekritiseerd, niet alleen door de tegenstanders van het OSS-fenomeen, maar ook door voorstanders van soepeler OSS-licentievormen.

5.4.

Kwalificatie van de “terbeschikkingstelling”

20.OSS kan op verschillende wijzen worden overgedragen. De softwarebestanden kunnen door gebruikers op een drager als een DVD-rom worden geplaatst en gratis worden overgedragen, of ze kunnen door een commerciële verdeler als Red Hat voor een prijs worden overgemaakt - al dan niet met privatieve software op dezelfde drager. De software kan tevens gedownload worden van een internetwebsite van een onderneming of organisatie, van een Newsgroup of in een peer-to-peer-netwerk. De software kan als standaardsoftware worden overgedragen, dan wel op maat ontwikkeld worden, of nog, deel uitmaken van een omvangrijker pakket van dienstverlening, met ondersteuning en consulting. Ook wordt OSS geïntegreerd in computerhardware, industriële apparaten en gebruiksapparaten, en kan het aldus deel uitmaken van een product dat verkocht, verhuurd of geleased wordt.

21.De contractuele relatie tussen de licentiegever(s) en de gebruiker wijkt zozeer af van de klassieke contractsmodellen, dat dit slechts kan aanzien worden als een onbenoemd, sui generis contract [98]. Toch zoekt men voor bepaalde aspecten van de contractuele relatie een aanknopingspunt bij bestaande contracten. Dit is o.m. van belang voor de beoordeling van het aansprakelijkheidsvraagstuk en de uitgebreide exoneratiebedingen [99]. De pogingen tot kwalificatie van de licentie komen echter kunstmatig over. Kwalificatie als een verkoopcontract is uitgesloten aangezien geen eigendomsoverdracht plaatsvindt (en vaak ook geen prijs wordt betaald) [100]. Voor betaalde ontwikkelingsprestaties kan er sprake zijn van aanneming (huur van diensten), ook in het kader van OSS, doch die kwalificatie slaat niet op de licentie zelf. Commerciële softwarelicenties worden meestal aanzien als huurcontracten indien royalties worden betaald. Het huurcontract veronderstelt de betaling van een huurprijs, maar dit is niet noodzakelijk een prijs uitgedrukt in geld. Verbintenissen in natura kunnen zeker een huurprijs uitmaken. Volgens een ruime opvatting kan zelfs elk voordeel dat de “verhuurder” verwacht van de terbeschikkingstelling van een goed, beschouwd worden als een huurprijs [101]. In die zin zou men kunnen stellen dat OSS altijd wordt uitgebracht en verbeterd in het kader van een systeem dat gericht is op een creatieve wederzijdse kruisbestuiving waarvan elke deelnemer voordelen verkrijgt. Ons inziens kan men een bepaalde licentie, als toetredingscontract, niet verschillend kwalificeren al naargelang de ene licentienemer de software mede ontwikkelt, en de andere alleen gebruik wenst te maken van de software, zonder bijdragen te leveren. De meeste licenties bevatten wederzijdse rechten en plichten, alhoewel deze voor de licentienemer vaak slechts gelden wanneer hij overgaat tot verspreiding van de software. Aangezien het de bedoeling is dat de licenties een coöperatief systeem onderbouwen, en dit een oogmerk is van de meeste deelnemers, gaat het niet om een zuivere vrijgevigheid, om een verbintenis “om niet”, ook al leggen bepaalde licenties geen harde verplichtingen op (zoals non-copyleft-licenties) [102]. Ons inziens gaat het wat ver om de doorsnee OSS-licentie als een werkelijke huur te definiëren, maar de gelijkenis is sterk genoeg om bepaalde regels inzake huur per analogie toepasselijk te maken op het sui generis contract [103]. Volgens anderen zou de afwezigheid van een vergoeding echter leiden tot een contract van bruikleen [104]. Dit lijkt toch erg kunstmatig. OSS wordt niet uit welwillendheid verspreid, maar in het kader van een coöperatief systeem of met het oog op de promotie van andere producten of diensten (of de promotie van individueel talent) [105]. Soms wordt de mogelijke kwalificatie als schenking [106] onderzocht, wat dan zou neerkomen op een schenking met last. In België wordt dit verworpen aangezien geen eigendom wordt overgedragen [107]. In het buitenland werd ook onderzocht of er sprake kan zijn van een vennootschapsvorm tussen de deelnemers van het systeem [108]. Alhoewel het o.i. niet correct is om de OSS-licentie, als modern contract sui generis en geheel afwijkend van klassieke rechtsopvattingen, absoluut in een klassieke rechtsfiguur te duwen [109], kan wel per analogie naar bestaande contracten verwezen worden om bijvoorbeeld de draagwijdte van essentiële verbintenissen en aansprakelijkheden te beoordelen. De regels van het huurcontract lijken dan het meest relevant, gelet op het feit dat de software in het kader van een systeem met wederzijdse “grant-back”-voordelen wordt uitgebracht.

5.5.

De aanvaarding van Open Source-licenties

22.Een licentie als de GPL wordt door een gebruiker niet uitdrukkelijk aanvaard (zoals dat typisch ook het geval is voor commerciële standaardsoftware). De licentie is een toetredingscontract [110] dat te nemen of te laten is. De tekst van de licentie kan op verschillende wijzen aan de gebruiker worden voorgelegd. Men kan de tekst als pop-up laten verschijnen in een openingsscherm bij de installatie van de software; men kan de licentie als tekst opnemen in de broncode zelf, of men kan in de broncode een verwijzing naar de tekst van de licentie opnemen. De verkrijger is echter niet verplicht om de broncode te lezen, en “mainstream”-gebruikers zullen dit ook niet doen. Men kan tekstbestanden als “licence.txt” opnemen tussen de bestanden van een package, bijvoorbeeld op een CD-rom of in een gecomprimeerd downloadbaar bestand. Op internet-downloadsites kan men bovendien een licentie aangeven door middel van een hyperlink. De licentie kan dan ofwel opvallend in een pop-up-venster weergegeven worden, ofwel door een link naar een andere html-page opgeroepen worden. In het ene geval moet de verkrijger “door” de licentie alvorens hij de software kan downloaden, in het andere geval niet. Daarnaast wordt software ook via peer-to-peer-netwerken verspreid - in dat geval is er een reëel risico dat er geen licentie wordt overgemaakt.

23.De GPL vereist in § 1 dat op elke verspreide kopie van de software een copyright notice en warranty disclaimer wordt aangebracht, en dat aan elke verkrijger een kopie van de licentie wordt overgemaakt. Voor de verspeiding van een gewijzigd programma worden explicietere eisen gesteld: indien het programma bij het opstarten interactief werkt, moet men ervoor zorgen dat een gepaste mededeling op het scherm verschijnt of afgeprint wordt. Deze mededeling heeft betrekking op de copyright notice, de afwezigheid van garanties c.q. uitdrukkelijke toekenning van garanties, de bepaling dat gebruikers het programma onder deze voorwaarden mogen her-verspreiden en de wijze waarop gebruikers de tekst van de licentie kunnen lezen (§ 2c). Waar § 1 vereist dat de tekst van de licentie wordt bijgevoegd, zal ingevolge § 2c moeten aangegeven worden, eventueel met een hyperlink of door een print, in welk bestand zich deze kopie bevindt.

Voor de installatie en het zuivere interne gebruik van de software bepaalt de GPL geen specifieke regels. § 5 GPL stelt dat de licentie van toepassing is en automatisch aanvaard is in geval van wijziging of verspreiding van het programma of afgeleide werken. Alleen deze aanvaarding geeft de gebruiker de toelating om het programma te wijzigen of te verspreiden (en hierbij baseert men zich duidelijk op het auteursrecht) [111]. Letterlijk opgevat, zou men hieruit kunnen afleiden dat voor het kopiëren en het loutere gebruik van de GPL-software geen aanvaarding van de licentie vereist is [112]. Nochtans is de aanvaarding ook in dit geval belangrijk, gelet op de exoneratieclausules, die logischerwijze toch bedoeld worden om ook schadegevallen te dekken in het kader van het louter gebruik van de software [113]. Daartegenover staat dan weer dat men volgens § 4 GPL het programma slechts mag kopiëren zoals uitdrukkelijk toegelaten is onder de licentie (wat dan toch de aanvaarding van de licentie veronderstelt...). Het gaat dus eens te meer om inconsistenties in de tekst van de GPL.

24.Commerciële software wordt sinds geruime tijd gedistribueerd onder dergelijke systemen van stilzwijgende aanvaarding, meer bepaald met shrink-wrap en click-wrap licenties die aan de gebruiker gepresenteerd worden bij het openen van de verpakking, dan wel door weergave van de tekst op het scherm bij het installeren van software of het downloaden van software van het internet. De handelingen van de gebruiker, die “doorgaat” na de kennisneming van de licentie, gelden als bewijs van de stilzwijgende aanvaarding. Wie als gebruiker de voordelen van software wil genieten, moet immers ook te goeder trouw de spelregels respecteren. De geldigheid van shrinkwrap- en clickwrap-licenties is in verschillende Europese landen nog niet door rechtspraak bevestigd, maar wordt meestal wel aanvaard [114]. Ten aanzien van browse-wrap-licenties, weergegeven op het internet via hyperlinks, bestaat meer scepticisme [115]. Hoedanook geldt het principe dat algemene voorwaarden voldoende duidelijk gepresenteerd moeten worden, zodat de gebruiker er redelijkerwijze kennis kan van nemen [116]. Een obscure link naar algemene “legal terms” op een website zou onvoldoende duidelijk kunnen zijn. Twijfels kunnen ook bestaan ten aanzien van tekstbestanden die niet duidelijk zijn aangeduid (bv. als “readme.txt”) of die verloren liggen tussen de verschillende bestanden van een CD-rom. In zulke gevallen zal, rekening houdend met de professionaliteit en ervaring van de gebruiker, moeten onderzocht worden of deze kennis had kunnen/moeten nemen van de licentie. Ook is de tekst van de meeste licenties in het Engels opgesteld, zonder officiële vertaling. Sommigen hebben hun twijfels aangaande de afdwingbaarheid van de Engelse tekst, in het bijzonder jegens consumenten [117].

5.6.

Garantie en aansprakelijkheid

5.6.1. Algemeen

25.In de rechtsleer worden de verbintenissen van de OSS-licentiegever vaak geminimaliseerd. Hij zou slechts software ter beschikking stellen die door anderen kan worden bewerkt om tot een verbeterd product te komen, zonder enige verbintenis naar het nuttig gebruik van de software toe [118]. Tot voor enkele jaren was het duidelijk dat de OSS-software gedeeld werd tussen gespecialiseerde ontwikkelaars, die het systeem kenden, de risico's accepteerden en die over de vereiste technische kennis beschikten (of dit meenden) en aldus op een bewuste wijze met deze software omgingen. Naarmate het OSS-fenomeen echter een grotere markt veroverd heeft, gaat dit niet altijd meer op. Meer en meer worden OSS-applicaties naar een groter publiek toe voorgesteld als een volwaardig en goedkoop alternatief voor commerciële applicaties. Ondernemingen bieden korven of stacks aan die voorgesteld worden als totaaloplossingen, gewoonlijk met betaalde aanvullende diensten inzake implementatie en ondersteuning. OSS is nu wereldwijd de preferente software voor publieke administraties (zie supra, randnr. 5) en wordt geïmplementeerd in gigantische organisaties [119] die vaak tot deze keuze overgaan omwille van beperkte budgetten. Dit is een belangrijke verschuiving in de filosofie en het valt te verwachten dat deze evolutie alsmaar zal toenemen. Een uitbreiding naar het grotere publiek toe betekent echter dat de basisfilosofie verwatert. Niet iedereen zal bewust met de software omgaan of heeft de middelen om de broncode te (laten) analyseren, noch om aanpassingen (te laten) uitvoeren. Organisaties die duizenden computers uitrusten met software die ongeschikt blijkt, kunnen een enorme hinder ondervinden door gebruiksonvriendelijkheid, compatibiliteitsproblemen of discontinuïteit van diensten. Fouten in berekeningen of formules die laattijdig aan het licht komen, kunnen tot een enorme schade leiden. OSS evolueerde van een alternatief product naar een gespecialiseerd product, en evolueert nu naar een mainstream-product. Gelet op deze evolutie, is de wijze van voorstelling van een concreet OSS-product aan het publiek cruciaal geworden. Indien men de software ondubbelzinnig voorstelt als een halfafgewerkt product dat behoorlijke bewerkingen veronderstelt vooraleer het efficiënt kan worden ingezet, dan worden de risico's voor mainstream-gebruikers op correcte wijze beperkt. Indien de software echter voornamelijk wordt voorgesteld als een goedkoop alternatief voor bestaande applicaties, dan moet men ook veronderstellen dat mainstream-gebruikers met beperkte budgetten de software om die reden zullen aanschaffen. Dezen zullen geen broncode onderzoeken of laten onderzoeken, noch aanpassen of zelf onderhouden, want dit zou paradoxaal duurder uitkomen dan de aanschaffing van een commercieel product met ondersteuning. Bijgevolg moeten ontwikkelaars en/of distributeurs van OSS die op de mainstream-markt gericht zijn, hun verantwoordelijkheid opnemen. De markt heeft recht op een minimale bescherming tegen software die fouten kan bevatten of onwerkbaar is, ook wanneer die gratis of goedkoop verspreid wordt [120].

26.We kwalificeerden de OSS-licentie naar Belgisch recht als een overeenkomst sui generis, die niet kan aanzien worden als een verbintenis “om niet” [121]. Vaak zijn de bedoelingen van programmeurs en distributeurs commercieel, zoals de promotie van andere commerciële producten of diensten, of de promotie van zichzelf in de arbeidsmarkt. En in het algemeen kan men zeggen dat de software ontwikkeld en verspreid wordt in het kader van een systeem, dat veronderstelt dat verschillende deelnemers aan het systeem bijdragen zullen leveren waarvan eenieder voordelen verwacht. Het verwachte voordeel is voldoende om het “om niet”-karakter terzijde te stellen [122]. Bijgevolg menen we niet dat de verbintenissen van de licentiegever per analogie aan schenking of bruikleen moeten beoordeeld worden [123].

Voor traditionele contracten die betrekking hebben op de levering van een goed, als koop-, huur- en aannemingscontracten in ruime zin, wordt de leveringsplicht omschreven als de verplichting tot terbeschikkingstelling aan de klant van het voorwerp van het contract, zodat deze er gebruik kan van maken rekening houdend met zijn aard en zijn bestemming [124]. Dit betekent niet dat onder alle omstandigheden een goed van hoogstaande kwaliteit dient geleverd te worden. Dit betekent wel dat een goed moet geleverd worden dat beantwoordt aan de legitieme verwachtingen van de verkrijger [125]. Deze legitieme verwachtingen zijn gebaseerd op de gebruiken, de kenmerken van gelijkaardige leveringen, en vooral de wijze waarop de kenmerken van het goed door de aanbieder worden voorgesteld c.q. worden verzwegen. Aldus komt de verplichting tot conforme levering in een eerste stap neer op de schepping van een correct verwachtingspatroon, waaraan men nadien ook beantwoordt, en dus een correcte uitoefening van de informatie- en waarschuwingsplicht in de precontractuele fase [126]. Wij zien niet in waarom dit basisprincipe, dat slechts een toepassing is van de algemene zorgvuldigheidsnorm, niet zou moeten toegepast worden op OSS [127]. Inzake OSS stellen we vast dat de levering van de software zelf gepaard gaat met de kennisneming van de licentie en dus samenvalt met de contractsluiting. Tekortkomingen zullen dus vaak in de precontractuele fase gesitueerd worden. In het kader van informaticacontracten benadrukt een uitgebreide literatuur en rechtspraak het belang van de informatieplicht, zij het dat het dan meestal gaat om de adviesplicht van een professioneel versus een leek in een one-to-one-situatie waarin de partijen kunnen communiceren aangaande hun behoeften [128]. Wat het aanbod van OSS betreft, gaat het eerder om de algemene presentatie van de kenmerken van de software in een afstandelijker one-to-many-relatie. Zeker wanneer het gaat om toetredingscontracten zoals OSS-licenties en er slechts weinig of geen gelegenheid is tot interactie tussen de kandidaat-verkrijger en de aanbieder, en er evenmin post-contractuele ondersteuning geboden wordt, dient men de nodige zorg te besteden aan de algemene informatieplicht, niet zozeer als een gepersonaliseerde bijstandsplicht, doch eerder als een algemene waarschuwingsplicht [129]. Gelet op de risico's impliceert dit o.i. dat minstens op een correcte wijze wordt weergegeven voor welk gebruik de software geschikt is, welke de vereisten zijn op het gebied van aanvullende software, hardware en aanvullende bewerkingen voor een efficiënt gebruik, welke compatibiliteitsproblemen er zijn, en de eventuele problemen aangaande gebruiksvriendelijkheid voor mainstream-gebruikers [130].

27.Naast de gebruiken van de sector, is de wijze waarop de software jegens kandidaat-gebruikers wordt voorgesteld dus cruciaal om de essentiële verbintenissen en de aansprakelijkheid van de licentiegever te beoordelen. Deze voorstelling creëert een bepaald gerechtvaardigd verwachtingspatroon in hoofde van kandidaat-gebruikers en zal aldus bepalen wat een conforme levering vereist.

Indien de licentiegever voldoende uitdrukkelijk de nadruk legt op de risico's en tekortkomingen van zijn halfafgewerkte product en de afwezigheid van elke ondersteuning, zodat onvoldoende ervaren of creatieve gebruikers afgeschrikt worden, dan richt hij zich duidelijk tot professionals die het risico accepteren en mag hij ervan uitgaan dat deze de geschiktheid van de open broncode kunnen beoordelen en kunnen aanpassen. Indien de software dan “as is”, met zijn gebreken, geleverd wordt, dan is dit conform de gewekte verwachtingen. Een vérgaande exoneratie lijkt dan mogelijk omdat er weinig of geen essentiële verbintenissen bestaan en omdat de gebreken ter kennis van de gebruiker worden gebracht [131]. Op grond van de informatieverplichting is dan wel vereist dat de risico's voor de gebruikers voldoende expliciet zijn. Stijlclausules en vage vermeldingen in de licentie zoals “de software wordt gegeven in de staat waarin hij zich bevindt” volstaan daarvoor niet [132]. Overigens speelt ook de leer inzake risicoaanvaarding hier ten volle, o.i. vergelijkbaar met de rechtspraak inzake de verkoop van tweedehandswagens [133]. Dit impliceert dat de software omwille van zijn aard kan beschouwd worden als kwalitatief riskant en grondig te controleren, en dat kleinere tekortkomingen via risicoaanvaarding gedekt zijn. In dit kader heeft het Hof van Cassatie beslist dat ook indien er sprake is van een risicoaanvaarding die inherent is aan een bepaalde zaak (in casu tweedehandswagens), er een grens bestaat tussen tekortkomingen die binnen de zone van risicoaanvaarding vallen, en ernstiger tekortkomingen die de zaak dermate ongeschikt maken dat zij niet kunnen geacht worden gedekt te zijn door een aanvaarding van een zeker risico [134]. Ook dit principe lijkt ons volkomen transponeerbaar naar OSS [135].

Indien de licentiegever daarentegen de software voorstelt als een gebruiksklaar product dat een goedkoop alternatief vormt voor bepaalde commerciële applicaties, dan heeft de licentiegever de essentiële verbintenis om tegemoet te komen aan de legitieme verwachtingen van de gebruiker [136]. Hier spelen de verplichting tot conforme levering en de informatieplicht ten volle. Dat de software in dat geval gratis of goedkoop is, kan in het licht van alle concrete omstandigheden nog steeds een criterium zijn om een mogelijke risicoaanvaarding te beoordelen, maar is op zich geen doorslaggevend criterium voor een minimalisering van de zorgvuldigheidsplicht van de licentiegever. Een gebruiker die te goeder trouw vertrouwde op een product dat hem ernstige schade berokkent, heeft geen boodschap aan het gratis karakter van de software. Bovendien is het postulaat, dat iedereen de open broncode vrij kan (laten) onderzoeken, niet altijd realistisch. Wie in eerste instantie klanten lokt met het gratis of goedkope karakter van zijn oplossingen, kan niet verwachten dat deze gebruikers belangrijke investeringen zullen uitvoeren voor analyse en correctie van de code. De verkrijger heeft uiteraard een eigen zorgvuldigheidsplicht in het kader van de beoordeling van zichtbare gebreken, maar die plicht moet zeker voor de budgettair beperkte markt realistisch worden beoordeeld. Waar het essentieel om gaat, is de creatie van een legitiem verwachtingspatroon in hoofde van de gebruiker en de schade die mogelijk voortvloeit uit een discrepantie tussen deze verwachting en de werkelijkheid. In zulk geval kan er sprake zijn van tekortkomingen in de leveringsplicht en/of precontractuele informatieplicht. Indien de licentiegever zich in deze omstandigheden tracht te exonereren van elke aansprakelijkheid, dan zal de clausule de essentiële verbintenis tot conforme levering uithollen, en is deze ongeldig (zie infra). Kortom, in geval van schade ingevolge gebreken of ongeschiktheid van de software, zal men op basis van de omstandigheden - waaronder de gebruiken en de wijze van voorstelling - kunnen nagaan of de gebruiker zich mocht vergissen aangaande de aanwezigheid van bepaalde kenmerken of kwaliteiten [137]. In elk geval geeft het “gratis” karakter van software op zich geen vrijgeleide om potentieel schadelijke software te verspreiden zonder dat tenminste volledige waarschuwingen zijn aangebracht [138]. De bestaande principes aangaande zorgvuldig handelen, zowel in de precontractuele fase als bij de uitvoering van de levering, en het principe van de conformiteit aan legitieme verwachtingen, geven de flexibele middelen om elke situatie met gezond verstand te beoordelen.

5.6.2. Exoneratie

28.Een typisch kenmerk van OSS-licenties is de uitsluiting van elke garantie (warranty) en elke aansprakelijkheid door middel van een exoneratiebeding (disclaimer). De GPL bijvoorbeeld stelt uitdrukkelijk dat geen garantie wordt gegeven aangezien de software gratis gelicentieerd wordt, voor zover de uitsluiting toelaatbaar is naar het toepasselijk recht (§ 11). In deze bepaling wordt tevens gesteld dat de gebruiker alle risico's aangaande kwaliteit en prestaties (performance) aanvaardt. Een volledige uitsluiting van aansprakelijkheid is opgenomen in § 12; ook deze uitsluiting geldt slechts voor zover het toepasselijk recht geen aansprakelijkheid voorschrijft [139]. Wie de software verspreidt moet de disclaimers kenbaar maken aan de verkrijgers. Uitzonderlijk mag men volgens de GPL wel een persoonlijke garantie geven in ruil voor een vergoeding [140], maar dan nog moet men de disclaimers van zijn voorgangers mededelen.

De disclaimers zijn uiteraard niet alleen typisch voor OSS; ze komen ook in talrijke licenties van privatieve software voor, maar dan gewoonlijk niet als een volledige uitsluiting van garanties en aansprakelijkheid. Naar Belgisch recht zijn exoneratiebedingen voor contractuele verbintenissen in principe toegelaten [141] tenzij zij dermate drastisch zijn opgesteld, dat de verbintenis in feite wordt uitgehold. Van een dergelijke uitholling is sprake wanneer de wezenlijke verbintenissen van de overeenkomst worden aangetast [142]. De volledige uitsluiting van aansprakelijkheid die in vrijwel alle OSS-licenties voorkomt lijkt ons problematisch. De gebruiker van de software vertrouwt op de software, die hij kan gebruiken voor allerlei toepassingen, gaande van eenvoudige hobbies tot inplanting in hoogtechnologische machines of medische producten. Met de volledige exoneratie vermijdt de licentiegever elk financieel risico wanneer hij software op de markt brengt die ernstige gebreken bevat. Deze licentiegever kan net zo goed een kwalitatief betrouwbare onderneming zijn als een student informatica die zich wil bewijzen. Verschillende auteurs aanvaarden het principe van volledige exoneratie omwille van het gratis karakter van het product, of omwille van het feit dat de licentiegever in feite geen essentiële verbintenissen zou dragen [143]. Volgens anderen daarentegen leidt de volledige exoneratie ertoe dat essentiële verbintenissen worden uitgehold, en is deze daarom ongeldig [144].

Ons inziens moet de problematiek genuanceerder beoordeeld worden. Of de licentiegever essentiële verbintenissen op zich heeft genomen, is afhankelijk van de wijze waarop hij de software voorstelt en de gebruiken in de sector. Indien ondubbelzinnig gewezen wordt op de tekortkomingen van de software, die men geeft “as is”, en men zich duidelijk richt tot gespecialiseerde gebruikers (maar dit alles dan expliciet en niet met stijlclausules), lijkt het ons mogelijk om zich vergaand te exonereren van garanties en aansprakelijkheid. Er bestaan dan weinig of geen essentiële verbintenissen waarvoor men zich niet zou kunnen exonereren, tenzij zelfs in zulke gevallen op grond van de gebruiken een harde kern van minimale kwaliteitskenmerken moet aanwezig zijn, in welk geval men een leveringsplicht heeft tot beloop van de minimale kenmerken. Zelfs indien er sprake kan zijn van risicoaanvaarding, te beoordelen in het licht van de omstandigheden, zijn bepaalde tekortkomingen dermate onaanvaardbaar dat zij niet meer tot de zone van het aanvaarde risico behoren [145]. Indien men anderzijds onvoldoende expliciet is aangaande mogelijke tekortkomingen, en men bij de doorsnee gebruiker een gerechtvaardigd verwachtingspatroon heeft gecreëerd aangaande de kenmerken van de software, dan heeft men o.i. een essentiële verplichting tot conforme levering, in overeenstemming met deze verwachting (zie supra). Van deze essentiële verplichting kan men zich niet volledig exonereren, en dit lijkt ons billijk [146]^, [147]. De markt heeft recht op bescherming tegen eventuele schadelijke software, en een minimaal aansprakelijkheidsrisico in hoofde van de aanbieders, wie dat ook mag zijn, lijkt ons in dit licht noodzakelijk. Dat de software gratis is, is niet relevant in het kader van risicobeheersing. Bovendien geldt uiteraard ook de algemene regel dat geen exoneratie mogelijk is voor bedrog of opzettelijke fouten (zoals het opzettelijk inbrengen van virussen of spywarecode in een programma).

Indien een gebruiker zich beroept op de schending van de informatieplicht tijdens de precontractuele fase, stelt zich de vraag of een standaard exoneratieclausule ook geldt voor de precontractuele aansprakelijkheid. Een beding kan zo ruim zijn opgesteld, dat de licentiegever ontslagen wordt van aansprakelijkheid, ongeacht de juridische grondslag. De precontractuele aansprakelijkheid is gebaseerd op de artikelen 1382-1383 B.W. Het beding zal dus geen contractuele verbintenis uithollen, maar een exoneratie betrachten van de algemene zorgvuldigheidsnorm. In principe is dat aanvaardbaar, voor zover de openbare orde niet geraakt wordt. Hoe dan ook, talrijke auteurs stellen dat een leverancier van software zich niet kan exonereren van zijn contractuele c.q. precontractuele informatieplicht, zeker niet volledig kan exonereren [148]. A fortiori zal een exoneratieclausule die slechts aanvaard wordt ná de precontractuele fase, geen precontractuele aansprakelijkheid kunnen uitsluiten. Het zou paradoxaal zijn om te stellen dat een contract, aangegaan mede doordat informatie foutief werd weergegeven, via een exoneratieclausule juist deze tekortkoming in de informatieplicht zou dekken [149]. In het algemeen concluderen wij dat exoneratieclausules die alle garanties en alle aansprakelijkheid voor schade uitsluiten, ongeldig zijn. Toch verdient het aanbeveling om, indien het mogelijk is, specifieke contracten aan te gaan met distributeurs van de software of integrators, die eventueel de software aanraden en/of aanpassen, en daarin bepaalde vrijwaringsclausules op te nemen. Meestal zijn deze dienstverleners bereid om meer aansprakelijkheid op zich te nemen.

29.Een aantal bijzondere omstandigheden kunnen invloed hebben op de aansprakelijkheid van de licentiegever en/of de geldigheid van exoneratiebedingen. Zo kunnen de regels inzake productaansprakelijkheid, en de onmogelijkheid tot exoneratie in dat verband, toepasselijk zijn indien de situatie kadert binnen de toepassingsvoorwaarden van de Europese richtlijn/de corresponderende Belgische wet [150]. OSS kan overigens deel uitmaken van hardware. OSS kan als besturingssysteem voor-geïnstalleerd worden op een computer die aan een klant wordt verkocht, of kan als embedded software deel uitmaken van een industrieel product of een consumentenproduct (zoals onderdelen van auto's, mobiele telefoons, wasmachines,...). In dat geval kan het deel uitmaken van een verkocht, verhuurd of geleased product, en indien er sprake zou zijn van gebreken dan zal de verkoper, verhuurder of lessor van het product aansprakelijk zijn voor het geheel. Daarnaast opperen een aantal commentatoren dat de vergaande aansprakelijkheidsuitsluiting, in zoverre ze tegen een consument wordt ingeroepen, (soms) kan aanzien worden als een onrechtmatig beding in de zin van de artikelen 31 en 32 WHPC [151].

30.De GPL bevat geen uitdrukkelijke uitsluiting van de vrijwaring tegen claims van derden wegens inbreuken op hun intellectuele rechten (tenzij men de algemene uitsluiting van garanties van § 11 breed interpreteert). Vreemd, want vrijwel elke commerciële licentie [152] bevat uitdrukkelijke clausules die (1) de gebruiker een juridische bescherming bieden in gerechtelijke procedures ingesteld door een derde die een inbreuk op zijn intellectuele rechten aanvoert, en (2) de herstelplicht jegens de gebruiker ingevolge het niet verder gebruik van de software minimaliseren, en kanaliseren naar een oplossing die de licentiegever zelf mag kiezen (zoals vervanging van inbreukmakende onderdelen, afkopen van intellectuele rechten). Deze clausules bevatten onrechtstreeks dan tevens een beperking van de aansprakelijkheid van de licentiegever. Voor OSS zou dit een gevoelig punt moeten zijn, aangezien er problemen kunnen ontstaan indien één van de talrijke “contributors” in een project beschermde code van derden in de software zou incorporeren, of wanneer claims zouden ingesteld worden op basis van schending van octrooien. Wie wat doet, is in het bazaarmodel niet altijd duidelijk, maar de broncode is wel transparant, wat betekent dat octrooihouders of auteursrechthebbenden gemakkelijk inbreuken kunnen naspeuren (wat bij privatieve software in object code veel moeilijker is). De gemiddelde ontwikkelaars van OSS beschikken daarenboven niet over de middelen om patent searches uit te voeren teneinde inbreuken te voorkomen [153]. In OSS middens zegt men dat de community eventuele schendingen van auteursrecht of octrooien meestal wel zal merken en het probleem eerder op een praktische manier zal opgelost worden. Binnen de OSS-wereld tracht men risico's te beperken via de Open Source Risk Management organisatie (OSRM), die via een verzekeringachtig systeem belooft bijstand te verlenen in geval van claims. Voor gebruikers die problemen ondervinden, kan zich in elk geval het probleem stellen van de moeilijke identificatie van de auteurs van de software, en bovendien hun insolvabiliteit en afwezigheid van een echte BA-verzekering. Omwille van het commerciële belang van deze risico's, geven een aantal distributeurs en integrators van OSS eigen garanties m.b.t. claims van derden [154].

5.6.3. Afwezigheid van een duidelijk identificeerbare verantwoordelijke

31.Het “kathedraal”-model van softwareontwikkeling mondt typisch uit in een uniforme licentie die gesloten wordt tussen één producent en alle gebruikers van de software. De producent heeft een exclusief auteursrecht en is uitsluitend aansprakelijk voor tekortkomingen en daaruit voortvloeiende schade. Het “bazaar”-model van ontwikkeling daarentegen kan de identificatie van personen die verantwoordelijk zijn voor foutieve of schadelijke code zeer moeilijk maken [155]. De software is het resultaat van de bijdragen, geleverd in een community die niet altijd transparant is. Bovendien is de geleverde software het resultaat van een historisch ontwikkelingsproces dat vaak evenmin transparant is [156]. De identificatie is nochtans belangrijk in geval van schadegevallen, waar vaak vraagtekens zullen rijzen aangaande de solvabiliteit en de verzekering van de betrokkenen. Sommige licenties spelen hierop in en eisen van de auteurs van gewijzigde versies een duidelijke documentatie van de wijzigingen, of de weergave van de namen van de betrokkenen en hun prestaties [157]. De GPL eist alleen dat de wijzigingen t.a.v. een vorige versie duidelijk worden weergegeven, met de datum van de wijziging (§ 2a). De GPL eist niet dat de auteur zijn naam vermeldt, en dergelijke vermeldingen mogen anoniem of onder een pseudoniem gebeuren [158].

Vooral wanneer verschillende programma's geïntegreerd worden aangeboden, kan het moeilijk zijn om een verantwoordelijke voor gebreken aan te duiden, in het bijzonder indien de softwarecomponenten op zichzelf foutloos zijn, doch de interactie fout loopt. Men zal dan moeten nagaan wie verantwoordelijk is voor het concept van deze integratie. In de praktijk kunnen tussenpersonen optreden die de risico's op zich willen nemen, zoals een systemsintegrator die de software gebruikt als een onderdeel van zijn oplossing, of een consultant die de software heeft aanbevolen, een ontwikkelaar die software op maat heeft gemaakt met OSS-componenten, een hardwareleverancier die geïntegreerde OSS aanbiedt, etc. Wanneer een exoneratie bestaat voor de kwaliteit van de software op zich (en geldig wordt geacht), kunnen er nog steeds servicecontracten bestaan op basis waarvan een dienstverlener aansprakelijk is - aldus kan eventueel diens verzekeraar tussenkomen [159].

32.Het concept van gezamenlijke ontwikkeling, hetzij simultaan, hetzij successief, roept vragen op aangaande collectieve auteursrechten of collectieve samenwerkingsverbanden zoals vennootschapsvormen (zie infra). Men kan zich tevens de vraag stellen of de aansprakelijkheid voor tekortkomingen en daaruit voortvloeiende schade als een individuele dan wel als een collectieve of solidaire aansprakelijkheid moet benaderd worden. Deze vraag is opnieuw zeer complex. In het kader van een concreet schadegeval zal ze moeten beoordeeld worden in het licht van het toepasselijk recht [160] en zal rekening moeten gehouden worden met alle relevante omstandigheden (zoals de wijze van ontwikkeling, de formulering van een bepaalde licentie, de individualiseerbaarheid van een bepaalde fout). Voor de GPL zal principieel het uitgangspunt zijn dat de verkrijger gecontracteerd heeft met verschillende licentiegevers, elk voor zijn bijdrage, en dat elke auteur verantwoordelijk is voor zijn individuele bijdrage [161].

5.7.

Auteursrechtelijke vragen

33.De relatie tussen OSS en het auteursrecht is bijzonder ambivalent. OSS zet zich af tegen de beperkende functie van het auteursrecht, maar anderzijds doet het toch een beroep op datzelfde auteursrecht om het concept af te dwingen. Dit blijkt uit § 4 GPL, dat bij inbreuken op de GPL de “automatische” beëindiging van de licentie voorschrijft, zodat het auteursrecht herleeft en een onrechtmatig verder gebruik van de software kan gesanctioneerd worden. De auteur van OSS doet geen afstand van auteursrecht - hij behoudt het als stok achter de deur [162]. Maar het zal geen verwondering wekken dat het auteursrecht soms moeilijk kan toegepast worden op een concept dat zo drastisch afwijkt. Zo wordt gesteld dat de formele vereisten van artikel 3 Auteurswet niet worden nageleefd [163], of dat de (toch wel bizarre) formulering van § 9 GPL strijdig is met het verbod tot licentiëring voor toekomstige exploitatiewijzen [164], of nog, dat de auteur door de toekenning van uitgebreide wijzigingsrechten, afstand doet van zijn morele rechten [165]. Ook is het niet duidelijk hoe de rechten van de verschillende betrokken auteurs moeten worden opgevat. De GPL stelt in § 6: “... each time you redistribute the program, the recipient automatically receives a license from the original licensor...” [166]. De aanvaarding van de licentie wordt dan vermoed door de handelingen van de gebruiker (zie randnrs. 22 e.v.). Er komt dus een rechtstreekse licentie tot stand tussen de verkrijger, de oorspronkelijke auteur en de opeenvolgende auteurs, telkens voor de relevante bijdrage [167]; een voortdurend aangroeiende bundel van licentierechten wordt zo telkens verder “downstream” doorgegeven. Preciezer uitgedrukt, verleent degene die de laatste versie van de software overdraagt aan een verkrijger, een licentie op de intellectuele rechten van zijn eigen bijdrage, terwijl hij de software die hijzelf gekregen heeft, alleen materialiter doorgeeft. De intellectuele rechten op die software worden rechtstreeks door de betrokken auteurs toegekend [168]. Aldus beschouwd, kunnen geen sublicenties gegeven worden [169]. Het principe van de rechtstreekse licentie is belangrijk, omdat in een rechtstreekse contractuele band de aansprakelijkheidsbeperking van de oorspronkelijke auteur en de andere auteurs geldt [170]. Een dergelijke rechtstreekse licentie is perfect geldig - het systeem is niet verschillend van software die door een detaillist wordt geleverd en die een ingesloten licentie bevat die de verkrijger rechtstreeks jegens de licentiegever bindt.

34.Men kan zich de vraag stellen of een OSS-product moet beschouwd worden als een bundeling van individuele bijdragen (waarbij elke auteur individuele licenties verleent voor zijn deel), dan wel als een collectief of onverdeeld werk, waarbij de bijdragen van elkeen opgaan in het geheel. Men kan zich zelfs afvragen of er geen samenwerkingsverband voorligt dat overeenstemt met een vennootschapsvorm [171]. Bij dergelijke kwalificaties mag men niet uit het oog verliezen dat de ontwikkeling van OSS typisch een internationale aangelegenheid is; de verschillende “contributors” zijn gevestigd in verschillende landen, en de software wordt toegepast in verschillende landen. Vennootschapsvormen en collectieve vormen van auteursrecht kunnen sterk van land tot land verschillen. De GPL en talrijke andere licenties bepalen niet welk recht van toepassing is, en het is ook volgens het internationaal privaatrecht niet altijd duidelijk welk recht toepasselijk is op de rechten van (individuele of collectieve) auteurs. Voor de toepassing van IPR richten sommigen zich naar de IPR-regels inzake auteursrecht, anderen richten zich meer op de IPR-regels inzake de licentie (de regels inzake contractenrecht) [172]. Het betreft hier een zeer complexe materie, die op zich reeds het voorwerp van uitgebreide studie kan uitmaken.

Het Belgisch recht kent geen collectief auteursrecht zoals dat in Frankrijk en Nederland bestaat. Bij een collectief werk naar Frans model kunnen de rechten op een werk waaraan talrijke personen in een gezamenlijk overleg hebben bijgedragen, gecentraliseerd toegekend worden aan één persoon, die het initiatief tot het werk neemt, de coördinatie van het werk regelt en het werk onder zijn naam uitbrengt [173]. In landen waar dit begrip gekend is, kan dit toegepast worden op gecoördineerde releases van OSS met een officieel karakter, uitgebracht onder leiding van een persoon of een comité [174]. De rechten op het werk worden dan gecentraliseerd uitgeoefend door de coördinator-auteursrechthebbende. In België komt de figuur van het werk in samenwerkingsverband (oeuvre de collaboration) in aanmerking in geval verschillende auteurs in “gezamenlijk overleg” simultaan samenwerken tot realisatie van een bepaald werk [175]. Het “simultaan” karakter van de bijdragen moet gerelativeerd worden: de bijdragen van de betrokkenen moeten niet gelijktijdig geleverd worden [176], maar wel geleverd worden met het oog op de creatie van één werk. Ook kan een persoon coauteur zijn indien zijn bijdrage kleiner is dan de bijdrage van anderen [177]. Sommige OSS-producten komen hiervoor in aanmerking, indien verschillende ontwikkelaars samenwerken om een release uit te brengen en bijvoorbeeld gezamenlijk naar de oplossing van problemen zoeken [178]. De rechten op het werk worden echter niet gecentraliseerd bij een coördinator. De uitoefening van de rechten verschilt al naargelang er sprake is van een deelbaar auteursrecht - wanneer in het werk een onderscheid kan gemaakt worden tussen de bijdragen van de verschillende auteurs - dan wel een onverdeeld auteursrecht - wanneer dit onderscheid niet kan gemaakt worden [179]. Is het auteursrecht onverdeeld, dan kunnen de coauteurs de uitoefening van hun rechten regelen bij overeenkomst, zo niet moeten ze gezamenlijk optreden en bij onenigheid een rechterlijke uitspraak bekomen (art. 4 Auteurswet). Een coauteur kan niet als Einzelgänger de gemeenschappelijke bijdrage exploiteren. Wel kan elke co-auteur zelf optreden in rechte wegens inbreuk op het auteursrecht (art. 4 Auteurswet). Gaat het daarentegen om een deelbaar auteursrecht, dan kan elke auteur de exploitatierechten uitoefenen voor zijn individuele bijdrage, voor zover dit het gemeenschappelijk werk niet in het gedrang brengt. De auteurs mogen echter niet met een andere persoon samenwerken in het kader van het werk (art. 5 Auteurswet). Deze regels zijn niet altijd zinvol in de context van OSS (vnl. het concurrentieverbod), en afwijkende regelingen zijn toegelaten [180].

De kwalificatie van “werk in samenwerkingsverband” komt niet in aanmerking voor releases van “spin-offs” of “forkings”, of andere situaties waarbij een auteur op eigen initiatief voorafbestaande software heeft aangepast zonder overleg met de voorgaande auteurs. In dat geval is er sprake van een afgeleid werk [181] en bestaan er afzonderlijke rechten op het voorafbestaande werk en het afgeleid werk. Dit strookt met de filosofie van de GPL, volgens dewelke elke auteur die een bijdrage geleverd heeft, een licentie verleent voor zijn bijdrage (zie randnrs. 33-34). Elke kwalificatie is echter afhankelijk van de concrete omstandigheden. In de praktijk is het belangrijk dat terzake klaarheid kan gebracht worden, zodat duidelijk is wie, in een internationale context, als rechthebbende kan optreden tegen inbreuken op een individueel, onverdeeld of collectief auteursrecht [182]. Als een praktische oplossing stelt de FSF voor dat auteurs hun rechten overdragen aan FSF-Europe, dat gecentraliseerd kan optreden [183].

Besluit

35.Het gebruik van OSS houdt risico's in voor gebruikers. Men heeft geen echt zicht op de kwaliteit, noch op de risico's van inbreuken op auteursrechten van derden, terwijl de aanbieders elke aansprakelijkheid voor deze risico's trachten te ontlopen. Gelet op de evolutie inzake OSS, dat meer en meer een mainstream-product voor de algemene markt wordt, waarbij men niet altijd mag uitgaan van het postulaat dat de broncode voor alle gebruikers leesbaar is, menen we dat de markt nood heeft aan een minimale bescherming, afhankelijk van de wijze waarop de software naar het publiek wordt voorgesteld. Naast dit probleem, stelt zich voor copyleft-licenties als de GPL, de vraag naar de draagwijdte van de “besmetting” van privatieve software met het GPL-statuut. De gebruikersmarkt kan dit risico onmogelijk voor alle situaties correct inschatten. We hebben getracht om een aanvaardbare middenweg te vinden tussen de verschillende belangen, die o.i. juridisch gefundeerd is ingevolge de klemtoon die de GPL zelf legt op het begrip “afgeleid werk”.

In deze bijdrage hebben we dan nog niet gehandeld over de problematiek van softwareoctrooien, die de ontwikkeling van OSS kunnen hinderen, aangezien een octrooi de functionaliteit van software beschermt tegen software met een gelijkaardige functionaliteit, ook al is de code op een andere wijze geschreven. Deze problematiek, die de voorbije jaren zeer turbulent was [184], en die culmineerde in de radicale verwerping van een ontwerprichtlijn door het Europese Parlement in juli 2005, kunnen we niet met voldoende nuances in deze bijdrage bespreken [185]. De basisvragen aangaande het bestaan van softwareoctrooien werden echter niet opgelost met de verwerping van de ontwerprichtlijn. De onzekerheid die jarenlang bestond m.b.t. het beleid van het Europees Octrooibureau bestaat nog steeds, al lijken velen ervan overtuigd dat het begrip “software octrooi” in Europa restrictiever zal worden. In de VS houdt de inflatie aan softwareoctrooigeschillen in elk geval onverminderd aan.

De juridische wereld heeft behoorlijk wat moeite met de “ondraaglijke lichtheid” van een concept van creatieve vrijheid dat een klassiek concept van intellectuele eigendom opzij zet. Dat mag blijken uit talrijke discussies in de juridische literatuur, niet alleen op het niveau van de grote principes, maar ook op het juridisch-technisch niveau, waar men moeite heeft om de draagwijdte van licentiebepalingen af te lijnen en klassieke regels van auteursrecht en verbintenissenrecht met deze filosofie te verzoenen. Het is merkwaardig hoe de aanvankelijke lichtheid van een concept aanleiding geeft tot moeizame juridische analyses (maar dit geldt bv. ook voor de regulering van het internet). Daarbij dient men beducht te zijn voor de verspreiding van mythes, vooral door tegenstanders van het concept.

Voor de gebruikers van OSS moet het vooral duidelijk zijn dat er uiteenlopende vormen van OSS-licenties bestaan, die alle hun specifieke kenmerken hebben, en die niet altijd klaar zijn geformuleerd. Een onderzoek van de licenties met het oog op hun implicaties is een essentiële vereiste vooraleer deze software wordt gebruikt, zeker indien men een verspreiding van deze software beoogt, al dan niet in combinatie met eigen software of hardware. Dit zou een onderdeel moeten vormen van de algemene risk management policy binnen de onderneming van de gebruiker, en bedrijfsjuristen kunnen hier een belangrijke waarschuwende rol vervullen. Het lijkt ook aangewezen dat ondernemingen die deze software intensief gebruiken een audit uitvoeren, en nagaan in welke mate deze software wordt gebruikt voor de creatie en verspreiding van eigen producten, dan wel wordt aangewend voor interne bedrijfskritische toepassingen. Zoals de auteurs van risicoanalyses in het buitenland menen wij dat het gebruik van deze software verantwoord is, mits men er op een bewuste wijze mee omgaat.

[1]	Advocaat te Brussel - Eversheds LLP.
[2]	De term “Open Source Software” wordt vaak gebruikt als een verzamelterm voor verschillende vormen van “vrije software”, die in een “community” wordt ontwikkeld en gelicentieerd wordt met bijzondere kenmerken. De term verwijst naar een bepaalde licentie, en een economisch model dat deze licentie als instrument hanteert voor de handhaving van het model. In meer specifieke zin echter, staat de term tegenover de zogenaamde Free Software van de Free Software Foundation (zie randnrs. 3-4). We hanteren hierna de term in de algemenere betekenis.
[3]	De internetservers draaien grotendeels op Apache, een OSS product. Ook het beheer van domeinnamen is gebaseerd op een OSS product (BIND).
[4]	Zie aangaande de begrippen “broncode” en “object code” en de escrow van broncode, A. Kemna, Source code depot, Zwolle, Tjeenk Willink, 1988; A. Naeyaert, “De broncode en het faillissement van de softwareleverancier”, Jura Falc. 1995-96, 529 e.v.; E. Montero, Les contrats de l'informatique et de l'internet, Larcier, 2005, nrs. 58 e.v.; E. Montero, “La communication des codes source de logiciels”, Ing.-Cons. 1995, afl. 5, 60-76; J. Proot, “Principes inzake escrow”, in S. De Keyser, K. De Vulder en S. Van Camp (eds.), Hoekstenen van informaticacontracten, Praktijkgids VZW, Kluwer, 2004, 168 e.v.
[5]	Reverse engineering of decompilatie zijn alleen toegestaan in de beperkte gevallen van art. 6 en 7 Softwarewet, of met uitdrukkelijke toestemming. De resultaten zijn niet altijd optimaal.
[6]	In het bijzonder de zgn. Softwarewet van 30 juni 1994 houdende omzetting in Belgisch recht van de Europese richtlijn van 14 mei 1991 betreffende de rechtsbescherming van computerprogramma's.
[7]	Art. 6 § 1 en 2 Softwarewet. Zie hierover L. Vael, “Auteursrechtelijke bescherming van software - De wet van 30 juni 1994”, T.G.R. 1995, afl. 2-3, 110 e.v.; T. Tjong Tjin Tai, “De omvang van het gebruiksrecht van programmatuur”, Computerrecht 2001, afl. 2, 60-65; F. Brison en J.-P. Triaille, “La Directive CEE du 14 mai 1991 et la protection juridique des programmes d'ordinateur en droit belge”, J.T. 1991, 787 e.v.; F. De Visscher en B. Michaux, Précis du droit d'auteur, Brussel, Bruylant, 2000, p. 214 e.v.; M. Flamée en F. Brison, “Auteursrecht toegepast op computerprogrammatuur: een grondslagenprobleem”, T.B.B.R. 1992, 469 e.v. Ook mag de gebruiker de werking van een programma bestuderen en uittesten om de beginselen te achterhalen, mits dit gebeurt bij het rechtmatig laden of in beeld brengen, de uitvoering, transmissie, of opslag ervan (art. 6 § 3).
[8]	Hij beschikt niet over zulk recht om bv. zelf securityproblemen op te lossen, wat een belangrijke leemte is.
[9]	Zie de referenties vermeld in voetnoot 4. Dit is een depot van de broncode bij een derde als een garantie voor de gebruiker. Wanneer bepaalde gebeurtenissen zich voordoen, die beperkt omschreven zijn in het escrow contract (zoals typisch het faillissement van de leverancier), zal de derde de broncode overdragen.
[10]	Kh. Charleroi 19 januari 1993, Jur. Liège 1993, 1178. Pro afgifte van broncode in geval van eigendomsoverdracht, A. Naeyaert, o.c., p. 534. In Nederland en Duitsland wordt dit meer aanvaard. Het Bundesgerichtshof oordeelde in een arrest van 16 december 2003 dat de broncode onder bepaalde omstandigheden kan verschuldigd zijn. Zie o.m. T. Hoeren, “Die Pflicht zur Uberlassung des Quellcodes”, ComputerR. (D) 2004, 721 e.v. Let wel: indien een licentiehouder fysiek over de broncode beschikt, vloeit daaruit nog niet automatisch dat deze de rechten heeft om software aan te passen of te verspreiden. Deze rechten moeten uitdrukkelijk toegekend worden.
[11]	Freeware is gratis software, die niet mag gewijzigd worden. Shareware is niet wijzigbaar, noch gratis: na een proefperiode moet betaald worden. Public domain software is software zonder copyright, wat een afstand van auteursrecht veronderstelt maar geen beschikbaarheid van de broncode vereist.
[12]	Lees over de historiek o.m.: www.gnu.org ; N. Newman, “The origins and future of open source software”, Net Action 1999, www.netaction.org/opensrc/future/oss-whole.html ; D. Rosenberg, “Copyleft and the religious wars of the 21st century”, www.stromian.com/copyleft.htm .
[13]	FSF, “What is copyleft?”, http://www.fsf.org/copyleft/copyleft.html .
[14]	Deze bestaat nu als de New BSD-License. Zie de tekst in www.opensource.org/licenses/bsd-license.php .
[15]	De kernel is het meest centrale onderdeel van een besturingssysteem, de kern die alle basisvoorzieningen verzorgt voor de andere delen van het besturingssysteem, en ook de interactie met de hardware verzorgt.
[16]	E. Raymond, “The Cathedral and the Bazaar”, First Monday 1998, www.firstmonday.org/issues/issue 3_3/raymond/index.html .
[17]	De ontwikkelingsprojecten van een “officiële” versie van OSS worden gewoonlijk centraal beheerd en verbeteringen worden door een comité beoordeeld vooraleer ze in een officiële versie worden opgenomen (zie bv. R. Van Wendel de Joode, H. de Bruijn en M. van Eeten, Protecting the Virtual Commons, Delft, 2002, 1-40). Daarnaast is het wel mogelijk dat via “forking” afgeleide takken van een programma ontstaan, met minder professioneel beheerde projecten en onbekende verantwoordelijken.
[18]	Mozilla Public License (MPL), consulteerbaar op www.mozilla.org . Zie voor een bespreking, G. Spindler (ed.), Rechtsfragen bei Open Source, Köln, Otto Schmidt Verlag, 2004, p. 320 e.v.
[19]	Zo wordt o.m. gesproken over Free Software, Open Source, copylefted software, non-copylefted free software, GPL-converted software, GNU-software, community software, enz.
[20]	Zie www.fsf.org/philosophy/free-sw.html .
[21]	Wel bestaat er een “Open Software License” die de filosofie vertolkt (www.opensource.org/licenses/osl-2.1.php ).
[22]	De Open Source Definition bestaat uit 9 criteria. Aangezien we ons in deze bijdrage voornamelijk richten op de GPL, die meer dan 50% van de open softwaremarkt beheerst, mag het volstaan om te verwijzen naar www.opensource.org voor commentaar op versie 1.9 van deze OSD. Lees over de filosofie van E. Raymond, één van de grondleggers van OSI, D. McGowan, “Legal implications of Open Source Software”, p. 22 e.v., http://papers.ssrn.com/paper.taf?abstract_id=243237 .
[23]	Het ruime OSS-begrip wordt soms ook FOSS (Free and Open Source Software) genoemd.
[24]	De term “free” heeft een dubbele betekenis (zowel “vrij” als “gratis”). Hier moet, volgens Stallman, de term “free” opgevat worden “as in Free Speech, not as in Free Beer”.
[25]	M. Clément-Fontaine, “La licence publique générale GNU”, Mémoire de DEA 1999, p. 23 (http://crao.net/gpl/gpl.pdf ). De GPL-licentie, die niet uitblinkt in consistentie, stelt dat de auteur van een afgeleid werk met geïntegreerde GPL-code, het werk moet licentiëren “at no charge” (§ 2b). Anderzijds mag “een vergoeding” gevraagd worden voor de “fysieke overdracht” van de broncode en/of het geven van garanties (§ 1b). Volgens § 3b mag men aan de verkrijger een schriftelijk aanbod doen om gedurende 3 jaar de broncode over te dragen voor een vergoeding die niet hoger mag zijn dan de kost van de fysieke overdracht. Voor kritiek, L. Rosen, Open source licensing, Prentice Hall, 2004, p. 131-132. Sommigen vragen zich af of er mededingingsrechtelijk onaanvaardbare prijsafspraken opgelegd worden (vgl. C. Heath, “Kartellrecht”, in Spindler (ed.), Rechtsfragen bei Open Source, Otto Schmidt Verlag, 2004, p. 267 e.v.).
[26]	Bv. via dienstverlening op maat, het aanbod van “stacks” als totaaloplossingen, ondersteuning of de verkoop van commerciële software die samen met OSS gedistribueerd wordt, met als voorbeelden de ondernemingen Red Hat Software en Debian.
[27]	In het Actieplan voor 2001 voor het eEuropa initiatief onderstreepte de Europese Commissie het belang van OSS als een best practice voor e-Government. In haar in 2004 verschenen policy onderstreepte het Engelse Office of Government Commerce (OGC) het belang van OSS (Open Source Software trials in government, final report). Zie ook het overzicht dat Unisys Belgium in 2001 opstelde (“Study into the Use of Open Source Software in the Public Sector”, http:/europa.eu.int/idabc/en/document/2623 ). Voor Nederland: B. Knubben, “Van overheid en openheid - keuzevrijheid begint bij transparantie van intellectuele eigendom”, Computerrecht 2004, 237 e.v.
[28]	Zie vooral D. De Roy, “L'irruption du logiciel libre dans le secteur public - À la découverte d'une actualité fort ancienne”, in Montero e.a. (eds.), Les logiciels libres face au droit, Cahiers CRID, Bruylant, 2005, 191-225; J. Jochmans en P. Strickx, Richtlijnen en aanbevelingen voor het gebruik van open standaarden en/of open specificaties bij de federale overheidsbesturen, (http://ksz-bcss.fgov.be/documentation/nl/documentation/ Pers/OpenstandaardenNL_FEDICT.pdf ); D. De Roy, “L'utilisation des logiciels libres par les pouvoirs publics. Réflexions sur quelques propositions récentes”, www.droit-technologie.org .
[29]	Wet van 10 augustus 2005 tot oprichting van het informatiesysteem Phenix, B.S. 1 september 2005. Deze protocollen en formaten kunnen OSS zijn, maar dat is niet noodzakelijk zo. Zie o.m. Stichting ICTU (ed.), Open Standaarden en Open Source Software voor het oprapen, OSOSS, Den Haag, 2005, 7 p. (www.ososs.nl ). Voor een situering van Phenix, zie I. Verougstraete, “Elektronica voor een betere rechtsbedeling”, in Goed procesrecht - Goed procederen, Postuniversitaire Cyclus W. Delva, 2002-2003, 465-515. Zie m.b.t. andere wetgevende voorstellen D. De Roy, o.c., en diens bedenkingen m.b.t. principes van gelijke behandeling in het kader van overheidsopdrachten (hierover ook B. Knubben, o.c., 240; N. Müller en C. Gerlach, “Open Source Software und Vergaberecht”, ComputerR. (D) 2005, 87 e.v.; Stichting ICTU (ed.), Handleiding Open Standaarden en Open Source Software in Nederlandse en Europese Aanbestedingen, 2 delen, Den Haag, OSOSS, 2005 (www.ososs.nl ).
[30]	Zie www.creativecommons.org .
[31]	Deze is nog niet opgelost na de verwerping van een ontwerp-richtlijn in 2005. Zie de verwijzingen in voetnoot 185.
[32]	Het betreft procedures in 2003 ingesteld door het bedrijf SCO dat stelt ingevolge acquisities eigenaar te zijn van Unix-code die in Linux geïncorporeerd zou zijn. Een procedure tegen IBM is nog hangende, een procedure tegen gebruiker DaimlerChrysler werd stopgezet. In de marge van deze zaak zijn nog andere procedures ingesteld. In het algemeen geeft men SCO weinig kans op slagen. Men kan deze zaak opvolgen op www.groklaw.net .
[33]	Zie http://www.gnu.org/licenses/licenses.html #GPL. De GPL, versie 2, dateert reeds van 1991. Geruime tijd wordt gewacht op versie 3, waarvan een eerste ontwerp voor discussie is gepubliceerd in januari 2006 (GPL-licentiegevers zijn echter niet verplicht om nieuwe versies toe te passen). Daarnaast bestaat er een Lesser General Public License (LGPL), die bedoeld is voor de combinatie van open library bestanden met privatieve software (zie hierover randnr. 13).
[34]	Men dient echter voor ogen te houden dat andere, minder vaak gebruikte licenties zoals de BSD- en MPL-families, op een aantal punten sterk kunnen afwijken.
[35]	M. O'Sullivan, “Making copyright ambidextrous: an exposé of copyleft”, JILT 2002, http://elj.warwick.ac.uk/jilt/02-3/osullivan.html , p. 6.
[36]	De FSF verklaart de GPL-licentie via Frequently Asked Questions (FAQs - zie www.gnu.org/licenses/gpl-faq.html ). Deze “verduidelijkingen” hebben o.i. geen bindende kracht t.a.v. licentienemers (zie infra, randnr. 12).
[37]	Zie over de automatische aanvaarding en de bundeling van individuele licenties infra, nrs. 22-24 en 33-34.
[38]	§ 1 GPL. Voor een gewijzigd programma moet ook aangeduid worden hoe de tekst van de licentie kan gelezen worden, bv. de naam van het tekstbestand (license.txt of gelijkaardige) (§ 2).
[39]	In geval van downloads van het internet moet de broncode op dezelfde website downloadbaar zijn.
[40]	Zie bv. J. Epplin, “Using GPL-software in embedded applications”, www.linuxdevices.com/articles/AT9161119242 . Als embedded software kent OSS trouwens groot succes. Onder de GPL kan men in dat geval de broncode ter beschikking stellen via het geschreven aanbod om broncode te overhandigen (§ 3b).
[41]	Dit blijkt duidelijk uit de tekst; zie bv. O. Koglin en A. Metzger, Urheber- und Lizenzrecht im bereich von Open Source Software, p. 9 (http://ig.cs.tu-berlin.de/Think-Ahead.ORG/pdfs/IV-3-KoglinMetzger.pdf ) en A. Engelfriet, “Open Source Software en octrooien: een moeilijke combinatie”, B.I.E. 2003, 205, noot 16.
[42]	Deze regels kunnen wel verschillen voor andere OSS-licenties.
[43]	Het begrip “verspreiding” is controversieel in de GPL-context - een terbeschikkingstelling van de software over een netwerk, als ASP-applicatie, wordt hier niet bedoeld. De specifieke Affero GPL werd opgesteld om deze leemte te dekken (zie bv. Van Wendel de Joode e.a., o.c., 58, en http://www.affero.org/oagpl.html ).
[44]	Deze regel werd nochtans niet nageleefd door de Linux-licentie, die bepaalde excepties bevat.
[45]	Ons inziens is de gebruiker echter niet verplicht om zijn naam te vermelden, zie infra, randnr. 31.
[46]	Onder de volgende randnrs. gaan we dieper in op dit begrip, dat zeer moeilijk ligt in het kader van de GPL.
[47]	Krachtens art. 1 § 1 Auteurswet is het adaptatierecht een onderdeel van het reproductierecht. In art. 5b Softwarewet wordt het adaptatierecht echter naast het reproductierecht van art. 5a geplaatst. Nochtans wordt geoordeeld dat dit geen afwijking is van het principe.
[48]	Het begrip “onteigening” is verwarrend aangezien de auteur van nieuwe code wel degelijk de auteur van deze code is en blijft. Hij is alleen verplicht om een bepaalde modellicentie te gebruiken.
[49]	Bv. K. Koelman, “Terug naar de bron: open source en copyleft”, Informatierecht/AMI 2000, afl. 8, 151, noot 20; Ph. Laurent, Logiciels libres: le droit d'auteur contre le droit d'auteur, 2003, p. 33-34 (http://www.droit-technologie.org/dossiers/logiciels_libres_ph_laurent.pdf ).
[50]	Bv. het schrikbeeld van werknemers van grote softwarehuizen die GPL-code zouden incorporeren, wat zou leiden tot de gedwongen vrijgave van de broncode van belangrijke commerciële programma's. Voorbeeld van Nadan, aangehaald door Ph. Laurent, o.c., p. 33, noot 69. Vgl. ook A. Engelfriet, o.c., 208 (“deze eisen kunnen een risico vormen voor de eigen applicatie”).
[51]	Zie supra, betreffende het begrip “verspreiding” en ASP-applicaties.
[52]	T. Jaeger, “Vererbungsleere - Rechtsfolgen bei der Verletzung der GPL”, Linux-Magazin 2002, afl. 1, www.linux-magazin.de ; C. De Preter en H. Dekeyser, “De totstandkoming en draagwijdte van open source-licenties”, Computerrecht 2004, 218.
[53]	L. Rosen, Open source licensing, Prentice Hall, 2004, p. 106 (“reciprocity”).
[54]	Title 17 United States Code USC, § 101. De wet geeft een aantal voorbeelden van zulk “gebaseerd zijn op”, waaronder de wijziging van een voorafbestaand werk.
[55]	Vgl. A. Berenboom, Le nouveau droit d'auteur, Larcier, 2005, 137 e.v. en 205; F. De Visscher en B. Michaux, Précis du droit d'auteur, Brussel, Bruylant, 2000, nrs. 49 e.v.; F. Brison, “Le titulaire du droit d'auteur”, DAOR 1992, 104.
[56]	De Franse wettelijke definitie spreekt over “l'incorporation d'une oeuvre préexistante sans la collaboration de l'auteur de cette dernière” (art. L. 113-2 lid 2 CPI). Ook de Duitse Bearbeitung is een afhankelijke creatie die wezenlijke kentrekken van een werk overneemt (zie in GPL-context, U. Würmeling en T. Deike, “Open Source Software: eine juristische Risikoanalyse”, ComputerR. (D) 2003, 88; G. Spindler, o.c., p. 112).
[57]	Ph. Laurent, o.c., in Les logiciels libres face au droit, p. 81. Alhoewel het recht van het grondgebied waar de bescherming wordt ingeroepen, toepasselijk is (zie randnr. 34), blijft het ook belangrijk om het Amerikaans recht te beschouwen als de achtergrond van het begrippenapparaat van de GPL.
[58]	Zie o.m. Cass. 25 september 2003, RABG 2004, 205, goedkeurende noot F. Brison.
[59]	Cass. 25 september 2003, o.c. Het arrest handelt niet uitdrukkelijk over het “afgeleid werk”, wel over de inbreukmakende reproductie in het algemeen.
[60]	Toegepast door de meeste Circuit Courts sinds de zaak Computer Associates. Zie D. Ravicher, Software derivative work: a jurisdiction dependent determination, 2002 (community.linux.com); A. Strowel en E. Derclaye, Droit d'auteur et numérique, Bruylant, 2001, p. 193-205. De AFC-test werd ook toegepast in Frankrijk (ook inzake Computer Associates).
[61]	In dezelfde zin stelt § 2b dat de verplichte toepassing van de GPL geldt voor “any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof”.
[62]	Code die gedicteerd wordt door een technische noodzaak, of die men om andere redenen slechts op één wijze kan formuleren, of die eenvoudig een toepassing is van standaardprocédés, beantwoordt niet aan het criterium van oorspronkelijkheid en wordt dus als onbeschermbaar aanzien op grond van de scènes à faire-doctrine of de merger doctrine (zie A. Strowel en E. Derclaye, o.c., p. 196-198).
[63]	U. Würmeling en T. Deike, o.c., p. 88-89; Y. Cool, “Interprétation de la principale licence de logiciel libre: liberté du code et contraintes de l'interprète”, R.D.T.I. 2005, afl. 21, 26 e.v.
[64]	In een interview stelde Stallman: “... When copyright law holds that a certain thing is not a derivative of our work, then our license for that work does not apply to it. (…) We cannot tell the courts to treat a certain kind of work as if it were a derivative, if the courts think it is not.” (www.softpanorama.org/copyright/license_archive/gpl.shtml , onder de topic “Thus spake Stallman”). In de FAQs zelf, stelt de FSF dat de vraag wanneer een afgeleid werk voorligt, een juridische vraag is die door de rechter dient opgelost te worden; de FSF geeft in de FAQs slechts de niet-bindende richtlijnen van haar eigen visie (zie infra, voetnoot 67, voor de referentie naar de FAQs). Het zou trouwens onaanvaardbaar zijn dat de FSF eenzijdig de voorwaarden van de GPL-licentie (een toetredingscontract!) zou kunnen “interpreteren”, wat in feite neerkomt op een eenzijdige wijziging. Overigens: zelfs indien de omschrijving van het afgeleid werk contractueel bindend zou zijn, kan de theorie van rechtsmisbruik toegepast worden (zie randnr. 14).
[65]	Ph. Laurent, o.c., in Les logiciels libres face au droit, o.c., p. 81, nr. 143; C. De Preter en H. Dekeyser, o.c., 218; U. Würmeling en T. Deike, o.c., 89.
[66]	§ 2 lid 2: “These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.” § 2 lid 3 bevat een rechtvaardiging: “Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program”.
[67]	Zie de uitleg die gegeven wordt in de Frequently Asked Questions (FAQs) van FSF (www.gnu.org/licenses/gpl-faq.html ). Vgl. T. Jaeger en O. Metzger, Open Source Software - Rechtliche Rahmenbedingungen der freien Software, München, 2002, p. 42 e.v.; T. Jaeger, in Die GPL kommentiert und erklärt, o.c., p. 64 e.v.; G. Spindler, o.c., p. 111-119; M. Välimäki, The rise of Open Source licensing, Helsinki, 2005, p. 123 e.v.
[68]	“In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License”.
[69]	Aldus kunnen distributeurs of integrators gemengde software of “stacks” verspreiden als totaaloplossingen.
[70]	Een library is een softwarebestand dat gestandaardiseerde codes bevat, voor de uitvoering van ondersteunende functies die een programma kan aanroepen wanneer dit nodig is. Zo kan een taxberekeningsprogramma bv. een beroep doen op libraries van derden waarin de meest voorkomende rekenfuncties reeds zijn opgenomen. Libraries werken enorm tijdbesparend in de ontwikkeling van software en zijn in de praktijk noodzakelijk.
[71]	Dit is de techniek van “statisch linken” waarbij de library met de nieuwe code tot éénzelfde bestand gecompileerd wordt. In dit geval wordt de “besmetting” algemeen aanvaard: bv. Ph. Laurent, in Les logiciels libres face au droit, o.c., p. 81; C. De Preter en H. Dekeyser, o.c., 219; T. Jaeger, o.c., p. 75-76. Zie ook in de VS de zaak MySQL/Progress uit 2002, de eerste bekende GPL-casus, waarin MySQL optrad tegen de overname van haar GPL-code via statisch linken, en de rechter opmerkte dat zij de beste argumenten had. Ingevolge minnelijke regeling kwam het niet tot een vonnis (MySQL AB/Progress Software Corp., 195 F. Supp. 2d 328, 329 (D. Mass.)).
[72]	Bijkomend argument voor de FSF is het feit dat de privatieve code en de GPL-code tijdens de uitvoering van het programma tijdelijk gefusioneerd worden in het werkgeheugen van de computer en dus ook gedurende korte tijd fysisch één geheel zouden vormen. Dit is echter geen argument: de fusie gebeurt door de gebruiker van de programma's, niet door de auteur. Een afgeleid werk veronderstelt de incorporatie van code door de auteur van het werk.
[73]	Lesser GNU Public License (voorheen “Library GNU Public License”). Zie de tekst op www.fsf.org/copyleft/lesser.html . Voor een bespreking, T. Jaeger en C. Schulz, Gutachten zur ausgewählten rechtlichen Aspekten der Open Source Software, 2005, 38-41 (http://opensource.c-lab.de/files/portaldownload/Rechtsgutachten-NOW.pdf ).
[74]	O.m. T. Jaeger, in Die GPL kommentiert und erklärt, o.c., p. 68-69, aanvaardt dit voor bepaalde combinatietechnieken (maar niet voor dynamische libraries); M. Välimäki, The rise of Open Source licensing, Helsinki, Turre Publ., 2005, 123 e.v.; Y. Cool, o.c., R.D.T.I. 2005, afl. 21, 33-34; G. Spindler, o.c., p. 113-114 (nuancerend); J. Epplin, “Using GPL-software in embedded applications”, (www.linuxdevices.com/articles ), p. 3. Vgl. ook K. Dankwardt, “Are non-GPL loadable Linux drivers really not a problem?”, (www.linuxdevices.com/articles ).
[75]	Ph. Laurent, o.c., in Les logiciels libres face au droit, p. 85, nr. 147; S. Dusollier, Ph. Laurent en P. Schmitz, Report on Open Source licensing of software developed by the European Commission, 2004, 21-22 (http://europa.eu.int/idabc/servlets/Doc?id=21197 ); L. Rosen, Open Source licensing, o.c., p. 119 e.v. Onzeker: C. De Preter en H. Dekeyser, o.c., p. 219. In de VS werd dit vereiste van concrete incorporatie ook door hoge rechtspraak bevestigd in de zaak Galoob (US Court Appeals, 9th C., Galoob/Nintendo, 1992, US App. Lexis 11266).
[76]	Dit werd ook bevestigd in de rechtspraak en rechtsleer m.b.t. internet-hyperlinks en framing. Wie op zijn website hyperlinks legt naar elementen van een andere website, incorporeert geen elementen van de andere website in de zin van het auteursrecht, ook al worden deze aldus “virtueel” geïncorporeerd. Het is ook hier de gebruiker van het internet die de combinatie van de gelinkte elementen veroorzaakt, niet de auteur van de hyperlinks. Zie bv. A. Strowel, “Liaisons dangereuses et bonnes relations sur l'internet. À propos des hyperliens”, A&M 1998, afl. 4, 302 en het Duitse Bundesgerichtshof 17 juli 2003, inz. Paperboy, GRUR 2003, 958 e.v.
[77]	U. Würmeling en T. Deike, o.c., 89-90; Y. Cool, o.c., R.D.T.I. 2005, afl. 21, 31-34.
[78]	Dit wordt uitdrukkelijk gesteld in de FAQs en in verklaringen van Stallman (zie voetnoot 64). De FAQs bevatten slechts indicaties overeenkomstig de eigen visie van de FSF op het begrip “afgeleid werk”.
[79]	Dit wordt sterk verdedigd door Y. Cool, “Interprétation de la principale licence de logiciel libre: liberté du code et contraintes de l'interprète”, R.D.T.I. 2005, afl. 21, 25-34. Dit wordt dus door de FSF zelf ontkend. Bovendien is de GPL geen evangelie voor non-copyleft-ontwikkelaars, die sterk gekant zijn tegen het virale combinatie-principe.
[80]	Vgl. voor Duitsland G. Spindler, o.c., 120-121.
[81]	Ook Ph. Laurent meent dat een contractuele uitbreiding rechtsmisbruik kan vormen (o.c., p. 85). Zie i.v.m. misbruik van auteursrecht, A. Berenboom, o.c., nr. 20; F. De Visscher en B. Michaux, o.c., p. 63-64, en in de VS: J. Webb en L. Locke, “Intellectual property misuse: developments in the misuse doctrine”, Harvard J.L.Techn. 1991, 257 e.v., m.b.t. overdreven beperkingen in softwarelicenties.
[82]	In deze zin ook K. Koelman, o.c., 151; Ph. Laurent, “Le droit d'auteur contre le droit d'auteur”, o.c., p. 35; Y. Cool, “Aspects contractuels des licences de logiciels libres: les obligations de la liberté”, in Les logiciels libres face au droit, o.c., 151. Dit werd ook aanvaard door de rechtbank te München in de zaak Netfilter (zie infra).
[83]	In België kan elke belanghebbende (elke “betrokkene”) voor de voorzitter van de rechtbank van eerste aanleg een vordering tot staken instellen op grond van schending van auteursrecht (art. 87 § 1 Auteurswet).
[84]	Zie ook § 4 en 5 GPL. Gelet op de uitdrukkelijke vrijheid van gebruik kan men niet stellen dat het gebruik toch beperkt wordt omdat het veronderstelt dat de software op een computer en in het RAM-geheugen gekopieerd wordt.
[85]	Zie o.m. de referenties supra in voetnoot 50.
[86]	Zie art. 3 Auteurswet. In dezelfde zin T. Jaeger, o.c., in Die GPL kommentiert und erklärt, p. 64, nr. 14.
[87]	S. Stijns, De gerechtelijke en de buitengerechtelijke ontbinding van overeenkomsten, Maklu, 1994, p. 480-481; Cass. 31 mei 1956, Arr. Cass. 1956, 823.
[88]	Y. Cool, o.c., in Les logiciels libres face au droit, o.c., p. 152 en 165.
[89]	“You may modify your copy (…) and distribute these modifications (…) provided that you also meet all of these conditions…” (§ 2 GPL).
[90]	Ook voorgesteld door T. Jaeger, in Die GPL kommentiert und erklärt, o.c., p. 64; T. Jaeger, “Rechtsfolgen bei der Verletzung der GPL”, Linux-Magazin 2002, nr. 1, downloadbaar www.linux-magazin.de/artikel/ausgabe/2002/01/recht/recht.html , p. 4, en toegepast in de zaak Netfilter/Sitecom, hierna besproken onder randnr. 17.
[91]	Zie bv. de rechtspraak volgens dewelke zelfs de klant die de object code van software op maat in eigendom verkrijgt, slechts recht heeft op de corresponderende broncode wanneer dit uitdrukkelijk werd overeengekomen (supra, voetnoot 10). Een tekenend voorbeeld van de tendens, in het kader van mededingingsrecht, is de terughoudendheid van de EU-Commissie t.a.v. een verplichte vrijgave van Windows broncode in de Microsoft-beslissing van 24 maart 2004, aangezien dit niet noodzakelijk werd geacht om interoperabiliteit te bewerkstelligen (§ 1004 van de beslissing).
[92]	Zie over rechtsmisbruik in de keuze tussen gedwongen uitvoering en ontbinding als sanctie van contractuele tekortkomingen, S. Stijns, o.c., p. 390-448. Over misbruik van auteursrecht, supra, voetnoot 81.
[93]	Downloadbaar op www.ifross.de . In deze zaak werden twee vonnissen geveld.
[94]	Inbreuken op de GPL worden blijkbaar gemakkelijk geregeld zonder beroep op de rechter. Ingevolge de impact van de GPL in de sector, overtreden weinig ondernemingen de bepalingen - het gezichtsverlies, de business sancties, en mogelijke aanvallen vanuit de hackerswereld, kunnen zeer effectief zijn. Zie in de VS nog de zaak MySQL/Progress, hoger aangehaald in voetnoot 71, die minnelijk geregeld werd.
[95]	Zie ook K. Koelman, “Brothers in arms: open source en auteursrecht”, Computerrecht 2004, 230 en M. O'Sullivan, “Making copyright ambidextrous: an exposé of copyleft”, JILT 2002, (http://elj.warwick.ac.uk/jilt/02-3/osullivan.html , p. 7). Zie voor een aantal hypothesen van inbreuken en de positie van derden, D. McGowan, o.c., p. 18-19. Het louter intern gebruik blijft echter toegelaten (supra, randnr. 15).
[96]	De aanvaarding bespreken we verder onder randnrs. 22 e.v.
[97]	E. Thole en W. Seinen, “Open source-softwarelicenties: een civielrechtelijke analyse”, Computerrecht 2004, 222.
[98]	P. Lemyre, Les logiciels libres sous l'angle de la responsabilité civile, 2002, www.juriscom.net , p. 28; Ph. Laurent, “Le droit d'auteur contre le droit d'auteur”, o.c., 44; F. Koch, “Urheber- und kartellrechtliche Aspekte der Nutzung von Open Source Software”, ComputerR. (D) 2000, 335; Y. Cool, o.c., p. 149.
[99]	Zie infra, randnrs. 25 e.v.
[100]	M. Clément-Fontaine, La licence publique générale GNU, 1999, p. 15 (http://crao.net/gpl/gpl.pdf ); Y. Cool, o.c., p. 144-147. Dit belet niet dat OSS wel een onderdeel kan uitmaken van een product dat verkocht wordt. Denk bv. aan de voor-installatie van Linux op een verkochte computer, of OSS die als embedded software geïntegreerd wordt in industriële machines of consumentenproducten (zie ook A. Metzger en T. Jaeger, “Open Source Software und deutsches Urheberrecht”, GRUR Int. 1999, 847-848).
[101]	Zie J. Vankerckhove, Les baux en général, Les Novelles, Droit civil, Tome VI, Larcier, 2000, p. 48 (terbeschikkingstelling van onroerend goed, die een toekomstige waardevermeerdering kan opleveren). Zie voor Frankrijk, M. Clément-Fontaine, o.c., p. 16-17 (met verschillende opvattingen). Contra: P. Lemyre, o.c., p. 28; Y. Cool, o.c., p. 147-148. Dezen veronderstellen ten onrechte dat een huurprijs in geld moet bestaan. Wel duiden ze ook de onbepaalde duur van OSS-licenties als problematisch aan (art. 1709 B.W. vereist een bepaalde duur).
[102]	Contra, wat non-copyleft-licenties betreft, T. Jaeger en C. Schulz, Gutachten zu ausgewählten rechtlichen Aspekten…, o.c., p. 56 e.v.
[103]	Zie verder betreffende de leveringsplicht, aansprakelijkheid en exoneratie.
[104]	M. Clément-Fontaine, o.c., p. 16; P. Lemyre, o.c., p. 28. Negatief: Y. Cool, l.c.
[105]	Bovendien kan de uitlener steeds de teruggave van het uitgeleende voorwerp eisen nadat dit gediend heeft voor het gebruik waarvoor het was uitgeleend (art. 1888 B.W.), wat niet strookt met het doel van OSS-licenties.
[106]	Dit wordt ernstig in Duitsland overwogen, o.i. om de ruime exoneratie van aansprakelijkheid te kunnen verantwoorden (zie o.m. G. Spindler, o.c., p. 153 e.v.; A. Metzger, noot onder LG München, ComputerR. (D) 2004, 779; A. Metzger en T. Jaeger, “Open Source Software und deutsches Urheberrecht”, GRUR Int. 1999, 847; F. Koch, o.c., ComputerR. (D) 2000, 335 en 340).
[107]	Y. Cool, o.c., p. 147, noot 366.
[108]	Zie bv. G. Spindler, o.c., p. 158-160.
[109]	In dezelfde zin Ph. Laurent, “Le droit d'auteur contre le droit d'auteur”, o.c., p. 44 en F. Koch, o.c., 335.
[110]	Bv. P. Lemyre, o.c., p. 27.
[111]	Art. 5 GPL stelt: “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 (…) Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it”. Dit systeem van afgeleide aanvaarding werd door de rechtbank te München aanvaard in de zaak Netfilter/Sitecom (hoger aangehaald, onder randnr. 17).
[112]	FSF-adviseur Moglen bevestigde in zijn Affidavit in de zaak Progress/MySQL (randnr. 18 van het Affidavit), dat geen aanvaarding vereist is voor het gebruik, het maken van kopies en zelfs wijziging voor eigen gebruik (http://www.gnu.org/press/mysql-affidavit.pdf ).
[113]	Ph. Laurent, “Le droit d'auteur contre le droit d'auteur”, o.c., p. 45, verwijzend naar Washa. De Franse Cecill-licentie, die op een aantal punten kan beschouwd worden als een verbetering van de GPL, bepaalt in art. 3.1. dat de aanvaarding wordt afgeleid uit het laden van de software, vanuit een fysiek medium of via downloaden.
[114]	Zie Ph. Laurent, o.c., p. 44 e.v.; C. De Preter en H. Dekeyser, o.c., 217; E. Thole en W. Seinen, o.c., 222; P. Blok en T. de Weerd, “Shrink-wrap- en clickwrap-licenties zijn aanvaardbaar”, Computerrecht 2004, 126-127, met kritisch naschrift M. Scheltema en E. Tjong Tjin Tai. In de VS werd de combinatie van een shrinkwrap- en clickwrap-licentie geldig geacht in de bekende zaak ProCD/Zeidenberg, maar er bestaan nog onduidelijkheden (zie bv. D. McGowan, o.c., 50-59).
[115]	Ingevolge een afwijzing van deze licenties in de VS, in de zaak Specht/Netscape, verwerpen verschillende Europese auteurs hun afdwingbaarheid (o.m. C. De Preter en H. Dekeyser, o.c., 217). Ons inziens mag men niet veralgemenen, en moet een mogelijke kennisneming beoordeeld worden naar de omstandigheden en de professionaliteit van de gebruiker (in deze zin, P. Lemyre, o.c., p. 25; M. Clément-Fontaine, o.c., p. 22; Y. Cool, o.c., 172-173; vgl. F. Koch, o.c., 340).
[116]	C. De Preter en H. Dekeyser, o.c., 217.
[117]	Spindler veroorzaakte commotie in Duitsland waar hij de afdwingbaarheid van de GPL om deze reden betwijfelde (G. Spindler, o.c., 67-69). Ondertussen heeft de rechtbank te München in een business-to-business-context de afdwingbaarheid van de Engelstalige GPL erkend (zie supra, randnr. 17). Ons inziens impliceert het gebruik van de software dat de gebruiker geacht moet worden de taal te begrijpen.
[118]	Bv. Ph. Laurent, “Le droit d'auteur contre le droit d'auteur”, o.c., p. 48; Y. Cool, o.c., p. 188.
[119]	Een bekende casus is de implementatie door de stad München op 14.000 pc's; deze implementatie werd een tijdlang opgeschort uit vrees voor de risico's van octrooi-inbreuken. Ook in het kader van het Phenix-project zullen op gigantische schaal implementaties nodig zijn (supra, randnr. 5).
[120]	Geen zinnig mens zal beweren dat gratis uitgedeelde stalen van consumentenproducten of voedingswaren schadelijk mogen zijn omdat ze gratis zijn. Waarom insinueren sommigen dat dan wel voor software?
[121]	Zie randnr. 21.
[122]	Dit heeft inderdaad niets meer te maken met echte figuren ten kosteloze titel zoals schenking of bruikleen. In het kader van huur wordt zelfs gesteld dat de terbeschikkingstelling van een ruimte met het oog op een latere waardevermeerdering, voldoende is om van een huurprijs te spreken (zie supra, voetnoot 101). In feite is OSS gebaseerd op een coöperatie-gedachte die veel weg heeft van een vennootschapsvorm.
[123]	Zo is de uitlener bij bruikleen slechts aansprakelijk voor gebreken die hij kende en waarvoor hij niet gewaarschuwd heeft (art. 1891 B.W.).
[124]	Traditionele definitie, zie bv. Cass. fr. 29 oktober 1968, Bull. civ. 1968, IV, nr. 295, p. 264.
[125]	P. Poullet en Y. Poullet, “Les contrats informatiques, réflexions sur 10 ans de jurisprudence belge et française”, J.T. 1982, 22, nr. 45, verwijzen inzake koop naar een “qualité normalement attendue”, restrictief op te vatten.
[126]	Zie B. Lejeune, “Devoir de conseil et obligation de délivrance du fournisseur en informatique”, R.R.D. 1988, 518. Dit geldt vooral bij een functionele non-conformiteit, wanneer een zaak geen inherente gebreken bevat, doch ongeschikt is voor het bestemde gebruik. Het onderscheid contractueel/precontractueel is in vele van deze casussen kunstmatig. Ook is er overlapping met de wilsgebreken dwaling en bedrog. Zie over de informatieplicht en haar contractuele of precontractuele grondslag o.m. A. De Boeck, Informatierechten en -plichten bij de totstandkoming en uitvoering van overeenkomsten, Intersentia, 2000, 572 p.; W. Wilms, “Het recht op informatie in het verbintenissenrecht - een grondslagenonderzoek”, R.W. 1980-81, 489-520.
[127]	Idem: P. Lemyre, o.c., p. 30; T. Jaeger en C. Schulz, Gutachten zur ausgewählten…, o.c., 66 (geen principieel onderscheid tussen OSS en privatieve software wat betreft beantwoorden aan verwachtingen). Dit wordt zelden besproken in de OSS-literatuur. Interessant is dat zelfs de beperkte aansprakelijkheid van de uitlener bij bruikleen, een echt “om niet”-contract, gegrond is op een waarschuwingsplicht en art. 1382 B.W. (Cass. 29 november 1963, Pas., I, 342). Ook kan (voor handelaars) verwezen worden naar het verbod van misleidende reclame in art. 23 WHPC, dat kan gekoppeld worden aan aquiliaanse aansprakelijkheid.
[128]	Zie bv. A. De Boeck, o.c.; B. Lejeune, o.c.; G. Vandenberghe, Partijenaansprakelijkheid bij softwarecontracten, Kluwer, 1984, 71 e.v.
[129]	Het principe van verhoogde informatieplicht bij toetredingscontracten wordt o.a. verdedigd door A. De Boeck, o.c., p. 212, nr. 486. Het is voor geïnteresseerde OSS-gebruikers soms wel mogelijk om interactief voldoende informatie in te winnen via de bestaande forums op het internet.
[130]	Vgl. P. Lemyre, o.c., p. 30.
[131]	Zie infra. Door de kennisgeving krijgen de gebreken een zichtbaar karakter en worden ze gedekt door de aanvaarding van de software. Toch is het verdedigbaar om te stellen dat zelfs voor halfafgewerkte producten een bepaalde minimumkwaliteit kan verwacht worden. Dit lijkt ons afhankelijk van de gebruiken in de sector.
[132]	Vgl. de algemene stijlclausules in huurcontracten inzake “de staat van het gehuurde goed”, waarvan de juridische waarde dubieus is (zie J. Vankerckhove, o.c., nr. 675).
[133]	Gelijkaardige redeneringen inzake risicoaanvaarding en het redelijke verwachtingspatroon van de contractant werden toegepast op de verkoop van tweedehandswagens (K. Moens, “Wilsgebreken en verborgen gebreken in de verkoop van tweedehandswagens”, in M. Faure en K. Moens (eds.), Een droomwereld voor auto's, IUS, nr. 6, Kluwer rechtswetenschappen, 1983, p. 118-119).
[134]	Cass. 15 september 1978, Arr. Cass. 1978-79, 52.
[135]	Ook halfafgewerkte softwareproducten hebben o.i. minimale kenmerken die niet in de risicozone horen.
[136]	Dit geldt uiteraard des te meer wanneer uitdrukkelijke garanties of adviezen gegeven worden, bv. wanneer de licentiegever de rol van consultant op zich neemt. De aansprakelijkheid lijkt ons dan eerder gebaseerd op een additioneel contract van huur van diensten, en niet de licentie, en de exoneratieclausule van de licentie zal hierop niet van toepassing zijn. Zie over de specifieke consultingrelatie o.m. S. Van Camp, “Consultingcontracten”, in S. De Keyser, K. De Vulder en S. Van Camp (eds.), Hoekstenen van informaticacontracten, Praktijkgids VZW, Kluwer, 2004, 150 e.v.
[137]	De zorgvuldigheid van de gebruiker zelf blijft belangrijk. Dit is zijn zorgvuldigheidsplicht in het kader van de levering. Ook moet er o.i. een analogie blijven met het vereiste van verschoonbaarheid van het wilsgebrek “dwaling”.
[138]	We wensen te benadrukken dat er uiteraard kwalitatief goede OSS bestaat. Het probleem voor veel van deze software is echter dat er wel theoretisch een ondersteuning voor problemen mogelijk is door een hele community, terwijl in werkelijkheid meestal geen georganiseerde ondersteuning geboden wordt, en problemen laattijdig of niet worden opgelost.
[139]	De Franse Cecill-licentie bevat een veel genuanceerder aansprakelijkheidsbeding.
[140]	Zoals gesteld in § 1 GPL; ook volgens § 11 geldt het principe van exoneratie “except when otherwise stated”.
[141]	Zie algemeen S. Stijns, “Contractualisering van sancties in het privaatrecht, inzonderheid bij contractuele wanprestatie”, R.W. 2001-02, 1260 e.v.; B. Dubuisson, in P. Wéry (ed.), Les clauses applicables en cas d'inexécution des obligations contractuelles, die Keure, 2001, 34 e.v. Zie voor een algemene toepassing op software, D. Gobert en E. Montero, “Les obligations de conformité et de garantie des vices cachés en matière informatique: le contrat au secours des incertitudes légales et jurisprudentielles”, Rev. Ubiquité 2002, afl. 11, 9 e.v. Uiteraard moet ook onderzocht worden of de gebruiker de clausule wel degelijk aanvaard heeft, volgens de principes aangehaald onder randnrs. 22 e.v. Zie ook het feit dat het louter gebruik van GPL-code niet door de GPL-licentie beheerst wordt, en dus ook de exoneratieclausules daarvoor niet zouden gelden (randnr. 23).
[142]	S. Stijns, o.c., 1264.
[143]	Ph. Laurent, “Le droit d'auteur contre le droit d'auteur”, o.c., 48-49; Y. Cool, o.c., in Les logiciels libres face au droit, p. 188. Onzeker: E. Thole en W. Seinen, o.c., Computerrecht 2004, 223-225.
[144]	G. Spindler, o.c., p. 166 (“da vertragswesentliche Pflichten abbedungen würden” - zelfs de minimale verplichtingen bij schenking zouden wegbedongen worden).
[145]	Cass. 15 september 1978, Arr. Cass. 1978-79, 52.
[146]	Zie bv. voor informaticacontracten in het algemeen, B. Lejeune, “Devoir de conseil et obligation de délivrance du fournisseur en informatique”, R.R.D. 1988, 519. Hier willen we per analogie verwijzen naar de rechtsleer inzake huurcontracten, die bevestigt dat een gedeeltelijke exoneratie mogelijk is aangaande gebreken of ongeschiktheid van verhuurde goederen, doch geen volledige exoneratie waardoor zelfs een totale ongeschiktheid van het goed niet zou gesanctioneerd worden (M. Fontaine, (noot onder Rb. Brussel 10 juni 1997), J.T. 1998, 11 ; B. Louveaux, Le droit du bail, De Boeck, 1993, 93-95 en 186).
[147]	In dat geval kan wel toepassing gemaakt worden van de “salvatorian clause”, die in vele licenties voorkomt, volgens dewelke een ongeldige clausule uitwerking zal krijgen in die zin dat zij geldig is en zo dicht mogelijk aanleunend bij de ongeldige clausule (vgl. § 11 en 12 GPL, waarin men exonereert “to the extent permitted by applicable law”, resp. “unless required by applicable law”). De vraag is hoe de rechter dan zelf gaat beoordelen waar de grens ligt van een aanvaardbare beperking van aansprakelijkheid, en bv. een minimumbedrag van aansprakelijkheid zal bepalen omdat voor de geldigheid van het beding een realistisch financieel risico vereist is.
[148]	J.-P. Buyle e.a., “Chronique de jurisprudence. L'informatique (1987-1994)”, J.T. 1996, 214; E. de Cannart d'Hamale, “Le devoir de conseil du fournisseur en informatique”, T.B.H. 1989, 578 en 582-583; Brussel 17 februari 1987, Computerrecht 1990/2, 83; Rb. Brussel 2 mei 1988, R.R.D. 1988, 507, noot B. Lejeune, “Devoir de conseil et obligation de délivrance du fournisseur en informatique” (en de noot p. 517). Contra: P. Poullet en Y. Poullet, o.c., J.T. 1982, 25-26. Genuanceerd: A. De Boeck, o.c., p. 475-493. De verschillende standpunten worden meestal ingenomen in het kader van nauwe contractuele relaties tussen een leverancier en een leek, waarbij de informatieplicht centraal staat, doch dit lijkt ons ook transponeerbaar naar de informatieplicht bij het aanbod van OSS, omwille van de risico's.
[149]	Vgl. G. Vandenberghe, “De aansprakelijkheid van de computerconstructeur”, R.W. 1978-79, 86; id., “De computer in het verbintenissenrecht”, T.P.R. 1984, 469, die stelt dat via art. 1382 B.W. de exoneratieclausules kunnen vermeden worden, aangezien deze strikt moeten geïnterpreteerd worden.
[150]	Richtlijn 85/374/EEG Raad van 25 juli 1985 (PB. L. 210, 7 augustus 1985) en de wet van 25 februari 1991 (B.S. 22 maart 1991). Software is een product onder de richtlijn (zie Mededeling EU Commissie 15 november 1988, PB. C. 144, 8 mei 1989, p. 42), alhoewel de Belgische wet alleen toepasselijk is op lichamelijke goederen. Voorwaarde is dan wel dat de programmeur de software met een (indirect) economisch oogmerk produceert, bv. de opbouw van een reputatie die men later kan verzilveren - de “reputational pay-off” (Ph. Laurent, o.c., p. 49-50). Deze drijfveer wordt ruim bevestigd (D. McGowan, o.c., p. 5 en 35-42; P. Lemyre, o.c., p. 17).
[151]	Vgl. Ph. Laurent, o.c., p. 50; Y. Cool, o.c., 188-189; E. Thole en W. Seinen, o.c., 225. Dit lijkt ons onwaarschijnlijk. Er moet dan sprake zijn van een verkoper en een consument en er moet een onevenwicht tussen de partijen zijn, waarbij rekening wordt gehouden met de lage prijs. In deze bijdrage gaan we niet specifiek in op het bijzondere domein van de consumentenkoop. Dit is een uitgebreid domein en (nog) niet erg relevant voor OSS.
[152]	Ook de Cecill-licentie (de “Franse GPL”) bevat zulke bepaling in art. 9.4. Vgl., inzake het huurcontract, de wettelijke vrijwaringsplicht tegen rechtsstoornissen door derden (art. 1726-1727 B.W.), waarvan men zich niet volledig kan exonereren.
[153]	Zie over de octrooiproblematiek verder, de verwijzingen in voetnoot 185. Binnen de OSS-wereld werden recent wel initiatieven opgezet om patent searches te vergemakkelijken.
[154]	Red Hat bv. biedt aan om inbreukmakende Linux-code te vervangen; HP geeft een financiële garantie m.b.t. Linux (www.hp.com/linux ). Een aantal garanties zijn uitdrukkelijk op de SCO-zaak gericht (supra, randnr. 6).
[155]	Lees in het algemeen P. Lemyre, o.c., p. 49 e.v.
[156]	De meeste communities gebruiken wel systemen voor het traceren van wijzigingen aan de code en de auteurs daarvan (al dan niet met pseudoniem), zoals journaals of systemen voor versiecontrole (Concurrent Version System - CVS). Zie Van Wendel de Joode e.a., Protecting the virtual commons, o.c., p. 17-18. Problemen van transparantie zijn groter bij de ontwikkeling van spin-offs (“forks”).
[157]	Soms wordt geëist dat gewijzigde versies onder een andere programmanaam worden verspreid, een eis die nog meer kracht kan bijgezet worden via merken. Een ander, voorzichtiger, systeem eist dat wijzigingen als afzonderlijke bestanden (“patches”) verspreid worden, waarbij de verkrijger de patches zelf zal moeten installeren. Het is dan duidelijker wie verantwoordelijk is voor de oorspronkelijke en voor de gewijzigde versie.
[158]	T. Jaeger en C. Schulz, Gutachten zu ausgewählten rechtlichen Aspekten der Open Source Software, 2005, 31 (http://opensource.c-lab.de/files/portaldownload/Rechtsgutachten-NOW.pdf ). Contra, maar zonder uitleg, E. Visser, “GNU General Public License - all rights reversed?”, Computerrecht 2004, 228. De Franse Cecill-licentie eist wel een naamsvermelding (art. 5.2.). De personen wier naam aldus vermeld wordt, worden vermoed auteur te zijn (art. 6 Auteurswet).
[159]	Een theoretisch voordeel van OSS is dan de transparantie van de broncode en het feit dat men voor ondersteuning niet afhankelijk is van één dienstverlener. Oplossingen kunnen in principe dus door verschillende personen onderzocht worden. De vraag is of dit theoretisch voordeel altijd in de praktijk werkt.
[160]	Zie de referenties in voetnoot 172 aangaande het IPR. In dit kader kunnen ook de toepasselijke regels inzake causaliteit tussen fout en schade (zeer verschillend overigens tussen common law en civil law) belangrijk zijn.
[161]	Zie infra, randnrs. 33 e.v. Lees o.m. P. Lemyre, o.c., p. 58; vgl. E. Thole en W. Seinen, o.c., 224.
[162]	Idem: D. McGowan, o.c., p. 4; M. Clément-Fontaine, o.c., p. 43; E. Visser, o.c., 227.
[163]	Art. 3 vereist een geschrift ten aanzien van de auteur en vereist dat de exploitatiewijzen, de vergoeding van de auteur, de reikwijdte en de duur van de rechten uitdrukkelijk worden bepaald. Zie m.b.t. de GPL, F. De Patoul, “Logiciels libres et droit d'auteur: les droits moraux et les règles contractuelles”, in Les logiciels libres face au droit, o.c., 116 e.v.; Ph. Laurent, “Le droit d'auteur contre le droit d'auteur”, o.c., p. 41-43.
[164]	Art. 3 § 1 laatste lid Auteurswet; vgl. F. De Patoul, o.c., 128-130; Ph. Laurent, o.c., 43; A. Metzger en T. Jaeger, o.c., 845-846. § 9 GPL stelt dat de licentienemer kan kiezen welke versie van de licentie toepasselijk is indien meerdere versies bestaan, en de licentiegever geen specifieke versie heeft aangeduid.
[165]	Lees F. De Patoul, o.c., 110 e.v.; Ph. Laurent, o.c., 38-39; O. Koglin en A. Metzger, Urheber- und Lizenzrecht im Bereich von Open Source Software, o.c., p. 8; M. Clément-Fontaine, o.c., p. 42 e.v. Lees over morele rechten en OSS ook G. Vetter, “The collaborative integrity of Open Source Software”, Utah Law Review 2004, 563-700.
[166]	De Mozilla-licentie stelt in art. 2 dat licenties gegeven worden door de “initial developer” en elke “contributor”.
[167]	Dit wordt aanvaard door o.m. E. Thole en W. Seinen, o.c., 222 en 225; C. De Preter en H. Dekeyser, o.c., 216; D. McGowan, o.c., p. 20; P. Lemyre, o.c., p. 21; Van Wendel de Joode e.a., o.c., p. 20. E. Visser meent dat dit systeem moet verklaard worden met een derdenbeding t.v.v. de oorspronkelijke auteur (o.c., 228). Dit lijkt ons echter niet noodzakelijk. Wel kan het voor de derden-verkrijgers voordelig zijn om hun rechten op te vatten als een derdenbeding; ze kunnen de GPL-bepalingen dan rechtstreeks inroepen tegen een aanbieder die de GPL niet respecteert (aldus Y. Cool, o.c., p. 155-159; contra: F. Koch, o.c., 335, volgens wie (naar Duits recht) de derden onvoldoende identificeerbaar zijn). Ons inziens is het twijfelachtig om de bepalingen van de GPL als een derdenbeding te interpreteren.
[168]	Y. Cool, o.c., p. 160.
[169]	Ph. Laurent, “Le droit d'auteur contre le droit d'auteur”, o.c., p. 29, doch later genuanceerd in Ph. Laurent, o.c. in Les logiciels libres face au droit, p. 56-57, en noot 146. Sommigen spreken nochtans voortdurend over sublicenties in de GPL-context (bv. E. Visser, o.c., 228). Uit § 4 GPL blijkt dan weer impliciet dat sublicenties zouden kunnen - opnieuw een voorbeeld van verwarrende terminologie. Vgl. L. Rosen, o.c., p. 127-128.
[170]	Bovendien is de geldigheid van een sublicentie afhankelijk van de geldigheid van de hoofdlicentie, wat problematisch is (Y. Cool, o.c., 160-161). Ook daarom is het principe van rechtstreekse licenties verkieslijker.
[171]	Zie supra, randnr. 21.
[172]	Gewoonlijk wordt het recht toegepast van het land waar de bescherming wordt ingeroepen (art. 93-94 WIPR - maar dit is een sterke vereenvoudiging). In EU-verband wordt voor contractuele kwesties het Verdrag van Rome van 1980 toegepast - voor intellectuele rechten worden wijzigingen verwacht in het komende “Rome II”. Zie algemeen A. Cruquenaire, “La loi applicable au droit d'auteur: état de la question et perspectives”, A&M 2000, 218 e.v.; F. De Visscher en B. Michaux, o.c., nrs. 699-806; H. Haouideg, “Les logiciels libres et le droit international privé”, in Les logiciels libres face au droit, o.c., 227-262; G. Spindler, o.c., p. 134-149.
[173]	Zie over het Franse oeuvre collective o.m. F. Brison, “Le titulaire du droit d'auteur”, DAOR 1992, 104; M. Clément-Fontaine, o.c., p. 10-11 en 19-20. Voor Nederland: K. Koelman, “Brothers in arms: open source en auteursrecht”, Computerrecht 2004, 231.
[174]	Aldus o.m. K. Koelman, l.c. Eerder contra: M. Clément-Fontaine, o.c., p. 13, nr. 20.
[175]	Art. 4 en 5 Auteurswet. Over het werk in samenwerkingsverband: A. Berenboom, o.c., nrs. 111 e.v.; F. Brison, o.c., 104 e.v.; F. De Visscher en B. Michaux, o.c., nrs. 42 e.v. Toegepast op OSS: Ph. Laurent, “Logiciels libres et droit d'auteur: naissance, titularité et exercice des droits patrimoniaux”, in Les logiciels libres face au droit, o.c., 32-39 en 47-57. Het type-voorbeeld is het audio-visuele werk waaraan scenaristen, regisseurs, acteurs, muziekcomponisten medewerken, of een song die uit muziek en tekst bestaat.
[176]	Zie F. Brison, o.c., p. 104-105; A. Berenboom, o.c., p. 197.
[177]	Cass. 22 mei 1980, Ing.-Cons. 1981, 354, noot M. Demeur; F. Brison en B. Michaux, “De nieuwe auteurswet”, R.W. 1995-96, 522.
[178]	Idem: Ph. Laurent, “Le droit d'auteur contre le droit d'auteur”, o.c., p. 24 (in het bijzonder t.a.v. de eerste release van een programma).
[179]	Zie voornamelijk F. Brison, o.c., p. 106 e.v.
[180]	Art. 4 en 5 Auteurswet zijn van suppletief recht. Zie o.m. E. Laevens, “Onderlinge contractuele vrijheid van coauteurs met betrekking tot hun gemeenschappelijk werk, vroeger en nu”, I.R. D.I. 1996, 19 e.v.
[181]	In dezelfde zin o.m. Ph. Laurent, o.c., in Les logiciels libres face au droit, 47-57. Zie aangaande dit begrip supra, randnrs. 11 e.v.
[182]	K. Koelman, “Brothers in arms…”, o.c., 231-232. In België kan elke betrokkene de vordering tot staking instellen (art. 87 § 1 Auteurswet).
[183]	Zie http://www.gnu.org/licenses/why-assign.html . Tevens wordt gevraagd dat indien de programmeur een werknemer van een softwarehuis is, diens werkgever een afstand van claims op het auteursrecht ondertekent.
[184]	De voorstellen van het Europees Parlement, de Commissie en de Raad stonden diametraal tegenover elkaar.
[185]	Zie o.m. K. Koelman, “Octrooi op software”, I&I 2003-6, 20-27; F. Petillion, “Patentability of software: status questionis”, I.R. D.I. 2004, 201 e.v.; E. Valgaeren, “Open source-code en octrooien - van copyleft naar patentleft”, Computerrecht 2004, 234 e.v.; A. Meijboom, “Pleidooi voor een evenwichtiger benadering van octrooien door de OS-gemeenschap”, Computerrecht 2004, 214.

Open Source Software: de ondraaglijke lichtheid van een concept, R.D.C.-T.B.H., 2006/5, p. 487-510

Rechercher Actualités

Filtrer