Bij klassieke escrow geeft de leverancier van software de broncode in bewaring bij een escrow-agent of een bewaarnemer. Deze partij bewaart een kopie van de broncode in een kluis tot het moment dat de leverancier niet meer in staat is de software te onderhouden, bijvoorbeeld in geval van een faillissement. Middels een escrow-overeenkomst verkrijgt de klant op dat moment de kopie van de broncode inclusief het recht op deze voor continuïteitsdoeleinden te gebruiken. De praktijk leert dat escrow-overeenkomsten er heel verschillend uit kunnen zien. In deze blog 10 punten waarop te letten bij het sluiten van een escrow-overeenkomst.
In sommige gevallen wordt nog steeds de klassieke escrow aangeboden, terwijl er sprake is van een clouddienst. Alleen afgifte van de broncode van de software is dan niet voldoende om continuïteit te bieden voor de afnemers van de clouddienst. Er moeten aanvullende maatregelen worden getroffen ten aanzien van de beschikbaarheid van de data en het in de lucht houden van de dienst (lees voor meer info onze blog 'Escrow voor clouddiensten: hoe werkt het?'). Niet alle standaard escrow-overeenkomsten zijn dus een daadwerkelijke praktische oplossing voor continuïteit.
Bij escrow is het van belang om te inventariseren welke partijen en assets relevant zijn in geval zich een calamiteit voordoet bij de softwareleverancier. Het kan hier bijvoorbeeld gaan om een hostingleverancier of een colocatieleverancier, die niet meer doorbetaald wordt door de softwareleverancier, als deze failliet gaat. Tevens is het van belang om te beoordelen welke assets onderdeel zijn van de dienstverlening, zoals bijvoorbeeld het eigendom van de hardware. Valt deze hardware bijvoorbeeld in de boedel? Als dit niet van te voren goed in kaart is gebracht, is het mogelijk dat de escrow-overeenkomst niet goed uitgevoerd kan worden.
In een inventarisatie is het van belang om vooraf duidelijkheid te hebben wie rechthebbende is ten aanzien van de software. Als je niet van tevoren goed controleert hoe het zit met de intellectuele eigendomsrechten loop je namelijk de kans dat de escrow-overeenkomst met de verkeerde partij wordt gesloten - bijvoorbeeld de werkmaatschappij - terwijl die niet de auteursrechten heeft. Tevens kan tijdens de inventarisatie vooraf blijken dat de rechten überhaupt niet liggen bij de partij, die er zelf vanuit gaat dat hij rechthebbende is, omdat de rechten bijvoorbeeld nog bij een externe ontwikkelaar ligt. Ook kunnen verpandingen of open source componenten conflicteren met de afspraken in een escrow-overeenkomst.
Zoals hierboven ook aangegeven, is het van belang om de keten te kennen die achter de softwareleverancier zit. In geval de software bijvoorbeeld een cloudapplicatie betreft kunnen de afspraken die de softwareleverancier maakt met zijn toeleveranciers effect hebben op de tenuitvoerlegging van de escrow-overeenkomst. De toeleveranciers moeten hun medewerking hebben toegezegd aan dergelijke constructies.
Het moet mogelijk zijn om de escrow-overeenkomst op te zeggen, zowel voor de softwareleverancier als de afnemer. Wel moet dit op een manier gebeuren dat de softwareleverancier niet om “twee voor twaalf” de escrow-overeenkomst kan opzeggen, zodat de afnemers alsnog vlak voor een calamiteit met lege handen kunnen komen te staan.
Bij cloudapplicaties is escrow meer dan broncode depot alleen, dat hebben we hierboven al gezien. Los van de continuïteit ten aanzien van de data en de hosting, kunnen ook medewerkers relevant zijn voor de continuïteit. Dit kunnen bijvoorbeeld de belangrijkste ontwikkelaars zijn of bepaalde helpdeskmedewerkers. Toegang tot deze medewerkers in geval van calamiteit moet dus onderdeel zijn van de escrow-overeenkomst.
Bij klassieke escrow komt het nog steeds wel eens voor dat er broncodes in escrow worden genomen, die niet gecontroleerd zijn door een onafhankelijke derde. In dat geval loop je het risico dat je een escrow-object hebt, wat niet geschikt is voor het doel: het voorkomen van continuïteitsproblemen met de afnemer. Van belang is het om met betrekking tot datgene wat in escrow wordt gebracht te controleren of het goed gedocumenteerd, bruikbaar en overdraagbaar is. Tevens is het essentieel om periodiek het escrow-proces te herhalen, zodat je zeker weet dat er een actueel escrow-object aanwezig is en dat er niks veranderd is in de auteursrechtelijke situatie.
Indien er persoonsgegevens worden verwerkt in het escrow-proces is het van belang om te controleren of deze conform de AVG worden verwerkt. Het is uiteraard niet te bedoeling dat de escrow-overeenkomst niet kan worden uitgevoerd, omdat dit bijvoorbeeld strijdig zou zijn met de rechten van betrokkenen. Zorg bij verwerking van persoonsgegevens voor een duidelijke wettelijke grondslag, zodat je niet voor verrassingen komt te staan bij een calamiteit.
Check bij een escrow-overeenkomst goed wat er is afgesproken in geval er conflict ontstaat over de tenuitvoerlegging van de overeenkomst. Wat zijn de afgiftegronden en wat gebeurt er als er conflict is over deze gronden op het moment van calamiteit? Wat gebeurt er als er onenigheid is over het wel of niet aanwezig zijn van wanprestatie? Het is voor een afnemer van belang dat er op zo kort mogelijke termijn continuïteit wordt geleverd, in geval van calamiteit. Zorg dus voor heldere afgiftegronden en goede afspraken over conflictoplossing.
De afspraken in de licentieovereenkomst of in de SLA moeten er niet voor zorgen dat de tenuitvoerlegging van de escrow-overeenkomst in gevaar komt. Zo kan er in de licentieovereenkomst staan dat de overeenkomst eindigt bij faillissement van de softwareleverancier. Een geldige licentie is echter wel nodig om een beroep te kunnen doen op de escrow-overeenkomst. Zorg er dus voor dat deze afspraken op elkaar aansluiten.
Meld je nu aan voor één van de nieuwsbrieven van ICTRecht en blijf op de hoogte van onderwerpen zoals AI, contracteren, informatiebeveiliging, e-commerce, privacy, zorg & ICT en overheid.