Broncode-escrow: zin of onzin?

Bij een escrowregeling wordt de broncode van uw software bij een onafhankelijke derde in bewaring gegeven. Gebeurt er iets met uw leverancier, meestal faillissement, dan krijgt u toegang tot die code.

Het is een verzekering tegen één specifiek scenario: uw leverancier verdwijnt. Voor dat scenario werkt het, mits de regeling goed is opgezet.

Het is nuttig om te weten waar het idee vandaan komt. Escrow stamt uit een tijd waarin software op uw eigen servers draaide en de leverancier de enige was die de code had. Als die wegviel, stond u met een systeem dat niemand kon onderhouden.

In een wereld waarin uw software als dienst draait op de infrastructuur van de leverancier, is dat scenario anders. Dan is niet de code uw grootste zorg maar de toegang tot uw gegevens en de continuïteit van de dienst. Dat verklaart waarom escrow bij een clouddienst zelden het juiste instrument is.

Er zijn drie partijen: u, uw leverancier en een onafhankelijke escrow-agent. De leverancier deponeert periodiek een kopie van de broncode bij die agent. In het contract staat bij welke gebeurtenissen de agent de code aan u vrijgeeft: faillissement is de bekendste, maar ook het staken van het onderhoud of het niet nakomen van herstelverplichtingen kunnen erin staan.

De praktijk staat of valt met de kwaliteit van de deponering. Een depot dat bij het tekenen één keer is gevuld en daarna nooit meer, geeft u over drie jaar een versie die niets meer met uw systeem te maken heeft. Periodieke deponering is daarom geen extraatje maar de kern van de regeling.

Sommige aanbieders bieden verificatie aan: de agent controleert of het gedeponeerde pakket compleet is en of het gebouwd kan worden. Dat kost extra en het is het enige onderdeel dat het verschil maakt tussen een regeling die werkt en een die op papier bestaat.

Broncode is niet hetzelfde als een werkend systeem. U heeft ook de bouwinstructies nodig, de configuratie, de omgevingsvariabelen, de databasestructuur en de kennis om het geheel draaiend te krijgen. Een depot met alleen code is een doos met onderdelen zonder handleiding.

Daar komt bij dat het depot vaak verouderd is. Als er bij elke oplevering opnieuw gedeponeerd moet worden en dat gebeurt één keer per jaar, ontvangt u bij een faillissement een versie die niet meer bij uw gegevens past.

Er is nog een aanname die zelden wordt getoetst: dat u met de code iets kunt. Broncode zonder de bijbehorende bouwomgeving, zonder documentatie over de infrastructuur en zonder iemand die het systeem kent, is een map met bestanden. De vraag die u zichzelf moet stellen is niet of u de code krijgt, maar wie hem de dag erna gaat draaien.

• Spreek af dat er bij elke release wordt gedeponeerd, niet periodiek.
• Neem in de regeling op dat ook de bouw- en installatie-instructies worden gedeponeerd, plus de afhankelijkheden.
• Laat de escrowpartij verifiëren dat wat er gedeponeerd wordt daadwerkelijk te bouwen is. Zonder die verificatie koopt u een bestandsoverdracht.
• Regel wie de licentie krijgt om de code te gebruiken en aan te passen, en of u die aan een derde mag geven die het onderhoud overneemt.

Broncode alleen is zelden voldoende om een systeem draaiend te krijgen. Wat er ook in hoort: de instructies om het geheel te bouwen, de configuratie van de omgeving waarin het draait, de databasestructuur, en een overzicht van de externe diensten waarvan het afhankelijk is met de bijbehorende sleutels of accounts.

Dat laatste is het onderdeel dat het vaakst ontbreekt en het meest bepalend is. Een systeem dat betaalt via een externe dienst, mail verstuurt via een andere en gegevens opslaat bij een derde, werkt niet zolang u geen toegang heeft tot die accounts. Leg in het contract vast op wiens naam die staan.

Vraag tot slot om documentatie op hoofdlijnen: hoe is het systeem opgebouwd, welke keuzes zijn er gemaakt en waarom. Een ontwikkelaar die er nieuw op komt, heeft daar meer aan dan aan de code zelf.

Vraag geen depot maar doorlopende toegang. Als de code in een repository staat waar u zelf leestoegang op heeft, met een omgeving die reproduceerbaar op te bouwen is, dan heeft u wat escrow belooft zonder de vertraging en de kosten.

Combineer dat met een afspraak dat de leverancier de omgeving documenteert en dat een derde partij die documentatie een keer heeft getoetst. Dan weet u dat het werkt, in plaats van dat u hoopt dat het werkt.

Waar escrow zich richt op het onwaarschijnlijke scenario, richt een exitregeling zich op het waarschijnlijke: u wilt over een paar jaar naar een andere leverancier of een ander pakket. Dat gebeurt vele malen vaker dan een faillissement, en het is het scenario waarin u werkelijk schade lijdt als er niets geregeld is.

Wat erin hoort: in welk formaat u uw gegevens krijgt, binnen hoeveel tijd, tegen welk tarief, en hoe lang de leverancier na opzegging blijft leveren om de overgang mogelijk te maken. Voeg toe dat u het exportformaat vooraf mag testen; een export die pas bij het vertrek blijkt onbruikbaar te zijn, helpt u niet.

Voor maatwerk hoort daar ook documentatie bij: hoe het systeem is opgebouwd, welke koppelingen er zijn, en welke keuzes er onderweg zijn gemaakt. Dat is het deel dat een nieuwe partij nodig heeft om verder te kunnen en het deel dat het duurst is om te reconstrueren.

• Bij standaardsoftware waarvan u de code normaal gesproken nooit ziet en waar geen doorlopende toegang mogelijk is.
• Bij een leverancier waarvan de continuïteit een reëel risico is en die niet bereid is tot doorlopende toegang.
• Als een toezichthouder of financier het expliciet eist, ongeacht wat u er zelf van vindt.

Ook als u uiteindelijk geen escrow afsluit, is het gesprek erover nuttig. U ontdekt namelijk hoe uw leverancier over continuïteit denkt, en dat is informatie die u anders niet krijgt. Een leverancier die precies kan uitleggen hoe zijn bouwproces werkt, waar de code staat en wat er gebeurt als hij wegvalt, geeft u meer zekerheid dan een depot.

Vraag daarbij ook naar het aantal mensen dat het systeem kent. Bij kleinere leveranciers is het reële risico niet faillissement maar dat de ene ontwikkelaar die het gebouwd heeft, vertrekt. Daar helpt geen escrow tegen; documentatie en een tweede paar ogen wel.

Wat u van dat gesprek onthoudt, hoort in uw dossier. Niet omdat het juridisch bindend is, maar omdat het bij de volgende contractverlenging het uitgangspunt vormt.

• Broncode-eigendom en overdracht
• Van softwarebureau wisselen
• Als uw leverancier wordt overgenomen

Wilt u eerst weten of het idee werkt voordat u groot investeert? Bij OneDayBuild laat u in één dag een werkend prototype bouwen.