1. WORKSHOP INKOOP IT-
SYSTEMEN DOOR OVERHEDEN
26 OKTOBER 2010

2. Verantwoording
In deze presentatie wordt algemene en beknopte informatie verstrekt
over een aantal juridisch relevante ontwikkelingen. Niet beoogd is om
hiermee juridisch advies te geven voor concrete situaties. Hoewel veel
zorg is besteed aan het opstellen van deze presentatie, aanvaardt
Dirkzwager advocaten & notarissen N.V. geen aansprakelijkheid voor
de inhoud ervan.
© Dirkzwager advocaten & notarissen N.V. 2010.
Alle rechten voorbehouden.

3. Inhoud
• Aanbestedingsrecht
(mr. Tony van Wijk)
• Algemene voorwaarden
(mr. Ernst-Jan van de Pas)
• IT-recht
(mr. Theo Bosboom)

4. Aanbestedingsrecht algemeen
• Bronnen aanbestedingsrecht:
- richtlijnen (2004/18 en 2007/66)
- nationale regelgeving (Bao en Wira)
- eigen inkoopbeleid
- rechtspraak

5. Levering of dienst?
• Levering = product
(standaard hardware/ software)
• Diensten = maatwerk
• Vaak gemengd:
hoogste waarde bepaalt kwalificatie
• Onderscheid weinig relevant
voor levering/dienst: Europese
aanbestedingsdrempel € 193.000,-

6. Europese procedures
• Standaard procedures:
- openbaar
- niet-openbaar (met selectiefase)
• Uitzonderingsprocedures
- onderhandelingsprocedure
- concurrentiegerichte dialoog

7. Open standaard / OSS
• Actieplan “Nederland Open in
Verbinding” 2007
- bestuursafspraak gebruik OSS/OS
- comply or explain and commit
• Handreiking “Het verwerven van
(open source) software” 2007

8. Aanbesteding open standaard
• Open standaard is een technische
specificatie (art. 23 Bao)
• Verwijzing naar open standaard in
beginsel toegestaan mits
- Europese of nationale norm met
toevoeging “of gelijkwaardig”
- omschrijving prestatie en functionele
eisen

9. Aanbesteding OSS
• OSS waarschijnlijk géén
technische specificatie
• OSS toegestaan als eis of wens,
mits:
- specifieke kenmerken duidelijk
gedefinieerd in aanbestedingsdocument;
- kenmerken objectief, niet-discriminatoir
en proportioneel

10. Tips/ aandachtspunten
• Neem rechtsverwerkingsclausule
in aanbestedingsdocument op:
De aanbestedingsdocumenten zijn met zorg samengesteld. Mocht
een gegadigde desondanks tegenstrijdigheden en/of
onvolkomenheden tegenkomen, dan dient de gegadigde deze zo
spoedig mogelijk, doch voor de Nota van Inlichtingen aan de
contactpersoon kenbaar te maken op straffe van verval van recht.
Als naderhand blijkt dat er onvolkomenheden en/ of
tegenstrijdigheden in de aanbestedingsdocumenten zitten en deze
zijn niet door de gegadigde zijn gemeld, kan dit de aanbesteder niet
worden aangerekend.
Ingeval een gegadigde wel tijdig melding doet bij de aanbesteder,
maar de aanbesteder er blijk van geeft niet van mening te zijn dat er
sprake is van een onvolkomenheid en/ of tegenstrijdigheid althans
de aanbesteder terzake geen aanpassingen respectievelijk
wijzigingen verricht, is de gegadigde verplicht nadere acties
(bijvoorbeeld een kort geding) te ondernemen op straffe van
(wederom) verval van recht om over deze (eventuele)
tegenstrijdigheid en/ of onvolkomenheid (na inschrijving) in rechte te
klagen.

11. Tips/ aandachtspunten
• Neem alcateltermijn ook in
aanbestedingsdocument op:
Een inschrijver verliest zijn recht om op te komen tegen de
voorlopige en/ of definitieve gunningsbeslissing wanneer de
inschrijver niet binnen 15 dagen na de datum van verzending van de
brief waarin het voornemen tot gunning bekend is gemaakt, is
gedagvaard in kort geding voor de burgerlijke rechter door
betekening binnen de genoemde termijn van een kort
gedingdagvaarding.

12. Tips/ aandachtspunten
• Voorlopige gunning bevat
(tenminste) de relevante redenen
• Bij onvoldoende motivering gaat
alcateltermijn niet lopen
• Inschrijver kan binnen zes
maanden (of 30 dagen bij
Europese publicatie van de
gunning) de overeenkomst laten
vernietigen

13. Tips/ aandachtspunten
• Onderhandelen/ wijzigingen na
gunning beperkt mogelijk: voeg bij
aanbestedingsdocument concept
van de overeenkomst
• Aanvullen offerte beperkt mogelijk
- kennelijke omissie
- bedoeling objectief bepaalbaar
• Let op (verstrijken)
gestanddoeningstermijn

14. WORKSHOP INKOOP IT-SYSTEMEN
DOOR OVERHEDEN
Algemene voorwaarden
mr. Ernst-Jan van de Pas

15. Mislukken van IT-projecten
• Overgrote deel van IT-projecten mislukt:
– Niet op tijd opgeleverd (geen fixed date)
– Buiten budget (geen fixed price)
– Systeem werkt niet zoals afgesproken (geen garanties)
• Goed contract kan helpen om problemen te
voorkomen + vangnet als het toch misgaat
• Let op “kleine lettertjes”:
– AV IT-leveranciers bevatten vergaande beperkingen

16. Toepasselijkheid AV
• Overeenstemming over toepasselijkheid door
aanbod en aanvaarding (kan ook impliciet)
• Twee vereisten:
1. AV moeten van toepassing worden verklaard “bij of voor
het sluiten van de overeenkomst” = dus niet achteraf!
2. Redelijke mogelijkheid tot kennisneming geven
(Informatieverplichting) = in beginsel ter hand stellen!
• Advies: AV van toepassing verklaren en als bijlage
aan RFP/aanbestedingsdocument hechten

17. Toepasselijkheid AV (2)
Vraag:
• Opdracht ligt onder aanbestedingsdrempel.
Gemeente stuurt RFP uit en verklaart daarin haar
algemene inkoopvoorwaarden van toepassing.
• Leverancier stuurt offerte en verklaart daarin zijn
algemene leveringsvoorwaarden van toepassing.
• Welke AV gelden?

18. Veelgebruikte AV
• Overheden hanteren vaak ARIV of ARVODI
• Let op: niet echt toegesneden op inkoop van IT
– ARIV 2008 = inkoop van spullen
– ARVODI 2008 = inkoop van diensten
• IT-inkoopvoorwaarden voor overheden:
– BIZA 1996 = inkoop van IT, maar verouderd
– ARBIT 2010 = inkoop van IT
• IT-leveranciers hanteren doorgaans:
– Fenit-voorwaarden 1994 / 2003
– ICT-Office voorwaarden 2008

19. ICT-Office vs ARBIT

20. ICT-Office
• ICT-Office zeer eenzijdig in voordeel leverancier:
– levertermijnen zijn onverbindende streefdata
– geen rechten of verwachtingen ontlenen aan begrotingen of
voorcalculaties van leverancier + afgegeven budget is nooit
een vaste prijs
– zeer beperkte garantie
– directe schade begrensd tot bedrag opdracht of € 500.000,-
– indirecte schade (waaronder verlies van data) uitgesloten
– bij gebrek altijd ingebrekestelling sturen = vertraging
– geen recht op opschorting of verrekening
– bij ontbinding geen geld terug; openstaande nota’s direct
opeisbaar
– etc.

21. Casus
Vraag:
• Leverancier pleegt wanprestatie, gemeente ontbindt
het contract en vordert betaalde licentiegelden terug
(100.000 euro).
• Leverancier weigert met een beroep op uitsluiting
van aansprakelijkheid ICT-Office voorwaarden.
• Wie heeft gelijk?

22. ARBIT
• Rijksinkoopvoorwaarden IT-Producten en Diensten
– Bedoeld voor rijksoverheid en voor “modale” projecten
– Gemeenten en provincies niet wettelijk verplicht om ARBIT
te gebruiken, al wordt dit wel aanbevolen
• Uitgangspunt: gezocht naar verantwoord en
contractueel midden (=trendbreuk)
• ARBIT minder eenzijdig dan BIZA, maar nog steeds
wel eenzijdige trekjes: goed uitgangspunt
• Let op: ARBIT vereist nog een apart contract voor
nadere uitwerking!

23. ARBIT (2)
• Enkele aandachtspunten ARBIT:
– Geen harde bepaling over vaste prijzen
– Geen harde bepaling over vaste levertermijnen
– Geen goed raamwerk implementatiefase + “Implementatie”
ziet alleen op aanpassen organisatie op software en niet
andersom; geen (data)conversie
– Redelijk ruime garantie: 12 maanden garantie op software
na acceptatie. Leverancier garandeert dat hij software 5 jaar
lang kan onderhouden
– Acceptatieprocedure summier uitgewerkt
– Pas betalen na acceptatie (= verplicht voorfinancieren)
– Aansprakelijkheid voor wanprestatie beperkt: 1.250K bij
zaak- en persoonsschade en daaruit voortvloeiende schade
of 4X totale Vergoeding bij andere schade

24. Tips voor gemeenten
• Hanteer eigen inkoopvoorwaarden en/of -contract
die/dat is toegesneden op inkoop van IT
• Kan ook zijn IT-addendum bij bestaande
inkoopvoorwaarden (ARIV of ARVODI)
• Bij gebruik ARBIT het contract niet vergeten!
• Verklaar inkoopvoorwaarden (+contract) van
toepassing in bestek/RFP
• Stuur inkoopvoorwaarden (+contract) toe aan
leverancier of aanhechten aan bestek/RFP
• Verklaar AV leveranciers (ICT-Office of Fenit-
voorwaarden) uitdrukkelijk buiten toepassing!

25. Vragen ?
• vandepas@dirkzwager.nl / 026 353 8323
• Bekijk ook onze kennispagina:
www.dirkzwagerieit.nl

26. WORKSHOP INKOOP IT
SYSTEMEN
DOOR OVERHEDEN
Do’s en don’ts IT contracten
mr. Theo Bosboom

28. Uit het nieuwe regeerakkoord:

29. Kan een goed IT-contract
mislukkingen voorkomen?
• Nee, waarschijnlijk niet
• Maar een goed contract kan wel:
– Een handige leidraad vormen voor het project
– Duidelijkheid scheppen over de rechten en
plichten van beide partijen en daarmee
discussies en geschillen voorkomen
– Uw juridische positie versterken voor als het
project toch misloopt of dreigt te gaan lopen

30. Kan een goed IT-contract
mislukkingen voorkomen? (II)
• Bovendien: door serieuze aandacht voor het
contract, komen omissies uit de selectiefase op
tafel
• Stuur zo concreet mogelijk IT-contract mee met
aanbestedingsstukken of offerte-aanvraag,
eventueel in combinatie met de eigen
inkoopvoorwaarden (ARBIT)
– Is efficiënt
– Schept duidelijkheid richting potentiële leveranciers
– Acceptatie contract kan rol spelen bij keuze voor leverancier
– Aanbieding gebaseerd op juiste contract
– Geeft voorsprong in de onderhandelingen

31. Soorten IT-contracten
• IT-overeenkomsten vaak gemengd
karakter: verschillende onderwerpen en
juridische aspecten:
– Levering hardware (pc’s, servers): koop, huur of
lease
– Gebruik software (licentie)
– Ontwikkelen (maatwerk)software
– Dienstverlening: implementatie, consultancy
– Detachering
– Onderhoud/SLA
– Outsourcing/ASP/SAAS/Cloud computing

32. Specificaties
• Onenigheid over uitleg specificaties is een van
de voornaamste oorzaken van geschillen:
weet wat u koopt!
• Wees duidelijk en zo volledig mogelijk
• Verwijs naar de afspraken en stukken uit de
aanbestedingsprocedure/voorfase
(die worden namelijk regelmatig onbewust weer
weggecontracteerd!)

33. Specificaties II
• “Weet wat u koopt” geldt ook voor
implementatie en onderhoud
• Zorg ervoor dat dit duidelijk is voordat het
hoofdcontract wordt getekend
• Bij voorkeur al uitgewerkt implementatieplan
en complete SLA

34. Prijzen en betaling
• Probeer prijzen (ook voor implementatie en
consultancy) al zoveel mogelijk duidelijk te
krijgen en vast te leggen
• Neem regels op voor tussentijdse
prijsstijgingen (indexcijfer) en voor meerwerk
• Let op betaalmomenten (substantieel deel
pas betalen na volledige acceptatie)

35. Acceptatieprocedure
• Goede acceptatieprocedure heel
belangrijk:
– Opdrachtgever wordt gedwongen software
kritisch te testen;
– Problemen vóór live-gang op tafel;
– Manier om juridische positie te verstevigen
(maatregelen bij falen acceptatietest)
– Manier om betalingen in pas te laten lopen
met opleveringen

36. Aansprakelijkheid
Stel dat er met het IT-systeem
absoluut niet te werken valt,
of het lukt niet om het aan de praat
te krijgen
Na maandenlang ploeteren nog altijd
geen oplossing
Wat nu!?

37. Aansprakelijkheid II
• Wat zegt de wet?
– Toerekenbare tekortkoming vereist
– Daarnaast eisen inzake verzuim, causaal
verband en toerekening
– Belangrijk: in beginsel onbegrensde
aansprakelijkheid
• In de praktijk vergaande beperkingen
• Wat is redelijk?

38. Aansprakelijkheid III
• Gezichtspunten:
– wat zijn de belangrijkste risico’s van het
project?
– welke schade kan daar uit voortvloeien?
– wat is de waarde van de opdracht en van de
eigen investeringen?
– Hoe ziet de rest van het contract eruit?
• Beperking/uitsluiting belangrijk onderdeel
contract, maar let ook op andere
(impliciete) beperkingen
• Vraag: kan rechter beroep op clausule
opzij zetten, als dat heel onredelijk is?

39. Intellectuele eigendom
• Software wordt met name beschermd door
auteursrecht en wordt in de regel
geëxploiteerd door middel van licenties
(gebruiksrechten)
• Let op beperkingen in licentiecontract mbt
bijvoorbeeld aantal gebruikers, locatie,
looptijd, enz: mogelijk obstakel bij
outsourcing, ASP en SAAS
• Zelf eigenaar blijven van maatwerk (of
terugverdienregeling)

40. Open source software
• Let in contracten op specifieke kenmerken
open source software
• Kan consequenties hebben voor regeling
projectverantwoordelijkheid, intellectuele
eigendom, licentievoorwaarden,
aansprakelijkheid, enz.
• Neem kennis van de toepasselijke
licentievoorwaarden (zoals de GPL)

41. Onderhoud en SLA’s
• Standaard onderhoudscontract
meestal helpdeskfunctie en recht
op nieuwe releases
• Geeft weinig waarborgen voor
afnemer
• Bij systemen waarvoor een hoge
beschikbaarheid cruciaal is,
Service Level Agreement (SLA)
aan te raden

42. Onderhoud en SLA’s (II)
• In SLA gedetailleerde afspraken over te
verrichten onderhoudsdiensten, meestal
gekoppeld aan ernst van het probleem
• Niet alleen responstijden, bij voorkeur ook
oplostijden (en algemene
beschikbaarheidsgarantie)
• Denk aan stok achter deur!
• Maak tijdig melding van uw wensen

43. Escrow
• Escrow regeling kan zinvol zijn, voor
waarborgen continuïteit onderhoud, met
name bij faillissement
• Let op inhoud en goede uitvoering regeling
(pas op voor schijnzekerheid!):
– Duidelijk contract, met betrouwbare derde
– Controlemogelijkheid
– Niet alleen broncode, ook documentatie
– Periodieke update
– Let op bij SAAS en ASP constructies