Contracten

IT 347

Gemeenschappelijk auteursrecht - beheer anders overeengekomen

Rechtbank Arnhem 13 april 2011, LJN BQ3855 (eisers tegen ECHOBOOMERS B.V.)

Auteursrecht. Contractueel gemeenschappelijk auteursrecht. Software-ontwikkeling (PlanDrive) voor rijscholen.  Ontbinding van samenwerkingsovk en vordering broncode.

Gemeenschappelijk beheer, conform 3:170 lid 2 jo. 3:168 lid 1 BW, tenzij anders overeengekomen. Samenwerkingsovereenkomst bepaalt dat het vrijstaat het product al niet niet zelfstandig te verveelvoudigen, aan te passen, uit te geven en exploiteren. Verplichting ter beschikking stellen van broncode. Broncode moet door ECHOBOOMERS worden afgegeven aan [eisers]. Samenhang vanDatabase behoeft niet te worden afgegeven: vordering onvoldoende geconcretiseerd. Portretrecht succesvol ingeroepen tegen gebruik van beeltenissen van eiser en familieleden.

4.8.  Derhalve volgt uit de artikelen 6 en 9 van de samenwerkingsovereenkomst, in onderling verband en samenhang gelezen, dat het in artikel 6 van de samenwerkings-overeenkomst geregelde zelfstandig recht van ieder der partijen om de generieke software PlanDrive te verveelvoudigen, aan te passen, uit te geven en te exploiteren, zich ook uitstrekt over de rechtsverhouding tussen partijen na de beëindiging van die samenwerkings¬overeenkomst. Aangenomen moet daarom worden dat beide partijen thans ieder zelfstandig gebruik maken van de in artikel 6 van de samenwerkings¬overeenkomst aan hen toegekende rechten. Het verweer van Echoboomers dat Rijschool [eiser sub 1] c.s. geen belang heeft bij de afgifte van de broncode van de generieke software PlanDrive, omdat voor iedere exploitatiehandeling Rijschool [eiser sub 1] c.s. toestemming nodig heeft van Echoboomers, die Echoboomers niet verleent, faalt dan ook.

Lees de uitspraak hier (link en pdf)

Artikel 6 – Intellectueel eigendom
Alle rechten van Intellectueel en Industrieel eigendom die betrekking hebben op de producten (het product) berusten bij alle partijen van deze samenwerkingsovereenkomst. Deze rechten zijn niet-exclusief en overdraagbaar aan derden. Het staat zowel Youngdog BV als Rijschool [eiser sub 1] vrij de producten (het product) al dan niet zelfstandig te verveelvoudigen, aan te passen, uit te geven en te exploiteren. Hiermee vervalt het artikel “Intellectueel en industrieel eigendom” in de overeenkomst tussen Youngdog BV en Rijschool [eiser sub 1], d.d. 6 mei 2008, volledig.

Artikel 8 – Wijze besteding winst (inkomsten)
Een partij dient voor een exclusief (wereldwijde) exploitatierecht van een product (de producten) een afdracht doen plaatsvinden aan het samenwerkingsverband van 25% van de netto-inkomsten van de verkoop van een product (de producten); (…)

Artikel 9 – Looptijd van de overeenkomst en ontbinding
De overeenkomst is van kracht gedurende de looptijd van het project en wordt daarna stilzwijgend verlengd, totdat een van de partijen de overeenkomst beëindigt. Beëindiging kan tussentijds, met onmiddellijke ingang, zonder dat rechterlijke tussenkomst is vereist en zonder dat de ontbindende partij ter zake tot enige vorm van schadevergoeding aan de andere partijen gehouden is, geheel of gedeeltelijk ontbonden worden. Bij beëindiging van de overeenkomst zal Youngdog BV binnen 7 dagen de broncode van de meest recente versie van de producten (het product) aan de samenwerkingspartners leveren.

IT 344

ICT-contractenrecht; Verslag van Conferentie ICT & Recht 2011 van IIR

Met dank aan Vera Schönfeldt, ICT~Office 

Donderdag 14 en donderdag 21 april jl. vond voor de derde keer de tweedaagse conferentie ‘ICT&Recht’ van het Institute for International Research (IIR) plaats. Ditmaal in het Olympisch Stadion te Amsterdam. De eerste dag van deze tweedaagse conferentie stond in het teken van contracteren. In totaal gaven zeven sprekers hun visie over actuele ontwikkelingen op het gebied van contracteren binnen de ICT-sector. Donderdag 21 april stond in het teken van ‘cloud computing’. Tijdens deze tweede conferentiedag kwamen naast de juridische aspecten ten aanzien van cloud computing ook de actualiteiten en technische aspecten ten aanzien van cloud computing aan bod.

Voor een volledig verslag van de IIR Conferentie ICT&Recht 2011, klik hier.

IT 342

Gemeenten en gebruik van Google Maps

Privacybezwaren en gebruikersvoorwaarden van Google Maps zijn dusdanig eenzijdg dat het Ministerie van Binnenlandse Zaken gemeenten waarschuwt voor het gebruik op hun sites. Dat volgt uit een onderzoek van adviesbureau Geon.

Privacybezwaren De zoekmachine van Google registreert het zoekgedrag van gebruikers om dit commercieel te kunnen inzetten. Ook voor Google Maps kan dit een rol spelen. Het is een wezenlijk businessmodel van Google. In de communicatie tussen overheid en burger is dit een onwenselijke situatie.

Data uitbuiten Overheidsgegevens kunnen door Google in andere vorm of in delen worden hergebruikt voor commerciële doeleinden (...) Hoewel Google aangeeft dat zij geen belang heeft bij persoonegegevens, wil dat nog niet zeggen dat de privacy is gewaarborgd. 

Ontraden worden het gebruik niet, omdat er geen evenwaardig alternatief is. Een licentie kopen moet echter wel. Op dit moment wordt vooral gebruik gemaakt van de gratis variant onder het mom: 'we zien wel waar het schip strandt' of 'we merken wel wanneer we door een juridisch bestuurlijke beslissing worden teruggefloten'. Ook op lokaal bestuurlijk niveau (colleges, gemeenteraden) heerst meer het beeld van trots dat de gemeente met haar dienstverlening mee kan gaan in de populariteit van Google dan dat men terughoudend en kritisch is.

Een mogelijk aankomend alternatief met overheidsdata gemaakt is Het project “Geografische zoek- en toondienst”, afgekort GEOZET. Naar verwachting is dit voor de zomer afgerond.

Lees het onderzoek hier.

IT 338

OPTA beboet mobieltjesspammer via sms-shortcodes

OPTA heeft in april 2011 aan Abor Creative C.V. en diens gevolmachtigde boetes van in totaal 550.000 euro opgelegd voor het overtreden van het spamverbod. Het betrof het verzenden van schermafbeeldingen voor mobieltjes. Abor Creative heeft ongevraagde SMS-berichten verzonden met een commercieel doel zonder dat ontvangers vooraf toestemmen hadden gegeven. Ook ontbrak in de SMS-berichten een geldige afmeldmogelijkheid. Voor de SMS-berichten werden de shortcodes 3311, 4747 en 6363 gebruikt.

Besluit van het college van de Onafhankelijke Post en Telecommunicatie Autoriteit tot oplegging van een boete ter zake van overtreding van artikel 11.7, eerste lid, en 11.7, derde lid, aanhef en onder b, van de Telecommunicatiewet (spamverbod).

Lees het besluit hier (pdf) en verder hier (link, link en link)

IT 337

Onduidelijk privacy beleid van mobiele apparaten

Met dank aan Wouter Dammers, SOLV. Dagblad De Pers bericht vandaag over de onduidelijkheid van privacyvoorwaarden van bedrijven als Facebook, Google en Apple. Dit naar aanleiding van de recente berichten over de opslag van locatiedata door de Apple iPhone en Google Android telefoons en de (vermeende) verkoop van data door TomTom, dat heeft gezorgd voor een licentiewijziging. Stuk voor stuk betreffen dit voorbeelden van hoe jouw persoonsgegevens gebruikt kunnen worden, zonder dat je je daar bewust van bent, of hoe het mis kan gaan met jouw (persoons)gegevens. Het artikel in De Pers geeft aan dat je als gebruiker van de diensten van deze bedrijven vaak (onbewust) akkoord hebt gegeven voor de opslag van jouw locatiedata, of dat het bedrijf jouw persoonsgegevens mag delen met derden...

In het artikel in De Pers leg ik uit dat de gebruiks- en privacy voorwaarden van deze bedrijven aan duidelijkheid te wensen over laat. Natuurlijk gaat de gemiddelde gebruiker deze voorwaarden niet stuk voor stuk doorlezen. Het betreffen meestal lange, lastige juridische documenten, waar het aan duidelijkheid te wensen over laat. Vaak wordt ook nog eens in het ene document verwezen naar een ander document, welke vervolgens weer verwijst naar een ander document. Door de spreekwoordelijke bomen zie je het bos niet meer.

Gelukkig heeft ook de Europese wetgever in de gaten dat "gewone mensentaal" veel meer duidelijkheid geeft aan de betrokkene - degene waar het om draait bij de verwerking van persoonsgegevens. Europa heeft, onder meer om deze reden, aangegeven om de huidige Privacy richtlijn - de richtlijn waarop onze Wet bescherming persoonsgegevens is gebaseerd - te herzien.

Een van de speerpunten bij die herziening is dat er meer duidelijkheid en transparantie moet komen voor de betrokkene (lees: de gebruiker).

Transparantie vormt een basisvoorwaarden, willen individuen controle kunnen uitoefenen over hun eigen gegevens en zich van een effectieve bescherming van hun persoonsgegevens kunnen verzekeren. Daarom is het van wezenlijk belang dat individuen door degenen die voor de verwerking verantwoordelijk zijn goed en duidelijk, op een transparante wijze, worden geïnformeerd over hoe en door wie hun gegevens worden verzameld en verwerkt, voor welke doeleinden, gedurende welke periode en in hoeverre zij het recht hebben hun gegevens in te zien, te corrigeren of te wissen.,

aldus een mededeling van de Europese Commissie. De huidige bepalingen die op de informatieverplichting voorzien, zouden niet meer volstaan:

Transparantie vereist in essentie dat de informatie vlot toegankelijk en gemakkelijk te begrijpen is en dat duidelijke en eenvoudige taal wordt gebruikt. Dit is in het bijzonder relevant in een online-omgeving, waarin privacyverklaringen vaak onduidelijk, moeilijk te vinden, ondoorzichtig en niet steeds conform de bestaande voorschriften zijn. Waar dit met name het geval zou kunnen zijn, is bij online "behavioural advertising" (gerichte reclame op basis van het surfgedrag). Zowel het grote aantal spelers dat zich ermee bezighoudt als de technologische complexiteit van deze praktijk maken dat het voor een individu moeilijk is te weten en te begrijpen of, door wie en met welk doel persoonsgegevens worden verzameld."

De Commissie overweegt bijvoorbeeld om een of meer EU-standaardformulieren (privacyverklaringen) op te stellen die door de voor de verwerking van gegevens verantwoordelijken moeten worden gebruikt. Een privacybijsluiter in normale mensentaal dus. Wat dat betreft is dat alleen maar aan te moedigen. Maar of het de situaties als in de inleiding van deze blog genoemd zal voorkomen durf ik te betwisten. Privacy by Design, een van de andere speerpunten van de herziening van de privacy richtlijn, zal in mijn optiek meer resultaat hebben in deze gevallen. Zo was het een 'foutje' van Apple dat de locatiedata werden opgeslagen. Iets wat met een software update gecorrigeerd zal worden.

Het staat bedrijven natuurlijk vrij om verder te gaan dan enkel een privacybijsluiter. Het is alleen maar aan te moedigen om met duidelijke grafische of audiovisuele uitleg aan te geven welke persoonsgegevens voor welke doeleinden worden gebruikt. Maar mijns inziens zou dit geen verplichting moeten zijn: Een duidelijke privacy verklaring - in combinatie met privacy by design - kan in mijn optiek volstaan.

Bron afbeelding: Onder CC BY-ND 2.0 licentie http://geekandpoke.typepad.com/geekandpoke/2006/11/googles_privacy.html

IT 332

Cloudhosting en escrow regelingen

Met dank aan Sander Remans, Escrow Alliance B.V. Sinds donderdag verschenen berichten in diverse media over de storing bij de Cloudhosting dienst van Amazon (o.a. tweakers en webwereld). In een webwereld opinie wordt door Andreas Udo de Haes zelfs gesproken over "cloudklunzen". Door de storing in een aantal van Amazon's hosting-centra zijn data en bijbehorende applicatie niet beschikbaar. Er is een angst ontstaan dat bij de uitval van de Cloudhosting leverancier er een totaal verlies van data en applicatie ontstaat. Een bedrijf kan zich beschermen tegen uitval van ICT infrastructuur, ook van cloud-omgevingen.

Een escrowregeling, met name een die specifieke eigenschappen van Cloudhosting in overweging neemt, voorkomt de paniek die bij een aantal bedrijven is opgetreden. In de escrowregeling worden vanuit historisch perspectief de broncode en de objectcode, en nu ook de onlosmakelijk verbonden database, de infrastructuur, het ecosysteem van relaties rondom de applicatie, de onderliggende contracten en de SLA’s.

Ook Wanda van Kerkvoorden heeft al eerder hier (IT 289) betoogd:

Als het internet “eruit ligt”, dan ligt het bedrijf stil en een back-up kan bijvoorbeeld het bedrijf een stap terug moeten laten zetten. Het is dus goed om hierover heldere afspraken te maken met de aanbieder, of juist situaties goed af te dekken als aanbieder van zulke diensten.

Door de juiste inzet van een escrowregeling worden bedrijfskritische applicaties en datasets beschermd.

IT 329

Paapst: Noot bij Oracle tegen Staat der Nederlanden

met dank aan Mathieu Paapst, Rijksuniversiteit Groningen

De ministeries van Financiën (FIN), van Sociale Zaken en Werkgelegenheid (SZW) en het ministerie van Volksgezondheid, Welzijn en Sport (VWS) willen in de toekomst één financieel administratief systeem in gebruik gaan nemen. De drie ministeries willen daarom overgaan tot hergebruik en uitbreiding van het systeem dat SZW in 2003 (na een aanbesteding) in gebruik heeft genomen en dat is gebaseerd op SAP-software. Om deze uitbreiding uit te voeren doen de ministeries een nieuwe aanbesteding voor de inhuur van ICT personeel (perceel 1) en de levering van aanvullende softwarelicenties (perceel 2). In het nieuwe bestek worden zowel de expertise als de producten van SAP dwingend voorgeschreven. Volgens Oracle, de concurrent van SAP, is iedere andere producent van software hierdoor bij voorbaat uitgesloten van mededinging en staat de inschrijving alleen open voor dienstverleners die SAP-software kunnen leveren en beschikken over SAP-expertise.

Lees de volledige noot hier (pdf)

Vzr. Rechtbank ’s Gravenhage 17 december 2010, LJN BO9287, IT 198 (Oracle Nederland B.V. tegen De Staat der Nederlanden) - of klik hier (pdf)

IT 324

Toepassen van de ARBIT

met dank aan Frank van ’t Geloof, Adriaanse De Meijer Advocaten voor deze bijdrage. Klik voor de pdf hier of lees verder.

De Algemene Rijksvoorwaarden bij IT overeenkomsten (ARBIT) uit 2010 zijn al meerdere malen becommentarieerd. Soms worden ze als tamelijk evenwichtig beschouwd, vooral als ze vergeleken worden met de BiZa modelcontracten die daarvoor gebruikt werden. Soms worden ze echter negatief beoordeeld.

Het is niet zonder meer duidelijk waarvoor de ARBIT nu precies wel en niet zijn bedoeld. Vooral het perspectief van waaruit ze beschouwd worden is van belang bij de beoordeling van de voorwaarden. Daarom wordt hieronder eerst vastgesteld voor welke overeenkomsten de ARBIT toepasbaar zijn. Daarna worden een aantal bepalingen beschouwd binnen het veronderstelde toepassingsgebied.

Toepassingsgebied voor de ARBIT
ARBIT is een acroniem voor “Algemene Rijksvoorwaarden bij IT-overeenkomsten”. Het is dus van toepassing op IT overeenkomsten. Artikel 1 geeft een aantal omschrijvingen van gebruikte begrippen. De definitie van een IT overeenkomst ontbreekt echter. De reikwijdte van de ARBIT is daardoor niet formeel afgebakend. In de toelichting staat hierover:

De ARBIT zijn vooral bedoeld voor modale IT-inkopen door de overheid en niet zozeer voor grote en bijzondere IT-projecten. Dat neemt niet weg dat ze ook dan als uitgangspunt voor het opzetten van een meer specifieke contractuele relatie met de IT markt kunnen dienen. Vanwege de flexibiliteit van de Overeenkomst kan deze veelal ook gebruikt worden bij de inzet van specifieke IT-producten en diensten zoals bijvoorbeeld webhosting of SaaS (software as a service). Een zorgvuldige specifieke omschrijving van zo’n nieuw product of dienst moet dan worden opgenomen in artikel 2 van de Overeenkomst. Daarna kunnen de ARBIT, die zoveel mogelijk techniekonafhankelijk zijn geschreven, ook daarop in beginsel gewoon van toepassing worden verklaard. De combinatie van ARBIT en Overeenkomst kan daarmee een solide basis vormen voor IT -contractering in de komende jaren. Overigens worden dergelijke specifieke IT-diensten vooralsnog niet beschouwd als ‘commodities’ waarvoor de ARBIT in de eerste plaats zijn bedoeld (zie de Algemene inleiding van deze Toelichting). Mocht uit evaluaties van de ARBIT blijken dat dergelijke thema’s hier toch meer specifiek aandacht verdienen, dan zal dat op een later tijdstip alsnog gebeuren.”

 [… ] Voor afwijkingen van de ARBIT of het al dan niet (mede) van toepassing verklaren van andere (algemene) voorwaarden kan slechts in uitzonderingssituaties aanleiding bestaan. Meestal verdient het echter ook dan aanbeveling om de ARBIT wel naast en ter aanvulling op die andere algemene voorwaarden van toepassing te verklaren.[……] [accent toegevoegd]

Uit bovenstaande blijkt dat de ARBIT bedoeld zijn voor ‘commodity’-achtige IT diensten en producten. SaaS diensten (Software as a Service, ofwel ‘cloud computing’) vallen daar vooralsnog niet onder, evenals grote en bijzondere projecten. Om meer te kunnen zeggen over wat in deze context ‘grote en bijzonder projecten’ zijn, moeten de ARBIT nader inhoudelijk worden beschouwd. De ARBIT bestaan uit een algemeen deel en vier specifieke delen. De bedoeling is dat steeds alle delen van toepassing worden verklaard. Het derde deel met bijzondere bepalingen is voor ‘opdrachten’. Daaronder vallen onder meer:
• adviesdiensten
• ontwikkeling maatwerkprogrammatuur
• leiding geven aan IT projecten.
Kennelijk gaan de opstellers van de ARBIT ervan uit dat adviesdiensten commodities kunnen zijn. Dat ligt op het eerste gezicht niet voor de hand. Een commodity is een eenvormig massaproduct, met een voorspelbare inhoud. Advies is alleen nuttig als van tevoren niet bekend is wat de inhoud van het advies is. Hieronder is uitgewerkt hoe deze twee schijnbaar tegenstrijdige begrippen inwerken op de toepasbaarheid va de ARBIT. Daaruit volgt tevens wat moet worden verstaan onder ‘IT projecten’ waaraan in bovenstaande opsomming leiding gegeven kan worden.

Wat in de automatiseringsbranche onder ‘adviesdiensten’ wordt verstaan varieert sterk van aard. Vaak worden dienstverleners die werk uitvoeren ten behoeve van een klant ’consultants’ genoemd. Bijvoorbeeld programmeurs en systeemanalisten. Strikt genomen zijn dat geen adviseurs. Zij nemen wel beslissingen voor de klant op uitvoerend niveau, maar adviseren de klant daar niet over. Toch is het gebruikelijk dit wel als adviesdiensten aan te merken. Met wat goede wil kunnen deze diensten als “adviesdiensten met een commodity-karakter” worden gezien. Daar tegenover staan bijvoorbeeld adviezen waarin strategische scenario’s voor operationele bedrijfsvoering van een onderneming voor de komende tien jaar worden afgewogen. De operationele organisatie van veel ondernemingen hangt sterk af van automatiseringsmogelijkheden. In gevallen als dit betreft het ook zuiver adviezen, want de klant wint deze adviezen in om zelf een goede beslissing te kunnen nemen. Deze adviezen zijn complex en uniek, en dus geen commodity.

Adviesdiensten maken niet zelden een integraal onderdeel uit van automatiseringsprojecten. Als de opdrachtgever tijdens het project keuzes moet maken naar aanleiding van adviesdiensten, kunnen die keuzes zijn bedrijfsvoering en het project beïnvloeden. Projecten waarin dat aan de orde is, lenen zich niet voor toepassing van de ARBIT. De ARBIT laten nauwelijks ruimte voor een verantwoordelijkheidsverdeling die recht doet aan de belangrijke rol die een opdrachtgever speelt in dergelijke projecten. Een professioneel leverancier aanvaardt geen aansprakelijkheid voor projectverantwoordelijkheden van de klant.

Artikel 55 is het derde en laatste artikel dat onder het hoofdje ‘adviesdiensten’ staat, en bepaalt dat de relevante fasen van een project in de overeenkomst moeten worden benoemd, evenals de fatale termijn per fase. Het begrip ‘fatale termijn ‘ betekent dat overschrijding ervan automatisch leidt tot verzuim van de leverancier. Dat geeft de opdrachtgever bevoegdheden tot het verhalen van schade en het opschorten en ontbinden van de overeenkomst. Hieruit volgt dat projecten waarvan de op te leveren prestatie volledig kan worden beschreven, waardoor een leverancier bij de uitvoering onafhankelijk is van de opdrachtgever, op deze basis kunnen worden uitgevoerd. Voor projecten die afhankelijk zijn van de opdrachtgever is deze bepaling ongeschikt. Artikel 55 kan dus alleen werken voor ‘commodity’ IT overeenkomsten, en is zo een voorbeeld van een bepaling die het toepassingsgebied van de ARBIT impliceert.

Enkele artikelen uit de ARBIT nader beschouwd
De ARBIT worden hierna beschouwd binnen het kader waarvoor ze bedoeld zijn. Onderstaande analyses gaan er van uit dat sprake is van IT overeenkomsten voor goederen en diensten waarvan de inhoud vooraf volledig is bepaald.

Onderzoeksplicht
Artikel 4 legt de leverancier een onderzoeksplicht op. De opdrachtgever hoeft volgens dit artikel alleen informatie aan de leverancier te verstrekken. Het commune contractenrecht voorziet in een genuanceerde balans van wederzijdse onderzoeksplichten bij het aangaan van overeenkomsten. De ARBIT sluiten deze onderzoeksplicht van de opdrachtgever niet uit. De opdrachtgever houdt dus een onderzoeksplicht. Een voorbeeldje: Een ministerie bestelt 10 PC’s, en krijgt die geleverd. Bij een poging deze PC’s als servers in te zetten, blijkt dat ze daarvoor niet geschikt zijn. Hier geldt een eigen onderzoeksplicht van het ministerie, of de ARBIT nu gelden of niet. Anders ligt dat als een welomschreven servercapaciteit gevraagd zou zijn. Dan moet de leverancier eerst punten die niet helemaal duidelijk zijn navragen, en daarna een geschikte aanbieding doen. Als de aanbieding niet aan blijkt te sluiten bij het gevraagde, is dat de verantwoordelijkheid van de leverancier. Dat is zo, of de ARBIT van toepassing zijn of niet. Het artikel verheldert wellicht de verwachtingen van het Rijk, maar heeft juridisch niet veel effect.

Vervangen van personeel
In de artikelen 5 en 22 krijgt de opdrachtgever een vergaande bevoegdheid in te grijpen op een project door vervanging van personeel te verlangen. Daarvoor moet wel een reden zijn. Als achteraf blijkt dat voor een dergelijke ingreep geen goede reden bestond, dan moet de leverancier dat aantonen, en hij moet bewijzen dat door dat ongerechtvaardigde ingrijpen meerkosten en vertragingen zijn ontstaan. Van een opdrachtgever die direct ingrijpt op de wijze waarop een uitbestede dienst wordt uitgevoerd, zou op zijn minst verwacht mogen worden dat deze zelf actief verantwoording aflegt voor zijn ingrijpen. De ARBIT regelen dat niet de ingrijpende opdrachtgever iets hoeft te verantwoorden, maar dat de leverancier moet aantonen dat het ingrijpen niet te verantwoorden was, iets wat buitengewoon lastig zal zijn. De leverancier wordt hiermee in een kwetsbare positie gebracht.

Intellectuele eigendom
Artikel 8 voorziet er kort gezegd in dat de intellectuele eigendom van speciaal voor de opdrachtgever gemaakte software bij die opdrachtgever ligt. Voor leveranciers is dat natuurlijk niet altijd even plezierig, maar het is duidelijk.

Het artikel gaat diep in op het feit dat persoonlijkheidsrechten bij de opdrachtgever moeten komen te liggen. Voor auteursrecht gerelateerde persoonlijkheidsrechten kan dit, maar voor octrooirecht gerelateerde persoonlijkheidsrechten is deze bepaling nietig (art 14 ROW). De leverancier moet zorgen dat zijn personeel bij voorbaat afstand doet van persoonlijkheidsrechten, en daar zelf ook bij voorbaat afstand van doen. De ARBIT bepaalt daarover dat de opdrachtnemer bij voorbaat een onherroepelijke volmacht verstrekt aan de opdrachtgever. In de huidige stand van het recht wordt een dergelijke bepaling in algemene voorwaarden vermoed onredelijk bezwarend te zijn. Persoonlijkheidsrechten zullen bij softwareontwikkeling niet snel een dispuut opleveren, maar het is toch jammer dat de overheid bepalingen opneemt die deels nietig en deels normaal gesproken als onredelijk worden beschouwd.

Garanties
Artikel 12 verlangt garanties van de leverancier. Deze lijken binnen het toepassingsgebied niet onredelijk, en zijn deels verzekerbaar. De garantie van vijf jaar onderhoud is iets om even goed op te letten. Voor levering van bijvoorbeeld smartphones lijkt mij dat vijf jaar wel erg lang is. Een leverancier moet dan goed opletten deze termijn in de overeenkomst expliciet te verkorten.

Gebruiksrechten
De bijzondere bepalingen gebruiksrechten betreffen voorwaarden bij de aanschaf van programmatuur. Het is de vraag of standaardsoftware werkelijk onder deze voorwaarden aangeschaft kan worden. Het is niet gebruikelijk dat een leverancier van standaard software onderhandelt over de te verstrekken gebruiksrechten. Een standaardsoftwareleverancier zal niet graag aan versieregels van een klant gebonden zijn. Voor iedere klant zou dan een ander ontwikkelbeleid gevoerd moeten worden. Het voordeel van standaardsoftware is juist dat de leverancier een eigen eenduidig ontwikkelbeleid hanteert, waar alle klanten baat bij hebben. Men zou verwachten dat een Rijksoverheid juist geen zaken zou willen doen met een standaardsoftwareleverancier die zijn versiebeleid en ontwikkelingsstrategie afstemt op de wensen van één klant.

Hersteltermijnen
Met betrekking tot de oplevering van maatwerkprogrammatuur is in artikel 58.6 bepaald dat, als er gebreken worden geconstateerd bij de acceptatietest, die binnen een door de opdrachtgever vast te stellen redelijke termijn opgelost moeten worden. Als dat niet lukt mag de opdrachtgever zelf voor correctie zorgen op kosten van de leverancier. Deze bepaling levert een wat onevenwichtige situatie op. Wat voor de opdrachtgever een redelijke termijn lijkt, kan voor degene die het moet realiseren een onmogelijke termijn zijn. Voor de opdrachtnemer zal het echter niet eenvoudig zijn aan te tonen dat de door de opdrachtgever gestelde termijn onredelijk is. Dat betekent dat de opdrachtnemer bij een fout tijdens de oplevering de controle kwijt is. Het laten oplossen van fouten door een derde, in bij die derde vooraf onbekende programmatuur, zal vaak duur zijn. De situatie kan op eenvoudige wijze verbeterd worden, namelijk door te verlangen dat de opdrachtgever een motiveringsplicht krijgt bij het stellen van een termijn als hier bedoeld.

Tweede oplevering moet foutloos
Het recht om de overeenkomst te ontbinden als bij de tweede test nog steeds fouten geconstateerd worden, is een erg rigoureus middel. Zelfs bij uitgesproken degelijk testen kan een matig ingewikkeld stuk programmatuur in een tweede acceptatietest nog gemakkelijk fouten bevatten. Bijvoorbeeld: een systeem bevat 20 parameters met gemiddeld 4 verschillende waarden. Dat levert 4 tot de macht 20 combinaties op, wat 1600 miljard combinaties oplevert. Van een dergelijk matig complex systeem zijn niet alle combinaties uit te testen. Temeer niet, omdat als een fout hersteld wordt, in beginsel alle combinaties opnieuw getest moeten worden. In dit licht is de algemene regel dat fouten in een tweede test het recht geeft tot ontbinding van de overeenkomst, is in veel gevallen niet redelijk. Een dergelijk recht schept een situatie waarin de opdrachtgever op niet gedwongen is zich redelijk op te stellen. Hoewel er best situaties te bedenken zijn waarin deze bepaling redelijk is, is dat bij maatwerkontwikkeling vaak niet het geval. Leveranciers dienen er dus alert op te zijn hierover in de overeenkomst zelf het nodige op te nemen, en opdrachtgevers dienen er bedacht op te zijn dat een zorgvuldig leverancier dit zal verlangen.

Jaarlijkse controle
Volgens de bijzondere bepalingen over onderhoud moet de opdrachtnemer minstens één keer per jaar controleren of de geleverde prestatie goed functioneert. Bij applicaties waarbij disfunctioneren niet onmiddellijk opgemerkt wordt, wil je waarschijnlijk vaker controleren dan één keer per jaar, terwijl in andere gevallen een periodieke controle gewoon niet nuttig is. Partijen doen er beiden verstandig aan erop te letten afspraken hierover standaard in de overeenkomst op te nemen.

Fatale termijnen
Opdrachtnemers moeten zich bij het sluiten van een overeenkomst bewust zijn dat artikel 76.2 bepaalt dat Functiehersteltermijnen en Reactietijden gelden als fatale termijnen. Zij moeten dus niet lichtvaardig afgesproken worden. Als een opdrachtnemer niet zeker is die termijnen en tijden te realiseren, dan moet hij ze niet afspreken.

Onderhoud bevat innovatief onderhoud
Artikel 82 bevat een opmerkelijke formulering: als de opdrachtgever dat wenst, omvat het onderhoud ook innovatief onderhoud. Artikel 84 werkt de inhoud van innovatief onderhoud nader uit: Onder de ARBIT bestaat een standaard onderhoudsovereenkomst tevens uit nieuwe versies. Bij pakketsoftware is dat gebruikelijk, maar bij maatwerksoftware niet. Deze artikelen leggen de opdrachtnemer van maatwerk op dat hij onder het onderhoudscontracten nieuwe versies moet ontwikkelen als de opdrachtgever dat wenst. Dat dit als ‘onderhoud’ is aangemerkt, valt moeilijk te begrijpen. Immers, innovatief onderhoud op maatwerk is kostbaar. Het is alleen gewenst als daarvoor een uitgesproken reden bestaat, en zou om die redenen expliciet afgesproken moeten worden. Vooral de leverancier moet er alert op zijn prijsafspraken hierover specifiek te regelen in de overeenkomst. Doet hij dat niet, dan kan hij in de toekomst onverwacht substantieel meer verplichtingen onder het onderhoudscontract blijken te hebben dan hij verwachtte.

Overigens is het maar de vraag of de verplichting nieuwe versies te leveren op maatwerksoftware geen kernbeding betreft, en daardoor geen algemene voorwaarde is, maar in de overeenkomst ze3lf moet zijn opgenomen. Het zal in een onderhoudscontract in veel gevallen de hoofdprestatie zijn die de leverancier moet leveren. Als in de overeenkomst niets verder is opgenomen, en de opdrachtgever zou een beroep willen doen op deze bepaling, dan zal al snel onenigheid ontstaan over wat wel en niet onder het begrip innovatief onderhoud moet worden verstaan in een specifiek geval.

Samenvatting
De ARBIT zijn voor het grootste deel prima toepasbaar op ‘commodity’ IT diensten en producten. De ARBIT zijn niet bedoeld en niet geschikt voor een project waarin de opdrachtgever het project inhoudelijk sterk beïnvloedt. Dat is bijvoorbeeld het geval bij veel zakelijke automatiseringsprojecten. Toepassing van de ARBIT in dergelijke gevallen zal het risico op een mislukt project vergroten door de verstorende werking van de ARBIT op een evenwichtige verdeling van verantwoordelijkheden tussen opdrachtgever en leverancier.

Binnen de categorie IT overeenkomsten waarvoor de ARBIT bedoeld zijn, zijn enkele kanttekeningen te maken bij de ARBIT. Een aanbestedende instantie dient alert te zijn dat leveranciers onderstaande punten in de relevante gevallen onderkennen en ter discussie stellen. Doet een leverancier dat niet, dan kan dat aanleiding zijn vraagtekens bij de professionaliteit van die leverancier te zetten.

De kracht van standaardsoftware zit hem in de mogelijkheid voor veel klanten tegelijk software te ontwikkelen en gestandaardiseerd uit te brengen. De ARBIT regelen het versiebeheer van standaardsoftwareleveranciers. Een opdrachtgever moet zich ernstig afvragen of hij een standaardsoftwareleverancier wil die de kern van zijn bedrijfsvoering, namelijk het versiebeheer van zijn software, aanpast aan één klant, omdat die klant dat verlangt in zijn inkoopvoorwaarden. In beginsel is dat geen goed idee.

De leverancier wordt door de ARBIT op twee manieren in een kwetsbare positie voor willekeur van een opdrachtgever gebracht. De eerste is dat de opdrachtgever personeel van de opdrachtnemer kan doen vervangen, zonder daarvoor zelf consequenties te hoeven dragen. Een deugdelijke verantwoording door de opdrachtgever voor een dergelijk ingrijpen zou op zijn plaats zijn. De tweede is dat de opdrachtgever de overeenkomst mag ontbinden als in een tweede acceptatietest nog fouten gevonden worden. Bij maatwerkontwikkeling van enige omvang zal deze bevoegdheid bijna zeker ontstaan, ongeachte de kwaliteit van de leverancier. De opdrachtgever mag daardoor dergelijke overeenkomsten vaak in een laat stadium ontbinden, met behoud van recht op schadevergoeding. Het gevolg van ontbinding voor de opdrachtnemer is dat hij alle ontvangen vergoedingen onder de overeenkomst moet terugbetalen, plus eventuele schadevergoeding. Een professionele opdrachtnemer zal een dergelijk risico niet accepteren.

De toepasbaarheid van een aantal bepalingen in de ARBIT is sterk afhankelijk van de aard van de in te kopen producten of diensten. Dit geldt voor de garantieperiode van vijf jaar, dat onderhoud per definitie inhoudt dat de geleverde prestatie één keer per jaar door de leverancier moet worden gecontroleerd, en dat innovatief onderhoud standaard binnen het begrip ‘onderhoud’ valt. Zowel opdrachtgevers als leveranciers moeten er alert op zijn deze punten altijd in de overeenkomst zelf te regelen. Gebeurt dat niet, dan kunnen de ARBIT ongewenste situaties in het leven roepen, en, vooral voor leveranciers, ook onverwachte verplichtingen.

Conclusie
De ARBIT zijn alleen bedoeld voor IT producten en diensten waarvan het resultaat vooraf in detail bekend is. Voor diensten waarbij dat niet het geval is, moeten zijn niet worden toegepast. Als dat wel gebeurt, roept dat voor de opdrachtgever serieuze risico’s in het leven. De kans op een succes zal afnemen door de mismatch tussen verantwoordelijkheden en aansprakelijkheden. Een leverancier die in een dergelijk geval de ARBIT accepteert, verdient enige argwaan.

Binnen het toepassingsgebied bevatten de ARBIT een aantal bepalingen waar vooral de leveranciers iedere keer bij stil moeten staan. Zo nodig moeten zij ervoor zorgen dat die bepalingen in de overeenkomst genuanceerd worden. Opdrachtgevers doen er goed aan leveranciers die dat nalaten met reserves te beschouwen, omdat dergelijk nalaten niet van een professionele houding getuigt.

ARBIT-voorwaarden: klik hier