Deponering av kildekode: Når trenger dere escrow?
Deponering av kildekode, eller escrow, innebærer at en uavhengig part oppbevarer kildekoden til et system og utleverer den til kunden hvis leverandøren går konkurs eller bryter avtalen. Det beskytter forretningskritiske systemer som leverandøren drifter. Ordningen krever presist definerte utløsende vilkår, og for mange prosjekter er enklere alternativer nok, for eksempel løpende tilgang til repoet.
Tenk deg at leverandøren som har bygget og drifter det viktigste systemet dere har, forsvinner i morgen, enten i en konkurs eller i en tvist som fryser samarbeidet. Hvem har da koden, og kan dere drive systemet videre? For forretningskritiske systemer som én leverandør alene sitter på, er deponering av kildekode, escrow, svaret på nettopp det spørsmålet. Det er et nisjetiltak, men for riktig system er det forskjellen på en håndterbar overgang og et havari. Denne guiden forklarer hvordan det fungerer, hva som må reguleres, og når enklere beskyttelse er nok.
Slik fungerer en deponeringsordning
Grunnideen er enkel. Kildekoden til systemet, sammen med det som trengs for å bygge og drifte det, deponeres hos en uavhengig part, en escrow-agent. Som kunde får dere ikke koden i hånden så lenge alt fungerer; den ligger i depot. Men hvis ett av de forhåndsavtalte vilkårene inntreffer, utleverer agenten koden til dere slik at dere eller en ny leverandør kan ta over.
Tre parter er altså involvert: dere som kunde, leverandøren og den uavhengige agenten. Avtalen regulerer hva som skal deponeres, hvor ofte nye versjoner skal leveres inn (en deponering som er to år gammel, hjelper lite), og nøyaktig hva som skal utløse en utlevering. Kostnaden består av en løpende avgift til agenten pluss noe arbeid med å holde deponeringen oppdatert. Den er sjelden stor sammenlignet med hva et kritisk system er verdt, men den finnes, og det er en grunn til først å spørre seg om ordningen virkelig trengs.
Utløsende vilkår må defineres presist
Escrow står og faller med vilkårene som utløser en utlevering. Er de vage, blir forsikringen virkningsløs akkurat når den trengs. Leverandøren eller et konkursbo kan nemlig bestride at noe faktisk har skjedd.
Vilkårene må derfor være objektive og etterprøvbare. Vanlige utløsere er konkurs eller avvikling, at leverandøren legger ned virksomheten, eller at den i strid med avtalen slutter å vedlikeholde systemet. Poenget er at agenten skal kunne konstatere at et vilkår er oppfylt uten først å måtte vente på utfallet av en langvarig tvist. Et dårlig formulert vilkår («hvis leverandøren ikke lenger kan levere») åpner for nettopp den typen strid. Et presist vilkår («når konkurs er åpnet») kan følges opp med en gang. Her er det verdt å bruke tiden, for det er i detaljene det avgjøres om escrow holder eller ikke.
Enklere alternativer og når de er nok
Escrow er ikke den eneste måten å beskytte seg på, og ofte ikke den enkleste. Før dere setter opp en deponeringsavtale, er det verdt å undersøke om et lettere alternativ gir tilstrekkelig trygghet.
| Beskyttelse | Passer når |
|---|---|
| Løpende tilgang til kodelageret | Dere kan få lesetilgang og egne kopier av kode og data |
| Jevnlige kodeleveranser | Dere ønsker å ha koden selv uten at en tredjepart er involvert |
| Deponering av kildekode (escrow) | Systemet er kritisk, og direkte tilgang er ikke mulig eller betryggende |
Det vanligste og ofte beste alternativet er rett og slett å ha lesetilgang til leverandørens kodelager og jevnlige kopier av både kode og data. Da har dere allerede mye av det escrow beskytter mot, uten avgift til en agent og uten administrasjon. Escrow tilfører mest i tilfeller der slik direkte tilgang ikke er mulig, eller der en uavhengig mellommann av andre grunner føles nødvendig. Med andre ord: Begynn med det enkle, og ta i bruk escrow når det enkle ikke er nok.
Et konkret scenario
En virksomhet lot en mindre leverandør bygge og drifte et system som styrte en sentral del av driften. Leverandøren var dyktig, men liten, og all kode og kunnskap satt hos dem. Ledelsen så risikoen: Hvis selskapet gikk under, ville systemet bli en svart boks som ingen kunne røre.
De veide alternativene mot hverandre. Løpende tilgang til kodelageret hadde vært nok, men leverandørens oppsett gjorde det vanskelig å gi ekstern tilgang. Valget falt derfor på escrow, med konkurs og avbrutt vedlikehold som presist formulerte utløsere og kvartalsvise deponeringer slik at koden aldri ble utdatert. Da systemet noen år senere skulle overtas av en annen part, viste det seg at deponeringen var oppdatert og komplett. Overgangen gikk ryddig for seg i stedet for å bli panikkartet.
Tilpass beskyttelsen til risikoen
Deponering av kildekode er verken noe alle prosjekter trenger eller noe dere bør avfeie. Spørsmålet er alltid det samme: Hvor ille ville det ha vært om leverandøren forsvant, og har dere allerede god nok tilgang til koden? Er systemet kritisk og tilgangen usikker, er escrow en billig forsikring mot et dyrt scenario. Er systemet mindre viktig eller koden allerede innen rekkevidde, holder det med enklere grep.
Vi i Weapp jobber for at kundene våre aldri skal føle seg innelåste, og drøfter gjerne riktig beskyttelsesnivå som en del av tjenestene våre. Lurer dere på hvordan dere sikrer et kritisk system? Ta kontakt, så hjelper vi dere med å veie escrow mot de enklere alternativene for akkurat den situasjonen dere står i.
Ofte stilte spørsmål
Hva er deponering av kildekode (escrow)?
En ordning der kildekoden til et system deponeres hos en uavhengig tredjepart. Kunden får ikke koden løpende, men den utleveres hvis bestemte vilkår inntreffer, typisk at leverandøren går konkurs eller vesentlig misligholder avtalen. Escrow er en forsikring for systemer som er forretningskritiske, og som leverandøren alene drifter og har koden til.
Når trengs escrow, og når er det overdrevet?
Det er berettiget når et system er kritisk for virksomheten, leverandøren alene sitter på koden og et avbrudd ville gjøre stor skade. Er systemet mindre viktig, eller har dere allerede løpende tilgang til koden, er escrow ofte unødvendig administrasjon. Spørsmålet dere bør stille, er: Hva skjer med oss hvis leverandøren forsvinner i morgen? Er svaret alvorlig, er escrow verdt å vurdere.
Hva koster en deponeringsordning?
Det påløper en løpende avgift til den uavhengige escrow-agenten, i tillegg til noe arbeid med å sette opp avtalen og rutinene for å deponere nye versjoner. Kostnaden er sjelden stor sett opp mot verdien av et kritisk system, men den er ikke null, og den er en grunn til først å undersøke om et enklere alternativ er nok for det aktuelle systemet.
Hvilke vilkår skal utløse en utlevering?
De må defineres presist, ellers blir escrow virkningsløs akkurat når den trengs. Vanlige utløsere er konkurs, avvikling eller at leverandøren slutter å vedlikeholde systemet i strid med avtalen. Det viktige er at vilkårene er objektive og etterprøvbare slik at agenten kan gripe inn uten en langvarig tvist om hvorvidt en utløsende hendelse faktisk har inntruffet.
Er det nok med løpende tilgang til repoet i stedet?
Ofte, ja. Har dere lesetilgang til leverandørens kodelager og jevnlige kopier av koden og dataene, har dere allerede mye av det escrow beskytter mot, uten en tredjepart. For mange prosjekter er det et enklere og billigere alternativ. Escrow tilfører mest når slik direkte tilgang av en eller annen grunn ikke er mulig eller ikke føles betryggende.