Kildekode-escrow: Hvornår er deponering nødvendig?
Deponering af kildekode, eller escrow, betyder at en uafhængig part opbevarer kildekoden til et system og udleverer den til kunden hvis leverandøren går konkurs eller misligholder aftalen. Det beskytter forretningskritiske systemer som leverandøren drifter. Ordningen kræver skarpt definerede udløsende betingelser, og i mange projekter er enklere alternativer som løbende adgang til repositoryet nok.
Forestil jer at leverandøren der har bygget og drifter jeres vigtigste system, forsvinder i morgen, enten ved en konkurs eller i en tvist der fryser samarbejdet. Hvem har så koden, og kan I køre systemet videre? For forretningskritiske systemer som en leverandør alene sidder på, er deponering af kildekode, escrow, svaret på netop det spørgsmål. Det er en nicheløsning, men for det rigtige system er det forskellen på en håndterbar overgang og et havari. Denne guide forklarer hvordan det fungerer, hvad der skal reguleres og hvornår en enklere beskyttelse er nok.
Sådan fungerer en deponeringsordning
Grundidéen er enkel. Kildekoden til systemet deponeres, sammen med det der skal til for at bygge og drive det, hos en uafhængig part, en escrow-agent. I som kunde får ikke koden i hånden så længe alt fungerer; den ligger i depot. Men hvis en af de på forhånd aftalte betingelser indtræffer, udleverer agenten koden til jer så I eller en ny leverandør kan tage over.
Der indgår altså tre parter: jer som kunde, leverandøren og den uafhængige agent. Aftalen regulerer hvad der skal deponeres, hvor ofte nye versioner skal indleveres (en deponering der er to år gammel, hjælper ikke meget), og præcis hvad der skal udløse en udlevering. Udgiften består af et løbende gebyr til agenten plus noget arbejde med at holde deponeringen opdateret. Den er sjældent stor sammenlignet med hvad et kritisk system er værd, men den findes, og det er en grund til først at spørge sig selv om ordningen virkelig er nødvendig.
Udløsende betingelser skal defineres skarpt
Escrow står og falder med de betingelser der udløser en udlevering. Er de vage, bliver forsikringen virkningsløs netop når der er brug for den. Leverandøren eller et konkursbo kan nemlig bestride at noget faktisk er sket.
Betingelserne skal derfor være objektive og kunne verificeres. Typiske udløsere er konkurs eller likvidation, at leverandøren lukker virksomheden eller at den i strid med aftalen holder op med at vedligeholde systemet. Pointen er at agenten skal kunne konstatere at en betingelse er opfyldt uden først at skulle vente på udfaldet af en langvarig tvist. En dårligt formuleret betingelse som “hvis leverandøren ikke længere kan levere” åbner for netop den slags strid. En skarp betingelse som “når leverandøren er erklæret konkurs” kan man handle på med det samme. Her er det værd at bruge tiden, for det er i detaljerne det afgøres om escrow holder.
Enklere alternativer, og hvornår de er nok
Escrow er ikke den eneste måde at beskytte sig på, og ofte ikke den enkleste. Før I opretter en deponeringsaftale, er det værd at undersøge om et lettere alternativ giver tilstrækkelig tryghed.
| Beskyttelse | Egner sig når |
|---|---|
| Løbende adgang til repoet | I kan få læseadgang og egne kopier af kode og data |
| Jævnlige kodeleverancer | I vil have koden i egen varetægt uden at en tredjepart er involveret |
| Deponering af kildekode (escrow) | Systemet er kritisk, og direkte adgang er ikke mulig eller betryggende |
Det mest almindelige og ofte bedste alternativ er simpelthen at have læseadgang til leverandørens repository og jævnlige kopier af både kode og data. Så har I allerede meget af det som escrow beskytter mod, uden gebyr til en agent og uden administration. Escrow giver mest værdi i de tilfælde hvor en sådan direkte adgang ikke er mulig eller hvor en uafhængig mellemmand af andre grunde føles nødvendig. Med andre ord: Start med det enkle, og tag escrow i brug når det enkle ikke er nok.
Et konkret scenarie
En virksomhed lod en mindre leverandør bygge og drifte et system der styrede en central del af forretningen. Leverandøren var dygtig, men lille, og al kode og viden lå hos dem. Ledelsen så risikoen: Hvis leverandøren gik ned, ville systemet blive en sort boks som ingen kunne røre ved.
De vejede alternativerne op mod hinanden. Løbende adgang til repoet havde været nok, men leverandørens opsætning gjorde det svært at give ekstern adgang. Valget faldt derfor på escrow, med konkurs og afbrudt vedligeholdelse som skarpt formulerede udløsere og kvartalsvise deponeringer så koden aldrig blev forældet. Da systemet nogle år senere skulle overtages af en anden part, viste det sig at deponeringen var opdateret og komplet, og overgangen forløb planmæssigt i stedet for i panik.
Tilpas beskyttelsen til risikoen
Deponering af kildekode er hverken noget ethvert projekt har brug for eller noget man skal afvise. Spørgsmålet er altid det samme: Hvor slemt ville det være hvis leverandøren forsvandt, og har I allerede tilstrækkelig adgang til koden? Er systemet kritisk og adgangen usikker, er escrow en billig forsikring mod et dyrt scenarie. Er systemet mindre vigtigt eller koden allerede inden for rækkevidde, er enklere løsninger nok.
Hos Weapp arbejder vi for at vores kunder aldrig skal føle sig låst fast, og vi drøfter gerne det rette beskyttelsesniveau som en del af vores ydelser. Overvejer I hvordan I sikrer et kritisk system? Kontakt os, så hjælper vi jer med at veje escrow op mod de enklere alternativer i jeres konkrete situation.
Ofte stillede spørgsmål
Hvad er kildekode-escrow (deponering)?
En ordning hvor kildekoden til et system deponeres hos en uafhængig tredjepart. Kunden får ikke koden løbende, men den udleveres hvis bestemte betingelser indtræffer, typisk at leverandøren går konkurs eller groft misligholder aftalen. Escrow er en forsikring for systemer der er forretningskritiske og som leverandøren alene drifter og har koden til.
Hvornår er der brug for escrow, og hvornår er det overdrevet?
Det er berettiget når et system er kritisk for forretningen, leverandøren alene sidder på koden og et driftsstop ville gøre stor skade. Er systemet mindre vigtigt, eller har I allerede løbende adgang til koden, er escrow ofte unødvendig administration. Spørgsmålet I skal stille, er: Hvad sker der med os hvis leverandøren forsvinder i morgen? Er svaret alvorligt, er escrow værd at overveje.
Hvad koster en deponeringsordning?
Der kommer et løbende gebyr til den uafhængige escrow-agent, plus noget arbejde med at sætte aftalen op og med rutinerne for at deponere nye versioner. Udgiften er sjældent stor i forhold til værdien af et kritisk system, men den er ikke nul, og den er en grund til først at undersøge om et enklere alternativ er nok til det pågældende system.
Hvilke betingelser skal udløse en udlevering?
De skal defineres skarpt, ellers bliver escrow virkningsløs netop når der er brug for den. Typiske udløsere er konkurs, likvidation eller at leverandøren holder op med at vedligeholde systemet i strid med aftalen. Det vigtige er at betingelserne er objektive og kan verificeres så agenten kan handle uden en langvarig tvist om hvorvidt en udløsende hændelse faktisk er indtruffet.
Er det nok med løbende adgang til repoet i stedet?
Ofte, ja. Har I læseadgang til leverandørens repository og jævnlige kopier af koden og dataene, har I allerede meget af det som escrow beskytter mod, uden en tredjepart. I mange projekter er det et enklere og billigere alternativ. Escrow giver mest værdi når en sådan direkte adgang af en eller anden grund ikke er mulig eller ikke føles betryggende.