Toelichting op de wijzigingen op de GIBIT De GIBIT 2023 is in wording.
Toelichting op de wijzigingen op de GIBIT
De GIBIT 2023 is in wording.
In dit document wordt een toelichting van de wijzigingen per artikel gegeven. In principe wordt iedere wijziging toegelicht, met dien verstande dat veelvoorkomende wijzigingen (zoals zoek/vervang wijzigingen) slechts één keer worden toegelicht.
Artikel 1, aanhef
Het onderscheid tussen de Inkoopvoorwaarden enerzijds (het betreffende document) en de GIBIT anderzijds (de toolbox waar de Inkoopvoorwaarden onderdeel van uit maken) wordt in de aanhef al gemaakt.
Ook wordt – ter voorkoming van ruis – ditmaal uitgewerkt dat begrippen zowel in enkelvoud als in meervoud in de Inkoopvoorwaarden voorkomen.
Artikel 1.1
Aan het artikel is een verwijzing naar artikel 9.10 (over impliciete acceptatie) toegevoegd. Dit is gebeurd in reactie op feedback van leveranciers.
Artikel 1.3
Het begrip Aflevering is toegevoegd. Dit komt terug in het eveneens nieuw toegevoegde artikel 5 over transport, eigendom en risico van Producten. Hiervoor is gekozen omdat de GIBIT tot op heden niet zo veel aandacht had voor fysieke producten. Het begrip is overgenomen uit de ARBIT.
Artikel 1.4
Het begrip Algoritmische toepassing is toegevoegd. Dit komt terug in het eveneens nieuw toegevoegde artikel 13 over dergelijke toepassingen. Zie de toelichting aldaar.
Artikel 1.7
Het begrip Bestek is toegevoegd. Het is een in aanbestedingsprocedures veel gebruikt begrip. Het gebruik van het begrip vergroot de herkenbaarheid en uniformiteit van documenten. Het begrip is overgenomen uit de ARBIT.
Artikel 1.11
Het oude begrip Hosting is hernoemd tot het begrip Dienstverlening op Afstand. Ter verheldering zijn er ook de woorden “(zoals cloud, ASP, SaaS, PaaS)” aan toegevoegd. Inhoudelijk gezien is er geen sprake van een wijziging; alle vormen van cloud, ASP, SaaS en PaaS zouden immers al onder de oude definitie van Hosting hebben gevallen. Op Dienstverlening op Afstand (voorheen: Hosting) is het bepaalde in hoofdstuk III van toepassing.
Artikel 1.17
De definitie van GIBIT 2022 is toegevoegd. Het doel is vooral te verhelderen dat met het begrip GIBIT voortaan altijd de gehele toolbox wordt bedoeld, niet slechts de inkoopvoorwaarden. Het is bekend dat dit begrip verder niet terugkomt in de tekst.
Artikel 1.18
Het woord zaken is door Producten veranderd in de definitie van ICT Prestatie. Inhoudelijk gezien is geen wijziging beoogd. De praktijk leerde evenwel dat de juridische begrippen “zaken” en “goederen” bij menig lezer tot verwarring leidde.
Artikel 1.21
Het begrip Inkoopvoorwaarden is toegevoegd. Zie verder de toelichting bij artikel 1.17.
Artikel 1.27
De definitie van Maatwerkprogrammatuur is iets verfijnd. Door de introductie van de nummers (i) en (ii) wordt het onderscheid tussen een zelfstandig programma enerzijds en aanpassingen of inrichtingen van Standaardprogrammatuur anderzijds wat zuiverder gemaakt.
Artikel 1.34
Het begrip Product is toegevoegd. Overal waar “zaak” stond is dit vervangen door Product. Inhoudelijk gezien is daarmee geen wijziging beoogd (nu het Product immers gedefinieerd is als een zaak). De ervaring leerde echter dat het juridische begrip ‘zaak’ bij niet-juristen wel eens tot verwarring leidden. Het begrip is overgenomen uit de ARBIT.
Artikel 1.35
Aan de definitie van Programmatuur is toegevoegd dat daaronder ook is te verstaan de te leveren Koppelingen.
Artikel 1.37
Aan het begrip Service Levels is bij de vermelding van de voorbeelden toegevoegd een norm voor Beschikbaarheid. Materieel gezien is dit geen wijziging, nu het een niet-limitatieve opsomming is en was.
Artikel 1.40
Aan de definitie van Update is toegevoegd dat de naamgeving of nummering niet relevant is voor de vraag of sprake is van een Update. Materieel gezien is dat geen wijziging, nu ook onder de oude definitie naamgeving of nummering niet relevant was. Het benadrukt evenwel dat leveranciers niet van afspraken over toekomstig onderhoud kunnen afwijken louter op grond van andere naamgeving of nummering.
Artikel 1.42
Het begrip Vergoeding is iets verruimd. In de nieuwe definitie kan daaronder ofwel de overeengekomen prijs, ofwel de feitelijk betaalde prijs worden verstaan. Dit is met name ingegeven door de praktijk, waarbij initieel kleine opdrachten soms uitgroeien tot grotere opdrachten. Het is dan niet onredelijk dat de aansprakelijkheid – waarbij het begrip Vergoeding wordt gebruikt – als het ware ‘mee-ademt’ met de feitelijke omvang van de opdracht.
Artikel 2.2
Aan dit artikel is ter verheldering toegevoegd dat de hoofdstukken II en III aanvullend op hoofdstuk 1 van toepassing zijn. Materieel is dit geen wijziging (er stond immers al dat hoofdstuk I altijd van toepassing is en wanneer de hoofdstukken II en III van toepassing zijn). Niettemin leert de ervaring dat de praktijk hier soms vragen over had.
Artikel 2.3
Aan dit artikel is – volledigheidshalve – toegevoegd dat algemene voorwaarden of bedingen van leverancier ook niet van toepassing zijn wanneer daar later naar verwezen wordt. Het is een reactie op de praktijk van enkele leveranciers om altijd naar dergelijke voorwaarden en bedingen te verwijzen.
Artikel 2.5
De rangordebepaling is veel uitgebreider (en daarmee ook genuanceerder) geworden. Voorheen werd slechts onderscheid gemaakt tussen de Inkoopvoorwaarden en de Overeenkomst. In de huidige versie is een rangorde gemaakt met onderscheid in allerlei soorten documenten. Ook is duidelijk gemaakt dat bij eventuele innerlijke tegenstrijdigheid in de Inkoopvoorwaarden, de specifieke hoofdstukken (II en III) prevaleren op het algemene hoofdstuk (hoofdstuk I).
Artikel 2.6
Het contractenrecht is in de kern nagenoeg volledig regelend recht. De wet geeft aldus de ‘default’, tenzij partijen anders overeenkomen. In de rechtspraktijk blijkt evenwel verschillend geoordeeld te worden over wat het bestaan van een contract betekent voor die aspecten van het regelend recht waar partijen geen expliciete keuze hebben gemaakt: blijft dan de genoemde ‘default’ van kracht, of geldt juist slechts het contract? Om aan die onduidelijkheid een einde te maken bepalen de Inkoopvoorwaarden dat het regelend recht in beginsel van toepassing blijft.
Artikel 3.4
Aan het artikel over het aanbod van de Leverancier is toegevoegd dat de leverancier ook risico’s die hij voorziet benoemt en bij Producten specificeert of deze nieuw, refurbished of tweedehands zijn. Het eerste is niets meer dan een ‘spreekplicht’ (vrij vertaald: “indien u iets weet, zeg het dan”). Het gaat uitdrukkelijk niet om een nader onderzoek of iets dergelijks (het gaat om reeds voorziene risico’s). De tweede toevoeging kan worden gezien als een specificatieplicht. In een tijd waarin ICT-producten steeds vaker gerecycled worden – hetgeen vanuit milieuoverwegingen in beginsel alleen maar toe te juichen is – is het voor gemeenten wel van belang te weten wat ze inkoopt.
Artikel 5
De 2020 versie van de Inkoopvoorwaarden bevatte slechts één artikel over transport, eigendom en risico van Producten: artikel 4.4 (oud) over het transportrisico.
Vandaar dat artikel 5 is toegevoegd. De inhoud is grotendeels overgenomen van artikel 6 en 7 ARBIT. In artikel 5.5 komt het oude artikel 4.4 terug (in andere bewoordingen). In artikel 5.6 is bewust afgeweken van de ARBIT: waar de ARBIT veronderstelt dat sprake is van eigendomsoverdracht, geeft GIBIT slechts randvoorwaarden voor het geval eigendomsoverdracht is overeengekomen. Dit aangezien in de praktijk Producten steeds vaker niet worden verkocht, maar onder een andere titel ter beschikking worden gesteld.
Artikel 6.4
Dit artikel verwijst naar het nieuwe artikel 7, zie de toelichting bij dat artikel.
Artikel 6.6
Dit artikel over aanvullende werkzaamheden is versimpeld. Waar voorheen op voorhand al vastlag tegen welke tarieven meerwerk wordt verricht, en bovendien door de verwijzing naar artikel 5 verondersteld werd dat er altijd een (implementatie)plan opgesteld moet worden voor dat meerwerk, worden nog slechts enige (proces)afspraken vastgelegd over het tot stand komen van afspraken over dergelijk meerwerk.
Artikel 7
In de 2020 versie van de GIBIT was reeds een voorziening opgenomen omtrent de afhankelijkheid van derde partijen. Deze stond wat ‘verdekt’ verwerkt in het oude artikel 6.6 en 6.7 en deze artikelen werden vervolgens in het artikel over implementatie en in het artikel over acceptatie van overeenkomstige toepassing verklaard. Dat werd niet als overzichtelijk ervaren.
Daar komt nog eens bij dat de ervaring leert dat het Applicatielandschap in de loop der jaren steeds complexer en omvangrijker is geworden en dat zodoende de afhankelijkheid van derde partijen steeds groter is geworden. Het belang voor een goede voorziening hiervoor is dus toegenomen.
Vandaar dat in deze versie van de Inkoopvoorwaarden de al bestaande regeling verder is uitgewerkt in dit artikel 7.
Het artikel ziet op de afhankelijkheid van derde partijen die geen hulppersoon zijn van een van de Partijen (artikel 7.1). Partijen zijn immers zelf verantwoordelijk voor de door hen betrokken hulppersonen. Het gaat in dit artikel juist om van Partijen onafhankelijke derden, zoals leveranciers van andere ICT Prestaties die gekoppeld moeten worden aan de onderhavige ICT Prestatie of van eigenaren van gebouwen indien apparatuur daar geïnstalleerd moet worden (om twee uiteenlopende voorbeelden te noemen).
In artikel 7.2 wordt vastgelegd welke partij in de basis moet vaststellen en aan de andere partij moet melden (‘aan de bel moet trekken’) indien van dergelijke afhankelijkheid sprake is. Meer dan een signaleringsplicht is dit niet. De gedachte is dat bij Dienstverlening op Afstand het de Leverancier is die bij uitstek weet of sprake is van dergelijke afhankelijkheid, terwijl bij overige dienstverlening het meer voor de hand ligt die taak bij de gemeente te leggen nu de gemeente het eigen Applicatielandschap het best zal (behoren te) kennen. Dit is een aanpassing ten faveure van de leveranciers; in de 2020-versie stond immers nog dat in beginsel verantwoordelijkheid voor coördinatie en dergelijke altijd bij de leverancier ligt. Dit laatste laat de plicht voor een leverancier tot het in het primaire aanbod signaleren van risico’s onverlet (zie artikel 3.4).
In artikel 7.3 ligt vervolgens vast dat over een aantal genoemde onderwerpen nadere afspraken moeten worden gemaakt. Ook dit is een aanpassing ten faveure van de leveranciers: waar in de 2020-versie immers nog stond dat op leverancier de plicht tot tijdig betrekken en coördineren van werkzaamheden van derde partijen ligt (artikel 6.6 oud), is in de onderhavige versie slechts een plicht opgenomen tot overleg en tot het maken van afspraken over ieders verantwoordelijkheid in relatie tot die derde partijen (zie artikel 7.3 sub ii, iii en iv). Het doel van de gehele bepaling is vooral om die afspraken zo vroegtijdig mogelijk te maken en verrassingen achteraf te voorkomen. Zie in dat kader ook artikel 7.5: uitgangspunt is dat de derde partij ook op voorhand al bij het overleg worden betrokken en dat ook met hen op voorhand al afspraken worden gemaakt.
Artikel 7.6 is het oude artikel 6.7 en bevat slechts enkele wijzigingen die verband houden met het meer generieke karakter dat het artikel heeft gekregen. Het bevat daarmee dus ook nog steeds de, genuanceerde, regeling over hoe om te gaan met blokkerende doch niet aan leverancier maar aan een derde partij toerekenbare kwesties. In de kern ziet (en zag) dit artikel op (i) een overlegplicht indien zich kwestie voordoen waarbij de ICT Prestatie niet conform werkt, terwijl de oorzaak daarvoor niet bij leverancier ligt (maar bij derde partijen, of de gemeente zelf); en (ii) de erkenning dat Leverancier in een dergelijke situatie gewoon recht heeft op datgene dat is afgesproken omtrent de gevolgen van Acceptatie (in de praktijk veelal: betaling). De wijzigingen zijn heel beperkt. In de aanhef wordt niet langer alleen van een ketentest gesproken, maar ook van een Acceptatieprocedure. Dat is materieel gezien geen wijziging, want artikel 7.4 oud GIBIT 2020 verklaarde artikel 6.7 oud al van overeenkomstige toepassing bij een Acceptatieprocedure. Onder sub i) stond voorheen dat Acceptatie geacht werd plaatsgevonden te hebben, er staat nu dat er geacht wordt geen sprake te zijn van een Gebrek. Hiervoor is gekozen om meer de nadruk te leggen op de betreffende blokkerende situatie (die dan dus niet kwalificeert als Gebrek (*)). Onder sub ii) is niets meer gewijzigd dan het toevoegen van de woorden “de ketentest of”. Onder sub iii) was reeds de plicht opgenomen om te komen tot overleg, de enige wijziging is dat voor de partij die het initiatief tot dat overleg moet nemen wordt verwezen naar lid 2.
(*) Voor de goede orde (voor de puristen onder de juristen): strikt genomen is hier een specifieke overmacht-situatie uitgeschreven. Het gaat immers om de situatie dat een Gebrek optreedt (=niet voldoen aan Overeengekomen gebruik), terwijl het intreden van dat Xxxxxx niet aan leverancier toerekenbaar is (denk bijvoorbeeld aan de situatie dat het koppelvlak van een andere leverancier niet aan de specificaties blijkt te voldoen). Om te voorkomen dat alsdan een patstelling ontstaat, voorzien de Inkoopvoorwaarden op voorhand in een overlegverplichting. Dit in de gedachte: het Gebrek moet worden opgelost, we zoeken in onderling overleg wel uit wie daarvoor wat moet doen en wie ervoor betaalt.
Artikel 8.2
Dit artikel is aangepast ten faveure van de leveranciers. De preventieve testen hoeven niet langer op een omgeving van Leverancier worden uitgevoerd, doch slechts op een omgeving die niet voor productieve doeleinden van de gemeente wordt gebruikt. Dit geeft ruimte de preventieve testen elders te doen, zelfs bij de gemeente zelf of bij een andere gemeente. Het testrapport hoeft bovendien niet langer standaard doch slechts op verzoek te worden overgelegd.
Artikel 8.3
Ook dit artikel is aangepast ten faveure van de leveranciers. Leveranciers hebben de ruimte te verwijzen naar een openbare vindplaats voor testrapportages (zoals een online portal).
Artikel 8.5
De tekst van deze bepaling is wat versimpeld en de terminologie is consistenter gebruikt.
Artikel 9.3
Aan dit artikel is toegevoegd dat het tot de zorgplicht van Leverancier behoort de voortgang van de implementatie te bewaken en zo nodig de gemeente te waarschuwen of zelfs aan te manen. Deze zorgplicht is gebaseerd op bestaande rechtspraak (vgl. o.m. ECLI:NL:GHSHE:2015:4428, r/o 3.8.4).
Artikel 10.4
Dit artikel is aangepast ten faveure van de leveranciers. Waar voorheen er stond dat het moment van het verrichten van Onderhoud in overleg wordt bepaald, zijn nu nog slechts de randvoorwaarden opgenomen dat Onderhoud zo min mogelijk verstorend moet zijn. Dit is gebeurd in reactie op kritiek van leveranciers dat in bulk verricht onderhoud niet met individuele klanten afgestemd kan worden. Ook is de plicht om verstorend onderhoud vooraf aan te kondigen afgezwakt tot een inspanningsplicht dit “zo mogelijk” tijdig vooraf aan te kondigen. Dit om de ruimte te bieden spoedonderhoud zonder aankondiging te doen.
Artikel 10.5
De tijden van minimale bereikbaarheid zijn verminderd. Dit artikel is aangepast ten faveure van de leveranciers.
Artikel 10.7
Er is toegevoegd wat er onder gebruikersondersteuning is te verstaan. Dit is materieel gezien nauwelijks een wijziging te noemen, nu immers al was opgenomen dat gebruikersondersteuning onder het onderhoud valt en de hier gegeven definitie beperkt is.
Artikel 10.10
Dit artikel is enerzijds iets strenger gemaakt en anderzijds ook verlicht.
Het is strenger in die zin dat is toegevoegd dat er ook ontbonden kan worden indien de Service Levels 3x niet worden gehaald in een periode van 6 aaneengesloten meetperiodes. Vrij vertaald betekent dit dat ontbonden kan worden indien een half jaar lang om de maand dezelfde Service Levels niet gehaald worden. In zo’n situatie is het serviceniveau structureel onder de maat en niet betrouwbaar, hetgeen de ontbinding rechtvaardigt.
Tegelijkertijd is het artikel ook verlicht, in die zin dat als alternatief voor ontbinding ook de optie is toegevoegd dat de gemeente om een verbeterplan kan vragen. Aangezien gemeenten bij de contracttoepassing de redelijkheid en billijkheid in acht zullen moeten nemen (vgl. o.a. artikel 6:2 BW) en zelfs uit publiekrecht voortvloeiende normen (vgl. artikel 3:14 BW), zal dit in de praktijk betekenen dat gemeenten niet altijd en ‘zomaar’ voor de zwaarste vorm van ontbinding zullen mogen kiezen.
Artikel 10.12
Aan dit artikel is toegevoegd dat (i) veiligheidsadviezen uitgebracht door NCSC of anderszins publiekelijk uitgebracht zo spoedig mogelijk zullen worden opgevolgd en (ii) dat risico’s zo spoedig mogelijk zullen worden gemitigeerd. De wijze waarop dit gebeurt is uitdrukkelijk aan Leverancier gelaten (zie ook woorden ‘of anderszins’). Voorop staat echter dat (het gebruik van) de ICT Prestatie veilig moet zijn, hetgeen bepaald geen onredelijke eis lijkt.
Artikel 10.15
Deze bepaling is wat eenvoudiger verwoord. Verder is de plicht tot afspraken over inhoud en frequentie van rapportage afgezwakt tot een optie daartoe.
Artikel 11.2
Het artikel bevatte al de bepaling dat in veel gevallen 30% van de overeengekomen vergoedingen eerst opeisbaar zijn na integrale Acceptatie. Aan het artikel is toegevoegd dat over de resterende 70% afspraken moeten worden gemaakt in de Overeenkomst. Dat is materieel gezien geen wijziging; ook onder de vorige versie moesten (logischerwijs) over de resterende 70% afspraken worden gemaakt. De toevoeging is louter ter verheldering / als signaal bedoeld. Er is overigens overwogen de bepaling heel anders op te zetten met allerlei betalingsschema’s en dergelijke, maar dat bleek uiteindelijk te casuïstisch en (dus) niet te passen bij generieke abstracte voorwaarden als de onderhavige Inkoopvoorwaarden.
Artikel 11.4
De tekst dat meerwerk wordt verricht tegen de overeengekomen dan wel gebruikelijke tarieven is verplaatst van artikel 5.6 oud naar dit artikel.
Artikel 11.5
Toegevoegd is dat facturen binnen drie maanden na het opeisbaar worden van de betreffende werkzaamheden dienen te worden verstuurd. De gedachte is dat laat factureren moet worden voorkomen; dat is in het belang van beide partijen. Specifiek voor werkzaamheden rondom de jaarwisseling geldt dat deze uiterlijk 6 januari moeten zijn gefactureerd; dit in verband met de jaarafsluiting.
Uiteraard blijft het overigens bepaalde omtrent facturering ook van kracht; zo kan alleen voor opeisbare verplichtingen worden gefactureerd en is voor opeisbaarheid veelal acceptatie vereist (zie artikel 11.2). Dit artikel is dus niet bedoeld om tegen de jaarwisseling opeens anders te factureren.
Artikel 11.8
Evenals in de GIBIT2020 is voor indexering aansluiting gezocht bij de DPI. De wijziging is daarin gelegen dat er steeds moet worden geïndexeerd tegen de laatst gepubliceerde en definitieve jaarmutatie. Aangezien die jaarmutatie in de loop van het jaar pas definitief wordt vastgesteld, wordt er dus feitelijk steeds met het indexcijfer van het jaar daarvoor gewerkt. Dat cijfer is zodoende voor beide partijen lang vooraf bekend en hierop kan door beide partijen geanticipeerd worden. Evenals in versie 2020 is aansluiting gezocht bij de groep J62 althans sectie J van de CPA2008, om zo dicht bij het prijspeil in de sector te blijven.
Artikel 11.9
Dit artikel is aangepast ten faveure van de leveranciers. Diverse leveranciers wezen erop dat het niet consequent is dat prijsverlagingen voor Derdenprogrammatuur direct moesten worden doorgevoerd, maar dat prijsverhogingen alleen per 1 januari mochten worden doorgevoerd. Dat onderscheid is komen te vervallen.
Artikel 11.10
Er is een artikel toegevoegd over onvoorziene aanzienlijke kostprijsverhogende omstandigheden. Het artikel voorziet in een overlegverplichting en geeft daarbij op voorhand drie opties: (i) prijsverhoging (gedeeltelijk) betalen, (ii) ICT Prestatie beperken of (iii) Overeenkomst beëindigen tegen vergoeding van de daarmee gemoeide kosten (dat laatste gelet op de verwijzing naar artikel 24.6). Met het artikel wordt voorkomen dat bij onvoorziene omstandigheden de gang naar de rechter is vereist (vgl. artikel 6:258 BW). De lat bij de rechter om tot wijziging van de overeenkomst te komen ligt bovendien vrij hoog. Het artikel geeft bovendien op voorhand aan tot welk percentage een kostenstijging geacht wordt voor risico van leverancier te zijn (<10%); dat geeft partijen op voorhand al enige zekerheid.
Artikel 12.1
Aan de lijst garanties is de garantie toegevoegd om voorgeschreven modificaties op Producten zo spoedig mogelijk door te voeren (bijv. in situaties van onveilige producten).
Artikel 12.3
Naar aanleiding van diverse opmerkingen van met name leveranciers is toegevoegd wat er in de Inkoopvoorwaarden onder een garantie is te verstaan. Dit is gedaan aangezien het vaste rechtspraak is dat wat onder een garantie is te verstaan afhangt van de partijbedoeling, terwijl die partijbedoeling regelmatig niet zal blijken bij het gebruik van de Inkoopvoorwaarden in formele inkoopprocessen als een aanbesteding. Zodoende ontstaat onzekerheid over de betekenis/interpretatie van begrippen als ‘garantie’ en ‘garanderen’. Dat klemt temeer nu in de juridische literatuur soms wordt gesteld dat aan de begrippen verstrekkende consequenties zijn verbonden. In de Inkoopvoorwaarden is met de begrippen slechts de resultaatsverbintenis met de genoemde bewijslastverdeling mee bedoeld, verder niets. Opnieuw een aanpassing ten faveure van de leveranciers (die bevreesd zijn voor voornoemde verstrekkende uitleg).
Artikel 13
Gemeenten zien steeds meer gebruik van algoritmen en de maatschappelijk vragen over dergelijk gebruik neemt ook toe. Er is ook allerlei (concept)wetgeving over het onderwerp in aantocht. Vandaar dat de GIBIT enkele (minimale) eisen stelt aan dergelijke toepassingen. Het is denkbaar – en onder omstandigheden ook wenselijk – dat in het bovenliggende contract de eisen nader worden uitgewerkt.
De eisen beperken zich vooralsnog tot de volgende basis-/kerneisen. In het eerste lid zijn eisen gesteld aan (de kwaliteit van) de Algoritmische toepassing: een rechtmatige dataverwerking, gestructureerde en neutrale dataverwerking en nauwkeurigheid. In het tweede lid is een gebruiksbeperking op de verwerkte data opgenomen: geen gebruik voor eigen doeleinden, tenzij volledig geanonimiseerd. Hiermee wordt enerzijds bedrijfsvertrouwelijke en privacygevoelige informatie beschermd, doch anderzijds erkend dat een algoritme ‘input’ nodig heeft om verrijkt te worden. Aangezien een algoritme in de praktijk regelmatig een ‘black box’ is , terwijl de gemeente als actor in een democratische rechtstaat het eigen handelen juist zal moeten kunnen verantwoorden is aan lid 3 toegevoegd dat leverancier zowel in algemene zin als in een specifiek geval moet kunnen uitleggen/verantwoorden hoe het algoritme werkt of waarom het tot een bepaalde beslissing is gekomen. Dat hoeft niet zo ver te gaan dat leverancier het algoritme prijs hoeft te geven (het belang van bescherming van bedrijfsvertrouwelijke informatie wordt onderkend), maar wel zo ver dat in voorkomend geval de beslissing in rechte toetsbaar wordt. Dat laatste is immers een basisbeginsel van de democratische rechtstaat. Gelet daarop is ook in lid 4 opgenomen dat de gemeente de informatie over de werking met derden (zoals de rechtbank) mag delen. Om diezelfde reden is ook opgenomen dat het bestaande controle-/auditrecht ook van toepassing is op de Algoritmische toepassing (strikt genomen is de bepaling welhaast overbodig, want dat controlerecht zag toch al op nakoming van alle verplichtingen).
Artikel 16.4
In dit artikel is de maximale aansprakelijkheid (fors) verlaagd van tienmaal de Jaarvergoeding per gebeurtenis naar tweemaal de Jaarvergoeding per gebeurtenis. De maximale totale aansprakelijkheid per jaar is bovendien fors teruggebracht van twintig tot vier maal de Jaarvergoeding. Uiteraard blijft onverlet – ongeacht dit ‘vangnet’ – dat gemeenten altijd proportionele afspraken zullen moeten maken. Andere afspraken zijn dus ook denkbaar.
Artikel 18.4
Toegevoegd is dat de inhoud van de onder de Inkoopvoorwaarden gesloten overeenkomsten mag worden gedeeld met aan gemeenten verwante partijen. De gedachte hierachter is dat gemeenten zo van elkaar kunnen leren. De clausule is beperkt tot de inhoud van de overeenkomsten; vrees voor schending van bedrijfsgeheimen is zodoende niet terecht. Aangetekend zij hierbij ook dat aanbestedingen veelal toch al openbaar zijn.
Artikel 18.6
Het boeteregime is aanmerkelijk versoberd. De boete is verlaagd van 4x de Vergoeding naar € 10.000,- per overtreding. Ook is opgenomen dat reeds betaalde boetes in mindering worden gebracht op de uiteindelijke schadevergoeding.
Artikel 19.3
Toegevoegd is dat leverancier enig door overmacht genoten voordeel dient te vergoeden, met inachtneming van de beperking van aansprakelijkheid. De gedachte is eenvoudig: leverancier zou niet rijker moeten worden van een overmachtssituatie. De bepaling is overgenomen uit de ARBIT.
Artikel 20.3
In het artikel stond reeds dat het Gebruiksrecht dat gemeenten verkrijgen niet voorziet in het recht zelf exploitatiehandelingen te verrichtten. Het woord ‘exploitatiehandelingen’ is zeer breed en is in de IE-literatuur ook gebruikelijk. Niettemin is zekerheidshalve nog toegevoegd dat gemeenten (dus) ook niet bevoegd zijn sub-licenties te verstrekken of rechten over te dragen (tenzij toegestaan). Een verduidelijking ten faveure van de leveranciers dus.
Artikel 20.4
De bepaling is iets vereenvoudigd.
Artikel 21
Aan dit artikel is in de aanhef het ‘onverminderd het Overeengekomen gebruik’ toegevoegd om duidelijk te maken dat het recht op toegang tot data en instellingen los staat van de features van de ICT Prestatie. Uiteraard is denkbaar dat de ICT Prestatie zelf qua features al helemaal voorziet in de behoefte van de gemeente (in welk geval de gemeente geen belang heeft bij een beroep op dit artikel), maar als dat niet of slechts deels het geval mocht blijken te zijn dan blijft een beroep op dit artikel dus mogelijk. Wel is toegevoegd dat de op te vragen gegevens louter de specifiek voor gemeente verwerkte gegevens betreft. Dit in reactie op opmerkingen van leveranciers dat er steeds vaker in multi-tenant omgevingen wordt gewerkt.
Artikel 22.1
Dit artikel is aangepast ten faveure van de leveranciers. Er is uitdrukkelijk ruimte geboden om voor alle informatie over en in verband met Derdenprogrammatuur naar externe vindplaatsen te verwijzen (zoals de documentatie of een online vindplaats). Dit geeft de leveranciers veel meer flexibiliteit om de informatie over Derdenprogrammatuur snel, schaalbaar en flexibel te bieden.
Artikel 22.7
Artikel 22 biedt enkele nuanceringen op de normale afspraken bij Derdenprogrammatuur. In lid 7 is hierop een uitzondering gemaakt bij Dienstverlening op Afstand. De gedachte hierachter is de volgende.
Artikel 22 is oorspronkelijk geschreven met de on premise situatie in het achterhoofd (de tekst stond immers al in XXXXX0000). Bij een on premise situatie wordt de software geïnstalleerd op lokale apparatuur en is het uitvoeren van het programma al een auteursrechtelijk relevante handeling waarvoor een licentie is vereist (vgl. artikel 45i Auteurswet). In die on premise situatie wordt dus zowel de software van de leverancier als de Derdenprogrammatuur (bijv. een SQL-server) geïnstalleerd en heeft de gemeente voor beide pakketten een licentie nodig. Aangezien die licentie in de praktijk niet onderhandelbaar is (noch voor leverancier, noch voor gemeente), onderkent artikel 22 dat die licentievoorwaarden dan prevaleren. Bovendien erkent artikel 22 dat Gebreken die worden veroorzaakt door bugs in die Derdenprogrammatuur geen (toerekenbare) Gebreken zijn, doch dat leverancier dan wel zo snel mogelijk een oplossing moet bedenken (‘om de bugs heen moet worden’, zie artikel 22.4).
Bij Dienstverlening op Afstand (cloud, SaaS) is de situatie een hele andere. De software wordt dan geïnstalleerd op de server van de leverancier. Het is de leverancier die (door het uitvoeren ervan) verveelvoudigingshandelingen verricht en die (dus) een licentie nodig heeft. Waar bij de on premise situatie het de gemeente zelf is die een licentie nodig heeft op die Derdenprogrammatuur (zoals een SQL-server), is het bij Dienstverlening op Afstand een interne kwestie voor de leverancier geworden om over de juiste licenties te beschikken. De gemeente koopt eenvoudigweg een totaalpakket als dienst. Juist omdat de gemeente een totaalpakket als dienst koopt, is het niet redelijk om daarop de nuanceringen van artikel 22 toe te passen.
Naar aanleiding van eerdere consultatierondes is gebleken dat het geheel uitsluiten van artikel 22 bij Dienstverlening op Afstand niet gepast is. Bij bepaalde vormen van Dienstverlening op Afstand is de leveranciers immers weinig meer dan een reseller en heeft de leverancier feitelijk geen enkele invloed op de voorwaarden waaronder de betreffende dienst kan worden aangeboden. Vandaar dat in de clausule nu is bepaald dat deze alleen van toepassing is op die Derdenprogrammatuur die door Opdrachtgever zelf wordt verveelvoudigd (=on premise) of die door Opdrachtgever wordt gebruikt (=bijv. resellsituatie van SaaS-software). Aanvullende hulpsoftware – die ‘onder water’ en onzichtbaar bij leverancier draait – zou dan bij Dienstverlening op Afstand niet onder de clausule vallen.
Artikel 23
Het artikel over vervanging van personeel is nieuw ingevoegd. Het is overgenomen uit de ARBIT, met dien verstande dat het verbod om personeel te vervangen behoudens toestemming niet is overgenomen. Dat werd te eenzijdig geacht door de werkgroep.
Artikel 24.1
Aan het artikel over opschorting is toegevoegd dat de leverancier bij een mogelijk beroep op opschorting voorafgaand moet waarschuwen voor de consequenties daarvan. Dit is een nadere invulling van de (toch al geldende) zorgplicht en overigens vooral ook fatsoenlijk.
Artikel 24.11
Aan dit artikel is als ontbindingsgrond toegevoegd het schenden van sanctiewetgeving en het handelen in strijd met de redelijkheid en billijkheid gelet op de bijzondere publieke positie van de gemeente.
Artikel 24.14
De samenhang met de bepaling omtrent exit is verhelderd.
Artikel 25
Het controlerecht is op enkele punten aangepast ten faveure van de leverancier. Zo is zowel aan lid 2 als 3 toegevoegd dat de aanleiding voor een controle kenbaar moet worden gemaakt. Dit stelt leverancier in staat om informatie ter beschikking te stellen en zodoende mogelijk de aanleiding voor de controle weg te nemen. Ook is in lid 2 opgenomen dat eerst om de generieke TPM moet worden gevraagd, alvorens een controle mag plaatsvinden.
Artikel 26.1
De scope van het artikel is iets verbreed: er kan niet alleen verlangd worden een exit-plan op te stellen, doch ook om een bestaand plan bij te werken. Een actueel plan lijkt in het belang van beide partijen.
Artikel 26.2
Het artikel geeft een rangorde voor de documenten die afspraken over de exit (kunnen) bevatten. Duidelijk is dat het bepaalde in de Inkoopvoorwaarden als vangnet is bedoeld; idealiter stellen partijen een specifieker plan op.
Artikel 26.3
Een exit kan onder omstandigheden complex zijn. Het verdient dan aanbeveling om de exit voorafgaand eens te evalueren / testen. Dit om te voorkomen dat zodra het moment werkelijk daar is er opeens onvoorziene omstandigheden opduiken. Leverancier kan voor het evalueren vergoedingen in rekening brengen (zie artikel 26.4).
Artikel 26.4
In de vorige versie van de GIBIT stond reeds dat de exit-werkzaamheden tegen de reguliere tarieven van leverancier worden verricht. In die versie stond ook dat het bepaalde in de Overeenkomst prevaleert op het bepaalde in de Inkoopvoorwaarden. Het was dus al zo dat de meer specifieke afspraken over tarieven voor exit-werkzaamheden leidend zijn. Dat laatste is thans wat explicieter verwoord in dit artikel. Materieel gezien geen wijziging dus.
Artikel 26.6
Dit artikel vermeldt welke maatregelen er in ieder geval in het kader van een overstap naar een soortgelijke (opvolgende) ICT Prestatie verlengd kunnen worden. De bewoording is slechts veranderd en het accent op het exit-plan wordt ook hier wat meer gelegd.
Artikel 26.7
In de basis geldt voor alle exit-werkzaamheden dat deze betaald worden verricht (zie artikel 26.4 en toelichting hiervoor). In afwijking daarop bepaalt dit artikel dat bij een beëindiging wegens toerekenbaar tekortschieten de diensten kosteloos worden verricht. Indien de overeenkomst is beëindigd wegens toerekenbaar tekortschieten van leverancier, staat vast dat sprake is van aansprakelijkheid van leverancier. Zodoende is deze bepaling in feite een vorm van schadevergoeding in natura. Ook de eenmalige vernietiging van gegevens dient zonder kosten te worden verricht. Dit is niet onredelijk, nu Leverancier de gegevens toch al zou moeten vernietigen. Leverancier heeft immers geen grond meer de gegevens na beëindiging onder zich te houden en zou mogelijk aansprakelijk zijn indien de gegevens wel lang worden bewaard. Beide punten stonden reeds in de GIBIT2020. De bewoording is wel veranderd ten gunste van Leverancier: voorheen kon al bij een toerekenbare tekortkoming dit artikel worden ingeroepen, nu moet de overeenkomst wel beëindigd zijn.
Artikel 26.9
Aan het artikel over de beperkte voortzetting is ter verheldering toegevoegd dat de voortzetting in beginsel onder gelijke voorwaarden plaatsvindt.
Artikel 28.2
De rangordebepaling van artikel 28 is geschrapt nu de Verwerkersovereenkomst in de algemene rangordebepaling is opgenomen.
Artikel 29.4
Dit artikel introduceert een back-up verplichting voor Leverancier.
Artikel 29.5
Dit artikel introduceert een rapportageplicht voor beveiligingsincidenten. Een dergelijke plicht bestaat reeds onder de Verwerkersovereenkomst; het is voor gemeenten echter van belang ook over andersoortige veiligheidsincidenten geïnformeerd te worden. Materieel gezien is het overigens nauwelijks een wijziging te noemen, want iedere gedegen norm voor informatiebeveiliging veronderstelt een goede rapportagestructuur en het werken conform beveiligingsnormen was reeds een eis.
Artikel 31.2
In dit artikel is nieuw toegevoegd dat indien voor gebruik van de ICT Prestatie een webbrowser is vereist, dat de ICT Prestatie correct dient te functioneren in recente en nog ondersteunde versies van gangbare webbrowsers. Zolang de ICT Prestatie zich conformeert aan standaarden zal dit geen onoverkomelijke eis zijn.
Artikel 31.3
In dit artikel is de eis opgenomen dat de omgeving zodanig moet zijn ingericht dat incidenten bij andere klanten geen nadelige invloed kunnen hebben op de ICT Prestatie. Dit is in reactie op situaties waarbij leverancier (veel te) lichtvaardig denken over het echt veilig en verantwoord inrichten van een multi-tenant omgeving.
Artikel 32
Er is een nieuw artikel over de Acceptatieprocedure ingevoegd, om zo – in aanvulling op het al bestaande artikel over Acceptatie – de typische kenmerken van een acceptatieprocedure in een cloud/SaaS-omgeving te adresseren.
Lid 1 bepaalt dat de acceptatie in een van de productieomgeving afgescheiden omgeving plaatsvindt. Dat zal in veel on premise situaties overigens ook zo zijn, bij Dienstverlening op Afstand is op voorhand duidelijk dat werken met afzonderlijke omgevingen een must is.
In lid 2 wordt onderkend dat een testomgeving niet altijd volledig vergelijkbaar hoeft te zijn met de productieomgeving. Vrij vertaald: het is denkbaar dat de testomgeving ‘lichter’ is, zolang dat maar geen afbreuk doet aan het nut van de Acceptatieprocedure.
Typerend aan Dienstverlening op Afstand is dat deze via internet wordt verleend. Het is zodoende begrijpelijk dat leveranciers zich gedwongen zien bepaalde vormen van onderhoud voortdurend, en ook al tijdens de fase van Implementatie, te verrichten. Bij dienstverlening via internet zullen veiligheidsupdates e.d. immers geïnstalleerd moeten worden. In de praktijk ontstaat er dan evenwel soms ruis of daarmee dan (dus) de volledige onderhoudsfase al begonnen is of niet. Vandaar het bepaalde in het derde lid: dergelijk onderhoud dat noodzakelijk is gelet op de aard van de dienstverlening valt onder de Implementatie, niet onder het Onderhoud.
Artikel 34.2
Vanwege de innerlijke consistentie zijn de tijden voor Beschikbaarheid gelijkgesteld met de tijden voor bereikbaarheid van de helpdesk. In alle gevallen geldt uiteraard dat het basisniveaus zijn; de Inkoopvoorwaarden zijn immers bedoeld als vangnet. In de praktijk zullen veelal andere afspraken over bereikbaarheid en Beschikbaarheid worden gemaakt.
Artikel 34.4
Aan dit artikel is de plicht toegevoegd om vooraf te informeren over Updates en Upgrades die downtime veroorzaken. Ook is de plicht toegevoegd actuele documentatie ter beschikking te stellen bij Updates en Upgrades.
Bij nader inzien lijkt de toegevoegde waarde van beide wijzigingen laag, gelet op wat er reeds in artikel 10.4 en artikel 14 is opgenomen. Het lijkt meer voor de hand te liggen eventueel de bestaande artikelen nog iets bij te werken dan om deze nieuwe artikelen te behouden.
Artikel 35
Nieuw toegevoegd is de plicht tot het verstrekken van een periodieke derdenverklaring (TPM) of ISO-verklaring of vergelijkbaar kwaliteitssysteem. Die verklaring ziet uitdrukkelijk slechts op de generieke aspecten van de dienstverlening, niet op klantspecifieke afspraken (zie lid 2). De Inkoopvoorwaarden sluiten met deze eis aan bij diverse normen en aanbevelingen waaruit volgt dat bij Dienstverlening op Afstand een dergelijke TPM vereist is. Dat dergelijke TPM’s ook in Nederland veel voorkomen blijkt bijvoorbeeld wel uit een site als xxx.xxxx0000.xx. Aangezien een ISAE3202 niet altijd passend wordt geacht is bewust ruimte geintroduceerd voor ISO-verklaringen of andere gelijkwaardige verklaringen.