Staat u op het punt om een software- of SaaS-contract te sluiten? Dan wilt u zeker weten dat alle essentiële topics in het contract zijn opgenomen. Niet alleen de algemene zaken als scope, looptijd en aansprakelijkheid, maar juist ook de voor software specifieke topics als acceptatietest, releasebeleid en licentiemodel. De typerende onderwerpen heb ik opgenomen in een handige checklist, waarmee u uw contract kunt beoordelen.
Een software- of software as a service (SaaS)-contract is anders dan een ‘gewoon’ it-contract. Er gelden specifieke aandachtspunten, zoals acceptatietest, releasebeleid, de keuze voor het soort ontwikkelmethode, licentiemodel en escrow regeling. Hieronder een aantal relevante topics waarop u een softwarecontract kunt beoordelen.
Het overzicht
Acceptatietest: Een acceptatietest vindt meestal plaats als de ontwikkeling van de software leidt tot een oplevering aan de opdrachtgever. Bij agile-softwareontwikkeling kan dat dus ook met de regelmaat van iedere sprint zijn. In softwarecontracten wordt vaak een bepaling opgenomen, waarin de leverancier aangeeft geen verantwoordelijkheid te zullen dragen voor gebreken die na acceptatie worden ontdekt. Oftewel bij de opdrachtgever ligt een verantwoordelijkheid om de acceptatietest goed uit te voeren. Het is belangrijk om de bepalingen rondom de acceptatietest kritisch door te nemen. Zijn ze reëel en leggen ze niet teveel verantwoordelijkheid bij u als opdrachtgever?
Releasebeleid: Zeker als u een standaard softwarepakket afneemt, is het releasebeleid relevant. In het contract dient een leverancier aan te geven hoe omgegaan wordt met zaken als patches, updates en upgrades. Ook staat vermeld op welke wijze u invloed kunt uitoefenen op het doorvoeren van veranderingen en verbeteringen in de software bij het onderhoud van de software.
Licentiemodel: Als u software gaat gebruiken, dan heeft u daarvoor een licentie nodig. Het prijsmodel hiervoor is anders dan wanneer u zelf eigenaar wordt van de software. Het licentie- en prijsmodel verschilt vaak sterk per softwareaanbieder. Bij een licentie- en prijsmodel gebaseerd op aantal gebruikers is dan nog de vraag welk type gebruikers: concurrent users of named users. In het contract is opgenomen welk model wordt gehanteerd en wat de verschuldigde vergoedingen voor de licentie zijn. Daarnaast staat omschreven wat de reikwijdte van uw licentie is, oftewel wie en welk gebruik van de software wel of juist niet is toegestaan.
Escrow regeling: Een escrow regeling is een overeenkomst tussen een softwareleverancier, de afnemer en een derde partij (de escrow agent). De escrow agent houdt de broncodes van de software in depot, waardoor de afnemer in bepaalde gevallen (discontinuïteit) hierover kan beschikken. Strijdpunt tussen leverancier en afnemer is dikwijls de vraag of (vermeend) tekortschieten in de dienstverlening door de leverancier ook moet gelden als grond voor afgifte. Een belangrijk punt voor aan de onderhandelingstafel want u wilt niet eindigen met een escrow regeling die niets waard blijkt.
Auteursrecht software: Een telkens terugkerende vraag is: wie is de rechthebbende van de software. Is dat de leverancier of de afnemer? In veel gevallen is een contractuele regeling in het contract nodig om te bereiken dat de intellectuele eigendomsrechten worden overgedragen. Voor de levering van het auteursrecht op een werk (overdracht) geldt het wettelijk vereiste van een ‘daartoe bestemde akte’. In de praktijk bestaat vaak een grote behoefte aan overdracht door de maker of rechthebbende aan een andere partij. Menigmaal wordt echter de overdracht door middel van de voorgeschreven akte over het hoofd gezien of nagelaten. Controleer dit dus goed.
Checklist
Om u te ondersteunen, is de checklist ‘softwarecontracten beoordelen’ opgesteld. Beoordeel uw contract met behulp van deze checklist en vink de topics eenvoudigweg af. Mist u iets? Onderneem dan actie, want u wilt niet voor verrassingen komen te staan tijdens of aan het einde van de looptijd.
Goed duidelijk artikel.
Ik wil het volgende uitgangspunt met betrekking tot SaaS toevoegen.
Wat ICT leveranciers en providers zich vaak niet realiseren is dat dit soort dienstverlening 100% outsourcing betreft. Met een eigen governance. Marketingteksten als “wij ontzorgen u” zijn dan ook misleidend.
————————————————————————————————————————-
Bij Cloud (en dus ook SaaS) dienstverlening zijn o.a. de volgende zaken dus uitgangspunten:
* Exit strategie (AVG artikel 28 lid 3g)
* Recht op audit/right to audit (AVG artikel 28 lid 3h)
* Verantwoordingsplicht (AVG artikel 5 lid 2), o.a. door middel van een TRANSPARANTE Verwerkersovereenkomst. WAAR worden de gegevens exact verwerkt, op welk platform (sub-verwerker), met welke maatregelen? Specifiek benoemd, of certificering.
Nog een extra aandachtspunt.
—————————————–
En wat de software zelf betreft, daar is de AVG ook op van toepassing.
Artikel 25 (privacy by design & default) is een ontwerp-requirement, van het type MUST-HAVE.
Voor nieuwe applicaties en alle nieuwe versies van bestaande applicaties.