Wat is software escrow?

Definitie: Software escrow is een regeling waarbij de broncode, documentatie en bouwinstructies van software worden bewaard bij een onafhankelijke derde partij, de escrow-agent. Treedt een vooraf afgesproken gebeurtenis op, zoals een faillissement van de leverancier of het structureel uitblijven van onderhoud, dan krijgt de gebruiker toegang tot dat materiaal om de software zelf of via een andere partij te laten onderhouden.

In het kort

• Bij software escrow zijn meestal drie partijen betrokken: de leverancier, de gebruiker en een neutrale escrow-agent die het depot beheert.
• Een escrow regeling voor broncode beschermt de continuïteit van bedrijfskritische software, niet het eigendom: na vrijgave mag je de software onderhouden binnen de afgesproken licentie.
• Verificatie bepaalt de waarde van het depot. Een map met bestanden is iets anders dan code waarvan getest is dat hij opnieuw te bouwen is.
• Bij SaaS is broncode alleen niet genoeg. Ook de serveromgeving, configuratie en een recente kopie van je gegevens moeten geregeld zijn.

Wat is software escrow?

Software escrow is een verzekering tegen het wegvallen van je softwareleverancier. Veel bedrijven werken met software die ze niet zelf bezitten: een pakket dat een kleine leverancier heeft gebouwd, een maatwerkapplicatie waarvan de leverancier de rechten houdt, of een online platform waarop het hele bedrijfsproces draait. Gaat die leverancier failliet, stopt hij met het product of reageert hij niet meer, dan heb je een probleem. Zonder broncode kan geen andere ontwikkelaar fouten oplossen, beveiligingsupdates doorvoeren of de software aanpassen.

Met software escrow leg je dat risico vooraf vast. De leverancier deponeert de broncode en alles wat nodig is om de software te begrijpen en te bouwen bij een onafhankelijke partij. Die partij bewaart het materiaal en geeft het alleen vrij als een van de afgesproken vrijgavegebeurtenissen optreedt. In Nederland wordt ook gesproken over een escrow regeling, broncodedepot of depotovereenkomst.

Waarom bestaat software escrow?

Leverancier en gebruiker hebben verschillende belangen. De leverancier wil zijn broncode niet zomaar afgeven, omdat daarin zijn kennis en vaak zijn verdienmodel zit. De gebruiker wil zeker weten dat de software blijft werken, ook als het met de leverancier misgaat. Software escrow is het compromis: de code blijft vertrouwelijk, maar ligt klaar voor het moment dat de gebruiker hem echt nodig heeft.

Dat speelt vooral bij software die bedrijfskritisch is, bij leveranciers die klein of nog jong zijn, en bij sectoren waar toezichthouders vragen naar continuïteit. Volgens Codekeeper noemen regelingen voor de financiële sector zoals DORA, en normen als ISO 22301 en ISO 27001, het beheersen van leveranciersrisico als onderdeel van goede bedrijfsvoering. Escrow is dan een manier om dat aantoonbaar te maken.

Hoe werkt een escrow regeling voor broncode?

Een escrow regeling verloopt in vaste stappen:

1. Overeenkomst sluiten. Leverancier, gebruiker en escrow-agent leggen vast wat er wordt gedeponeerd, hoe vaak, welke verificatie plaatsvindt en wanneer vrijgave volgt.
2. Eerste depot. De leverancier levert de broncode en de bijbehorende materialen aan bij de agent.
3. Verificatie. De agent controleert of het depot compleet en bruikbaar is. Het niveau van die controle wordt vooraf afgesproken.
4. Periodieke updates. Bij nieuwe versies van de software levert de leverancier een bijgewerkt depot aan. Een depot van drie jaar oud heeft weinig waarde als de software sindsdien flink is veranderd.
5. Vrijgave. Doet zich een afgesproken gebeurtenis voor, dan dient de gebruiker een verzoek in. De leverancier krijgt meestal een termijn om bezwaar te maken. Volgens Codekeeper volgt bij betwisting doorgaans arbitrage.
6. Gebruik na vrijgave. De gebruiker of een nieuwe ontwikkelaar gebruikt het materiaal om de software te onderhouden en draaiende te houden.

Wat hoort er in het depot?

Alleen de broncode deponeren is onvoldoende. Een ontwikkelaar die de software moet overnemen, heeft veel meer nodig. Sprintlaw noemt onder meer de volgende onderdelen:

• De volledige broncode, inclusief alle modules.
• Buildscripts en de tools die nodig zijn om de software te bouwen.
• Instructies voor installatie en uitrol, en de configuratie van de omgeving.
• Technische documentatie en architectuurschema’s.
• Het databaseschema en een beschrijving van de velden.
• Documentatie van API’s en koppelingen.
• Een lijst met gebruikte pakketten van derden en hun licenties.
• Waar nodig sleutels of inloggegevens die voor de uitrol nodig zijn, zorgvuldig beheerd.

Welke vrijgavegebeurtenissen zijn gebruikelijk?

De vrijgavegebeurtenissen, ook wel release triggers genoemd, vormen de kern van de overeenkomst. Veelvoorkomende voorbeelden zijn:

• Faillissement of surseance van betaling van de leverancier.
• De leverancier staakt zijn bedrijfsactiviteiten.
• De leverancier levert gedurende een afgesproken periode geen onderhoud of support.
• Het product wordt beëindigd en er komen geen updates meer.
• Een ernstige tekortkoming in het contract die niet binnen een gestelde termijn wordt hersteld.
• Een overname of overdracht van de software aan een andere partij.

Law & More adviseert om elke gebeurtenis zo te formuleren dat ze objectief vast te stellen is, bijvoorbeeld via het insolventieregister of het handelsregister van de KvK. Een vage formulering zoals “onvoldoende onderhoud” leidt eerder tot discussie dan een concrete termijn waarbinnen een melding moet zijn opgelost.

Welke soorten verificatie zijn er?

Het verschil tussen een bruikbaar en een waardeloos depot zit vaak in de verificatie. Escrow-agents bieden daarvoor verschillende niveaus aan:

Codekeeper werkt bijvoorbeeld met de niveaus Validated, Verified en Certified, waarbij bij Certified een mens het depot beoordeelt en een volledige buildtest plaatsvindt. Hoe hoger het niveau, hoe hoger de kosten, maar ook hoe groter de zekerheid dat je na vrijgave echt verder kunt.

Tweepartijen of driepartijen?

Er bestaan twee hoofdvormen. Bij een tweepartijenregeling sluit alleen de leverancier een overeenkomst met de escrow-agent; de gebruiker is daar geen partij bij. Bij een driepartijenregeling tekent de gebruiker mee en heeft hij een eigen, rechtstreekse aanspraak op de agent.

Volgens Law & More biedt alleen de driepartijenvorm echte zekerheid. Bij een tweepartijenregeling moet bij faillissement de boedel van de leverancier meewerken, en de curator kan weigeren een overeenkomst na te komen. Bij een driepartijenregeling heeft de agent een directe verplichting tegenover de gebruiker.

Software escrow en faillissement in Nederland

Het belangrijkste scenario voor escrow is een faillissement van de leverancier. Het Nederlandse recht geeft daar een aantal aandachtspunten bij, die Law & More uitgebreid beschrijft:

• De depotovereenkomst valt onder de regels van bewaarneming in artikel 7:600 van het Burgerlijk Wetboek.
• De curator kan op grond van artikel 37 van de Faillissementswet weigeren een lopende overeenkomst na te komen.
• Een licentie die al vóór het faillissement is verleend, blijft volgens de uitspraak van de Hoge Raad in de zaak Credit Suisse/Jongepier uit 2018 in stand, omdat de curator een voortdurende gedoogplicht niet kan beëindigen.
• De licentie op de broncode kun je daarom beter nu al verlenen onder een opschortende voorwaarde, in plaats van pas op het moment van vrijgave. Een licentie die pas na het faillissement tot stand moet komen, is kwetsbaar.

Laat een escrow-overeenkomst voor bedrijfskritische software beoordelen door een jurist met ervaring in IT-contracten.

Hoe werkt escrow bij SaaS?

Bij SaaS draait de software niet bij jou, maar bij de leverancier of diens hostingpartij. Een depot met alleen broncode helpt dan weinig: je hebt ook servers, configuratie, koppelingen en vooral je eigen gegevens nodig. Lewis Silkin wijst erop dat traditionele broncode-escrow de gegevens in de cloud meestal niet dekt, en dat sommige SaaS-aanbieders escrow helemaal niet toestaan.

Daarom zijn er varianten ontstaan:

• SaaS escrow, waarbij naast broncode ook de omgeving, configuratie en databases worden vastgelegd, zodat de applicatie elders kan worden opgestart.
• Continuity escrow, waarbij volgens Codekeeper de betaling van hosting, API’s en infrastructuur na een probleem tijdelijk doorloopt, zodat de dienst blijft draaien terwijl een oplossing wordt gezocht.
• Periodieke data-export, die je ook los van escrow kunt afspreken, zodat je altijd over een recente kopie van je eigen gegevens beschikt.

Wat kost software escrow?

Geen van de geopende bronnen noemt vaste bedragen, omdat de prijs sterk afhangt van de opzet. Wel is duidelijk uit welke onderdelen de kosten bestaan:

Volgens Codekeeper zijn SaaS escrow en continuity escrow duurder dan traditionele escrow, omdat ze technisch complexer zijn. Law & More geeft aan dat doorgaans de klant betaalt, tenzij anders is afgesproken. Leg in het contract vast wie welke kosten draagt.

Software escrow of eigen broncode?

Bij standaardsoftware en SaaS is escrow vaak de enige manier om iets van zekerheid te krijgen, omdat de leverancier de broncode niet aan elke klant geeft. Bij maatwerk ligt dat anders. Daar kun je ook afspreken dat de broncode in een repository staat waar jij toegang toe hebt, met documentatie en een vaste manier van uitrollen. Dan heb je de code al, en is escrow minder nodig.

Wat betekent dit voor jouw project?

Bij een nieuw idee onderzoek ik eerst of een bestaand pakket, een koppeling of maatwerk het beste past. Die keuze bepaalt ook hoe je de continuïteit regelt. Kies je voor een pakket of SaaS-dienst, dan hoort de vraag wat er gebeurt als die leverancier stopt bij de selectie. Kies je voor maatwerk, dan wil ik vooraf duidelijk hebben waar de code staat, wie erbij kan en hoe een andere ontwikkelaar later zou kunnen aansluiten.

Ik vind het belangrijk dat je die afspraken maakt voordat er iets misgaat. Op het moment dat een leverancier niet meer reageert, is het te laat om nog te regelen welke materialen je nodig hebt.

Vraag? Draait een belangrijk deel van je werk op software waarvan je niet weet wat er gebeurt als de leverancier stopt? Stuur me welke software het is en waarvoor jullie hem gebruiken. Dan kijken we samen wat een logische eerste stap is. Lees ook wat er komt kijken bij een maatwerk webapplicatie.

Veelgestelde vragen over software escrow

Wat is een escrow regeling voor broncode?

Een escrow regeling is een afspraak waarbij een onafhankelijke partij de broncode en documentatie van software bewaart. Bij een vooraf afgesproken gebeurtenis, zoals faillissement van de leverancier, krijgt de gebruiker toegang tot dat materiaal om de software te laten onderhouden.

Word je eigenaar van de software na vrijgave?

Nee. Na vrijgave mag je de broncode gebruiken om de software te onderhouden en te blijven gebruiken binnen de afgesproken licentie. Het eigendom en de intellectuele eigendomsrechten blijven bij de leverancier, tenzij in het contract iets anders is geregeld.

Is software escrow mogelijk bij SaaS?

Ja, maar alleen broncode deponeren is bij SaaS meestal onvoldoende. Een SaaS escrow regeling omvat ook de omgeving, configuratie en gegevens, en sommige aanbieders kiezen voor continuity escrow waarbij de hosting tijdelijk doorloopt.

Verwante termen

Broncode · Intellectueel eigendom software · Vendor lock-in · SLA · SaaS · Doorontwikkeling en onderhoud