Kwaliteit en software: een goede zaak 1

Transcriptie

1 Kwaliteit en software: een goede zaak 1 Software is inmiddels vrijwel een gebruiksgoed geworden. Dit roept ook vragen op over kwaliteitscriteria die juridisch aan software kunnen worden gesteld. Al vele jaren wordt echter geworsteld met het toekennen van een plaats aan software in ons verbintenissenrecht. Software is digitaal en bestaat uit bits en bytes. Veel belangrijke juridische begrippen, zoals de koopovereenkomst, zijn echter gekoppeld aan de stoffelijkheid van goederen. In 2011 heeft de Europese Unie door de vaststelling van de Richtlijn consumentenrechten[2] een belangrijke stap gezet in de richting van het aanvaarden van software als een consumentengoed. Dit betekent volgens de auteur dat standaardsoftware die op een drager wordt geleverd onder de kaders van het kooprecht moet vallen. Voor standaardprogrammatuur die zonder drager wordt geleverd moet dat kader zo veel mogelijk worden toegepast. Het wettelijk kooprecht heeft de grootste impact op transacties met consumenten. In de zakelijke praktijk wordt via standaardcontracten vaak een specifieke invulling aan de overeenkomst gegeven. De overeenkomst tot ontwikkeling van software vraagt weer om een ander perspectief. Dit artikel beoogt een bijdrage te leveren aan een gestructureerde visie op softwaregebreken in het verbintenissenrecht. 1 Het (dis)functioneren van software Er zijn vele redenen waarom software niet de beoogde werking heeft. De oorzaken hiervan schuilen in technische gebreken in de software zelf, gebrekkige samenwerking tussen verschillende softwarepakketten, programmeerfouten en/of miscommunicatie tijdens de softwareontwikkelingsfase. In het laatste geval werkt de software misschien wel, maar doet de software niet wat de opdrachtgever ervan verwachtte. Het gevolg kan zijn dat de softwareontwikkeling niet wordt voltooid of dat de software niet in gebruik wordt genomen. Wanneer meerdere softwarepakketten op zichzelf wel werken, maar niet in samenhang met elkaar, kan het mankement door gebrekkige interfaces tussen die software worden veroorzaakt. Programmatuur kan tevens te snel verouderen omdat de leverancier daarvan geen nieuwe versies of programma s beschikbaar stelt. Bij het beoordelen van de kwaliteit van software is er daarom een contextueel aspect aan de orde. Zo zijn het tijdvak waarin de software werd vervaardigd en de toenmalig beschikbare technieken tevens relevant. Ook de voorziene toepassing van de software is van belang: het belang van de ongestoorde werking van software voor ruimtevaart of medische toepassingen is evident en kan bijvoorbeeld door middel van certificatie worden gewaarborgd.[3] In veel zakelijke ICT-contracten is het van belang vast te stellen op welk tijdstip het disfunctioneren van de software aan de orde komt. Wordt dit vastgesteld tijdens de fase voorafgaand aan de aflevering of acceptatie van de software, dan kan het gebrek eventueel tot afkeuring en/of contractsbeëindiging leiden. Is de software eenmaal geleverd[4] of geaccepteerd, dan is er meestal sprake van een beperkte garantietermijn en worden gebreken afgehandeld via een zogenoemd onderhoudscontract. Softwaregebreken vertonen mijns inziens een zeker patroon. Daarom onderscheid ik ten behoeve van dit artikel drie soorten softwaregebreken:[5] 1 Auteur: Mr. W.F.R. Rinzema, Computerrecht 2012/40

2 a. technische gebreken, dat wil zeggen het niet of niet goed functioneren van software zonder dat aan het gebrek een gebruikershandeling ten grondslag ligt. Een voorbeeld hiervan is het vastlopen van de computer door een softwarefout, rekenfouten of de aanwezigheid van een virus. b. functionele gebreken: de software functioneert technisch wel, maar doet functioneel niet wat de gebruiker daarvan verwachtte. De uitkomsten van het systeem zijn voor de gebruiker bijvoorbeeld niet bruikbaar (genoeg) c.q. voldoen niet aan wettelijke vereisten. c. belevingsgebreken: de software functioneert technisch en functioneel goed maar de gebruiker had daar andere verwachtingen van. Deze belevingsgebreken zijn soms terug te voeren op interpretatieverschillen ten aanzien van de overeengekomen specificaties. Een afnemer kan de software bijvoorbeeld niet gebruiksvriendelijk vinden. De beleving kan ook de uitleg van het afgesloten contract betreffen, bijvoorbeeld als de leverancier de werkende software niet verder door ontwikkelt. Tussen de technische gebreken enerzijds en de belevingsgebreken anderzijds neemt de rol van de gebruiker en de beoogde toepassing van de software dus toe. Uiteraard kan in de praktijk ook een combinatie van dergelijke gebreken aan de orde zijn. Een technische fout kan bestaan uit slechte architectuur die aan de software ten grondslag ligt. Hierdoor kunnen weer andersoortige gebreken opdoemen, zoals beperkte onderhoudsmogelijkheden van de software. Ook kunnen gebreken in de loop der tijd van categorie muteren, omdat goed functionerende software bijvoorbeeld door wijziging van onderliggende of aanpalende softwarepakketten, zoals databasemanagementpakketten, ineens niet meer goed functioneert. 2 Wat is software eigenlijk? Een gevaar bij het beoordelen van gebreken in computerprogrammatuur[6] is dat software als een generiek begrip wordt gezien. Weliswaar bestaat alle programmatuur uiteindelijk uit bits and bytes en verzamelingen rekenregels, dit neemt echter niet weg dat software waarvan de kwaliteit juridisch moet worden beoordeeld verschillende modaliteiten en toepassingen kan hebben. Een eerste indeling betreft de taak van het computerprogramma. Struik e.a onderscheiden systeemprogrammatuur, functieprogrammatuur en applicatie- of toepassingsprogrammatuur.[7] Het samenstel van programma s dat zich richt op de uitvoering van taken en functies op het gebied van de interne huishouding van een gegevensverwerkende machine noemen zij systeemprogrammatuur. Een voorbeeld hiervan is Windows 7. Functieprogramma s dienen er volgens hen voor om gegevens of bestanden op eenvoudige wijze aan de computer in behandeling te geven of om routinewerkzaamheden te ondersteunen. Een voorbeeld hiervan is WinZip. Toepassingsprogrammatuur, zoals Word, stelt de eindgebruiker in staat bepaalde gebruikstaken op de computer of een apparaat uit te voeren. Databasemanagementsystemen, zoals het open source pakket MySQL, worden volgens Struik e.a door sommigen als een vierde categorie gezien. Deze programma s worden benut voor onder meer gebruik en beheer van grote gegevensverzamelingen.[8] In alle categorieën kunnen zich technische, functionele en belevingsgebreken voordoen. Belevingsgebreken zullen echter sneller spelen bij toepassingsprogrammatuur en databasemanagementsystemen.

3 Een tweede onderscheid kan worden gemaakt tussen bron- en objectcodes van software, ook wel als source- en objectcodes aangeduid. Hoewel er volgens Struik e.a geen sprake is van een eenduidige definitie van de term broncode wordt doorgaans gedoeld op de versie van de software waarin wijzigingen in de programmatuur het beste kunnen worden aangebracht. Doorgaans is dit de hogere programmeertaal of assembleertaal van de software.[9] Bij standaardsoftware wordt deze broncode door de maker of aanbieder van de software meestal niet aan de gebruiker vrijgegeven. Bij zogenaamde open source software wordt de gebruiker al dan niet op ideologische gronden wel toegang tot de broncode verschaft.[10] De objectcode is de vertaalde versie van de software die nodig is om de computer de beoogde functies te laten verrichten. Belevingsgebreken zullen bij broncodes niet snel aan de orde zijn, anders dan dat de afnemer wellicht had verwacht dat hij ook toegang tot de broncode zou verkrijgen.[11] Technische of functionele gebreken kunnen zich in de broncode wel voordoen. Een derde onderscheid betreft standaardprogrammatuur versus maatwerkprogrammatuur. Standaardprogrammatuur is volgens Struik e.a. bestemd voor meerdere afnemers en dus min of meer breed inzetbaar. Dit betekent vrijwel automatisch dat de rechten op de software bij de leverancier of een derde blijven berusten en de afnemer slechts een gebruiksrecht of licentie verkrijgt. Standaardprogrammatuur kan uit modules bestaan, welke apart kunnen worden verworven en geïntegreerd kunnen werken. Alle modules samen worden dan als suite aangeduid. Maatwerkprogrammatuur is ontworpen en ontwikkeld met het oog op de specifieke wensen van een bepaalde opdrachtgever.[12] In de praktijk is dit onderscheid niet zo eenvoudig te maken, omdat leveranciers op verzoek vaak maatwerkaanpassingen in de standaardprogrammatuur aanbrengen.[13] Alle door mij onderscheiden soorten gebreken kunnen zich bij deze typering van software voordoen. Ten onrechte wordt er in de praktijk vaak van uitgegaan dat de intellectuele-eigendomsrechten op maatwerk aan de opdrachtgever toekomen, omdat hij immers de kosten van ontwikkeling heeft betaald. Overdracht van rechten dient echter uitdrukkelijk te zijn overeengekomen.[14] In zowel de zogenoemde Softwarerichtlijn[15] als de Nederlandse implementatiewetgeving is er vanwege de steeds voortschrijdende techniek bewust van afgezien de term computerprogrammatuur te definiëren. Deze keuze is mijns inziens geheel juist en ook bij het beoordelen van de kwaliteit van software is dit uitgangspunt relevant. Ten slotte: software is in feite een geestesproduct dat echter niet kan bestaan zonder de gegevensdrager, waarop deze is vastgelegd. Deze drager was van oorsprong een diskette, cd-rom, dvdrom of tape. Tegenwoordig wordt software ook vaak op een centrale locatie ( server ) opgeslagen en zonder tussenkomst van andere gegevensdragers verspreid, namelijk via het internet. Men kan dan de software downloaden en vervolgens met behulp van een key de software activeren. Er komt dan bij de aflevering van de software geen drager meer aan te pas. Bij sommige contractsoorten, zoals SaaS ( Software as a Service ) downloadt de gebruiker de software zelfs in het geheel niet.[16] 3 Contracten en werkwijzen 3.1 Contractvormen In het algemeen zal aan het gebruik van software een overeenkomst ten grondslag (moeten) liggen. Software wordt immers beschermd door de bepalingen van de Auteurswet en gebruik van software kan leiden tot inbreuk op de rechten van de auteursrechthebbende. Daarom is het noodzakelijk een blik te werpen op de contractvormen die bij het gebruik en de verwerving van computerprogrammatuur het

4 meeste worden gehanteerd. De inhoud van deze contracten is van belang voor het doen van uitspraken over softwarekwaliteit. Een van de meest voorkomende contractvormen is de zogenoemde licentie- of gebruiksrechtovereenkomst. Op basis van een dergelijk contract wordt door of namens de auteursrechthebbende op de software aan een of meerdere partijen het recht toegekend de software binnen randvoorwaarden te gebruiken. De licentieovereenkomst kan worden gecombineerd met onderhoud op de desbetreffende programmatuur. Gebruiksrecht en onderhoud worden in de praktijk vaak als aparte producten aangeboden. In veel softwarelicentieovereenkomsten wordt het afsluiten van softwareonderhoudscontracten echter als voorwaarde gesteld voor het hebben van aanspraak op foutherstel. Een andere relevante contractvorm is de dienstverleningsovereenkomst. Deze overeenkomst kan betrekking hebben op de ontwikkeling van maatwerkprogrammatuur dan wel het leveren van diensten, die met behulp van computerprogrammatuur worden uitgevoerd. Als voorbeeld van het laatste werd al de SaaS-overeenkomst genoemd, maar ook outsourcing [17] is een vorm van ICT gedreven dienstverlening. Softwareontwikkeling is een proces dat doorgaans door middel van een gefaseerde aanpak wordt uitgevoerd, bijvoorbeeld door het (allereerst) opstellen van specificaties en het vervolgens vertalen daarvan in programmacode.[18] Als onderdeel van een dienstverleningsovereenkomst kunnen ook licentievoorwaarden worden gehanteerd, die wanneer er geen (volledige) overdracht van intellectuele-eigendomsrechten plaatsvindt betrekking hebben op het gebruik van de programmatuur. Contracten die betrekking hebben op de beschikbaarstelling of overdracht van stoffelijke voorwerpen, waarvan software een onderdeel vormt, mogen uiteraard niet worden vergeten. Wanneer de software embedded is, dat wil zeggen niet meer van het voorwerp kan worden gescheiden bijvoorbeeld omdat hij via een chip met het voorwerp is verbonden, is er veelal geen sprake van toepasselijke licentievoorwaarden. Computer en software vormen als het ware één zaak.[19] Voorbeelden hiervan zijn de magnetron of een lift, die niet meer zonder software zou kunnen worden gebruikt en via klassieke contractmodellen, zoals de koop- of huurovereenkomst, wordt geleverd. Daarnaast zijn er ook apparaten die niet zonder software werken en waarbij de software wel een zelfstandige rol speelt, zoals cadcamsystemen of de spelletjescomputer. Wanneer samen met het voorwerp van koop licentievoorwaarden ter hand worden gesteld, rijst de vraag of die voorwaarden wel van toepassing zijn. De koper neemt veelal pas kennis van die voorwaarden, nadat hij het product al heeft aangeschaft. Dit kan zich voordoen wanneer hij het product in gebruik neemt en daarbij op algemene voorwaarden wordt geattendeerd, dan wel de verpakking van het betreffende product opent en daarin een set algemene voorwaarden aantreft.[20] Ten slotte moet melding gemaakt worden van de aparte softwareonderhoudsovereenkomst. Dat onderhoud heeft per leverancier een andere inhoud. Het onderhoudscontract biedt echter meestal een drietal kerndiensten, namelijk: (i) preventief en correctief onderhoud gericht op het voorkomen en herstellen van fouten,[21] (ii) beschikbaarstelling van verbeterde versies[22] van de software, waarin kleine aanpassingen hebben plaatsgevonden en (iii) beschikbaarstelling van ingrijpende gewijzigde versies van de software, waardoor de werking van de software wordt gewijzigd of uitgebreid. Laatstgenoemde software wordt vaak als nieuwe versie aangeduid en wordt soms op basis van een nieuw contract geleverd. Vergaande onderhoudsverplichtingen kosten de afnemer meer geld (denk aan 24 uur per dag, 365 dagen in het jaar service en korte fouthersteltijden). Meestal wordt een

5 onderhoudscontract afgesloten voor een bepaalde duur, bijvoorbeeld voor drie jaar of wordt een kortdurend contract afgesloten dat steeds stilzwijgend wordt verlengd. Soms worden onderhoudscontracten serviceovereenkomsten genoemd, maar dergelijke overeenkomsten kunnen ook naast onderhoudscontracten bestaan bijvoorbeeld om de afnemer consultancydiensten te verstrekken. 3.2 In de praktijk veel gehanteerde standaardvoorwaarden In de rechtspraktijk komen vele contracttypes voor, die de beschikbaarstelling van software regelen. Dit kunnen aparte (licentie)overeenkomsten zijn, dan wel overeenkomsten die licentieparagrafen bevatten. Het kunnen standaardcontracten zijn van fabrikanten of leveranciers[23], maar ook van brancheorganisaties als ICT~Office of van de rijksoverheid[24] dan wel andere organisaties. Het gaat hier overigens om contracten bestemd voor zakelijke transacties. De ICT~Officevoorwaarden werden opgesteld door deze branchevereniging met 550 leden in de desbetreffende sector.[25] Deze algemene voorwaarden bevatten spelregels die bruikbaar zijn in het contact tussen leveranciers en opdrachtgevers bij het leveren van producten en het verrichten van diensten op het gebied van IT, telecommunicatie, internet en kantoortechnologie.[26] De overheidsvoorwaarden ARBIT zijn algemene voorwaarden die de verhouding tussen het Rijk als opdrachtverlener en ICT-bedrijven als leverancier vastleggen.[27]. De ARBIT zijn vooral bedoeld voor modale IT-aankopen door de overheid en niet zozeer voor grote en bijzondere IT-projecten. De voorwaarden bestaan uit 84 artikelen en dienen in samenhang met eveneens door het Rijk ontwikkelde modelcontracten te worden gebruikt. 3.3 Contracteren en leveren in de praktijk Bij standaardsoftware zijn de eigenschappen daarvan meestal in zogenoemde documentatie beschreven. Deze documentatie is over het algemeen bestemd voor gebruikers van de software, maar soms wordt ook documentatie meegeleverd die de technische werking van de programmatuur beschrijft. De kwaliteit van dergelijke documentatie wordt in de praktijk vaak als beperkt of zelfs gebrekkig ervaren. Er zijn zelfs situaties waarin documentatie in het geheel ontbreekt. Bij maatwerksoftware wordt de beoogde werking van de software in specificatiedocumenten beschreven, zoals functionele specificaties. Ook dit is niet altijd het geval en kan ook afhankelijk zijn van de gehanteerde software ontwikkelmethode. Gebruikelijk bij softwarecontracten is dat de software allereerst wordt afgeleverd en vervolgens al dan niet door de leverancier op hardware wordt geïnstalleerd. Pas na deze installatie kan de afnemer de werking van de software vaststellen en beoordelen. Hiertoe is doorgaans een acceptatietest in het leven geroepen, die overeenkomstig een acceptatietestprocedure wordt uitgevoerd. Deze acceptatie is een niet-onbelangrijk fenomeen: het gevolg van acceptatie is namelijk dat de afnemer op basis van bepaalde spelregels (de acceptatietestprocedure) tot aanvaarding van de software overgaat. Wanneer er sprake is van levering van standaardsoftware, bestaat de acceptatie soms uit een stilzwijgende aanvaarding, namelijk wanneer er niet binnen een zekere periode klachten zijn ingediend. Bij grotere softwarepakketten of -projecten kan de acceptatie ook delen van de software betreffen en wordt de procedure afgesloten met eindacceptatie. Ten aanzien van de door mij onderkende soorten gebreken geldt dat de bovengenoemde werkwijze in ieder geval bestemd is om discussies over belevingsgebreken in te kaderen. De afnemer aanvaardt de software immers op enig moment. In beperktere mate geldt dit ook voor functionele gebreken, dat wil zeggen in ieder geval voor zover dergelijke gebreken redelijkerwijs kenbaar waren. Dit betekent ook

6 dat de gemaakte afspraken over de omvang en diepgang van de acceptatietest relevant zijn. Voor technische gebreken geldt dat de waarde van de testprocedures vooral ligt in het tijdig onderkennen van dergelijke problemen en het voorkomen van schade bij ingebruikneming. Ook nadien kunnen zich echter technische problemen voordoen waarbij de vraag rijst of deze alleen verholpen behoeven te worden wanneer de opdrachtgever een onderhoudscontract heeft afgesloten. 4 Het juridisch kader Hiervoor is uiteengezet dat het begrip software ook contextueel moet worden geïnterpreteerd, omdat software altijd in een bepaalde situatie wordt gebruikt of beschikbaar wordt gesteld. Om het juridisch kader voor de beoordeling van de kwaliteit van de software te kunnen vaststellen dient gekeken te worden naar de aard van de relatie die tussen de betrokken partijen wordt aangegaan. 4.1Het auteursrecht De maker (auteur) van een computerprogramma heeft het exclusieve recht te beschikken over de software. Die bevoegdheid zegt echter niets over de kwaliteit van de software c.q. de vraag welke waarborgen de maker moet bieden als hij gebruiksrechten verstrekt. Die vraag is namelijk van verbintenisrechtelijke aard. Wel relevant is dat in art. 45j Aw (Auteurswet) een correctierecht is opgenomen voor de rechtmatige verkrijger van een exemplaar van het computerprogramma.[28] Dit wetsartikel is van belang wanneer de maker niet bereid of gehouden is fouten te herstellen. Het recht op foutcorrectie op grond van art. 45j Aw is beperkt. Volgens de wetsgeschiedenis wordt onder fouten verstaan: ( ) onvolkomenheden in het programma die moeten worden verbeterd teneinde het computerprogramma voor het daarmee beoogde doel te kunnen gebruiken. [29] Ook het opsporen en lokaliseren van fouten wordt hieronder begrepen. Uitbreidingen en verbeteringen van de software vallen niet onder het artikel. Technische en functionele gebreken vallen mijns inziens onder dit recht op foutherstel. Voor belevingsgebreken is dat afhankelijk van het geval. Dat de wettekst verwijst naar het beoogd gebruik is overigens een mooie entree voor een Haviltexdiscussie[30] over dit onderwerp. Kan foutherstel van software ook door een derde worden verricht, nu de gebruiker veelal niet in staat zal zijn zelf de softwarefout te herstellen? De Hoge Raad heeft zich in 1996 over de inschakeling van derden bij foutcorrectie uitgesproken.[31] Hij vond het oordeel van het hof dat inschakeling van derden geoorloofd achtte, geen blijk geven van een onjuiste rechtsopvatting. Ondanks het feit dat het geschil stamde uit de tijd vóór de inwerkingtreding van art. 45 Aw, zou de uitspraak volgens annotator Verkade thans niet anders zijn geweest. Art. 45j Aw staat er niet aan in de weg dat een softwareleverancier in de overeenkomst met de gebruiker nadere condities omtrent het correctierecht opneemt. De ratio van de wettelijke correctiebevoegdheid is volgens Struik e.a namelijk dat de operationele werking van het computerprogramma wordt gewaarborgd, zonder dat de gebruiker daarbij afhankelijk is van medewerking van de auteursrechthebbende softwareleverancier. Daarom kunnen sancties worden gesteld indien de gebruiker aanpassingen in de programmatuur aanbrengt of laat aanbrengen door een derde, die geen foutcorrectie inhouden. Volgens hen lijkt de ratio van dit artikel zich er niet tegen te verzetten dat de softwareleverancier third party maintenance (TPM) of andere vormen van het inschakelen van derden voor het verbeteren van fouten in zijn overeenkomst met de gebruiker verhindert of beperkt. Een TPM-verbod sluit in het algemeen namelijk niet uit dat een gebruiker zelf fouten verbetert. Pas indien een gebruiker zelf onvoldoende kundig is om zelf de fouten te corrigeren, zou inschakeling van derden mogelijk zijn, omdat het TPM-verbod anders de gebruiker te afhankelijk

7 maakt van de leverancier. Dat laatste zou volgens hen in strijd zijn met het dwingend recht van art. 45j Aw.[32] Naar mijn mening is de gedachte dat de afnemer software zelf zou kunnen onderhouden alleen reëel wanneer het gaat om problemen waarvoor de afnemer over voldoende informatie beschikt. Om fouten in software te kunnen herstellen, is het namelijk doorgaans nodig toegang te hebben tot de broncode daarvan. Ook kunnen andere informatie en technische documentatie nodig zijn om een fout in software te corrigeren. De Auteurswet verplicht echter niet tot verstrekking van de voor het verbeteren van de fouten benodigde materialen. Omdat de Auteurswet geen regels omtrent het verstrekken van de broncode stelt, is de gebruiker in het geval dat hij aanspraak wil maken op de broncode voor foutenherstel aangewezen op de inhoud van de overeenkomst met de softwareleverancier en de uitleg die daaraan in het concrete geval moet worden gegeven. 4.2 Het kooprecht Wat is kopen van software Koop is de overeenkomst waarbij de een zich verbindt een zaak te geven en de ander om daarvoor een prijs in geld te betalen, zo bepaalt art. 7:1 BW. Terwijl de koopovereenkomst gericht is op eigendomsoverdracht, hebben huur en pacht geen verdere strekking dan om de wederpartij het genot van de zaak te verschaffen, meent Hijma.[33] Hieruit blijkt dat de eigendomsoverdracht met aanverwante verplichtingen, zoals de verplichting tot aflevering, een van de kernaspecten van een koopovereenkomst is. Daardoor onderscheidt de koopovereenkomst zich van overeenkomsten waarin de dienstverlening centraal staat en software hetzij het resultaat is van de uitvoering van de overeenkomst, dan wel software een hulpmiddel is voor het verrichten van een dienst. Waar de verwerving van standaardsoftware in de volksmond vaak wordt aangeduid als het kopen van software, is het de vraag of en op welke wijze de bepalingen van titel 1 Boek 7 BW van toepassing zijn. Ik zal die titel hierna eenvoudshalve als het kooprecht aanduiden. Het feit dat in de volksmond gesproken wordt over het kopen van software is overigens wel begrijpelijk. Veel software heeft zich namelijk ontwikkeld tot een product dat men in een (web)winkel verwacht aan te treffen en als commerciële waar verwerft. De koopbeleving wordt verstrekt door de veronderstelde standaardwerking van die software. Dat kan een tekstverwerkingspakket zijn, een ingewikkelder boekhoudpakket of simpelweg een spelletje voor gebruik op een computer. Ook de wijze van marketing van en het adverteren voor standaardsoftware is met andere producten vergelijkbaar. Rechtstreekse toepassing van het wettelijk kooprecht is gezien het bepaalde in art. 7:1 BW alleen mogelijk indien er sprake is van een zaak. Volgens art. 3:2 BW zijn zaken de voor menselijke beheersing vatbare stoffelijke objecten, zodat de vraag rijst of software aan die definitie voldoet. Een tweede mogelijkheid om het wettelijk kooprecht te hanteren is te vinden in art. 7:47 BW, dat stelt dat een koop ook op een vermogensrecht betrekking kan hebben. In dat geval zijn de bepalingen van de vorige afdelingen van toepassing voor zover dit in overeenstemming is met de aard van het recht, aldus het wetsartikel. Software zelf is vooral een verzameling data, die zonder drager niet kan bestaan. Om die data te kunnen kopen, dient een kopie van de data te worden gemaakt, welke door middel van een drager of een datacommunicatieverbinding aan de afnemer wordt verstrekt. Anders dan bij energie gaat de data niet door gebruik verloren. De termen zaak en eigendomsoverdracht zijn in dit geval dus

8 ongelukkig. Het is doorgaans bovendien niet de bedoeling dat de rechten op de software overgaan. Meestal verkrijgt de afnemer van de software slechts een gebruiksrecht/licentie.[34] Over de vraag of software een stoffelijk voorwerp is zijn de meningen al geruime tijd verdeeld.[35] De discussie betreft de vraag of data zelfstandig voorwerp van eigendom kunnen zijn dan wel dat daarvoor koppeling van die data aan een fysieke drager noodzakelijk is. De wetgever is op dit punt onduidelijk, al wijst Westerdijk[36] op art. 7:46d BW dat in lid 4 bepaalt dat een specifiek ontbindingsrecht niet bestaat voor de koop op afstand van computerprogrammatuur, waarvan de verzegeling is verbroken, waaruit à contrario kan blijken dat de artikelen wel van toepassing zijn op de koop van software. Bij de implementatie van de bepalingen betreffende overeenkomsten op afstand en consumentenkoop op afstand, noemde de minister deze materie casuïstisch en afhankelijk van de omstandigheden van het geval, maar volgens hem is er wel sprake van een roerende lichamelijke zaak als de software op een drager wordt geleverd.[37] Voorstanders zoals Kleve[38] gebruiken natuurwetenschappelijke redeneringen en maken vergelijkingen met elektriciteit. Ook wordt door schrijvers, zoals Steur, verwezen naar het feit dat software vaak op een drager moet worden vastgelegd om te kunnen bestaan, waardoor aan de vereiste stoffelijkheidseis wordt voldaan.[39] Volgens De Koning e.a. kan een object stoffelijk zijn wanneer het onderworpen kan worden aan de macht van de mens, het een zekere waarde heeft en het volgens verkeersopvattingen als een geïndividualiseerd geheel kan worden beschouwd.[40] Tegenstanders, zoals Franken[41] vinden software geen zaak omdat een zaak uniek is, terwijl gegevens meervoudig beschikbaar kunnen worden gesteld. De verwijzing naar de drager die de software stoffelijk maakt, achten zij niet relevant omdat software steeds vaker zonder drager, namelijk via het internet, wordt verspreid. Thole pleit ervoor om software, waarvoor slechts een licentie wordt verleend als huur aan te duiden.[42] Veel aandacht kreeg het arrest van Hof Amsterdam d.d. 1 juni 2010 dat drager en data duidelijk scheidde. De kernoverweging van het hof luidde als volgt: Het programma ImageSan is vastgelegd op een of meerdere gegevensdragers. Het in deze zaak gestelde gebrek houdt geen verband met deze gegevensdragers, maar met de werking van de daarop vastgelegde software. Anders dan een gegevensdrager, kan die software op zichzelf niet worden aangemerkt als een voor menselijke beheersing vatbaar stoffelijk object en is dan ook geen zaak in de zin van artikel 3:2 BW. Niettemin leidt het feit dat ImageSan standaardsoftware is, die als een pakket kan worden aangeschaft (hier voor ruim ) en waarmee het recht op het vrije en duurzame gebruik van de software wordt verkregen met de omstandigheid dat het in deze zaak gaat om de kwaliteit van die software en niet om de auteursrechtelijke dimensie daarvan, het hof tot het oordeel dat, op grond van het bepaalde in artikel 7:47 BW, titel 7.1 van toepassing moet worden geacht. [43] 4.3 Software geleverd op een drager Op 25 oktober 2011 werd de nieuwe EG-Richtlijn consumentenrechten van kracht, welke binnen twee jaar in nationale wetgeving dient te zijn geïmplementeerd. Een belangrijke wijziging die de definitieve versie hiervan bevat ten opzichte van de eerdere versie uit 2008, is de toevoeging van het begrip digitale inhoud. Hieronder worden volgens overweging 19 verstaan: ( ) gegevens die in digitale vorm geproduceerd en geleverd worden, zoals computerprogramma s, toepassingen, spellen, muziek, video s en teksten, ongeacht of de toegang tot deze gegevens wordt verkregen via downloaden of streaming, vanaf een materiële drager of langs een andere weg. Als digitale inhoud wordt geleverd op een materiële drager, zoals een cd of dvd, dient deze beschouwd te worden als roerende lichamelijke

9 zaak[44] in de zin van deze Richtlijn en is het volledige regime van de Richtlijn van toepassing. Overeenkomsten betreffende digitale inhoud, die niet op een materiële drager wordt geleverd, worden voor de toepassing van deze Richtlijn niet aangemerkt als verkoop- of dienstenovereenkomst. Vervolgens bepaalt overweging 19: Naast de algemene informatieverplichtingen dient de handelaar de consument op de hoogte te stellen van de functionaliteit en de relevante interoperabiliteit van digitale inhoud. Het begrip functionaliteit dient te verwijzen naar de manieren waarop digitale inhoud kan worden aangewend, bijvoorbeeld voor het in kaart brengen van consumentengedrag; het dient ook te verwijzen naar de aan- of afwezigheid van technische beperkingen, zoals bescherming via Digital Rights Management of regiocodering. Het begrip relevante interoperabiliteit is bedoeld om de informatie te beschrijven over de standaardhardware en -software waarmee de digitale inhoud compatibel is, bijvoorbeeld het besturingssysteem, de vereiste versie en bepaalde hardwarekenmerken. De geciteerde overwegingen worden in de Richtlijn op overeenkomstige wijze uitgewerkt en dienen uiteindelijk ook in nationale wetgeving te belanden. Met de implementatie van deze Richtlijn is het dus van belang een knoop door te hakken[45] en eens en voorgoed vast te stellen dat het kooprecht in ieder geval van toepassing is op software die op een drager wordt geleverd. Die conclusie is door deze Richtlijn onvermijdelijk, sluit aan bij de hiervoor geciteerde opmerking van de minister en maakt een einde aan een langdurig debat waarin geen echt harde argumenten kunnen worden gebruikt. De conclusie is bovendien een niet-onlogische keuze en biedt het voordeel dat bij verwerving van softwarelicenties het kooprecht handvatten biedt. Dit draagt bij aan de volwassenheid die software inmiddels wel heeft bereikt dan wel in een concreet geval bereikt zou moeten hebben. Inherent aan deze redenering is dat de drager en niet de data voorwerp van de eigendomsoverdracht zijn. Het kooprecht is mijns inziens zowel van toepassing als er feitelijk gebruiksrechten worden geleverd als in het geval waarin ook wordt afgesproken dat de rechten op de software worden overgedragen. Die laatste situatie is overigens uitzonderlijk en zal door uitleg van de door partijen gemaakte afspraken moeten worden vastgesteld.[46] 4.4 Software geleverd zonder drager De genoemde Richtlijn sluit uit dat er bij software die niet op een drager wordt geleverd sprake is van een verkoop- of dienstenovereenkomst, al kent de Richtlijn ook voor die situaties vrijwel vergelijkbare beschermende bepalingen. Dit onderscheid sluit op zichzelf niet aan bij de stand der techniek, waarbij steeds meer software via het internet wordt beschikbaar gesteld. Evenmin doet het recht aan de realiteit. De vraag drager of niet is voor de licentieverstrekker slechts een logistieke aangelegenheid of een marketingkwestie. Ik vrees echter dat Nederland weinig ruimte heeft om deze indeling te negeren en dat voor zover mogelijk dit in het kader van eenduidige wetgeving ook niet verstandig zou zijn. Een duidelijke keuze is in dit verband maatschappelijk beter dan een voortslepend intellectueel debat. In de lijn van het arrest van Hof Amsterdam in de Imagesanzaak ben ik van mening dat er wel aanleiding is voor toepassing van de schakelbepaling van art. 7:47 BW bij levering van software zonder drager.[47] Deze conclusie zal gezien het vorenstaande niet verbazen. Toepassing van het kooprecht acht ik grotendeels in overeenstemming met de aard van het recht. Deze insteek sluit ook aan op het voorstel voor een Verordening betreffende een gemeenschappelijk Europees kooprecht dat de Commissie op 11 oktober 2011 heeft ingediend.[48] Hierin wordt digitale inhoud weliswaar gescheiden van het begrip goederen [49], maar vindt inhoudelijk gelijkstelling plaats.[50]

10 Bepalingen van het kooprecht die zien of de stoffelijkheid van het verkochte, zoals betreffende de eigendomsoverdracht en de risico-overgang bij aflevering, zijn naar hun aard bij dragerloze aflevering uiteraard niet van toepassing. 4.5 Gevolgen van toepasselijkheid van het kooprecht Indien de koopbepalingen volledig van toepassing zijn, heeft dit vooral voor de consumentenkoop vergaande consequenties. Krachtens art. 7:6 lid 1 BW kan in dat geval slechts beperkt van de kooptitel worden afgeweken. Een in dit verband belangrijk onderdeel van het kooprecht is de zogenoemde conformiteitseis vastgelegd in art. 7:17 lid 1 BW.[51] Dit wetsartikel geeft aan dat de afgeleverde zaak aan de overeenkomst moet beantwoorden. Volgens lid 2 beantwoordt een zaak niet aan de overeenkomst indien zij, mede gelet op de aard van de zaak en de mededelingen die de verkoper over de zaak heeft gedaan, niet de eigenschappen bezit die de koper op grond van de overeenkomst mocht verwachten. De wet geeft vervolgens een niet-limitatieve opsomming van wanneer dat het geval is, zoals (lid 2): wanneer de zaak niet de eigenschappen bezit die voor een normaal gebruik daarvan nodig zijn en waarvan koper de aanwezigheid niet behoefde te betwijfelen, alsmede de eigenschappen mist die nodig zijn voor een bijzonder gebruik dat bij de overeenkomst is voorzien. Lid 4 noemt als voorbeeld dat indien een monster of model is getoond of verstrekt de zaak hiermee moet overeenstemmen. Bij de aanschaf van software zal vooral de eis van lid 2 een rol spelen. In het geval dat een demo of een proefexemplaar van de software is verstrekt, is ook lid 4 van belang. Een weliswaar oud, maar toch mooi voorbeeld van toepassing van de conformiteitsleer is te vinden in het vonnis van Rechtbank s-gravenhage in de zaak Wolfsbergen c.a./exact[52] waarin de rechtbank vanuit dit kader ingaat op verweren over inherente gebrekkigheid van (nieuwe) standaardsoftware en de normale functionaliteit die de afnemer mag verwachten. De vastgestelde tekortkoming leidt vervolgens tot de ontbinding van zowel de licentie- als de onderhoudsovereenkomst. Voor de toepassing van art. 7:17 BW zijn tevens de aard van de zaak en de mededelingen van de verkoper over de zaak van belang. Het gaat er niet alleen om wat de koper daadwerkelijk heeft verwacht, maar ook wat hij heeft mogen verwachten omtrent de eigenschappen van de gekochte zaak. Alle omstandigheden van het geval zijn hierbij van belang. Onder eigenschappen kunnen volgens Hijma alle kwalitatieve discrepanties tussen koopcontract en zaak vallen.[53] Deze insteek biedt ook ruimte voor maatschappelijke ontwikkelingen rond softwarekwaliteit, zoals de vraag of een afnemer van software mag verwachten dat deze van voldoende beveiliging is voorzien zodat hackers niet lichtvaardig kunnen binnendringen. Ook de beoogde toepassing van de software kan een rol spelen. Dergelijke vragen rond verwachtingspatronen zullen als gevolg van de ontwikkeling van de techniek en de toepassing van software steeds blijven bestaan en kunnen dus met behulp van deze flexibele norm worden beantwoord. Soms rust er een onderzoeksplicht op de koper, waardoor bij niet-naleving daarvan geen beroep op non-conformiteit kan worden gedaan. De Hoge Raad heeft zich op 25 maart 2011 nader uitgesproken over de reikwijdte van deze onderzoeksplicht en de hierna te bespreken klachtplicht van de koper van een zaak.[54] Naarmate de koper op grond van de inhoud van de koopovereenkomst en de verdere omstandigheden van het geval sterker erop mag vertrouwen dat de zaak beantwoordt aan de overeenkomst, zal van hem minder snel een (voortvarend) onderzoek mogen worden verwacht, meent de Raad. De koper mag in het algemeen afgaan op de juistheid van de hem in dit verband door de

11 verkoper gedane mededelingen, zeker als die mogen worden opgevat als geruststellende verklaringen omtrent de aan- of afwezigheid van bepaalde eigenschappen van het gekochte, aldus opnieuw de Raad. Technische gebreken zouden mijns inziens niet onder deze onderzoeksplicht moeten vallen. De goede technische werking van software mag worden verondersteld. Dit zou anders kunnen zijn als de afnemer weet dat hij een zogenoemde bètaversie van de software krijgt, maar ook dan kan het in beginsel niet zo zijn dat de afnemer daardoor schade lijdt die hij niet hoefde verwachten. De informatieverplichtingen die de Richtlijn consumentenrechten met betrekking tot de functionaliteit en de relevante interoperabiliteit oplegt zijn tevens omstandigheden die tot de verantwoordelijkheid van de leverancier behoren. Deze informatie kan de licentieverstrekker in de productdocumentatie vastleggen. Voor functionele en belevingsgebreken geldt dat bij grotere projecten vaak zeer specifieke afspraken worden gemaakt over de aard en omvang van afleverings- en acceptatietestprocedures. Dit verzwaart de rol van de afnemer. In situaties waarin volgens het contract met uitsluitend aflevering wordt volstaan, en dus geen acceptatietest wordt voorzien, is de onderzoeksplicht van de afnemer beperkter. Ten slotte is de omvang van de documentatie die de leverancier de afnemer ter hand stelt ook van belang voor de inhoud van de onderzoeksplicht: hoe minder informatie, hoe minder onderzoek mogelijk is. Het feit dat de afnemer bij het uitvoeren van testen (derde)deskundigen inschakelt kan ook invloed hebben op zijn onderzoeksplicht. Als de software niet aan de overeenkomst beantwoordt, dan bepaalt art. 7:21 lid 1 BW dat de koper (a) aflevering van het ontbrekende, (b) herstel van de afgeleverde zaak of (c) vervanging van de afgeleverde zaak kan vorderen. Als de koper een consument is gelden aanvullende rechten voor de koper: hij kan (a) de overeenkomst ontbinden of (b) de prijs verminderen in overeenstemming met de mate van afwijking van het overeengekomen. 4.6 Verval van rechten Krachtens art. 7:23 lid 1 eerste volzin BW kan de koper geen beroep doen op art.7:17 BW, als hij de verkoper niet binnen bekwame tijd nadat hij het gebrek heeft ontdekt over de non-conformiteit informeert. Dit wordt ook wel de klachtplicht genoemd. Indien sprake is van een consumentenkoop geldt art. 7:23 lid 1 laatste zin BW, dat een kennisgeving binnen een termijn van twee maanden na de ontdekking in ieder geval tijdig is. Voor de vaststelling van de vereiste mate van voortvarendheid is de ingewikkeldheid van het onderzoek volgens de Raad in zijn arrest van 25 maart 2011 ook relevant. Als een koper op eenvoudige wijze kan (laten) vaststellen of een vermoed gebrek ook echt bestaat, zal het onderzoek niet lang mogen duren. Als deze zekerheid echter alleen op langdurig of kostbaar onderzoek kan worden gebaseerd, dan zal de koper daarvoor de nodige tijd moeten worden gegund. Ook als de koper voor het verkrijgen van informatie of voor het verrichten van onderzoek afhankelijk is van de medewerking van derden, zal daarmee rekening moeten worden gehouden. Ook in dit opzicht hebben de aflever- en acceptatietestprocedures die partijen hebben afgesproken daardoor betekenis. In veel ICT-contracten wordt bepaald dat klachten binnen een maximale, veelal relatief korte periode moeten worden gemeld. De sanctie van het niet-tijdig melden is doorgaans dat het recht op ontbinding of kosteloos herstel vervalt. Gebreken worden vervolgens op basis van garantierechten of onderhoudscontracten afgehandeld. 4.7 Het Weens Koopverdrag

12 In veel softwareovereenkomsten vindt een uitsluiting van de toepasselijkheid van het CISG oftewel het zogenoemde Weens Koopverdrag[55] plaats. De werking van dit verdrag is beperkt tot internationale, zakelijke transacties. De reden voor deze uitsluiting is dat het verdrag in afdeling 2 eveneens een conformiteitseis bevat en daarnaast de koper bescherming toekent tegen rechten van derden. De vraag is echter of dat verdrag sowieso van toepassing kan zijn op softwarecontracten. Eerste lezing van de tekst van het verdrag doet namelijk vermoeden dat dit niet het geval is. Volgens art. 1 Weens Koopverdrag is dit alleen van toepassing op roerende zaken en in art. 2 lid f wordt bijvoorbeeld de koop van elektriciteit uitgesloten. Ook in dit verband komt de vraag weer op welke rol de stoffelijkheid en de eigendomsoverdracht spelen die in het verdrag worden verondersteld. De term roerende zaak wordt in het Weens Koopverdrag niet gedefinieerd. De term kan evenmin met behulp van het Nederlands recht worden uitgelegd want zij heeft een autonome betekenis. Bertrams[56] citeert een uitspraak van het Oberster Gerichtshof Oostenrijk van 21 juni 2005,[57] waaruit blijkt dat verkoop van standaardsoftware, die zich bevindt op een roerende zaak, moet worden gekwalificeerd als een koopovereenkomst in de zin van het Weens Koopverdrag. Hij wijst tevens op het vonnis van Rechtbank Arnhem van 28 juni 2006[58] dat haar vaststelling, dat standaardsoftware geleverd op een drager een roerende zaak is in de zin van het verdrag, overigens baseert op een preadvies van Bertrams zelf.[59] Thole meent dat het verdrag alleen gelding heeft wanneer ook het auteursrecht in het kader van de transactie wordt overgedragen.[60] Hijma meent het uit het verdrag te destilleren koopbegrip zakelijk overeenkomt met het ten onzent gehanteerde.[61] Schlechtriem & Butler stellen dat in de meeste jurisdicties de opvatting wordt gehuldigd dat software geleverd op een drager onder de toepassing van het Weens Koopverdrag valt.[62] Hierbij kan het volgens hen ook om maatwerksoftware gaan, nu art. 3 lid 1 overeenkomsten tot levering van te vervaardigen of voort te brengen roerende zaken aan koopovereenkomsten gelijkstelt. Die interpretatie sluit mijns inziens niet aan bij de gebruiken in de praktijk. Maatwerksoftware wordt in de praktijk als het resultaat van dienstverlening gezien, tenzij het alleen gaat om aanpassingen in de standaardsoftware zelf. Genoemde auteurs menen dat er bij softwarelicenties sprake moet zijn van eeuwigdurende gebruiksrechten omdat tijdelijke gebruiksrechten onvoldoende de notie van eigendomsoverdracht raken. Dit onderscheid lijkt mij echter ongewenst omdat het een opdeling van softwarelicenties teweeg zou brengen die alleen verband houdt met de wijze waarop voor het softwaregebruik wordt betaald. De waarde van de eeuwigheid van het gebruiksrecht wordt bovendien sterk gerelativeerd door de economische veroudering van de software, waardoor deze meestal binnen drie tot zeven jaar haar werkelijke waarde verliest. In de context van dit artikel is art. 3 lid 2 Weens Koopverdrag ook van belang. Volgens dat artikellid is het verdrag niet van toepassing op overeenkomsten waarin het belangrijkste deel van de verplichtingen van de partij die de roerende zaken levert, bestaat in de verstrekking van arbeidskracht of de verlening van andere diensten. Hiervoor moet in eerste instantie de economische waarde van respectievelijk de zaken en de diensten worden vergeleken. Ook kan relevant zijn welk deel van de overeenkomst essentieel is. De overeenkomst tot levering van ICT gerelateerde diensten kan daardoor van de werking van het Weens Koopverdrag zijn uitgezonderd, ook al vindt in dat kader levering van software plaats. 4.8 De dienstverleningsovereenkomst

13 Wanneer het gaat om software als dienstverlening zal doorgaans het wettelijk kader van de overeenkomst van opdracht van toepassing zijn.[63] De opdracht kan overigens zowel bestaan uit het ontwikkelen van software zelf, als het verrichten van een dienst met behulp van software. Onderwerpen als de zorgplicht, de informatieplicht, de verplichting tot het doen van rekening en verantwoording e.d. komen in deze titel van Boek 6 BW terug en zijn bruikbaar bij het beoordelen van de kwaliteit van software. In zakelijke transacties kan van dit kader worden afgeweken en daardoor wordt de inhoud van de overeenkomst en de wijze van uitvoering daarvan uiteraard van belang. Dat geldt ook voor fenomenen als de aanvullende werking van de redelijkheid en billijkheid en de al genoemde Haviltexformule. Hoewel de dienstverleningsovereenkomsten in de praktijk nog al eens afwijken van dit wettelijk kader, bevat het kooprecht in beginsel wel een bruikbaar kader voor het invullen en beoordelen van (onderdelen van) dergelijke dienstverleningssituaties.[64] Ook het conformiteitsprincipe grijpt immers terug op de redelijke verwachtingen die de afnemer van het geleverde mocht hebben. Kleinere maatwerkaanpassingen in standaardprogrammatuur zouden voor mij overigens geen aanleiding zijn om niet langer van koop te spreken. Een voorbeeld hiervan is de situatie waarin de leverancier zich verplicht specifieke eisen en wensen van zijn klant als onderdeel in zijn standaardsoftware op te nemen. Hiertoe kan hij op economische gronden besluiten omdat dergelijke aanpassingen ook voor andere gebruikers relevant kunnen zijn of omdat daardoor de onderhoudbaarheid van de software wordt vereenvoudigd. Zeer klantspecifieke aanpassingen zal een leverancier doorgaans als aparte software willen zien, waarvoor een dienstverleningscontract wordt afgesloten. Voorbeelden van het verrichten van diensten met behulp van software is outsourcing oftewel uitbesteding van computer- of bedrijfsprocessen. Ook het hosten van systemen of cloudcomputing valt in die categorie. Het feit dat het gebruik van software een belangrijk onderdeel is van de dienstverlening betekent namelijk niet dat de overeenkomst daardoor niet langer door het bepaalde omtrent de overeenkomst van opdracht wordt beheerst. Wanneer het ter beschikking stellen van ICTinfrastructuur of software namelijk als faciliterend is te beschouwen of een logisch uitvloeisel van de overeengekomen werkzaamheden is, dient de overeenkomst te worden gekwalificeerd als een overeenkomst van opdracht, zo meende Rechtbank Utrecht bijvoorbeeld.[65] Volgens art. 6:77 BW geldt overigens in het geval dat: ( ) bij de uitvoering van een verbintenis gebruik (wordt) gemaakt van een zaak die daartoe ongeschikt is, de tekortkoming die daardoor ontstaat de schuldenaar (wordt) toegerekend, tenzij dit, gelet op inhoud en strekking van de rechtshandeling waaruit de verbintenis voortspruit, de in het verkeer geldende opvattingen en de overige omstandigheden van het geval, onredelijk zou zijn. [66] Hoewel ook in dit wetsartikel de term zaak wordt gebruikt, heeft dit uitgangspunt bredere gelding. Zo achtte de Amsterdamse rechter ABN Amro aansprakelijk voor investeringsverliezen, omdat een cliënt niet van het elektronisch TradeBoxsysteem van de bank kon gebruikmaken.[67] Veel dienstverleningscontracten met belangrijke ICT-aspecten bevatten bijzondere bepalingen of bijlagen die de geldende criteria voor het gebruik van dergelijke hulpzaken reguleren. Een voorbeeld hiervan is een Service Level Agreement[68] waarin vaak minutieus wordt aangegeven welke werking van dergelijke hulpmiddelen mag worden verwacht. Concluderend kan met betrekking tot ICT-dienstverleningsovereenkomsten worden gesteld dat de softwarefouten primair moeten worden beoordeeld in het kader van de zorg die van een goed

14 opdrachtnemer mag worden verwacht. De positie van de contractspartijen, de inhoud van de afgesloten contracten en de overige omstandigheden van het geval zijn vervolgens leidend bij het beantwoorden van de vraag welk kwaliteitsniveau van de ontwikkelde of als hulpmiddel gebruikte software moet worden verwacht.[69] Concreet betekent dit dat technische en functionele gebreken eerder in het kamp van de dienstverlener zullen liggen dan in dat van de opdrachtgever. Voor belevingsgebreken gelden de gebruikelijke beginselen van het contractenrecht mijns inziens ten volle en hangt het van de omstandigheden van het geval af. Deze conclusies zijn uitgangspunten, in de praktijk blijven uiteraard de omstandigheden van het geval doorslaggevend. Onderdeel daarvan vormen factoren als hetgeen partijen daadwerkelijk hebben afgesproken, het doel van de overeenkomst en bekendheid met de werking van software die bij de uitvoering van de opdracht zouden worden ingezet. 5 ICT~Office en ARBIT Hiervoor is het kader geschetst van software en softwaregebreken, zijn praktijksituaties beschreven en werden wettelijke kaders weergegeven. Daarbij is aangegeven dat standaardcontracten vaak eigen regelingen bevatten die voor het beoordelen van softwaregebreken, zeker in een zakelijke context, van belang zijn. Om hierop in te gaan grijp ik terug op de reeds aangehaalde ICT~Officevoorwaarden en de ARBITbepalingen. 5.1 ICT~Office De ICT~Officevoorwaarden bestaan uit een basismodule die algemene contractuele onderwerpen betreft en zestien modules voor bijzondere situaties, die per geval overeengekomen kunnen worden. Module 1 van de voorwaarden betreft de Licentie voor programmatuur en gaat ervan uit dat als niet is overeengekomen dat er een acceptatietest wordt uitgevoerd de cliënt de programmatuur aanvaardt in de staat waarin deze zich op het moment van aflevering bevindt ( as is ), derhalve met alle zichtbare en onzichtbare fouten en gebreken, onverminderd de verplichtingen van leverancier op grond van de garantieregeling ( ).[70] Is zo n test wel afgesproken dan is cliënt verplicht onder zijn volledige en uitsluitende verantwoordelijkheid te toetsen of de afgeleverde programmatuur beantwoordt aan de door leverancier schriftelijk kenbaar gemaakte functionele of technische specificaties en, ingeval de programmatuur geheel of gedeeltelijk maatwerkprogrammatuur betreft, aan de tussen partijen schriftelijk overeengekomen functionele of technische specificaties. De cliënt is verplicht leverancier ( ) door middel van een schriftelijk en gedetailleerd testrapport over de fouten te informeren. Van een fout is alleen sprake indien cliënt deze kan aantonen en indien deze reproduceerbaar is.[71] De (veronderstelde) acceptatie van de programmatuur heeft tot gevolg dat leverancier gekweten is voor de nakoming van zijn verplichtingen betreffende terbeschikkingstelling en aflevering van de programmatuur ( ) en doet niet af aan het recht van cliënte op herstel van kleine gebreken en aan zijn garantierechten.[72] De garantieregeling houdt in ieder geval in dat de leverancier zich naar beste vermogen ervoor inspant fouten in de programmatuur binnen een redelijke termijn te herstellen. Garantie houdt volgens deze leveringsvoorwaarden niet in dat de aan cliënt ter beschikking gestelde programmatuur geschikt is voor het feitelijke en/of beoogde gebruik door cliënt of dat de programmatuur zonder onderbreking, fouten of gebreken zal werken of dat steeds alle fouten en gebreken worden verbeterd.[73] De garantieperiode zelf bedraagt drie maanden, waarna de cliënt een onderhoudsovereenkomst moet hebben afgesloten om op foutherstel aanspraak te kunnen maken. De herstelverplichting vervalt indien cliënt zonder schriftelijke toestemming van leverancier wijzigingen in de programmatuur aanbrengt of laat aanbrengen. Ook bepaalt deze module dat het gebruiksrecht van cliënt tot de zogeheten objectcode van de programmatuur is beperkt, geen broncode

15 wordt verstrekt en onderhoud alleen wordt geleverd indien dit is overeengekomen. Het recht zelfstandig fouten te herstellen is gelimiteerd tot uitzonderingen in de wet bepaald en verder uitgesloten. Module 2 Ontwikkeling van programmatuur geeft invulling aan de onderzoeks- en informatieplicht door te wijzen op het belang van goede informatieverstrekking, vastgestelde specificaties voor de software en goede samenwerking. Ook worden risico s toegedeeld, zoals aan de cliënt voor de juistheid van de door hem verstrekte gegevens. De zorgplicht van de leverancier wordt uitdrukkelijk benoemd maar de leverancier staat er niet voor in dat de in opdracht van cliënt ontwikkelde programmatuur geschikt is voor het feitelijke en/of beoogde gebruik door cliënt. Evenmin garandeert de leverancier dat de programmatuur zonder onderbreking, fouten of overige gebreken zal werken of dat steeds alle fouten en gebreken worden verbeterd. De module bevat vergelijkbare bepalingen omtrent acceptatie als de eerste module en bepaalt tevens dat acceptatie van de programmatuur tot gevolg heeft dat leverancier gekweten is voor de nakoming van zijn verplichtingen inzake de ontwikkeling van de programmatuur. De opdrachtgever verwerft geen intellectuele-eigendomsrechten op het maatwerk, maar verkrijgt een wat ruimer gebruiksrecht. Hij verkrijgt geen toegang tot de broncode en ook het recht zelfstandig fouten te herstellen is beperkt tot de wettelijke uitzonderingen. In de algemene module wordt de toepasselijkheid van het Weens Koopverdrag uitgesloten.[74] Voor alle door mij onderscheiden foutcategorieën bieden deze voorwaarden hierdoor aanknopingspunten. Over het algemeen wordt de verantwoordelijkheid van de leverancier daarbij beperkt, rusten op de klant/opdrachtgever zwaardere verplichtingen en zullen herstelwerkzaamheden op betaalde basis worden verricht. 5.2 ARBIT De ARBIT onderscheiden als voorwerp van de ICT-overeenkomst het verzamelbegrip Prestatie. Deze term omvat alle vormen van software of ICT-dienstverlening. De voorwaarden gaan ervan uit dat deze Prestatie geschikt dient te zijn voor het Overeengekomen gebruik. Met die laatste term wordt gedoeld op: ( ) het door Opdrachtgever beoogde gebruik van de Prestatie zoals dat ten tijde van het sluiten van de Overeenkomst op grond van het Bestek en/of op basis van de in artikel 4 bedoelde informatie, voor Wederpartij kenbaar is of redelijkerwijs moet zijn, een en ander voor zover dat gebruik in de Overeenkomst niet uitdrukkelijk is uitgesloten of beperkt. In dit art. 4 is de onderzoeks- en informatieplicht van de contractspartijen uitgewerkt. Gebruiksrechten worden omschreven als het recht op grond waarvan Opdrachtgever bevoegd is tot het installeren en gebruiken van Standaardprogrammatuur overeenkomstig het Overeengekomen gebruik met inbegrip van alle daarvoor redelijkerwijs noodzakelijke al dan niet tijdelijke verveelvoudigingen en openbaarmakingen. Hoe ver het recht op foutherstel strekt zal ook met dit Overeengekomen gebruik samenhangen, zij het dat dit ook het recht om de Standaardprogrammatuur voor test- en ontwikkeldoeleinden te gebruiken omvat. Een broncode wordt in beginsel niet verlangd maar er bestaat wel aanspraak op een zogenoemde Escrowregeling betreffende de broncode waardoor onderhoud op de software bij calamiteiten kan worden gewaarborgd. Voor zover het betreft een Prestatie die specifiek voor Opdrachtgever is of wordt ontworpen of vervaardigd en/of onder leiding of toezicht van Opdrachtgever dan wel aan de hand van diens instructies of ontwerpen is of wordt gerealiseerd kennen de ARBIT het uitgangspunt dat eventuele

16 intellectuele-eigendomsrechten aan de Opdrachtgever toekomen. Daar hoort volgens de toelichting ook de broncode van de software bij. Een Gebrek in de software wordt gedefinieerd als iedere storing en/of ander mankement als gevolg waarvan de Prestatie (auteur: de software ) niet voor het Overeengekomen gebruik geschikt is. Ook de ARBIT gaan uit van een acceptatieprocedure en kennen een garantieperiode van twaalf maanden toe waarin de Leverancier gehouden is Gebreken te herstellen. In art. 1.1 ARBIT wordt Acceptatie omschreven als de goedkeuring door Opdrachtgever van (onderdelen van) de Prestatie. Deze goedkeuring heeft gevolgen voor de eigendomsovergang van zaken, het ingaan van gebruiksrechten en de betalingsplicht. Daarnaast treedt na Acceptatie de garantietermijn in. Voor maatwerkprogrammatuur kennen de ARBIT een uitgebreidere acceptatieprocedure, die voor beide partijen niet vrijblijvend is. Als de opdrachtgever onvoldoende gebruikmaakt van de acceptatieprocedure heeft dat voor hem negatieve gevolgen. Bij contractering op basis van de ARBIT kan mijns inziens worden gesteld dat technische gebreken in ieder geval gedurende de garantietermijn voor rekening van de leverancier zijn. Hetzelfde geldt voor functionele en belevingsgebreken als deze aan het beoogde gebruik van de Prestatie kunnen worden gerelateerd. Bij het laatste is de acceptatietestprocedure wel van belang: het niet of onvoldoende volgen van die procedure kan voor de opdrachtgever nadelige effecten hebben. 6 Bijzondere situaties 6.1 Aanschaf van software as-is In softwarelicentiecontracten komt vaak de bepaling voor dat de software as-is wordt aangeschaft. Deze Angelsaksische notie gaat ervan uit dat de koper de goederen aanvaardt in de staat waarin deze zich bevinden, derhalve met inbegrip van alle zichtbare en onzichtbare tekortkomingen daarin en zonder dat implied warranties van toepassing zijn. De aangehaalde ICT~Officevoorwaarden kennen ook een soortgelijke bepaling zij het dat de afnemer daardoor niet al zijn rechten verliest. De term asis heeft in het Nederlands recht geen vastomlijnde betekenis en behoeft derhalve steeds uitleg.[75] Wat zijn de gevolgen van een dergelijke bepaling, indien de koopbepalingen van titel 7.1 BW van toepassing op de aanschaf van software zouden zijn? Voor professionele partijen kan dit betekenen dat geen beroep op de bepalingen omtrent conformiteit kan worden gedaan. De redelijkheid en billijkheid (art. 6:2 jo. art. 6:248 BW) kunnen echter mee brengen dat een dergelijke bepaling als onaanvaardbaar wordt bestempeld. Het lijkt mij bijvoorbeeld moeilijk vol te houden dat een afnemer geacht moet worden de software as is te hebben aanvaard, wanneer het besluit tot verwerving van die software op basis van informatie van de leverancier is genomen. Hetzelfde kan spelen als de leverancier ook een andere rol speelt, zoals die van implementatiepartner. Voor consumententransacties is deze bepaling één van de factoren voor invulling van de conformiteitsbepaling. 6.2 Het effect van het niet afsluiten van een onderhoudscontract Op 15 april 2011 deed de Hoge Raad[76] uitspraak in een kwestie die een ondeugdelijk melkwinningsysteem betrof. Onderdeel van het gekochte was het zogeheten 4-KGM-systeem. Dit computersysteem zou het mogelijk moeten maken om tijdens het melken een controle op mogelijke aanwezigheid van mastitis (uierontsteking) uit te oefenen. De installatie functioneerde ondanks een voortdurende stroom van klachten over steeds andere gebreken niet naar behoren en voldeed volgens Hof Arnhem daardoor niet aan de conformiteitseis van art. 7:17 BW. De koper ontbond uiteindelijk de koopovereenkomst. Volgens de leverancier had hij die bevoegdheid echter verloren, omdat niet was voldaan aan de klachtplicht. Weliswaar had de koper steeds geklaagd over gebreken, maar dat betrof

17 slechts aanmeldingen van gebreken in het kader van de onderhoudsovereenkomst en niet een conformiteitsklacht onder de koopovereenkomst, waardoor naar zijn mening verjaring was ingetreden. De Hoge Raad oordeelde echter anders. De voortdurende stroom van klachten over de gebreken waren telkens binnen bekwame tijd na het ontdekken daarvan gemeld en het was, ook de verkoper, duidelijk dat hierdoor ook werd geklaagd over het niet voldoen van het systeem aan de overeenkomst, meende de Raad. Dat partijen tevens een onderhoudsovereenkomst hadden gesloten op grond waarvan [eiser] verplicht was tot herstel over te gaan, staat aan dat oordeel niet in de weg. Ook de wettelijke verjaringstermijnen schuiven volgens de Hoge Raad mee op en beginnen steeds opnieuw bij vervolgklachten. De overwegingen van de Hoge Raad zijn in dit verband belangrijk genoeg om enkele daarvan hier te vermelden: Volgens onderdeel 2.2 is voor ieder gebrek waarover [verweerder] heeft geklaagd een aparte verjaringstermijn gaan lopen, zodat zijn vordering verjaard is voor zover die is gebaseerd op klachten die meer dan twee jaren voor de stuiting van de verjaring ter kennis van [eiser] zijn gebracht. Dit betoog kan niet leiden tot de conclusie dat de buitengerechtelijke ontbinding heeft plaatsgevonden na verloop van de in artikel 7:23 lid 2 bedoelde verjaringstermijn. [eiser] was immers ook afgezien van de onderhoudsovereenkomst op grond van de koopovereenkomst gehouden telkens na een klacht over non-conformiteit het gebrek te herstellen (artikel 7:21 lid 1, aanhef en onder b, BW). Nu na iedere poging tot herstel bleek dat het melkwinningsysteem nog niet naar behoren functioneerde, is telkens nadat [eiser] daarvan op de voet van artikel 7:23 lid 1 (tijdig) in kennis was gesteld, ingevolge artikel 7:23 lid 2 ook telkens een nieuwe verjaringstermijn gaan lopen (vgl. Kamerstukken I , , nr. 323b, blz. 10). Daarom was de bevoegdheid van [verweerder] om tot ontbinding over te gaan niet verjaard. Hij heeft immers van die bevoegdheid gebruik gemaakt (ruim) binnen twee jaren nadat hij had geklaagd over het feit dat het melkwinningsysteem ook na de levering van het 4- KGM-systeem dat volgens [eiser] tot een verbetering van het functioneren van het gehele systeem zou leiden, en ondanks de ook daarna nog gevolgde pogingen tot herstel nog steeds niet aan de overeenkomst beantwoordde Opmerking verdient overigens dat ingevolge artikel 7:23 lid 2 een schadevordering in beginsel verjaart door verloop van twee jaren nadat (tijdig) is gereclameerd over het gebrek dat die schade heeft veroorzaakt, en dat voor een vordering ter zake van een andere schadepost als gevolg van een later aan het licht gekomen gebrek een nieuwe verjaringstermijn gaat lopen nadat ter zake van dat later gebleken gebrek is gereclameerd. Dit is echter anders indien het gebrek aan de verkochte zaak, na herhaalde pogingen tot herstel daarvan, telkens terugkeert en telkens tot nieuwe (gevolg)schade leidt. In een zodanig geval, dat erdoor wordt gekenmerkt dat tijdig is gereclameerd nadat het gebrek zich voor het eerst voordeed, en dat daarna eveneens is gereclameerd over het terugkeren daarvan, is het in strijd met de strekking van deze bepaling de vordering tot vergoeding van de schade uit de beginperiode verjaard te achten omdat meer dan twee jaren sinds de eerste klacht(en) zijn verstreken. Gezien de hiervoor geschetste praktijk met betrekking tot onderhoudscontracten, is deze uitspraak mijns inziens voor ICT-contracten voor groot belang. In de eerste plaats heeft de conformiteitsregeling ten aanzien van consumenten immers een dwingendrechtelijk karakter. Daarnaast zijn er gevallen waarin zakelijke partijen geen afwijkende afspraken hebben gemaakt en het kooprecht bij gebreke van andere afspraken van toepassing is. In de derde plaats kan de uitspraak reflexwerking hebben in situaties waarin zakelijke partijen wel andere afspraken hebben gemaakt. Ook bij slecht functionerende ICT-systemen is het immers vaak zo dat de afnemer een stroom van vaak verschillende

18 klachten uit of dat klachten zich na verloop van tijd weer gaan voordoen. Gezien de hiervoor aangehaalde definitie van acceptatie van de geleverde software zal een leverancier er vaak van uitgaan dat de rechten van de afnemer daardoor zijn beperkt. En wat te denken van SLA s waarin de verplichting van de leverancier bij het niet halen van de afgesproken levels is beperkt tot het toekennen van service-credits?[77] Wanneer deze Melkrobot-uitspraak wordt toegepast kan de afdwingbaarheid van de oorspronkelijke (koop)overeenkomst dan niettemin ter discussie staan. 7 Conclusies Zowel de term software als de term gebrek is een begrip dat invulling behoeft. De zwaardere rol die software maatschappelijk is gaan spelen rechtvaardigt dat het recht duidelijk is over de kwaliteit die een afnemer daarvan mag verwachten en daarvoor kaders biedt. Technische fouten behoren bijvoorbeeld niet met het bekende adagium software is nooit foutloos te worden goedgepraat. Dit adagium kan hooguit betekenen dat de afnemer de leverancier ruimte moet geven fouten te herstellen. Toepassing van het kooprecht op levering van software die niet grotendeels op verzoek van de afnemer is vervaardigd, geeft software een volwassen plaats in het recht. De notie van conformiteit biedt namelijk een ruime norm om de kwaliteitseisen aan af te meten en is niet tijdgebonden. Voor consumententransactie is toepassing van het kooprecht door de EU-Richtlijn consumentenrechten bovendien onvermijdelijk. Zakelijke partijen kunnen overeenkomen dat zij van het kooprecht afwijken en waar zij dat doen kan het kooprecht aanvullende werking hebben. De praktijk toont aan dat zij dergelijke afspraken ook feitelijk maken, bijvoorbeeld via standaardvoorwaarden. Wanneer software grotendeels het resultaat is van een overeenkomst van opdracht of een hulpmiddel is bij het uitvoeren van een opdracht, moet het beoordelingskader voor de kwaliteit van de software niet primair liggen in de technische merites van die software. Het gaat dan vooral om de kwaliteit van de werkzaamheden die de opdrachtgever op basis van de overeenkomst van opdracht mocht verwachten. De opmerking software is nooit foutloos is in dat geval nauwelijks relevant. Technische gebreken horen ook dan in beginsel niet voor te komen. Voor functionele gebreken geldt dit in iets mindere mate ook. Belevingsgebreken hangen samen met het verwachtingspatroon dat de opdrachtgever mocht of moest hebben van de werkzaamheden en moeten volgende de gebruikelijke kaders van het verbintenissenrecht worden afgehandeld. Voetnoot [1] Mr. W.F.R. Rinzema is advocaat bij Ventoux. De auteur dankt Jacob Kooistra voor zijn hulp bij het vervaardigen van dit artikel. [2] Richtlijn 2011/83/EU van het Europees Parlement en de Raad van 25 oktober 2011 betreffende consumentenrechten, tot wijziging van Richtlijn 93/13/EEG van de Raad en van Richtlijn 1999/44/EG van het Europees Parlement en de Raad en tot intrekking van Richtlijn 85/577/EEG en van Richtlijn 97/7/EG van het Europees Parlement en de Raad (PbEU 2011, L 304/64-88). [3] Zo heeft het Duitse test- en meetinstituut TÜV een certificaat als kwaliteitsnorm voor de software producerende industrie ontwikkeld specifiek gericht op verbetering van de technische kwaliteit van softwaresystemen. [4] Met term levering wordt in dit artikel niet per se gedoeld op de juridische levering maar op aflevering c.q. beschikbaarstelling. In de praktijk wordt bijv. veel gesproken over het leveren van softwarelicenties, waarmee wordt gedoeld op het verstrekken van gebruiksrechten op standaardsoftware.

19 [5] Ik realiseer mij dat iedere rubricering leidt tot versimpeling van een problematiek. [6] De termen computerprogrammatuur, programmatuur en software worden in dit artikel als algemene aanduiding en als synoniemen gebruikt. Hetzelfde geldt voor de termen standaardprogrammatuur en standaardsoftware. [7] Struik, Van Schelven & Hoorneman, Softwarerecht, Deventer: Kluwer [8] Struik e.a. 2010, p. 23 e.v. [9] Struik e.a. 2010, p [10] Zie bijv. Computerrecht 2004/5 dat in zijn geheel aan open source software is gewijd. [11] In zijn arrest van 15 november 2011 (Hof Arnhem 15 november 2011, LJN BU5540) merkte Hof Arnhem de vraag aan wie de rechten op de broncode toekwamen als een vraag van contract uitleg aan. [12] Struik e.a. 2010, p. 42. [13] Zie voor een interessante verhandeling over de vraag of een opdrachtgever dan wel een leverancier bepaalt of en wanneer er sprake is van standaard- dan wel maatwerksoftware Rb. Zutphen 29 december 2011, LJN BU9991. [14] Zie echter art. 6 Aw. [15] Richtlijn 2009/24/EG van het Europees Parlement en de Raad van 23 april 2009 betreffende de rechtsbescherming van computerprogramma s, (PbEU 2009, L 111/16-22). [16] Dat wil zeggen dat er een slechts een hulpprogramma wordt gedownload om toegang tot de software waar het om gaat te verkrijgen. [17] Zie het themanummer Computerrecht 2005, afl. 4. [18] Deze ontwikkelmethoden veranderen van tijd tot tijd op basis van inzichten binnen de ICTsector. Zo wordt de Agile ontwikkelvorm tegenwoordig veel gehanteerd, waarbij de software in korte, overzichtelijke fasen en perioden wordt gerealiseerd. [19] Vgl. Van der Steur, Grenzen van rechtsobjecten, een onderzoek naar de grenzen van objecten van eigendomsrechten en intellectuele eigendomsrechten, Deventer: Kluwer 2003, p e.v. [20] Zie over dergelijke click-wrap of schrink-wrap overeenkomsten bijv.: M.W. Scheltema & Tjong Tjin Tai, Overeenkomsten sluiten door openen en klikken?, Computerrecht 2003 afl. 4, p [21] Kleinere verbeteringen, meestal voor foutherstel, worden als patch of update verstrekt. [22] In de praktijk wordt geen consistente terminologie gehanteerd. Nieuwe versies worden ook wel als nieuwe releases aangeduid. In laatstgenoemd geval heten verbeterde versies dan vaak nieuwe versies. [23] Zoals Oracle, SAP of Microsoft. [24] Regeling van de Minister-President van 7 juli 2010, Stcrt. 2010, [25] Die samen een omzet van bijna 30 miljard hebben en meer dan medewerkers. Zie hiervoor o.a. T.J. de Graaf, Opbouw en aansprakelijkheidsregeling ICT~Office-voorwaarden 2009 kritisch bekeken, Contracteren , p

20 [26] Deze voorwaarden bestaan uit een algemeen deel en een zestien tal modules voor bijzondere situaties, zie [27] Zie over de ARBIT D.T.L. Oosterbaan, De ARBIT van de rijksoverheid, Computerrecht 2011/97, p [28] Volgens Struik e.a in 8.3 e.v. impliceert het feit dat uitdrukkelijk de term exemplaar in art. 45j Aw wordt gebruikt, dat het correctierecht niet toekomt aan degene die geen fysiek exemplaar van de software tot zijn beschikking heeft gekregen. [29] Kamerstukken II 1992/93, , nr. 7, p. 11 (NEV II). [30] HR 13 maart 1981, NJ 1981/635. Bij de uitleg van een schriftelijke overeenkomst is het niet genoeg om naar de taalkundige betekenis van de tekst te kijken, ook moet worden bekeken welke betekenis de partijen aan de tekst gaven en wat ze over en weer van elkaar mochten verwachten. [31] HR 21 juni 1996, NJ 1997/327, m.nt. D.W.F. Verkade (De Wild/Van Genk). [32] Struik e.a. 2010, p [33] Asser/Hijma 5-I 2007/14. [34] Zie hoofdstuk VI Aw. [35] Zie bijv. Neppelenbroek, De aanschaf van standaardsoftware en de toepasselijkheid van het kooprecht, VrA 2005/2, p en Westerdijk, De verbintenisrechtelijke status van software: geen zaak van belang?, in: A.R. Lodder & A. Oskamp (red.), Caught in the Cyber Crime Act (liber amicorum voor prof. mr. H.W.K. Kaspersen) Deventer: Kluwer 2009, p Hof Arnhem oordeelde op 3 mei 2011 (Hof Arnhem 3 mei 2011, LJN BQ5240) dat s en digitale documenten geen zaken zijn omdat als zaken moeten worden beschouwd de voor menselijke beheersing vatbare stoffelijke objecten. Een zeer uitvoerig overzicht van destijds heersende opvattingen is terug te vinden bij Thole, De juridische kwalificatie van de aanschaf van software, in: NVvIR feestbundel, [36] In zijn noot bij Hof Amsterdam 1 juni 2010, LJN BM6320; Computerrecht 2010/143, afl. 5 (Hulskamp/Beeldbrigade). [37] Zie p. 6 van de nota naar aanleiding van het verslag van de aanpassing van Boek 7 BW in verband met de implementatie van Richtlijn 97/7/EG, Kamerstukken II 1999/2000, , nr. 5. [38] Kleve, Juridische iconen in het informatietijdperk, Deventer: Kluwer 2004, p [39] Vgl. Van der Steur, Grenzen van rechtsobjecten, een onderzoek naar de grenzen van objecten van eigendomsrechten en intellectuele eigendomsrechten, Deventer: Kluwer 2003, p [40] Korteweg, De vermogensrechtelijke status van digitale gegevens (bespreking arrest Hof Arnhem 3 mei 2011, LJN BQ5240), in: Juridisch Up to Date 2011/18, p Deze redenering sluit aan op de benadering die de Hoge Raad in een strafrechtelijke kwestie koos, zie HR 31 januari 2012, LJN BQ9251. [41] Franken, Kaspersen & De Wild, Recht en computer, Deventer: Kluwer 2004, p. 43. [42] Thole, De juridische kwalificatie van de aanschaf van software, in: NVvIR feestbundel, [43] Hof Amsterdam (nevenzittingsplaats Arnhem) 1 juni 2010, LJN BM6320, r.o. 4.6 (Hulskamp/Beeldbrigade).