Bij de traditionele verkoop van on-premises software zijn contractsbepalingen over het in escrow geven van de broncode vrij standaard geworden. Vandaag de dag hebben cloud applicaties, waaronder software-as-a-service (SaaS) oplossingen, evenwel meer en meer de plaats van on-premises software overgenomen.
Bij SaaS loopt de klant vaak een groter risico om de toegang tot de applicatie te verliezen dan bij traditionele software. Het traditionele broncode escrow-model is doorgaans niet voldoende om dat risico in te perken. Saas-klanten eisen dan ook steeds vaker dat ook voor SaaS applicaties een escrow oplossing wordt voorgesteld : de SaaS escrow overeenkomt.
Hoe werkt een dergelijke SaaS escrow overeenkomst en hoe worden de risico’s en kosten tussen de partijen verdeeld?
Om dit nieuwe escrow-model te begrijpen, dien men eerst het traditionele on-premises escrow-model te begrijpen. Escrow van broncode biedt kopers een noodplan voor het geval de softwareleverancier failliet gaat of niet langer kan instaan voor onderhoud en ondersteuning van de software.
Wanneer een onderneming afhankelijk wordt van bepaalde software om zijn activiteiten te kunnen voortzetten, dan is een escrow-bepaling voor broncode in de softwarelicentieovereenkomst (en een aparte driepartijen escrow-overeenkomst voor broncode tussen de klant, de softwareleverancier en een escrow-agent) een essentieel vangnet voor de bedrijfscontinuïteit. Het bestaan van escrow is zo gebruikelijk geworden dat softwareleveranciers het steeds vaker standaard in hun overeenkomsten opnemen. Dit leidt tot soepelere onderhandelingen en schept ook vertrouwen bij de klant.
On-premises software werkt in de eigen live omgeving van de klant. De gegevens van de klant worden opgeslagen op zijn interne systemen en back-upsystemen. De beschikbaarheid van de software is dan ook afhankelijk van de beschikbaarheid van het eigen systeem van de klant. Als de softwareleverancier besluit om te stoppen met het verder ontwikkelen van de software, failliet gaat of zijn activiteiten staakt, zorgt dit in het algemeen vaak voor weinig problemen voor de klant, omdat de software kan blijven draaien op het systeem van de klant.
In dergelijke gevallen zal de klant zich dan beroepen op zijn rechten onder de traditionele broncode escrow-overeenkomst. Hij zal op basis hiervan toegang krijgen tot de broncode en de ontwikkelomgeving om de software opnieuw te ontwikkelen (of laten ontwikkelen door een andere dienstverlener), waardoor hij de software kan blijven gebruiken, onderhouden en updaten met weinig of geen downtime.
Omdat er weinig of geen dreiging is van onmiddellijke, substantiële onderbreking van het bedrijf, bevatten traditionele escrow-overeenkomsten voor broncode vaak de voorwaarde dat de broncode door de escrow-agent slechts mag vrijgegeven wordt indien een zekere tijd verlopen is (de softwareleverancier moet bijvoorbeeld zijn activiteiten gestaakt hebben voor een periode van 60 dagen of meer).
Bij SaaS daarentegen situeren de softwarecode, infrastructuur, gegevens en opslag zich in een productieomgeving buiten het bedrijfspand van de klant. De beschikbaarheid van de software hangt vaak niet alleen af van de SaaS dienstverlener, maar ook van zijn externe hosting-/cloudproviders. Storingen en ontoegankelijkheid van gegevens, ook al duren die slechts enkele minuten, kunnen resulteren in een aanzienlijke bedrijfsonderbreking voor de klant. In zo’n scenario heeft een traditionele broncode escrow-overeenkomst weinig of geen nut voor de klant.
De klant heeft dan ook een veel breder scala aan escrow diensten nodig om hem te helpen in het geval van een storing, waaronder een kopie van zijn data die worden opgeslagen in een veilig back-up datacenter, back-up hosting, zeer gedetailleerde documentatie met bouwinstructies voor het opnieuw creëren (of het inschakelen van een externe leverancier voor het opnieuw creëren) van de applicatie en de productieomgeving, en natuurlijk de broncode en objectcode.
Om aan deze noden tegemoet te komen, bieden leveranciers van broncode escrow diensten nu ook SaaS-risicobeheerdiensten aan. Deze escrow-leveranciers hebben programma’s gemaakt om de continuïteit van SaaS-applicaties en de toegankelijkheid van gegevens te garanderen. Zo maken zij het mogelijk dat de SaaS-applicatie (en alle gegevens van de klant) wordt gekopieerd naar een tweede server in een beveiligd datacenter en kunnen zij zelfs een stand-by herstelomgeving hosten waarop de applicatie naadloos kan verder draaien in het geval van bedrijfskritische applicaties waarbij de klant zich zelfs geen paar minuten downtime kan veroorloven.
Alhoewel SaaS dienstverleners zich aanvankelijk vaak verzet hebben tegen het opnemen van escrow-bepalingen in SaaS licentieovereenkomsten, lijkt hierin de laatste tijd een kentering te komen. SaaS dienstverleners namen immers aanvankelijk het standpunt in dat ze geen continuïteitsgaranties dienden te geven en vertrouwden op het bedrijfscontinuïteits- en noodherstelbeleid om klanten gerust te stellen (ook al is dit bedrijfscontinuïteits- en noodherstelbeleid vaak van toepassing op het bedrijf van de SaaS dienstverlener en niet op dat van de klant).
Nu bedrijven echter steeds meer weten over cloudoplossingen en meer ervaring hebben met het in gebruik nemen van SaaS-applicaties, zien we in de praktijk meer en meer vraag naar SaaS escrow-bepalingen in SaaS licentieovereenkomsten.
Hoe onderhandelen over een SaaS escrow?
Er zijn veel zaken waar je rekening mee moet houden bij het onderhandelen over escrow-bepalingen voor SaaS. De omvang van wat in escrow wordt gegeven is een belangrijke kwestie, omdat de klant wil dat wat in escrow wordt gegeven alles bevat wat nodig is om de ontwikkelomgeving te reproduceren en de applicatie te laten draaien. Vaak is het niet duidelijk wat dit juist inhoudt. De details die een SaaS dienstverlener in zijn documentatie moet geven om de klant of een derde partij in staat te stellen de uitvoerbare code (executabele code) te hercompileren, kunnen veel meer zijn dan wat de SaaS dienstverlener gewoonlijk vermeldt in zijn klantendocumentatie, hetgeen tot extra kosten voor de SaaS dienstverlener kan leiden.
In sommige gevallen, om de oplossing volledig over te zetten naar een andere omgeving, kan de klant toegang nodig hebben tot aanvullende software of gegevensbronnen van derden die de SaaS-applicatie ondersteunen. SaaS dienstverlener moeten hierbij overwegen of zij wel de nodige rechten hebben gekregen van deze derde partijen om dit alles in escrow te plaatsen.
Klanten willen vaak gebruik maken van escrow service providers die gespiegelde (mirrored) applicaties kunnen onderhouden en die onmiddellijk kunnen geactiveerd en gehost worden door de escrow-agent, de klant of de externe dienstverlener van de klant. Deze dienen in feite als een bedrijfscontinuïteitslocatie. Dergelijke escrow-oplossingen kunnen duur zijn, waardoor de kwestie van de kostentoewijzing een ander punt van onderhandeling is bij SaaS escrow-clausules.
Daarnaast is een van de grootste twistpunten tussen Saas dienstverlener en klanten de escrow vrijgavevoorwaarden. Zoals hierboven besproken, vereist in het traditionele softwaremodel de vrijgave van broncode over het algemeen dat de softwareleverancier alle activiteiten voor een aanzienlijke periode (bijv. 30-60 dagen) staakt, een faillissementsaanvraag indient of in een andere procedure met betrekking tot insolventie of liquidatie zit, dan wel officieel stopt met het ontwikkelen van de software en/of de ondersteuning ervoor.
Met betrekking tot het SaaS escrow-model begrijpen verstandige klanten de noodzaak van vrijgavevoorwaarden die de urgentie van downtime kunnen aanpakken. SaaS dienstverlener willen hun applicaties en de intellectuele eigendomsrechten die er mee samenhangen evenwel niet zo gemakkelijk vrijgeven.
Daarom sluiten de vrijgavevoorwaarden voor SaaS escrow vaak aan bij de toepasselijke service-level agreements. Als een SLA voorziet in redelijke oplossingen voor korte periodes van ongeplande downtime, dan kan de SaaS-leverancier argumenteren dat de escrow alleen moet worden geactiveerd bij langere periodes van ongeplande downtime of wederkerende storingen.
Hoewel er over verschillende punten in deze SaaS escrow-bepalingen kan onderhandeld worden, aanvaarden SaaS dienstverleners steeds vaker de aanwezigheid van SaaS escrow en nemen ze deze op in hun licentievoorwaarden om potentiële klanten die op hun hoede zijn voor bedrijfscontinuïteitsrisico’s te overtuigen.
Vanuit het standpunt van de klant moet beoordeeld worden (1) of de applicatie bedrijfskritisch is; (2) wat de kosten zijn zowel op financieel vlak als op vlak van reputatieschade; (3) de beschikbaarheid van vervangende applicaties; (4) de overgangstijd naar een vervangende applicatie; en (5) de stabiliteit en betrouwbaarheid van de softwareleverancier.
Ook al worden SaaS escrow bepalingen meer en meer gebruikelijk in SaaS overeenkomsten, de vraag blijft of ze wel doeltreffend zijn. Een escrow kan de klant gerust stellen op het ogenblik dat hij de risico’s inschat bij het aangaan van een SaaS overeenkomst, maar de daadwerkelijke praktische overgang van de applicatie, het datacenter en de hostingomgeving in het geval aan de escrow vrijgavevoorwaarden is voldaan kan soms rampzaliger zijn dan de downtime zelf. Het is dan ook belangrijk om solide Saas escrow overeenkomsten te sluiten die alle risico’s dekken.
