Verzin een ICT-contract en win het Handboek ICT-contracten!

| AE 7659 | Iusmentis | 59 reacties

handboek-ict-contractenVolgende week verschijnt mijn nieuwste boek: het Handboek ICT-contracten. Het boek is geschreven voor iedereen die regelmatig ICT-contracten moet maken. Welke contracten heb je zoal en wat moet daar nu precies in? En ik geef er tien weg.

Regelmatig krijg ik de vraag of ik een contract voor het een of ander op de plank heb liggen. Ik moet me dan altijd inhouden om niet te reageren met “heb jij nog een nieuwe site voor me op de plank liggen”, maar het onderliggende punt snap ik: het is meestal een kwestie van de juiste clausules op een rijtje zetten. Alleen weten wélke clausules je op een rijtje moet zetten, blijft een uitdaging.

Dit boek (geschreven samen met ICTRecht-collega Steven Ras) zet die clausules op een rijtje, op meer dan 30 rijtjes zelfs. Contracten worden samengesteld en besproken van affiliateovereenkomst tot whitelabel-resellingovereenkomst, en de clausules van aflevering van software tot het Weens koopverdrag dat iedereen afsluit.

Geïnteresseerd? Bekijk de inhoudsopgave of lees deze of deze preview.

En dan nu de weggeefactie: ik geef tien exemplaren weg aan mensen die een ICT-contract weten dat in het handboek genoemd had moeten worden. Roept u maar, wat ontbreekt er? Graag met enige uitleg en als het kan een linkje naar een voorbeeld van zo’n contract. Timestamp op mijn server is beslissend. Kom maar op!

Overigens is het wat mij betreft tijd voor een paar wettelijke standaardcontracten, maar dat zal nog wel even duren.

Arnoud

Deel dit artikel

  1. Valt me op dat je met name contractzaken mbt de ICT produkten c.q. diensten hebt beschreven in je boek en niet over de mensen die ze leveren. Denk dan aan zaken als geheimhoudingsverklaringen (NDA komt in de buurt maar is niet helemaal hetzelfde, ik bedoel meer in de richting van verhouding werknemer/werkgever), concurentiebedingen, outsourcing. Daarnaast zie ik zo niet of je de contractvorm “raamcontract” hebt beschreven. Dit is met name bij de overheid populair, dan kun je binnen vooraf gestelde afspraken en regels bij een (voor een bepaalde periode) gecontracteerde leverancier produkten en/of diensten afroepen. Behandelt het boek trouwens ook clausules die gaan over de gevolgen van niet nakoming (boetes, sancties, ontbinding, verhalen van kosten indien derde partij na ontbinding het gevraagde moet leveren etc.)?

    • Een raamcontract staat er inderdaad niet in. Ik denk dat we dat vergeten zijn omdat we al de ICT leveringsvoorwaarden hebben, offertes met steeds dezelfde AV komt op hetzelfde neer als een raamcontract. Maar je hebt gelijk, het is een andere vorm en hij had erin gemoeten. Jij bent de eerste winnaar, mail je me even vanaf het adres van je reactie?

      Clausules staan uitgebreid benoemd in hoofdstuk 4.

  2. Ik mis nog een samenwerkings-/partnershipovereenkomst.

    Wat bij ons veel voorkomt is dat een partij bij ons komt met een (goed) idee. Er wordt dan een contract opgesteld wie wat doet, hoe de inkomsten verdeelt wordt, welke kosten wel en niet mogen worden afgetrokken van de inkomsten (zo telt directie salaris bijvoorbeeld niet mee, om te voorkomen dat ze zo extra winst uit de samenwerking kunnen trekken). Daarnaast wordt er nagedacht over wanneer één van beide partijen de overeenkomst mag opzeggen en hoe dat afgehandeld wordt, zelfde voor faillissementen.

    Ik mis trouwens ook nog een kopje over “Responsible Disclosure” voorwaarden, verder zie ik wel veel SaaS, maar geen PaaS. Er is ook wel geschreven over hosting (ik vermoed webhosting), maar hoe zit het met het verhuren van fysieke hardware (daar zijn wel onderhoudscontracten en supportcontracten voor, maar verder niet)?

    • Een vaststellingsovereenkomst, zou ik dat noemen. Meh. Het kan inderdaad in de ICT voorkomen, maar het voelt net over het randje. Net als een arbeidscontract voor een ICT-medewerker: daar staan ICT-clausules in (vertrouwelijkheid, eigendom data) maar ik zou dat geen ICT-contract willen noemen.

      Verder is zo’n contract eigenlijk altijd maatwerk, want je moet dat specifieke conflict oplossen en dus specifiek daarvoor vastleggen wat er gaat gebeuren. Dus nee, die hoort niet in een handboek. Sorry.

  3. Ik mis een beetje IaaS. Nu staan er hier en daar wel wat paragrafen in Hoofdstuk 4 die je kan gebruiken in een IaaS contact, van wie is de data, wie regelt de beveiliging en wie is aanpsrakelijk voor schade door gebruik van de server, maar toch had ik een apart hoofdstuk verwacht aangezien Cloud Computing booming is 😉

    Mooi voorbeeldje is bijvoorbeeld: https://www.gandi.net/static/contracts/en/iaas/pdf/IAAS-Contract-US-1.0.pdf

    En hier nog een heel epistel over hoe je een IaaS contract in elkaar zet: https://www.duo.uio.no/bitstream/handle/10852/22926/SILALAHIx-xMaster.pdf.pdf?sequence=1

    • Hmm, dat is wel een interessante suggestie. Ik heb zelf wat moeite om vanuit juridisch perspectief veel verschil te zien tussen IaaS en PaaS. In beide gevallen is het dienstverlening met zekere beschikbaarheidscijfers en inspanning voor ondersteuning. Maar is het wezenlijk anders, als je de diensten goed definieert? Ik bedoel, downtime is downtime. Of je I dan wel je P down is, is dan toch niet meer dan een detail in de uitvoering?

      • Ja, maar op die manier redeneren vind ik net iets te kort door de bocht ;-). Bij PaaS heb je minder te vertellen over de hardware die gebruikt wordt dan bij een IaaS oplossing. Daarbij komt bij IaaS vaker meer afspreken over storage/backup mbt I/O. Of over snelheden en linkup providers en de redundantie daarvan. Of wat dacht je van security en compliance (zoals PCI DSS Compliancy voor bijv. Credicard gegevens), of ga ik nu wel heel diep 😉

        Maar de reden dat ik IaaS (danwel het broertje PaaS) noemde is omdat ik het hele Cloud gebeure een beetje vond missen 🙂 Misschien dat het in het boek hier en daar wel terugkomt maar dat kon ik net niet zien natuurlijk in de inhoudsopgave 😀

  4. Zie dat mijn reactie niet onderaan terecht is gekomen dus bij deze: Zie ik het goed dat er nog geen aandacht wordt besteed aan de meldplicht datalekken? Lijkt mij ook een clausule waar aandacht aan besteed moet worden met de mogelijke boetes vanuit het CBP?

    En vrijwaringsverklaring met betrekking tot ‘hackers’ kan ik er volgens mij ook niet in terugvinden? Hierbij denk ik aan een contract met bijvoorbeeld een bounty platform als hackerone: https://hackerone.com/ En daarnaast hoe ver mag een vrijwaringsverklaring gaan ten aanzien van het testen van de beveiliging door bijvoorbeeld social engineering naast pentesting?

  5. Op dit moment heb ik een leverancier die naast zijn standaard contract gebruik maakt van een Dossier Afspraken en Procedures (DAP). Waarin de afspraken worden vastgelegd welke niet in hun standaard contract worden vestgelegd. Is over de rechtsgeldigheid/aandachtspunten die hierbij van toepassing zijn ook iets beschreven? O komt dit als onderdeel van het hoofdstuk opbouw contracten naar voren?

    Misschien niet helemaal de opzet van het boek, maar wellicht dat een aantal voorbeelden van verkeerd opgestelde contracten en de gevolgen daarvan nog verhelderend kunnen werken. Of een overzicht van alarmbellen, termen of combinaties hiervan die als deze in een contract staan al tot argwaan kunnen/moeten leiden?

    • Dossier Afspraken en Procedures klinkt als vastleggen van de werkafspraken voor de invulling van een contract. Ik neem aan dat het hier gaat om een verzameling documenten die in onderling overleg is vastgesteld. Deze afspraken zijn (uiteindelijk) wel af te dwingen als beide partijen ooit hebben aangegeven zo te willen werken.

      Wanneer de leverancier met een standaard handboek komt noem ik dat “algemene voorwaarden”.

  6. Zie/herken het niet zo snel: Uitsluiting aansprakelijkheid leverancier/extern beheerder als klant bepaalde software wenst te behouden terwijl deze formeel niet meer te ondersteunen is. Denk aan bijv. windows xp, server 2003..

    Dat wil je buiten AV regelen om de klant de risico’s volledig in te laten zien.

      • Ik denk meer aan situatie waar klant schade leidt na beveiligings incident (populair gezegd: wordt gehackt) en raakt data kwijt, verliest een project, of leidt anderszins schade. Stel dat is herleidbaar naar oude software met niet gepatched (en niet te patchen) gat. De klant zou kunnen dan kunnen stellen dat jij als leverancier/beheerder (vooral dat laatste) beter had moeten weten. Zou ook kunnen stellen dat hij/zij het niet zo had begrepen en niet inzag wat de gevolgen konden zijn.

        Mijn ervaring is dat klanten soms wat kort van geheugen zijn, zaken ineens niet of anders hadden begrepen als het ze beter uitkomt.

  7. Aankoop van ICT hardware, onderhoud van ICT hardware, ICT hardware lease. Telefonie abonnementen (individueeel en organisaties), Telefoonlease.

    Datacentrum gerelateerde gecontracten (huren racks, huren servers). Inclusief bedingen over fysieke toegang Cloud gerelateerde contracten (huren instances, opslagruimte computercapaciteit). Inclusief bedingen rondom opslaglocatie/ safe haven Inclusief aansprakelijkheid bij storingen

    Grid /supercomputing (inhuren computer capaciteit op een grid of supercomputer)

    Inhuren fail-overcapaciteit/locatie (inclusief bedingen over plaatsen gespecialiseerde hardware en regelmatige fail-over tests.

  8. Heb je gedacht aan een contract voor werknemers die in hun vrije tijd software ontwikkelen dat los staat van de normale werkzaamheden? Natuurlijk wel! Dat vergeet jij niet. 🙂 Contracten betreffende een BYOD-situatie staan er ook in, toch?

    Maar wat er ook in moet is wie er verantwoordelijk is als mijn Google Car automatisch over een voetganger heen rijdt. 🙂 Ofwel, waar ligt de verantwoordelijkheid als een robot (auto) een ongeluk veroorzaakt.

    • Dat laatste is niet iets wat je als ict-boer met je klant zal regelen 😉

      Zal ongetwijfeld een boeiende discussie op gaan leveren. Waarbij verschil tussen verantwoordelijkheid en aansprakelijkheid wel eens groot zou kunnen zijn/worden. Laten we trouwens google standaard maar aansprakelijk stellen, die hebben meer centen 🙂 en uiteindelijk de meeste invloed op kwaliteit software. Aangezien omgekeerde bewijslast in politiek Den Haag een leuke term gevonden wordt, zou die ook voor google kunnen gelden…

  9. Contracten mbt apps en apps stores en muziekvideo en muziek/videostores en streamingdiensten

    Is een appstore een software distributeur of een reseller of een tussenpersoon en wie is er bijvoorbeeld verantwoordelijk als de app niet doet wat de store aangeeft dat hij zou moeten / mogen doen (vooraf en bij installatie).

  10. Ongelimiteerde licentie voor het gebruik/redistributie/etc. van door ‘contractors’ geproduceerde code en intellectueel eigendom, zonder dat het intellectueel eigendom zelf overgedragen wordt (zoals normaliter het geval is bij dit soort werk)?

    Deze gebruik ik met enige regelmaat zelf voor betaald open-source-werk.

  11. Sinds de Diginotar-affaire is er bij heel wat decentrale overheden gedoe over de relatie tussen de TTP die verificatiecertificaten uitgeeft en gebruikers van elektronische handtekeningen. Misschien is het aardig aan dit type overeenkomst aandacht te besteden?

    • overeenkomst van overdracht van auteursrecht/i.e.-rechten op software?
    • escrowovereenkomst voor SaaS
    • overeenkomst voor huur van rackspace en/of suite in datacentrum
    • model schoningsverklaring
    • overeenkomst met protocol t.a.v test/acceptatie
    • overeenkomst voor werkwijze exit en transitie naar opvolgend leverancier
      • Ha Arnoud, bedankt voor het aan de kant zetten van je cynisme! SaaS-escrow waarin duidelijk wordt gemaakt dat de SaaS-softwaregebruiker een licentie heeft onder de (opschortende voorwaarde) van faillissement van SaaS-dienstverlener lijkt mij in ieder geval beter dan ‘niets geregeld hebben’ en dus geen licentie hebben maar alleen een dienstverleningsovereenkomst, waarna een faillissementscurator dus ook geen licenties hoeft te eerbiedigen (a la het Berzona-arrest). Ideaal is het allemaal niet, maar de wet en jurisprudentie zijn te onduidelijk respectievelijk te grillig om het treffen van een dergelijke regeling in belangrijke gevallen waarin continuïteit essentieel is na te laten. In een wereld ‘na Berzona’ lijkt SaaS-escrow mij in ieder geval veelal zekerder (of in ieder geval eenvoudiger) dan een TTP-constructie.

        Een schoningsverklaring is een verklaring die een voormalig leverancier afgeeft aan zijn voormalig opdrachtgever waarin hij verklaart dat zijn apparatuur geschoond is van de data van zijn voormalige klant. Niet echt een voorbeeld van een overeenkomst dus… , maar wel iets waarvoor een voorbeeldmodel wellicht handig kan zijn.

  12. Ik mis het onderwerp testen. Dar betreft zowel de mogelijkheid waarbij je als zzp een door de opdrachtgever opgesteld testplan uitvoert (je bent dan niet verantwoordelijk voor de dekking van het testplan, maar ten hoogste voor de uitvoering). Maar ook als je het testplan wel zelf opstelt zijn er genoeg problemen te bedenken. En dan kan het ook gebeuren dat tgv bugs de uitvoering een week stilligt.

  13. Op basis van de inhoudsopgave alleen al lijkt me dit een heel zinvol boek! Het denkt de heel veel belangrijke aspecten af en ik ben erg benieuwd naar het boek zelf: Bij deze mijn poging om een boek te winnen: Een paar dingen die ik op het eerste gezicht niet zag: – Steeds meer developers werken als ZZP-er. Is er een standaardovereenkomst voor een freelance developer die als ZZP-ers meewerkt aan een product? – Content en creative commons. Bij veel software-ontwikkeling gaat het niet alleen om code maar ook om artwork en content, bijvoorbeeld de gebruikte iconen. Het is verstandig om daar ook afspraken over te maken: of creative commons iconen mogen worden gebruikt.

  14. Wat te denken van het begrip: “No cure, no pay” op te nemen? Bij o.a. de dienstverlening datarecovery, wordt gesteld dat als het helemaal niet lukt, men niets hoeft te betalen. Maar stel dat 50% van de data wordt teruggehaald, doordat de rest technisch/fysiek niet (meer) mogelijk is, is dan in juridische zin wel voldaan aan de “cure” en dus dient men te betalen? Ik zou het boek (e-book?) sowieso wel aanschaffen.

  15. Misschien is het geen apart contract, maar de omstandigheid waarbij een partij die software heeft ontwikkeld, deze software op hardware gaat verkopen. Bijvoorbeeld op een tablet. Hierbij heb je natuurlijk met meerdere zaken te maken: verkoop van hardware, licentieovereenkomst, enz. Wellicht een overweging in je boek waard, omdat ik deze situatie vaker zie ontstaan op het moment.

  16. Hoi, heb je een contracteringsvorm opgenomen in geval een voorwaarde voor gunning van de opdracht het goed doorlopen van een Proof of Concept is , dus in de vorm van een LOI (Letter of Intent), voorafgaand aan het overeenkomen van een Mantelovk, Nadere ovk, etc?

  17. Ik mis eigenlijk de turnkey-overeenkomst. Denk daarbij aan een leverancier van een apparaat, of een component dat software bevat. Het is natuurlijk het eindresultaat dat telt, maar het is een bijzondere uitdaging of de leverancier veel vrijheid mag hebben om voor een bepaalde benadering te kiezen.

    Daarnaast zijn er een aantal zekerheidsovereenkomsten die deel hadden kunnen uitmaken van een grotere overeenkomst, maar waar in de loop van de tijd toch behoefte aan bestaat. Denk daarbij aan de verpandingsovereenkomst en de overeenkomst van vruchtgebruik op auteursrecht. Omdat dit goederenrechtelijk werkt, kan het wellicht bescherming bieden tegen een wanpresterende curator. De door J2CV al genoemde overeenkomst van overdracht van auteursrecht, kan je overigens onder opschortende voorwaarde maken. Het voordeel van de leverancier is dat in beginsel het auteursrecht bij hem blijft. En omdat alle de leveringshandelingen al zijn vervuld valt bij een onverhoopt faillissement van de leverancier, het auteursrecht buiten de failliete boedel.

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS