# Hvem ejer kildekoden? Guide til ejerskab af software > Du ejer ikke softwaren, bare fordi du har betalt. Få rettighederne skriftligt og kode, data og konti i eget navn: en tjekliste mod vendor lock-in. - URL: https://bon.do/artikler/hvem-ejer-kildekoden - Markdown: https://bon.do/artikler/hvem-ejer-kildekoden.md - Author: Morten Bondo Vraa - Published: 2025-04-04 - Updated: 2026-11-09 - Reading time: 6 minutes - Section: Ejerskab ## In 30 seconds - Betaling for specialudviklet software overdrager ikke ophavsretten: få en skriftlig overdragelse, før du skriver under. - Hav kode, data, domæne, cloud og tredjepartskonti i din virksomheds navn fra dag ét. - Test exit, mens samarbejdet er godt: byg og kør systemet uden leverandørens hjælp. ## Key facts - **Kildekode:** Din, i dit eget repository - **Rettigheder:** Skriftlig overdragelse, ikke kun en licens - **Data:** Kan eksporteres i et åbent format - **Domæne og DNS:** Registreret på din virksomhed - **Cloud- og tredjepartskonti:** Ejet af dig, leverandøren får begrænset adgang - **Overdragelse:** Dokumenteret og testet --- Forestil dig, at din software er lanceret og virker. Et år senere vil du skifte leverandør, bygge videre med dit eget team eller integrere med en ny platform. Så opdager du, at du ikke ejer kildekoden, at data sidder fast hos den gamle leverandør, eller at domænet står i leverandørens navn. Det er vendor lock-in. Det er dyrt, og det kan undgås med nogle få krav fra starten. Denne guide gennemgår de digitale aktiver, du som softwarekøber bør eje, og hvad du skal bede din udviklingspartner om, før du skriver under. ## Hvem ejer kildekoden? Det gør udvikleren, medmindre kontrakten siger noget andet. Efter ophavsretsloven opstår ophavsretten hos den, der skaber værket, og § 59 giver arbejdsgiveren ophavsretten til edb-programmer, som de ansatte skriver som en del af deres arbejde ([ophavsretsloven](https://www.retsinformation.dk/eli/lta/2023/1093)). Når du køber software af et bureau, har bureauet altså rettighederne til de ansattes kode. Rettighederne overgår ikke til dig, fordi du betaler fakturaen. Overdragelsen skal aftales, og den skal være tydelig. Efter § 53, stk. 3, giver en overdragelse af retten til at udnytte et værk på én måde ikke ret til at udnytte det på andre måder. En kontrakt, der kun giver dig ret til at "bruge" softwaren, giver dig måske ikke ret til at ændre den, lade en anden leverandør ændre den eller sælge den videre. Bed derfor om: - en skriftlig overdragelse af rettighederne til den specialudviklede kode og dokumentation, ikke kun en brugsret - en udtrykkelig ret til at ændre, videreudvikle, videregive og give underlicenser - en liste over leverandørens eksisterende komponenter, frameworks og biblioteker og den licens, du får til dem - en liste over open source-komponenter og deres licenser, så du kender dine forpligtelser Reglerne er forskellige fra land til land. Hvis leverandøren eller din virksomhed er uden for Danmark, så tjek, hvilket lands ret kontrakten følger. Denne guide indeholder praktiske råd og er ikke juridisk rådgivning; få en advokat til at læse den konkrete kontrakt. ## Hvad med kode skrevet med AI? Ophavsretten beskytter originale udtryk, der afspejler et menneskes egne kreative valg. AI-værktøjer er i dag en del af det meste udviklingsarbejde, og det påvirker ejerskabet. Dansk Industri påpeger, at kode, som AI har produceret med lidt menneskeligt input, måske ikke lever op til det krav, mens kode, hvor en udvikler træffer de centrale valg og bearbejder resultatet, kan opfylde kravet ([DI](https://www.danskindustri.dk/vi-radgiver-dig/virksomhedsregler-og-varktojer/ai/juridiske-ai-varktojer/nar-ai-har-lavet-koden-hvem-ejer-sa-programmet/)). I praksis: spørg din leverandør, hvordan de bruger AI, og sørg for, at kontrakten og den leverede dokumentation (arkitekturnoter, versionshistorik, kodegennemgange) viser det menneskelige arbejde bag produktet. ## Hvorfor er klart ejerskab vigtigt? Ejerskab er ikke en juridisk formalitet, der først bliver relevant ved exit. Det er det, der lader dig skifte leverandør, ansætte internt, rejse kapital eller sælge virksomheden, uden at teknologien bliver en bremse. Når ejerskabet er uklart, opstår der typisk fire problemer: - **Skift bliver dyrt.** En ny leverandør skal genskabe det, du allerede har betalt for. - **Data bliver svære at flytte.** Eksporten kommer i et format, som ingen andre kan læse. - **Driften hænger på én person.** Ingen andre har adgang til konti, kode eller infrastruktur. - **Due diligence falder negativt ud.** En investor eller køber opdager, at virksomheden ikke ejer sin egen software. Inden for regulerede områder som medtech og life science skal du også have adgang til kode, data og dokumentation for at kunne besvare spørgsmål ved audits og holde produktets tekniske dokumentation opdateret, både [på vej mod CE-mærkning](https://bon.do/artikler/fra-ide-til-marked-medicinsk-software) og efter lanceringen. ## De aktiver, du bør eje Ejerskab betyder, at du har adgang, dokumentation og rettigheder, når du har brug for dem. Det betyder ikke, at du skal gøre alt selv. Gå de syv aktiver igennem: kildekode, data, domæne og DNS, hosting, tredjepartstjenester, dokumentation og en skriftlig exitplan. ### 1. Kildekode og versionsstyring Hav koden i et Git-repository under din egen organisation på GitHub, GitLab, Azure DevOps eller lignende, ikke under leverandørens konto. En brugerkonto i en andens organisation er ikke ejerskab. - Alle repositories, inklusive infrastruktur som kode og deployment-scripts. - Mindst to administratorer hos jer. - En kodebase, der kan bygges uden adgang til leverandørens private miljø. - De hemmeligheder og den konfiguration, der skal til for at køre den, opbevaret et sted, I kontrollerer. ### 2. Database og data Data er ofte det mest værdifulde aktiv og det sværeste at flytte. Du skal kunne eksportere dem i et åbent format uden at spørge om lov. - En dokumenteret datamodel og en metode til at eksportere data. - Adgang til databasen via en konto, du ejer. - Backup og gendannelse, der er testet, ikke bare sat op. Hvis leverandøren behandler personoplysninger for dig, kræver GDPR en databehandleraftale, hvor leverandøren efter dit valg sletter eller returnerer alle personoplysninger, når opgaven slutter ([databeskyttelsesforordningen, artikel 28, stk. 3, litra g](https://eur-lex.europa.eu/legal-content/DA/TXT/?uri=CELEX:32016R0679)). Brug den bestemmelse. ### 3. Domæne og DNS Domænet er din adresse på nettet. Registrér det på din virksomhed med jeres egne kontaktoplysninger, og behold loginoplysningerne til domæneregistratoren. Det samme gælder DNS-zonen, fordi DNS styrer mail, subdomæner og verifikationsposter. Leverandøren kan få adgang til at oprette poster; I beholder ejerskabet. ### 4. Hosting og cloud Cloud-kontoen er ofte der, hvor lock-in bliver dyrest. Hvis leverandøren ejer kontoen, ejer leverandøren reelt din drift. - Cloud-kontoen er din, med din fakturering og dine sikkerhedspolitikker. - Leverandøren får rollebaseret adgang, ikke ejerskab. - Infrastrukturen er beskrevet som kode, så den kan genskabes. Siden september 2025 har EU's dataforordning (Data Act) også givet erhvervskunder rettigheder ved skift mellem cloud- og andre databehandlingstjenester, og gebyrer for skift udfases senest 12. januar 2027 ([dataforordningen](https://eur-lex.europa.eu/legal-content/DA/TXT/?uri=CELEX:32023R2854)). Der forhandles om ændringer, så tjek den gældende tekst. Rettighederne hjælper, men de erstatter ikke, at du ejer kontoen. ### 5. Tredjepartstjenester og API-nøgler Moderne produkter kører på mange tjenester: betaling, mail, SMS, AI, kort, analyse og support. Hver tjeneste har en konto og en nøgle. Ligger nøglen i leverandørens konto, er den ikke din. Før en liste over hver tjeneste, dens formål, hvem der ejer kontoen, hvor nøglerne ligger, og hvad der sker med abonnementet, når samarbejdet slutter. ### 6. Dokumentation Dokumentation gør det muligt for et andet team at overtage systemet. Bed om arkitektur og datamodel, herunder [arkitekturbeslutningerne og begrundelserne for dem](https://bon.do/artikler/monolit-eller-microservices), en driftsvejledning med deployment og rollback, teststrategi og kendte begrænsninger, og en overdragelse med en reel gennemgang, ikke bare en zip-fil. ### 7. En skriftlig exit-plan Beskriv i kontrakten, hvordan kode, data, konti og dokumentation overdrages, når samarbejdet slutter, uanset årsagen, og hvad leverandøren hjælper med i overgangen. Deponering af kildekoden (escrow) er mest relevant, når leverandøren beholder koden, fx ved licens- eller SaaS-software. Ligger koden allerede i dit repository, betyder exit-planen mere end en deponering. ## Tjekliste til ejerskab af software Gå listen igennem, før du skriver under, og igen en gang om året: - Kontrakten overdrager rettighederne til den specialudviklede kode og dokumentation til dig. - Tredjeparts- og open source-komponenter er listet med licenser. - Alle aktiver har en navngiven ejer i din virksomhed. - Alle konti (Git, cloud, domæne, DNS, tredjepartstjenester) står i din virksomheds navn. - Data kan eksporteres i et åbent format. - En databehandleraftale dækker sletning eller returnering af personoplysninger. - Der findes en dokumenteret exit-plan. - En person, der ikke er tilknyttet leverandøren, har bygget og kørt systemet fra jeres repository. ## Sådan håndterer bon.do ejerskab Hos bon.do er al kode, alle data og alle IP-rettigheder dine fra dag ét. Vi arbejder så vidt muligt i repositories og cloud-konti i dit navn, bygger på åbne, veldokumenterede værktøjer og har dokumentation og overdragelse med i arbejdet, uanset om det er en [MVP med fast omfang eller et fast team](https://bon.do/priser). Ejerskab er en del af, hvordan vi [udvikler og driver software for vores kunder](https://bon.do/ydelser). Er du i tvivl om, hvem der ejer hvad i dit nuværende produkt? [Kontakt os](https://bon.do/kontakt) for en uforpligtende gennemgang af din kode, dine konti og din kontrakt. --- ## Questions we get asked ### Hvem ejer kildekoden, når et bureau udvikler min software? Efter dansk ret opstår ophavsretten hos udvikleren, og en arbejdsgiver får rettighederne til de programmer, de ansatte skriver. Kunden ejer kun koden, hvis kontrakten overdrager rettighederne. Få en skriftlig overdragelse, der dækker brug, ændringer og videregivelse. ### Hvad er vendor lock-in? Vendor lock-in er, når det koster mere at forlade en leverandør end at blive, fordi du ikke ejer koden, data eller de konti, produktet kører på. Det er et kontrakt- og arkitekturproblem, og det er billigst at løse, før du skriver under. ### Hvad skal der stå om ejerskab i kontrakten? Kontrakten skal overdrage rettighederne til den specialudviklede kode, liste tredjeparts- og open source-komponenter med licenser, angive hvem der ejer hver konto, og beskrive hvordan data, kode og dokumentation overdrages, når samarbejdet slutter, uanset årsagen. ### Har jeg brug for deponering af kildekoden (escrow)? Deponering er mest relevant, når leverandøren beholder kildekoden, fx ved licens- eller SaaS-software. Ligger koden allerede i dit eget repository, er der sjældent brug for det. ### Kan vi blive ved med at bruge bon.do's værktøjer efter en overdragelse? Ja. Vi bygger på åbne, dokumenterede værktøjer, som du selv kan køre, og vi overdrager konti, dokumentation og en gennemgang.