Je bent er bijna uit met een zorginstelling na maanden van onderhandelen, en dan stuurt hun juridische afdeling op het laatste moment een e-mail: “We verwachten een software escrow overeenkomst als onderdeel van het contract.” Je weet globaal wat escrow inhoudt, maar hoe je het juridisch correct in je voorwaarden verwerkt zonder je broncode onnodig bloot te stellen of de deal te laten stranden, is een stuk lastiger. Dit artikel geeft je concrete stappen en laat zien waar de valkuilen zitten.

Wanneer verschijnt een escrow-verzoek op je bureau?

Enterprise-klanten, overheidsinstanties en organisaties in de zorg stellen escrow bijna standaard. Herkenbare signalen: de klant vraagt naar je “bedrijfscontinuïteitsplan”, wil weten wat er met de software gebeurt als jij failliet gaat, of verwijst naar een inkoopbeleid of aanbestedingsdocument met een clausule over “toegang tot broncode in noodgevallen”. Soms staat het expliciet in een programma van eisen; soms is het een mondeling verzoek dat later formeel wordt. Hoe eerder je dit signaleert, hoe beter je het kunt sturen.

Wat legt een software escrow overeenkomst vast?

Een software escrow overeenkomst regelt dat jij als ontwikkelaar (de deponent) je broncode en aanverwante materialen deponeert bij een neutrale derde partij, de escrow-agent. De klant is de begunstigde. De agent beheert het depot en geeft de inhoud alleen vrij als een zogenaamde triggergebeurtenis plaatsvindt.

Wat er precies in bewaring wordt gegeven, is cruciaal om concreet te omschrijven. Denk aan broncode inclusief versiehistorie, buildinstructies en scripts, afhankelijkheden en libraries, infrastructuurconfiguraties (zoals Terraform-bestanden of Docker-compose), en technische documentatie die nodig is om de software daadwerkelijk te kunnen draaien. Een depot met alleen de broncode maar zonder buildscripts is voor de meeste klanten waardeloos. Wees hierover glashelder in de overeenkomst.

De trigger: het gevoeligste punt

De triggergebeurtenis bepaalt wanneer de escrow-agent de code vrijgeeft. Typische triggers zijn: faillissement of surseance van betaling, het staken van de softwareontwikkeling of -support, of een materiële contractbreuk die niet binnen een redelijke termijn wordt hersteld.

Dit is het punt waar de onderhandeling scherp kan worden. Klanten willen brede triggers; jij wilt ze nauw en objectief toetsbaar. Formuleer triggers altijd zo dat vrijgave alleen mogelijk is na een formele verificatie door de escrow-agent, niet op basis van een eenzijdige mededeling van de klant. Een clausule als “indien de leverancier naar oordeel van de klant tekortschiet” is voor jou onaanvaardbaar. Kies voor objectief aantoonbare omstandigheden, bij voorkeur verbonden aan officiële rechtshandelingen of rechtbankuitspraken.

Stap 1: Is escrow verplicht of een wens?

Check als eerste de opdrachtbevestiging, het aanbestedingsdocument of de raamovereenkomst. Is escrow expliciet als vereiste opgenomen, dan heb je weinig ruimte om te weigeren, maar wel om de voorwaarden te onderhandelen. Is het een wens die tijdens de onderhandeling naar voren komt, dan heb je meer speelruimte over hoe je het inricht en wie wat betaalt.

Stap 2: Kies het juiste type arrangement

Er zijn drie relevante varianten. Bij een klassieke broncode-escrow deponeer je de broncode periodiek bij een agent. Dit past bij maatwerksoftware die de klant zelf zou kunnen draaien. Bij een SaaS-escrow gaat het verder: omdat de klant de software niet zelf host, moet het depot ook een continuïteitsplan bevatten, instructies voor het opzetten van de eigen infrastructuur, en mogelijk toegang tot cloudconfiguratiebestanden. Dit is complexer en duurder. Een verificatie-escrow voegt daar nog aan toe dat de agent actief controleert of de gedeponeerde code ook daadwerkelijk bruikbaar is door deze te bouwen en te testen. Dit geeft de klant meer zekerheid, maar vraag een hogere vergoeding als dit vereist is.

Voor SaaS-producten is een klassieke broncode-escrow in veel gevallen onvoldoende. Adviseer je klant daar eerlijk over; het voorkomt discussies achteraf.

Stap 3: Kies een erkende escrow-agent

In Nederland zijn gespecialiseerde escrow-agents actief die standaardovereenkomsten hanteren. Lees die standaardovereenkomst grondig voordat je iets toezegt aan je klant. Let op: sommige standaardovereenkomsten van agents bevatten bepalingen die de agent het recht geven om de code te inspecteren buiten de verificatieprocedure om, of die de agent vrijwaren op een manier die jouw belangen raakt. Pas de overeenkomst aan of onderhandel hierover voordat je tekent.

Stap 4: De escrow-clausule in je voorwaarden

Een goed geformuleerde clausule in je algemene voorwaarden of opdrachtbevestiging bevat minimaal de volgende elementen:

  • Een verwijzing naar de separate escrow-overeenkomst als bijlage bij het contract
  • Een omschrijving van wat wordt gedeponeerd (zo concreet mogelijk)
  • De triggergebeurtenissen, limitatief opgesomd
  • De licentieomvang bij vrijgave (zie ook het IP-onderdeel hieronder)
  • De updateverplichting en de frequentie
  • De kostenverdeling

Valkuil in de taalkeuze: vermijd vage termen als “alle relevante materialen” of “volledige broncode”. Dit leidt tot interpretatieproblemen. Benoem specifiek welke repositories, welke branches (doorgaans alleen de productie-branch) en welke configuratiebestanden onder het depot vallen. Sluit expliciet uit: intellectueel eigendom van derden waarvoor je geen sublicentiëring mag verlenen, interne tools die geen deel uitmaken van het geleverde product, en testomgevingen of prototypes.

Stap 5: Wie betaalt wat?

Escrow-agents rekenen doorgaans een eenmalig inrichtingstarief en een jaarlijkse beheervergoeding. Een verificatie-escrow kost extra. In de praktijk geldt als vuistregel: als escrow een vereiste is vanuit de klant, draagt de klant de kosten of worden ze gedeeld. Leg dit contractueel vast, inclusief wat er gebeurt bij verlenging van de escrow-overeenkomst. Stel in je clausule ook vast wie verantwoordelijk is voor het betalen van de agent als de overeenkomst tussentijds eindigt.

Stap 6: Het updateprotocol

Een escrow-depot zonder updateverplichting is snel waardeloos. Stel een protocol vast waarbij je bij elke nieuwe productierelease verplicht bent het depot bij te werken, of minimaal op kwartaalbasis. Wijs een verantwoordelijke persoon aan (bij naam of functie), beschrijf hoe de klant kan verifiëren dat het depot actueel is, en bepaal wat de gevolgen zijn als een update uitblijft. Dit is ook in jouw belang: een verouderd depot vergroot de kans op een dispuut over de volledigheid van wat er is gedeponeerd.

De IP-valkuil

Dit is het punt dat veel ontwikkelaars te laat zien. Vrijgave van de broncode is niet hetzelfde als overdracht van het intellectueel eigendom. In de escrow-clausule moet je expliciet vastleggen dat de klant bij vrijgave een beperkte gebruikslicentie krijgt, niet de eigendomsrechten op de code. Die licentie is doorgaans beperkt tot intern gebruik voor het in stand houden van de eigen bedrijfsvoering, en mag niet worden doorgelicentieerd of commercieel worden geëxploiteerd. Neem dit op in de clausule zelf, niet alleen in de achterliggende escrow-overeenkomst.

Wanneer kun je een escrow-verzoek weigeren of beperken?

Bij kleinere opdrachten, eenmalige projecten of klanten zonder aantoonbare afhankelijkheid van jouw software is een volledig escrow-arrangement disproportioneel. Je kunt een escrow-verzoek bespreekbaar maken door alternatieven aan te bieden: een code-in-bewaring bij de notaris, een contractuele verplichting tot kennisoverdracht bij beëindiging, of een openbrondocumentatiepakket dat de klant in staat stelt een andere partij het beheer te laten overnemen. Presenteer dit niet als weigering, maar als een oplossing die past bij de schaal van de samenwerking.

Checklist: minimale vereisten voor een waterdichte clausule

  • Concrete omschrijving van het depot-materiaal, inclusief exclusies
  • Limitatieve opsomming van triggergebeurtenissen, gekoppeld aan objectief verifieerbare omstandigheden
  • Expliciete beperking van de licentie bij vrijgave (gebruiksrecht, geen eigendomsoverdracht)
  • Updateprotocol met frequentie en verantwoordelijke
  • Kostenverdeling inclusief afspraken bij contractverlenging en tussentijdse beëindiging
  • Verwijzing naar de separate escrow-overeenkomst als contractuele bijlage
  • Bepaling dat vrijgave alleen plaatsvindt na formele vaststelling van de triggergebeurtenis door de escrow-agent

Software escrow hoeft geen dealbreaker te zijn, maar vraagt wel dat je de risico’s kent voordat je akkoord gaat. De trigger-formulering en de IP-afbakening zijn de twee punten waarop je niet moet toegeven. Kies de escrow-agent zorgvuldig, lees hun standaardovereenkomst voor je iets toezegt, en zorg dat het updateprotocol ook in je interne werkproces is verankerd, niet alleen op papier. Dan is escrow een professionele afspraak die vertrouwen schept.