Exit-plan

Escrow: hvad deponering af kildekode kan, og hvad den ikke kan

Escrow: hvad deponering af kildekode kan, og hvad den ikke kan

Escrow betyder, at leverandørens kildekode deponeres hos en uafhængig tredjepart, som udleverer den til jer, hvis en aftalt hændelse indtræffer, fx konkurs. Det kan hjælpe ved installeret eller skræddersyet software, hvor nogen kan overtage koden, og er sjældent nok alene ved en tjeneste i cloud.

Kildekode deponering lyder som en forsikring, og det er derfor let at købe tryghed, der ikke holder. I en exit-plan er spørgsmålet, om nogen kunne få systemet til at køre, hvis koden blev udleveret i morgen. Artiklen bygger på generel viden, for der er ingen særlig regel om escrow i de kilder, sitet bygger på. Aftaler af denne slags er forskellige, og den konkrete tekst afgør det.

Sådan virker en escrow-aftale

En escrow-aftale, på engelsk ofte software escrow agreement, har tre parter: leverandøren, kunden og den, der opbevarer materialet. Leverandøren deponerer kode og dokumentation og opdaterer dem med aftalte mellemrum. Aftalen angiver, hvilke hændelser der udløser udlevering, og hvad kunden må med materialet bagefter.

Fire punkter afgør, om aftalen har værdi.

  1. Udløserne. Konkurs er den oplagte. Ophør af vedligehold, at produktet udgår, og væsentlig misligholdelse kan være andre. Hvem afgør, at udløseren er sket, og kan leverandøren gøre indsigelse?
  2. Brugsretten. I skal have ret til at bruge, ændre og lade andre arbejde på koden, efter at den er udleveret. Ellers har I en pakke, I ikke må åbne.
  3. Indholdet. Kode alene er sjældent nok. Byggevejledning, oversigt over tredjepartskomponenter, skemaer for databaser og driftsdokumentation skal med.
  4. Opdatering. Et depot fra for to versioner siden hjælper lidt. Aftalen skal sige, hvornår der deponeres, og nogen skal kontrollere, at det sker.

Hjælper det ved konkurs?

Delvist, og juraen er ikke enkel. Forenklet sagt kan en konkurs efter konkursloven føre til, at boet tager stilling til, om det vil indtræde i aftalen (§ 55), og boet kan opsige et vedvarende forhold med sædvanligt eller rimeligt varsel (§ 61). Ejendele, der tilhører andre, skal efter § 82 gå til den, der har ret til dem. Hvordan det rammer en aftale om deponeret kode, har vi ikke fundet belæg for, og det er et spørgsmål til advokat. Aftalens ordlyd og tidspunktet for overdragelsen af rettigheder kan betyde noget, og det er vores ræsonnement.

Der er også en praktisk side, som ikke kræver jura. Et bo arbejder ikke på jeres tidsplan. Det kan tage tid at få udløsningen gennemført, og imens står driften stille, hvis det var leverandøren, der kørte systemet. Se leverandøren går konkurs.

Hvorfor det sjældent er nok ved SaaS

Ved en tjeneste, leverandøren driver i cloud, er koden kun én del af det, der skal til. Systemet består også af drift, infrastruktur, overvågning, konfiguration og kundernes data. Deponeret kode giver jer ingen af delene. Den er desuden bygget til mange kunder og til en bestemt platform, så den kan være tung at få op at køre for én virksomhed.

Nogle leverandører tilbyder en udvidet ordning, hvor også driftsmiljø og data er med i depotet. Det kan give mere, men det gør aftalen større og sværere at holde opdateret, og I skal stadig kunne køre miljøet. Vurdér det efter samme spørgsmål: hvem gør det, og hvor længe vil det tage?

For de fleste SaaS-kunder vil en egen kopi af data og en testet eksport give mere end kode, fordi de virker uden om både konkursbo og leverandør. Med data i hånden kan I begynde forfra andetsteds.

Hvornår det giver mening

Escrow er værd at overveje, når alle fire ting er til stede: systemet er kritisk, der findes ingen reel afløser, leverandøren er lille eller sårbar, og I har adgang til nogen, der kan overtage koden. Det gælder fx et branchesystem uden alternativ installeret hos jer selv eller en lille nicheleverandør. Er det jer, der har betalt for at få koden bygget, er spørgsmålet et andet. Så bør I eje den eller have direkte adgang, se leverandøren vil ikke udlevere koden.

Test depotet, ellers ved I det ikke

Et depot, ingen har prøvet at bygge fra, er et løfte. Den mest grundige prøve er, at en uafhængig fagperson bygger systemet fra det deponerede materiale i et rent miljø og får det til at starte. En mindre prøve er at få bekræftet, at filerne kan åbnes og er den aktuelle version.

Er prøven urealistisk, så skriv det ned i planen. Så ved ledelsen, at escrow her er en sidste udvej uden kendt tidsramme.

Hvad det kræver, og hvad det koster at lade være

En escrow-aftale kræver en tredjepart, som tager betaling for opbevaring, et aftaleforløb med leverandøren, kontrol af deponeringer og eventuelt en teknisk prøve. Dertil kommer den person, der skal kunne overtage koden, hvis den udleveres. Beskriv posterne i ord, og sæt to daterede bud på tidsforbruget, et lavt og et højt.

Uden escrow kan et lukket system med en lille leverandør ende som et stop uden vej tilbage. Opgør det selv som dagstabet i forretningen gange den tid, det vil tage at købe eller bygge noget nyt. Hændelsen er sjælden, så beskriv den roligt, og sammenhold den med omkostningen ved egen kopi og reserveløsning, som ofte dækker meget af det samme.

Arbejdet giver noget, selv om depotet aldrig åbnes. I får afklaret, hvem der reelt kan vedligeholde systemet, og hvor godt det er dokumenteret.

Det skal I lade være med

  • At købe escrow for at kunne sætte et kryds · uden en, der kan bruge koden, er værdien lille.
  • At deponere uden brugsret · udlevering hjælper kun, hvis I må bruge materialet.
  • At erstatte datakopien med escrow · koden bringer ikke jeres data tilbage.

Det skal planen kunne vise

  • ☐ Om escrow er vurderet for systemet, og hvorfor det er valgt til eller fra.
  • ☐ Udløsere, brugsret og indhold af depotet.
  • ☐ Dato for seneste deponering og version.
  • ☐ Hvem der kan overtage koden, og om det er aftalt.
  • ☐ Resultatet af en prøve, eller at der ikke er lavet nogen.

Kilder

Senest gennemgået: november 2026.

Næste skridt

Find ud af, om I har en eneste aftale, hvor escrow overhovedet er relevant, og spørg, hvem der ville kunne overtage koden. Er svaret ingen, så vælg egen kopi og reserveløsning, og skriv begrundelsen i beslutningsnotatet.

Læs også: Produktet udgår · Exit-vilkår i kontrakten

→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal I have en plan B?

Skriv kort, hvilke systemer eller leverandører det drejer sig om, og hvad der sætter arbejdet i gang. Så vender jeg tilbage. Rådgivningen er uvildig og uafhængig, og Nielco IT har ikke indgået forhandleraftaler med leverandører.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.

Seneste på bloggen