GIBIT: De gemeentelijke IT inkoopvoorwaarden

Gemeenten in Nederland gebruikten tot voor kort vaak de Algemene Rijksvoorwaarden IT-Overeenkomsten (ARBIT) als algemene voorwaarden om IT producten en diensten in te kopen. Daar ontbraken enkele belangrijke onderwerpen in en KING, het Kwaliteitsinstituut Nederlandse Gemeenten, dat gemeenten ondersteunt bij het verbeteren van hun informatievoorziening, heeft het op zich genomen nieuwe voorwaarden op te stellen, specifiek voor gemeenten. In december 2016 zijn die voorwaarden, de GIBIT, uiteindelijk vastgesteld en beschikbaar gemaakt voor gebruik. Dit artikel evalueert deze voorwaarden en geeft aanbevelingen, zowel voor de GIBIT zelf voor toekomstige versies, voor gebruikers van de huidige versie en voor leveranciers die geconfronteerd worden met deze voorwaarden.

‘Hosting’
Dat is vooral relevant voor wat de GIBIT ‘Hosting’ noemen. Of de term ‘Hosting’ nu zo gelukkig gekozen is kan betwist worden, maar de toevoeging is bijzonder nuttig en vult een gat in wat de ARBIT naar mijn mening nog steeds laat vallen. “Hosting” betekent in de GIBIT: “Het door Leverancier door middel van technieken voor com­municatie op afstand aan Opdrachtgever ter beschikking stellen van de ICT Prestatie”. Daarmee wordt alles afgedekt wat maar met enige goede wil onder “Cloud” geschaard zou kunnen worden. En dat is zinvol. Met het hoofdstuk over privacy worden eisen vanuit de Algemene Verordening Gegevensverwerking explicieter dan in de ARBIT geadresseerd. Ook onderhoud, beschikbaarheid en continuïteit worden hier specifiek geregeld voor deze situaties.

Standaard Programmatuur
In artikel 19 GIBIT staat een afzonderlijk regime voor ‘derdenprogrammatuur’, waarbij de mogelijkheid geopend wordt leveranciersvoorwaarden te accepteren, die dan prevaleren boven de GIBIT (lid 19.8). Het begrip ‘derdenprogrammatuur’ is als volgt gedefinieerd: “Programmatuur waarvan (a) de intellectuele eigendomsrechten geheel niet bij Leverancier en/of een aan Leverancier gelieerde vennootschap rusten en (b) waarbij Leverancier niet in staat is bepaalde ontwikkelingen aan / wijzigingen in die programmatuur af te dwingen.”

In de toelichting bij artikel 19 staat: “Er kan worden gedacht aan programmatuur van partijen als Microsoft, Oracle, Adobe, Goog­le, IBM, HP, SAP, etc. De regeling van artikel 19 is opgenomen omdat erkend wordt dat leveran­ciers veelal geen invloed hebben op de kwaliteit/functionaliteit van deze Derdenprogrammatuur, noch op de voorwaarden waaronder deze Derdenpro­grammatuur op de markt wordt gebracht.” Dus: als een leverancier eigen programmatuur levert, dan gelden de licentie- en onderhoudsvoorwaarden van de GIBIT, namelijk de licentie- en onderhoudsregels voor maatwerkprogrammatuur.

De bevoordeling van leveranciers die via resellers aanbieden wordt in lid 9.7 versterkt. Leveranciers die standaard software via resellers aanbieden mogen zelf de prijsverhogingen kiezen en doorbelasten, maar leveranciers die direct leveren mogen hoogstens CBS indexering toepassen, en resellers mogen alles in één keer factureren terwijl hun concurrenten dat 70% bij levering en 30% na acceptatie moeten accepteren. Overigens is het onwaarschijnlijk dat deze bepaling ooit toepasselijk zal zijn, omdat voor deze groep immers de leveranciersvoorwaarden gelden.

Zelfs met de toelichting is het raadselachtig waarom een leverancier die op een aanbesteding inschrijft via een reseller in een aanzienlijk gunstiger positie geplaatst wordt dan een leverancier die zijn software direct zelf distribueert. Het tweede deel van de definitie van ‘derdenprogrammatuur’ geeft daarop waarschijnlijk het antwoord: Het gaat erom dat de leverancier (lees: de reseller) de ontwikkeling van de programmatuur niet kan beïnvloeden. Het gaat dus kennelijk om standaardprogrammatuur. Maar dan nog blijft de vraag waarom de invloed van de reseller een criterium zou zijn. Het zou bij standaard programmatuur relevant kunnen zijn dat individuele klanten geen ontwikkelingen in de programmatuur kunnen afdwingen. Als een klant dat wel zou kunnen (ongeacht of er een reseller tussen zit of niet) dan zou je kunnen zeggen dat de programmatuur niet ‘echt standaard’ is en dan is er ook minder reden dat de voorwaarden standaard is. Dat komt verdedigbaar over. Echter, als een softwareleverancier werkt met zeer grote resellers die veel implementatiediensten verzorgen, dan kan het soms wenselijk zijn dat juist een dergelijke reseller wel invloed heeft. Omgekeerd, als een leverancier zelf direct software verkoopt, maar klanten nooit veranderingen kunnen afdwingen op de ontwikkeling van de programmatuur (een zeer gebruikelijke situatie voor leveranciers van software tools) , dan is het onbegrijpelijk dat zij anders worden behandeld dan bedrijven die resellers inzetten. Zou een gemeente zo onverstandig zijn de GIBIT onverkort te hanteren voor de aankoop van standaard programmatuur, dan zal iedere verstandige leverancier van standaard software een kleine (invloedloze) reseller inzetten, wat een prijsopdrijvend effect heeft en wat voor de gemeente kwalitatief lang niet altijd wenselijk is.

De GIBIT moeten naar mijn mening aangepast worden om in plaats van ‘derdenprogrammatuur’ in een uitzonderingspositie te plaatsen, ‘standaard programmatuur’ in die positie te plaatsen, los van de distributiestructuur van de leverancier. De definitie van standaard programmatuur moet dan niet zijn dat resellers er geen invloed op mogen hebben, maar juist klanten niet.

Leveranciersvoorwaarden
In lid 2.3 staat: “De toepasselijkheid van enige algemene of specifieke voorwaarden of bedingen van Leverancier, onder welke benaming ook, wordt uitdrukke­lijk van de hand gewezen”. In 2.5 staat: “In geval van strijdigheid tussen het bepaalde in de GIBIT en het bepaal­de in de Overeenkomst prevaleert het bepaalde in de Overeenkomst boven het bepaalde in de GIBIT”.  Dit zijn tegenstrijdige bepalingen. In 2.3 staat, dat wat 2.5 toelaat, niet geldt. 2.3 had beter geformuleerd kunnen worden in de zin dat voorwaarden, die na ondertekening van de overeenkomst op welk wijze dan ook meegezonden worden, niet van toepassing zijn.

Fatale termijnen
Lid 4.1 begint met “Overeengekomen termijnen voor levering en/of andere prestaties gelden als vast en fataal”. IT diensten zijn in bijna alle gevallen situaties waarin samengewerkt wordt. Bovendien zijn het diensten die vaak dynamisch van aard zijn. In de praktijk betekent dit, dat een termijnoverschrijding door een afnemer (nagenoeg) nooit als fatale termijn wordt gehandhaafd, waardoor termijnen het karakter van een fatale termijnen verliezen: als termijnen niet als fataal gehandhaafd worden, mag de andere partij erop vertrouwen dat ze dat niet zijn. Wil je daarna een beroep doen op rechtsmiddelen, dan is alsnog een geldige ingebrekestelling en verzuim vereist. Hoe kan de ander anders immers weten wat wel en wat niet fatale termijnen zijn? De opstellers hadden het voorbeeld van de ARBIT beter kunnen overnemen en uitgaan van de wettelijke verzuimregeling. Dat sluit beter aan bij wat de praktijk nodig heeft.

In lid 5.5 worden ‘tussentijdse opleverdata’ weer als niet-fataal aangemerkt. Naar mijn mening maakt dit nog onduidelijker wat wel en wat niet fataal zou moeten zijn volgens de voorwaarden. “Tussentijdse opleverdata” is ongedefinieerd, en ik vraag me af of het definieerbaar is. En als alleen de absolute einddatum fataal is, impliceert dat dan dat bij vertragingen tussentijds ingebrekestelling vereist is? En als dat zou gebeuren, wat is dan nog de betekenis van het fatale karakter van de einddatum? Schuift die mee met de gegunde redelijke termijnen die voor de tussentijdse data zijn gegeven? Of impliceert dit dat de gemeente de leverancier juist niet kan aanspreken op tussentijdse vertragingen om het fatale karakter van de einddatum niet aan te tasten? Deze benadering veroorzaakt in geval van geschillen een nog onduidelijkere situatie dan die toch altijd al op de loer ligt bij geschillen over IT projecten.

Kwaliteitsnormen
De GIBIT stellen in artikel 6 eisen aan beveiligingsnormen en overige kwaliteitsnormen. Wat die normen inhouden, staat in een afzonderlijk document van KING met de titel “Gemeentelijke ICT kwaliteitsnormen”.  Hierin wordt weer verwezen naar online beschikbare normen voor een hele reeks aan onderwerpen: Architectuur, Interoperabiliteit, beveiliging, dataportabiliteit, toegankelijkheid, archivering, infrastructuur, documentatie en e-facturering. Per onderwerp wordt naar normen verwezen van diverse bronnen. Het betreft dus een forse bibliotheek van een enorm scala aan normen die van toepassing kunnen zijn. Het artikel specificeert hoe leveranciers moeten aantonen dat ze aan de gestelde eisen voldoen. Dat is nuttig en een goede toevoeging op de ARBIT.  Het is wel zaak dat een gemeente in de overeenkomst zet welke normen toepasbaar zijn op de betreffende overeenkomst. Als de gemeente dat niet zou doen, dan moet de leverancier gaan interpreteren welk normen voor “de functie en het toepassingsgebied” relevant zijn, want dat is wat het artikel voorschrijft. Zou daar later discussie over ontstaan, dan zal het de nodige moeite kosten een rechter te overtuigen dat de leverancier dat niet zo had mogen beoordelen.

Garanties
In art. 10.2 GIBIT staat: “Indien Opdrachtgever tijdens de looptijd van de Overeenkomst op enig tijdstip constateert dat de ICT Prestatie of delen daarvan niet voldoen aan voornoemde garanties, zal Opdrachtgever Leverancier hiervan schriftelijk of per email en in spoedgevallen ook telefonisch op de hoogte stellen. Indien Leverancier van mening is dat Opdrachtgever geen beroep kan doen op de garantiebepalingen, omdat een Gebrek niet behoort tot de gegarandeerde eigenschappen of terug te voeren is op niet aan Leverancier toe te rekenen oorzaken of op niet door Leve­rancier geleverde of geadviseerde Programmatuur of apparatuur, rust de bewijslast terzake op Leverancier”.

Wat betreft toerekenbaarheid is deze bepaling niet problematisch en ongeveer gelijk aan de ARBIT. Als de gemeente stelt dat een bepaald gebrek onder de garantie valt en de leverancier dat beaamt, maar zich vervolgens beroept op ontoerekenbaarheid – dus dat het gebrek niet door doen of laten van de leverancier is veroorzaakt - dan moet de leverancier dat, zo nodig, bewijzen.

Als de gemeente echter stelt dat de programmatuur iets niet (goed) doet, en de leverancier stelt gemotiveerd waarom de verwachte eigenschap niet onder de garantie valt, dan zou normaal gesproken de gemeente moeten bewijzen dat het daar wel onder valt. De logica daarbij is dat een overeenkomst beschrijft wat overeengekomen is, en niet wat niet overeengekomen is (tenzij het uitzonderingen op het wel overeengekomen deel betreffen). Iemand die stelt dat iets niet onder een overeenkomst valt, die kan dat alleen maar stellen, want bewijs is alleen mogelijk van hetgeen wèl onder de overeenkomst valt. De leverancier wordt door deze bepaling in een onmogelijke bewijspositie geplaatst. Het is niet ondenkbaar dat een rechter deze algemene voorwaarde op grond van artikel 6:233 sub a BW als onredelijk bezwarend aanmerkt, waardoor hij vernietigbaar wordt.

Aansprakelijkheid
De GIBIT sluiten in art 13.2 aansprakelijkheid uit voor wat vaak ‘indirecte schade’ genoemd wordt. Dit wordt gedaan door limitatief op te sommen wat wel voor schadevergoeding in aanmerking komt, waardoor, wat daarin niet staat, dus niet voor schadevergoeding in aanmerking komt. Het gaat daarbij om schade in de ondersteunde zakelijke processen zelf. Voorbeeld: Als de software om WOZ belasting te heffen niet goed werkt, dan is de leverancier niet aansprakelijk voor gemiste WOZ inkomsten van een gemeente. Voor kosten die gemaakt moeten worden om schade te beperken, bestaat wel aansprakelijkheid. Deze regeling is helder en marktconform.

Wat verzekering betreft eist GIBIT twee maal het aansprakelijkheidsbedrag als minimaal verzekerde som. Het enige wat van belang is bij verzekeringseisen, is dat de verzekerde bedragen in verhouding staan tot het totale risico van de portefeuille van de leverancier. Twee keer het maximale aansprakelijkheidsbedrag voor de opdracht is aardig als dit één van de weinige opdrachten van de betreffende leverancier is, maar dat zou geen uitgangspunt mogen zijn. In de meeste gevallen zal twee keer het risico veel te laag zijn. In de ARBIT is geëist dat ‘naar verkeersnormen passend’ verzekerd is. Ook dat is niet ideaal, want hoe toets je dat, maar het is minder kort door de bocht.

Geheimhouding
De geheimhoudingsverplichting is versterkt met een boetebeding. Omdat boetes onverzekerbaar zijn, kunnen boetes beter specifiek per opdracht overeengekomen worden. Voorzichtigheid bij het opleggen van contractuele boetes is verstandig om leveranciers niet onnodig te weerhouden mee te dingen. Hoewel boetes bijna altijd grove maatregelen zijn, is in dit geval de contractuele boete niet gesteld op situaties dat vertrouwelijke gegevens lekken, maar op het niet nakomen van een inspanningsverplichting om gegevens geheim te houden. Dat verzacht de pijn een beetje.

Vrijwaring intellectuele eigendomsinbreuken
De GIBIT bevatten in artikel 17.7 e.v. een clausule die de opdrachtgever vrijwaart van claims van derden, waarin beweerd wordt dat de oplossing hun intellectuele eigendomsrechten zou schenden. Helaas wordt hieraan niet de bevoegdheid van de leverancier gekoppeld om de verdediging op zich te nemen. Dat is echter iets wat iedere volwassen leverancier zal eisen. Juridische kosten kunnen ernstig uit de hand lopen in dit soort zaken, temeer als bij meerdere klanten van de leverancier tegelijk dezelfde claim neergelegd zou worden. Bovendien kan, als in een procedure de klant de schending zou erkennen of tot een extreem dure schikking zou komen, dat - letterlijk - desastreus uitpakken voor de leverancier. Kortom, vrijwaren zonder recht op procederen namens de klant, is accepteren dat je ten onder gaat bij de eerste de beste claim van dit soort, of die nu gegrond is of niet. Persoonlijk zou ik het als roekeloos kwalificeren als een leverancier dit accepteert. En in zee gaan met roekeloze ondernemingen, is niet iets wat de gemeenten zouden moeten willen, laat staan eisen.

Exit
Ten opzichte van de ARBIT is de exit veel uitgebreider geregeld. Voor de opdrachtgever is dit een flinke verbetering ten opzichte van de ARBIT: een goede exitregeling is meer waard dan rechtsmiddelen. Uiteindelijk gaat het erom dat de processen die door de IT oplossingen ondersteund worden, niet verstoord worden. Rechtsmiddelen kunnen daar nauwelijks aan bijdragen maar een goede exitregeling wel. Het is dus een goede zaak dat juist hieraan meer aandacht wordt besteed.

Toepasselijk recht en jurisdictie
Gelukkig is de wat malle uitsluiting van regels van het internationaal privaatrecht (wat dwingend Europees recht is en dus niet uitgesloten kàn worden) niet overgenomen uit de ARBIT.

Conclusies en aanbevelingen
De GIBIT bevat een aantal belangrijke verbeteringen ten opzichte van de ARBIT. Dat heeft in het bijzonder betrekking op hosting (waar ook alle vormen van Software as a Service onder geschaard worden) en daarmee samenhangende verwerking van persoonsgegevens en aanverwante diensten. De uitgebreidere aandacht voor kwaliteitsnormen en voor ‘exit’ zijn belangrijke winstpunten. De beëindiging van overeenkomsten is, door de uitgebreidere regeling van een exit, beter geregeld dan in de ARBIT. Niet alles is echter positief. Ik vat de vier aandachtspunten, die voor aanbestedende gemeenten het belangrijkst zijn, hieronder samen. Afhankelijk van de opdracht kunnen andere aandachtspunten uit dit artikel ook van belang zijn voor gemeenten die de GIBIT gaan gebruiken. Voor leveranciers is het zaak alle besproken punten te overwegen voor vragen voor de nota van inlichtingen, als ze overwegen in te schrijven op opdrachten waar de GIBIT van toepassing worden verklaard.

I.          Als een leverancier van standaard software direct, dus niet via een onafhankelijke reseller, zou willen aanbieden in een aanbesteding, dan wordt deze leverancier in een nadeliger positie geplaatst dan wanneer hij aanbiedt via een reseller. Deze regeling kan in het nadeel van de gemeente werken en er is geen ratio voor te ontdekken. Het begrip ‘derderprogrammatuur’ moet vervangen worden door het begrip ‘standaard programmatuur’. Niet de distributiemethode is van belang, maar aan de mate waarin de leverancier al dan niet bereid is de standaard aan te passen op wensen van klanten: Als software op klantwens aangepast kan worden, dan betreft het geen standaard software (artikel 1.7, 3.7, 9.2, 9.7, 9.9, 19, ).

II.         Er staat in de GIBIT dat termijnen fataal zijn, behalve tussentijdse termijnen. Dit is een regeling die eerder verwarring dan duidelijkheid schept. Het stramien de standaard wettelijke regeling is aanzienlijk helderder en sluit veel beter aan op de IT-praktijk (artikelen 4.1 en 5.5).

III.        Als de gemeente stelt dat een gebrek onder de garantie moet worden opgelost en de leverancier is van mening dat dit niet het geval is, dan moet de leverancier onder deze voorwaarden bewijzen dat dit niet het geval is. Bewijstechnisch is dat (praktisch) onmogelijk; je kunt alleen bewijzen dat iets er wel onder valt, maar niet dat iets er niet onder valt. Voor leveranciers zou dit onaanvaardbaar moeten zijn, het lijkt mij disproportioneel bij aanbestedingen en het is zelfs niet ondenkbaar dat het een onredelijk bezwarende algemene voorwaarde is. In de ARBIT staat een dergelijke bepaling niet. (artikel 13.2).

IV.        In de vrijwaringsregeling van de GIBIT voor intellectuele eigendomsclaims van derden ontbreekt het recht voor de leverancier te mogen procederen namens de klant. Dat is iets wat softwareleveranciers normaal gesproken (zouden moeten) eisen. Dit kan leveranciers, die hun risico’s willen beheersen, mogelijk weerhouden mee te dingen; in ieder geval moet worden verwacht dat in veel nota’s van inlichtingen hierover vragen zullen verschijnen. (artikel 17.7 e.v.).

Om te voorkomen dat gemeenten iedere keer zelf bij voorbaat allerlei clausules moeten aanpassen voordat ze de GIBIT toepassen, zou een herziening van de GIBIT zelf op de genoemde punten voor de hand liggen.

Als een gemeente voorwaarden moet kiezen bij een aanbesteding, dan zijn er goede argumenten toch de GIBIT te gebruiken in plaats van de ARBIT. Waar dat in de betreffende aanbesteding relevant is, kunnen de genoemde bezwaren voorkomen worden door de betreffende GIBIT-bepalingen in de overeenkomst bij voorbaat aan te passen. De voordelen van de GIBIT boven de ARBIT zijn deze extra aandachtspunten in de overeenkomst namelijk wel waard.

Tot slot: het zou mooi zijn als de GIBIT paritair, dus in samenwerking met een representatie van leveranciers, zouden worden vastgesteld, zoals bedoeld in artikel 3.9C van de Gids Proportionaliteit. De genoemde pijnpunten zouden daarbij kunnen worden opgelost op een manier die ook voor de markt aanvaardbaar is. Hierdoor zouden de GIBIT aan bruikbaarheid en aan gezaghebbendheid kunnen winnen.