Algemene Voorwaarden en IT – Inleiding

In de IT worden allerlei algemene voorwaarden toegepast. Algemene voorwaarden zijn in de wet gedefinieerd als: “een of meer bedingen die zijn opgesteld teneinde in een aantal overeenkomsten te worden opgenomen, met uitzondering van bedingen die de kern van de prestaties aangeven, voor zover deze laatstgenoemde bedingen duidelijk en begrijpelijk zijn geformuleerd”. Het zijn dus standaard contractvoorwaarden. Bijna alle contracten in de IT bestaan voor het overgrote deel uit algemene voorwaarden. Pas je een voorwaarde voor een specifieke overeenkomst aan uit een set algemene voorwaarden, dan is die ene voorwaarde op dat moment niet meer een algemene maar een specifieke voorwaarde.

“Bedingen die de kern van de prestaties aangeven, voor zover deze laatstgenoemde bedingen duidelijk en begrijpelijk zijn geformuleerd”, worden meestal kernbedingen genoemd. Bijvoorbeeld, bij een koopovereenkomst worden wat er geleverd wordt en de prijs die daarvoor wordt betaald, als kernbedingen gezien.

De wet definieert ‘algemene voorwaarden’ omdat er een aantal bijzondere regels voor gelden. De belangrijkste luidt: “Een wederpartij is ook dan aan de algemene voorwaarden gebonden als bij het sluiten van de overeenkomst de gebruiker begreep of moest begrijpen dat zij de inhoud daarvan niet kende.” In deze context wordt onder ‘gebruiker’ verstaan de partij die de algemene voorwaarden aanbiedt en de ‘wederpartij’  degene aan wie ze worden aangeboden. Dit geldt dus niet voor kernbedingen. Je kunt dus bijvoorbeeld niet aan een koopprijs gebonden zijn die je niet kende. Omgekeerd, kunnen algemene voorwaarden (of je ze nu wel of niet gelezen had voor je ze aanvaarde) ook ‘onredelijk bezwarend’ zijn. Is de wederpartij een consument, dan kan al snel sprake zijn van onredelijke bezwarendheid. Bij gebruik tussen ondernemingen is daarvan veel minder snel sprake. Dat komt, omdat een ondernemer geacht wordt niet blind in te stemmen met algemene voorwaarden, maar ze eerst wel even te bekijken. Er is dan veel minder snel sprake van ‘onredelijkheid’.

Algemene ICT voorwaarden worden meestal opgesteld door leveranciers, maar grote opdrachtgevers hanteren vaak hun eigen algemene ICT inkoopvoorwaarden. Leveranciers in de IT passen vaak zelf opgestelde algemene voorwaarden toe. Dat is vooral zo bij levering van standaard software. Bij diensten worden ook vaak de branche standaarden toegepast. In deze blog behandel ik, na de functie van algemene voorwaarden in algemene zin,  in hoofdlijnen de NLdigital voorwaarden van de IT branche en de overheidsvoorwaarden ARBIT en GIBIT. Daarna ga ik in op productspecifieke algemene voorwaarden. Ik sluit af met vergelijkingen op hoofdlijnen.

De functie van ICT voorwaarden

De hoofdfunctie van algemene ICT voorwaarden is het verdelen van verantwoordelijkheden en risico’s tussen de partijen. In de  IT is dat essentieel. Waar in veel andere sectoren schadeaansprakelijkheid van leveranciers onbeperkt is, is dat bij IT eigenlijk nooit zo. Hoe komt dat? Wel, als je een bedrijfsproces automatiseert, dan is het de bedoeling dat er van alles automatisch goed gaat en er minder fouten zijn op transactieniveau. Dat is waar je een automatiseerder voor betaalt. Gaat er echter iets mis, dan is dat niet bij een enkele transactie, maar bij alles. Zou dergelijke schade verhaalbaar zijn op de leverancier, dan zou je niet zozeer voor het verbeteren van je proces betalen, maar voor het afdekken van risico’s op procesfouten in de bedrijfsvoering. Dat laatste bestaat wel, maar dat heet ‘verzekeren’, en dat is iets fundamenteel anders dan automatiseren. Bovendien, risico’s verbonden aan de kern van de bedrijfsvoering – die door te automatiseren beperkt worden – zijn normaal gesproken niet eens verzekerbaar. En dat geldt ook als je automatiseerder bent.

Dit fenomeen zorgt er voor dat bij ICT voorwaarden altijd aansprakelijkheidsbeperkingen bevatten. Nu kan aansprakelijkheid alleen ontstaan uit iets waarvan je verplicht bent het te leveren. Bij IT producten en diensten kan je dat op allerlei manieren formuleren. Als softwareleverancier zal je bij voorkeur alleen ‘leveren van de software’ afspreken, maar als klant gaat het er natuurlijk alleen om dat die software doet waarvoor hij hem koopt. De manier waarop dit vorm gegeven wordt, is via garanties – of juist uitsluitingen van garanties. Met name op dit punt bestaan grote verschillen tussen de diverse sets algemene voorwaarden.

NLdigital voorwaarden

In Nederland zijn de meest toegepaste voorwaarden die van NLdigital, een brancheorganisatie voor IT bedrijven die onder dezelfde naam standaard algemene ICT voorwaarden uitgeeft. Deze voorwaarden gingen in het verleden onder de namen “Nederland ICT voorwaarden”, “ICT Office Voorwaarden” en daarvoor nog de “Fenix Voorwaarden”. Ook inhoudelijk zijn deze voorwaarden in de loop van de tijd geëvolueerd. Onder de naam “ICT Office Voorwaarden” was het een modulair systeem. Je moest als leverancier per opdracht de relevant modules selecteren en aanbieden aan (potentiële) klanten. Dat ging vaker fout dan goed, want er werden meestal teveel, te weinig of de verkeerde modules aangeboden. Dat systeem is redelijk snel weer verlaten en er is sinds “Nederland ICT voorwaarden” weer één set voor alles.

Omdat de NLdigital voorwaarden door de IT branchevereniging zijn opgesteld, wekt het geen verbazing dat de klant wat meer risico’s krijgt toebedeeld dan de leveranciers. De hoofdbepalingen zijn dat aansprakelijkheid voor ‘indirecte schade’ is uitgesloten, en voor directe schade is het beperkt tot de bedongen prijs – bij duurovereenkomsten die voor één jaar, en een absoluut maximum van €500.000. Omdat ‘indirecte schade’ geen wettelijk begrip is, staat dit als volgt uitgewerkt: “Indirecte schade, gevolgschade, gederfde winst, gemiste besparingen, verminderde goodwill, schade door bedrijfsstagnatie, schade als gevolg van aanspraken van afnemers van klant, schade verband houdende met het gebruik van door klant aan leverancier voorgeschreven zaken, materialen of programmatuur van derden en schade verband houdende met de inschakeling van door klant aan leverancier voorgeschreven toeleveranciers is uitgesloten.” Dit sluit het overgrote deel van het ‘normale’ Nederlandse schadebegrip uit.

De garantie op SaaS diensten, programmatuur en andere dienstverlening is beperkt tot een inspanningsverplichting: De leverancier moet zich inspannen fouten te herstellen, maar mag dat met tijdelijke omwegen doen.

Het komt er kort gezegd op neer dat, als er fouten zijn en de leverancier neemt geen serieuze poging die op te lossen, dan kan hij aansprakelijk zijn voor schade aan data en eventueel aan programmatuur (kosten van vervanging wellicht) tot maximaal 5 ton of de afgesproken (jaar)prijs, als dat minder is. Klanten kunnen hierdoor hoogst zelden beroep doen op juridische actie: de kans op een succesvolle schade-aansprakelijkheid is klein door de vergaande garantiebeperking in combinatie met de eveneens vergaande aansprakelijkheidsbeperking. Voor afnemers is het niet zo snel aantrekkelijk te gaan procederen als deze voorwaarden van toepassing zijn. De belangrijkste ontsnapping aan deze voorwaarden voor afnemers is als de leverancier opzettelijk nalatig is. Op grond van het dwingend recht is aansprakelijkheidsbeperking in die gevallen niet mogelijk.

De klant mag opdrachten van bepaalde tijd en met een vastgesteld doel niet opzeggen. Bij onbepaalde tijd mogen beide partijen met een redelijke termijn opzeggen, waarbij de leverancier nooit een schadevergoeding hoeft te betalen.

Hiernaast zijn er diverse andere bepalingen. Bijvoorbeeld, als er programmatuur wordt ontwikkeld, dan blijven de auteursrechten bij de leverancier. Risico van leveringen gaat direct bij levering over, maar eigendom pas na betaling. Er is een uitgebreid artikel over informatie- en overige medewerkingsverplichtingen. Dit artikel legt de klant een reeks verplichtingen op die er voor zorgen dat de risico’s van miscommunicatie – wat in de IT de grootste oorzaak van problemen is – de-facto bij de klant liggen.

Tot slot staat in de NLdigital voorwaarden een arbitragebeding. Er moet geprocedeerd worden bij de Stichting Geschillen Oplossing Automatisering, de SGOA. Op zich is daar wel wat voor te zeggen. Materiedeskundigen als arbiter in plaats van een algemene rechter en geen beroepsmogelijkheden kunnen aantrekkelijke kanten van deze vorm van rechtspleging zijn. Hoewel ik niet twijfel aan de integriteit van de aangesloten arbiters en andere deskundigen, krijgt deze stichting bijna al haar werk via deze NLdigital voorwaarden en dus eigenlijk via de IT branchevereniging. Dat is een wat moeizame situatie omdat er geen volledig onafhankelijkheid is of toch in ieder geval kan deze omstandigheid de schijn daarvan oproepen. Het zou mooi zijn als iets als de SGOA een soort afdeling van het Nederlands Arbitrage Instituut zou functioneren in plaats van als zelfstandige stichting die een indirecte afhankelijkheid heeft van één kant van de partijen in de geschillen die zij behandelt.

ARBIT voorwaarden

ARBIT staat voor Algemene Rijksvoorwaarden Bij IT overeenkomsten. Ik heb in 2011 al eens gepubliceerd over de ARBIT voorwaarden in Computable. Dat ging toen over de vraag of een aanbestedende dienst wel altijd onverkort vast zou moeten houden aan de ARBIT, of beter zou kunnen voorsorteren op noden van de leveranciers die vaak voorzienbaar in conflict zijn met de ARBIT. Als je als aanbestedende dienst in de aanbesteding voorwaarden stelt die het lastig maken voor leveranciers een voor hen winstgevende aanbieding te doen dan wel risico’s tot een voor hen aanvaardbaar niveau te beperken, dan zullen betrouwbare bedrijven die hun eigen bedrijfsvoering op orde hebben niet inschrijven, wat omgekeerd ook iets minder positiefs over de wel inschrijvende bedrijven zegt. Overigens zijn er sindsdien wel wat scherpe randjes verwijderd uit de ARBIT. Het blijft belangrijk het niet per definitie ongewijzigd van toepassing te verklaren en er altijd eerst nog eens kritisch door te gaan voordat je een aanbesteding doet, maar de kans op conflicten is nu kleiner dan toen.

Ook de ARBIT beperkt de aansprakelijkheid van de leverancier. Echter, het gaat hier om vier maal de overeengekomen prijs voor alle vormen van schade onder het ‘normale’ Nederlandse schadebegrip. Dat is dus nogal wat ruimer dan de NLdigital aansprakelijkheid. Niettemin blijft het risico redelijk verzekerbaar voor de leverancier, waardoor dit geen obstakel hoeft te vormen.

Ook de garantie heeft een volkomen ander karakter: “Wederpartij garandeert voor de duur van twaalf maanden na Acceptatie, dat hij Gebreken voor zijn rekening herstelt.” Onder een dergelijke garantie ontstaan uiteraard veel eerder rechten voor de klant. Toch zit er een tijdsbeperking is, wat getuigd van enige beperking van de eigen belangen.

Alle rechten van Intellectuele eigendom die op kosten van de klant zijn ontwikkeld, komen toe aan de klant. Ook dit staat lijnrecht tegenover de NLdigital voorwaarden. Vanuit het principe dat degene die alles betaalt, de vruchten zou moeten plukken, ben ik geneigd de ARBIT uitgangspunten hier wat voor de hand liggender te vinden dan die van NLdigital.

De ARBIT bepaalt dat, als de leverancier iets niet weet, het zijn verantwoordelijkheid was te zorgen dat hij alles wat van belang kon zijn, wel had uitgevraagd. De verantwoordelijkheid voor communicatiestoringen wordt hier dus bijna geheel bij de leverancier gelegd: hij had beter onderzoek moeten doen. Dat is wel weer een vergaand uitgangspunt. De informatie moet in beginsel van de afnemer komen en het is dan tamelijk eenzijdig om, als die informatie niet of onvolledig wordt verstrekt, dat risico bij de ander te leggen. Ik vraag me hier af of je als afnemer hier nu mee geholpen bent. Het zet de deur voor je eigen mensen open voor een passieve houding en nalatigheid. Dat is niet alleen voor de leverancier vervelend, maar vooral voor de eigen organisatie. Het is daarom vaak een onhandig uitgangspunt. Veel beter zou het zijn hier wat specifieke op in te gaan in de omschrijving van de opdracht.

Vaak is het sterkste recht voor een afnemer de mogelijkheid snel op te zeggen. Voor opzeggen hoef je niet naar de rechtbank, wat voor de meeste remedies wel het geval is. Opzegging kan soms een vervelende dreiging zijn en leveranciers kunnen daar meer door gemotiveerd worden dan drieging met bijvoorbeeld schadeacties. De ARBIT voorziet hiervoor een prima regeling. De opdrachtgever mag overeenkomsten altijd opzeggen als hij een ‘redelijke termijn’ in acht neemt. Bij niet -doorlopende opdrachten is er een regeling voor een vorm van beëindigingsvergoeding opgenomen.

Risico-overgang gebeurt bij levering. Eigendomsovergang door acceptatie. Een uitgebreid artikel is gewijd aan acceptatie.

GIBIT voorwaarden

GIBIT staat voor Gemeentelijke Inkoopvoorwaarden Bij IT. In de inleiding van de GIBIT staat onder meer: “Vanuit de verkenning is geadviseerd om de ARBIT als basis te gebruiken voor de  gemeentelijke inkoopvoorwaarden. Specifieke zaken die binnen het gemeentelijk domein relevant zijn, dienen toegevoegd te worden, zoals: bepalingen omtrent flexibiliteit (onder meer bij samenwerkingen en migraties), het (aantoonbare) gebruik van standaarden (onder meer gemeente specifieke standaarden), veiligheid (onder meer informatiebeveiliging en privacy) en aansluiten op Cloud-ontwikkelingen en landelijke infrastructuur.

Hieruit komt ‘gemeente-specifieke standaarden’ als bijzonderheid ten opzichte van het Rijk aannemelijk over, al zou je verwachten dat dit in aanbestedingsstukken verbijzonderd wordt en niet in algemene contractvoorwaarden voorwaarden. De andere punten komen toch een tikje merkwaardig over. Waarom zou het Rijk andere algemene eisen aan flexibiliteit, veiligheid en aansluitmogelijkheden hebben? Een ook hier: als het specifieker wordt, zijn dat zaken die in algemene voorwaarden horen?

De GIBIT is niet alleen anders op de genoemde punten, maar is anders gestructureerd. In de GIBIT staan nog wat meer dingen waarvan je denkt: ‘wat heb je daar nu aan als gemeente?’ Bijvoorbeeld opnemen dat de leverancier verplicht is een SLA aan te bieden. Ik zou niet weten waarom een leverancier dat niet zou willen doen, omdat 90% van de SLA’s in de IT feitelijk werken als garantie-beperkingen, waarover hieronder meer. Een SLA aangaan nadat alle echte serviceovereenkomsten al gesloten zijn, dat loopt voor de klant niet vaak goed af. Ook de algemene verwijzing naar ‘gemeentelijke standaarden’ komt niet erg constructief over. Daar zijn er namelijk nogal wat van en je zou verwachten dat, als je gaat aanbesteden, je als aanbestedende dienst expliciet aangeeft aan welke standaarden moet worden voldaan. Als algemene verplichting is dit veel te vaag en dat kan alleen maar tot eindeloze discussies in rechte leiden.

De garanties die de GIBIT eist zijn verdergaand dan die van de ARBIT: Er is geen maximum termijn.

De aansprakelijkheidsclausule is wat gecompliceerder dan die van de ARBIT en lijkt leveranciersaansprakelijkheid iets verder te beperken door specifiek categorieën schade te benoemen en een maximum van €5 miljoen op de vier keer de opdrachtwaarde toe te voegen.

Eén van de meest aantrekkelijke kenmerken van de ARBIT, namelijk flexibiliteit in opzegmogelijkheden, ontbreekt in de GIBIT. De GIBIT bepaalt dat tijdelijke overeenkomsten niet, en doorlopende met een opzegtermijn van 18 maanden kunnen worden opgezegd.

Productspecifieke algemene voorwaarden

In de IT moeten twee vormen van softwareproducten worden onderscheiden: Software licenties en Software as a Service (SaaS). De afnemer van het eerste verwerft een recht om een kopie van software te maken en die ergens voor te gebruiken. De afnemer van het tweede niet. Die verwerft een recht om gebruik te mogen maken van de informatiesystemen van een ander, waarop specifieke software gebruikt kan worden. In het eerste geval koop (ingeval van een oneindig gebruiksrecht) of huur (ingeval van een tijdelijk gebruiksrecht) je een kopie van de software (voor een afgebakend doel), in het tweede geval neem je een dienst af.

In het geval van een auteursrechtelijke licentie, krijg je dus alleen maar een kopie van een setje bits en bytes. Die koop je, omdat je de verwachting hebt daar iets nuttigs mee te kunnen doen. Als dat niet zo is, heb je er natuurlijk niets aan. Je wilt daarop dus een soort van garantie hebben. Hoe ver die garantie rijkt, hangt sterk af van het soort software, hoewel garanties op software bijna altijd zeer beperkt zijn. Bij softwaregaranties loopt de leverancier twee risico’s die hij wil voorkomen. Ten eerste kunnen er fouten in software zitten. Als software op een niet van tevoren afgebakend aantal manieren kan worden ingezet, dan is volledig voorkomen van fouten nog steeds praktisch onmogelijk. Ook kunnen door veranderende omgevingsfactoren bepaalde ‘normale’ functies plots een ‘fout’ worden. Software die onlosmakelijk vast onderdeel is van een machine (ofwel ‘embedded software’), kan vaak wel volledig getest worden, omdat alle mogelijke manieren van gebruik van een machine vaak ook wel getest kunnen worden.

Daarnaast is er de verwachting die klanten hebben van de functionaliteit. Als mensen software eenmaal gebruiken, is die vaak snel hoger dan wat de software biedt. Verwachtingen ten aanzien van software zijn subjectief en snel veranderend.

Bij embedded software wordt meestal ruime garantie gegeven. Maar anders is dat meestal juist zeer beperkt. Ook op de software op uw iPhone heeft u bijna geen garantie. Dat is geen probleem, want Apple zorgt natuurlijk wel dat ze niet opeens een paar miljard boze klanten hebben. Alleen, als je schade leidt doordat iets niet lekker werkt, dan hoef je niet aan te kloppen voor schadevergoeding of voor een onmiddellijke oplossing van het probleem.

Softwarelicenties gaan meestal verder tamelijk specifiek in op wat gebruikers wel en niet met de software mogen doen. De algemene voorwaarden vormen in die zin eigenlijk het business model van de softwareleverancier. Voor welk gebruik wil de leverancier welke vergoeding? Een ander soort gebruik moet dan dus worden uitgesloten, want daarvoor kan eventueel weer een andere vergoeding gevraagd worden. Ook allerlei vormen van bescherming tegen verspreiding van de software kunnen in dergelijke voorwaarden geregeld worden. Dit zijn vaak tamelijk specifieke zaken voor specifieke software en dat is dan ook de reden waarom voor standaard software meestal algemene voorwaarden gebruikt worden die voor die specifieke software zijn opgesteld, en geen branche-standaarden.

Bij softwarelicenties is er altijd één bijzonder onderwerp wat goed geregeld moet worden, en dat zijn de vrijwaringen van de klant in geval van claims van derden, dat de klant door gebruik te maken van de betreffende software, inbreuk zou maken op rechten van die derde. Een softwarelicentie is een auteursrechtelijk gebruiksrecht. Als de leverancier niet bevoegd zou zijn om dat te leveren, dan is er dus eigenlijk helemaal niets geleverd. In de meeste landen kunnen de gevolgen daarvan door de leverancier niet worden beperkt. Anderzijds, als bonafide leverancier, wil je absoluut niet dat de klant daar zelf over gaat procederen (en het wellicht verprutst). Wat je in zo’n geval wil, is alle klanten die zijn aangesproken zelf vertegenwoordigen en één procedure tegen de claim voeren, om die zo snel mogelijk van tafel te krijgen. Beide partijen hebben dus belang bij een vrijwaringsafspraak en die hoort in iedere softwarelicentie te staan.

Bij SaaS is het allemaal wat anders. Wat de functionaliteitsgaranties op en garantie op ontbreken van fouten in software betreft niet: dat is even beperkt. De gebruiksbeperkingen zijn vaak wat eenvoudiger omdat de leverancier vaak de mogelijkheid heeft heel specifiek functionaliteit aan te bieden waarover hij zich, wat misbruik betreft, niet al teveel zorgen hoeft te maken. Meestal is er wel een soort ‘redelijk gebruik’ bepaling, die ingrijpen mogelijk maakt als een klant een systeem misbruikt voor iets waar het duidelijk niet voor is bedoeld en dat gebruik overlast veroorzaakt. Je krijgt geen kopie van de software en de software hoeft dus ook niet zo uitgebreid beschermd te worden. Maar dat de functies bereikbaar zijn, daarop moeten meestal wel garanties gegeven worden. Leveranciers met een machtpositie zullen ook dat in de praktijk zo formuleren dat er nooit een beroep op gedaan kan worden en gebruikers moeten er dan op rekenen dat het goed zal gaan, omdat anders de klanten allemaal weg lopen. Bij specifiekere SaaS diensten zullen afnemers vaak harde garanties willen en invloed wensen op maatregelen om problemen op te lossen. Immers, is een informatiedienst niet beschikbaar, betekent dat vaak dat organisaties gewoon niet kunnen functioneren. Een SaaS dienst in gebruik nemen zonder beschikbaarheidsgaranties van één of andere soort, is niet verantwoord. Maar ook hier zal een leverancier geen schaderisico accepteren als de dienst dan toch niet beschikbaar is. Eenvoudigweg omdat leveranciers dergelijke schade niet kunnen dragen of verzekeren.

Bij SaaS diensten is er vaak een aparte overeenkomst waarin de beschikbaarheidsafspraken vastgelegd worden, een  Service Level Agreement, ofwel SLA. Leveranciers bieden die vaak graag aan. Er staan indrukwekkende dingen in als ‘99% beschikbaarheid wordt gegarandeerd’. Omdat er vaak niet bij staat over wat voor periode dat wordt gemeten, in welke eenheden en hoe het wordt gemeten (meestal wordt er helemaal niet gemeten), betekent het niet zo veel. Ook staat er elders meestal dat dit exclusief ‘downtime voor onderhoud’ is. Als dat niet heel helder wordt geformuleerd, betekent het percentage ook niets. Gaat het systeem down, dan is er immers onderhoud. Iedere SLA die onduidelijkheden bevat, is feitelijk een garantiebeperking. Vaak ben je zonder SLA beter af dan met.

Bij SaaS diensten worden door de leverancier gegevens van de gebruikende organisatie verwerkt. Daarover moet van alles worden afgesproken: Hoe aan de Algemene Verordening Gegevensverwerking (AVG) wordt voldaan en hoe de gegevens in algemene zin beschermd worden. Bij standaard SaaS diensten zal een leverancier anticiperen op behoeften die hij kan verwachten in de markt. Zijn die eisen hoog, dan wordt juist op dit vlak wel wat meer gegarandeerd. Dat betekent trouwens niet dat je veel kunt met die garanties. Schadeaansprakelijkheid is toch ook in deze gevallen meestal erg beperkt en andere remedies zijn niet gemakkelijk te nemen. Je kunt proberen weg te gaan bij de aanbieder, maar dat kan ook zonder die garanties. Flexibiliteit voor opzegging en transitie naar een andere dienst is eigenlijk de enige manier om risico’s werkelijk te beperken.

Vergelijking en conclusies

De NLdigital voorwaarden worden zeer breed toegepast. Daardoor is het de-facto een marktstandaard in Nederland. De verklaring daarvoor is dat afnemers meestal de algemene voorwaarden niet lezen. Met name de lock-in die door moeizame afscheidsclausules en ongunstige IE afspraken zijn opgenomen, maar ook de praktische onmogelijkheid garanties te verlangen en al helemaal om schade te verhalen, brengen afnemers meestal in de positie dat ze feitelijk helemaal niets kunnen verlangen van hun leverancier en de leverancier ruim baan heeft te doen waar hij zin in heeft. Bij juridisering van conflicten staat de leverancier eigenlijk altijd sterker. Alleen als opzettelijk schade toebrengen verweten kan worden (en bewezen kan worden) dan zijn er juridische mogelijkheden voor de afnemer. Tegen doodgewoon geklungel niet. En dan is er nog de dreiging dat ook de leverancier gewoon kan opzeggen (bij overeenkomsten voor onbepaalde tijd). Dat kan ook bijzonder vervelend zijn.

In de IT is de klant eigenlijk altijd al wel de kwetsbare partij. Dat komt door de aard van de materie (de klant wordt er afhankelijk van), maar ook doordat schadeverhaal geen realistische actie is, en schadeverhaal is wel waarop het civiele recht voornamelijk gebaseerd is. Het ligt daarom eigenlijk meer voor de hand om – afgezien van aansprakelijkheid – wat meer mogelijkheden te eisen als afnemer om risico’s te beperken. Het rijk heeft dat met de ARBIT grotendeels succesvol gedaan. Het zijn voorwaarden die voor de meeste leveranciers nog wel werkbaar zijn, maar die de afnemer toch een redelijke mate van bescherming bieden. De GIBIT is een afgeleide van de ARBIT maar, zou ik IT inkopen voor een gemeente, dan zou ik waarschijnlijk meestal de voorkeur aan de ARBIT geven. Als leverancier zou me ARBIT of GIBIT lood om oud ijzer zijn.

Wat eigenlijk standaard in de ARBIT (maar ook in de GIBIT dus) opgenomen zou moeten zijn, is dat standaard software en standaard SaaS diensten onder de voorwaarden van de leverancier afgenomen worden. Daarbij zou ‘standaard’ wel goed gedefinieerd moeten worden. Dat zou iets moeten zijn als dat het in exact dezelfde vorm gebruikt wordt door minstens x verschillende organisaties, dan wel dat de leverancier kan bewijzen dat de software niet is ontwikkeld ten behoeve van één specifieke organisatie (om ook nieuwe software mee te kunnen nemen). In de praktijk wordt hier zo wel mee omgegaan, maar alleen bij partijen die marktmacht hebben. Dat is aanbestedingstechnisch een slechte zaak. Je moet als aanbesteder iedereen gelijk behandelen. Dat je standaard voorwaarden voor standaard software en SaaS diensten accepteert, is als algemeen uitgangspunt goed verdedigbaar, omdat die voorwaarden deel uitmaken van het gebodene en de prijs daarop is afgesteld. Een aanbestedende dienst doet er verstandig aan dit, als het relevant is voor de aanbesteding, als afwijking op de ARBIT (dan wel GIBIT) op te nemen. Eventueel zou je wel kunnen opnemen wat er in ieder geval niet in dergelijk leveranciersvoorwaarden mag staan, zoals boetebedingen of bepalingen die de afnemer beperken in zijn mogelijkheden zich aan wettelijke verplichtingen te houden.

Bij particuliere afnemers van standaard software (en SaaS) zijn voorwaardenonderhandelingen bijna helemaal van marktmacht afhankelijk. Zowel bij de afnemer: Grote afnemers kunnen hardere eisen stellen, als bij de leveranciers: Als er geen serieus alternatief is, dan onderhandel je gewoon nooit.

Wat nu als een leverancier met eigen voorwaarden komt voor de afname van andere IT diensten dan standaard software en SaaS? Kijk er als afnemer altijd heel kritisch naar. Vaak is het nog nadeliger dan de NLdigital voorwaarden. Krijg je ooit onenigheid, dan zit je als klant op alle mogelijke manieren klem. Boven alles: zorg er voor dat je zonder al te grote problemen weg kunt. Lock-in was, is en blijft het grootste risico voor afnemers. Probeer lock-in vooraf zo ver mogelijk te minimaliseren. Dat is voor afnemers met stip het belangrijkste in bijna iedere IT overeenkomst.

Meer informatie?

Neem vrijblijvend contact op met onze advocaat

Geef een reactie