Hvem ejer koden? Sådan sikrer du ejerskab af kildekode og adgange

Ejerskab af kildekode følger ikke automatisk med når du betaler en freelancer eller et bureau for at bygge din løsning. Uden en skriftlig aftale har den der har skrevet koden, som udgangspunkt ophavsretten, og du har kun ret til at bruge den. Selv med rettighederne på plads ejer du i praksis kun det du har adgang til: repository (kodearkiv), domæne, hosting og de tjenester systemet kører på.

Jeg er udvikler, ikke jurist, så brug guiden som praktisk vejledning og ikke som juridisk rådgivning. Jeg overtager og videreudvikler selv systemer som andre har bygget, og det er dér manglende rettigheder og adgange bliver dyre.

Den korte version

Min tommelfingerregel er enkel: virksomheden ejer, og udvikleren låner. Det gælder både rettighederne og kontiene.

Ser din situation anderledes ud, er det ikke nødvendigvis et problem i dag. Det bliver det den dag du vil skifte udvikler, sælge virksomheden eller hente en investor. Skal du først finde den rette udvikler, så start med min komplette guide til at hyre en udvikler, og kom tilbage hertil når kontrakten skal skrives.

Hvem ejer koden hvis intet er aftalt?

Når en ansat skriver et program som led i sit arbejde, overgår ophavsretten til arbejdsgiveren efter ophavsretslovens § 59. Den regel gælder kun ansatte. Hyrer du en freelancer, beholder freelanceren som udgangspunkt rettighederne. Hyrer du et bureau, er det bureauets ansatte der skriver koden, så rettighederne havner hos bureauet. I ingen af tilfældene havner de hos dig.

To andre regler i samme lov er gode at kende:

• En kopi er ikke en overdragelse. Efter § 53, stk. 2 indbefatter overdragelse af eksemplarer ikke overdragelse af ophavsretten. Har du fået koden som en zip-fil, har du en kopi og ikke rettighederne.
• En overdragelse giver ikke automatisk ret til at ændre. Efter § 56 må du kun ændre koden eller overdrage rettighederne videre hvis det er sædvanligt eller åbenbart forudsat. Det er præcis det du har brug for når en ny udvikler skal bygge videre, eller når du sælger virksomheden.

Helt uden rettigheder står du dog ikke. Efter § 36 må den der lovligt bruger et program, rette fejl og tage en sikkerhedskopi. Men retten er smal: den dækker ikke nye funktioner, og den giver dig ikke ret til at sælge eller licensere løsningen videre.

En domstol kan også se på hvad I begge må have forudsat da aftalen blev indgået. Det er bare en usikker og dyr vej til noget som et par sætninger i kontrakten kunne have løst.

Overdragelse, licens eller noget midt imellem

Der findes fire almindelige modeller, og den rigtige afhænger af hvad løsningen betyder for din forretning.

Til et system der er kernen i din forretning, anbefaler jeg typisk den anden model. Den er fair over for begge parter og giver dig frihed til at lade en hvilken som helst udvikler bygge videre.

Uanset model bør aftalen nævne tre ting udtrykkeligt:

1. Alle former for brug. Efter § 53, stk. 3 giver en ret til én form for brug ikke ret til andre. Skriv at overdragelsen omfatter enhver form for brug, også former I ikke har tænkt på endnu.
2. Ret til at ændre og overdrage videre. Skriv at du må ændre og videreudvikle koden, også via andre udviklere, og at du må overdrage rettighederne videre, fx ved et salg af virksomheden.
3. Tidspunktet. Mange aftaler lader rettighederne overgå ved betaling. Det er rimeligt, men aftal gerne at de overgår for hver betalt milepæl, så én omstridt faktura ikke efterlader hele projektet uden en klar ejer.

Sådan sikrer du ejerskabet i praksis

Rettighederne på papiret er halvdelen. Den anden halvdel er kontrollen over de konti koden lever på. Står repository eller domæne i udviklerens navn, hjælper en perfekt kontrakt ikke meget den dag udvikleren ikke svarer. Tag trinene i denne rækkefølge, helst før den første linje kode bliver skrevet.

1. Få overdragelsen ind i kontrakten

Skriv rettighederne ind i den aftale I alligevel laver, eller som et kort tillæg til udviklerens standardvilkår. Resten af aftalen, fra omfang til opsigelse, gennemgår jeg i tjeklisten til en kontrakt med en freelance udvikler.

2. Opret repository i virksomhedens egen organisation

Opret en organisation til virksomheden på GitHub eller GitLab, og læg koden dér. Udvikleren bliver inviteret som bruger med de rettigheder opgaven kræver. Gør mindst to personer fra virksomheden til ejere, så I heller ikke er afhængige af én medarbejder.

Ligger koden allerede på udviklerens private konto, kan den flyttes. En overførsel af et repository på GitHub beholder hele historikken, issues og pull requests.

3. Registrér domænet med virksomheden som registrant

Registranten er den der har retten til domænet. Det skal være virksomheden, ikke udvikleren og ikke bureauet. Et bureau må gerne administrere domænet for dig så længe virksomheden står som registrant. For .dk-domæner kan du slå registranten op hos Punktum dk. Står en anden som registrant, sker en overdragelse via Punktum dk's selvbetjening, hvor den nye registrant skal acceptere.

4. Læg hosting og database på virksomhedens konti

Hosting, server, database og backups skal ligge på konti som virksomheden har oprettet og betaler med sit eget kort. Udvikleren får sin egen bruger. Del aldrig ét fælles login, for så kan du ikke fjerne én persons adgang uden at lukke alle andre ude. Tjek også at du selv kan hente en backup af databasen uden at spørge nogen.

5. Opret tredjepartstjenester i virksomhedens navn

Betaling, mail, SMS, statistik, app stores og de AI-tjenester systemet bruger, skal også være virksomhedens konti. API-nøgler (de nøgler systemet bruger til at tale med andre tjenester) hører hjemme i en adgangskodemanager som virksomheden styrer, fx 1Password eller Bitwarden, og ikke i en mail eller en chat. Så kan nøglerne skiftes når en udvikler stopper.

6. Saml dokumentation og designfiler hos dig

En kort vejledning i repository om hvordan projektet sættes op og i drift, er en del af det du ejer. Det samme gælder designfiler og opgavestyring. Ligger det hele i udviklerens eget Figma eller Notion, ejer du koden uden forklaringen.

Gråzonerne: open source, genbrugt kode og AI

Open source-pakker

Næsten al moderne software bygger på open source-pakker, altså kode som andre har skrevet og stiller frit til rådighed. Dem kan udvikleren ikke overdrage til dig fordi udvikleren ikke ejer dem. Du bruger dem på deres egne licensvilkår.

De fleste licenser, fx MIT og BSD, stiller få krav. Copyleft-licenser som GPL kan kræve at du frigiver din egen kildekode når du distribuerer softwaren, og AGPL kan også ramme software der kun bruges over netværket, som en SaaS. Bed derfor om en liste over væsentlige pakker og deres licenser.

Udviklerens egne byggeklodser

Mange udviklere genbruger generelle moduler og værktøjer på tværs af kunder. Det er fair, og det gør ofte projektet billigere. Kravet er at du får en tidsubegrænset, uopsigelig og vederlagsfri brugsret til de dele, og at den også dækker en fremtidig udvikler der skal ændre i dem. Ellers ejer du huset, men ikke fundamentet.

Kode skrevet med AI

Mange udviklere skriver i dag kode med hjælp fra AI-assistenter. Det amerikanske Copyright Office konkluderede i sin rapport om AI og ophavsret fra januar 2025 at rent AI-genereret materiale ikke er beskyttet, og at prompts alene næppe er nok. Det mennesker selv bidrager med, herunder kreative ændringer af det AI har lavet, kan derimod være beskyttet.

Rapporten er ikke bindende i Danmark, men det praktiske råd er det samme: aftal at udvikleren står inde for al leveret kode uanset hvordan den er skrevet, og at din kode og dine data ikke må deles med tjenester der træner på dem.

Hvis du allerede mangler rettigheder eller adgange

Opdager du at kontrakten ikke siger noget om rettigheder, eller at domænet står i udviklerens navn, så handl mens samarbejdet stadig fungerer. Det er langt nemmere at få en underskrift og en kontooverførsel fra en udvikler der er glad for samarbejdet, end fra en der lige er blevet opsagt.

1. Læs det du har. Tilbud, ordrebekræftelser og bureauets standardvilkår siger ofte noget om rettigheder, også selvom der ikke findes en egentlig kontrakt.
2. Bed om en skriftlig overdragelse nu. Et kort tillæg på en halv side kan være nok. En freelancer der har fået sin betaling, har sjældent grund til at sige nej. Bygger et bureau sin forretning på licenser, skal du til gengæld regne med at fuld overdragelse koster ekstra.
3. Flyt kontiene. Brug trinene ovenfor, og start med domænet og repository.
4. Få vurderet hvad du overtager. Før du betaler for rettighederne til ældre kode, så få en uafhængig gennemgang af koden, så du ved om den er værd at bygge videre på.

Er udvikleren holdt op med at svare, eller er samarbejdet kørt helt fast, så gennemgår jeg forløbet i guiden om at skifte udvikler midt i et projekt. Står der meget på spil, så tal med en advokat før du bygger videre på koden.

Når fuldt ejerskab ikke er det rigtige

Jeg anbefaler at du ejer koden til det der er kernen i din forretning. Men der er situationer hvor det ikke er det rigtige at kræve:

• Standardplatforme. Bruger du Shopify, et færdigt bookingsystem eller et andet SaaS-produkt, kommer du aldrig til at eje koden, og det er helt i orden. Det vigtige er at du ejer domænet og kan få dine data ud i et brugbart format.
• Et bureaus eget produkt. Er din løsning en opsætning af en platform som bureauet sælger til mange kunder, bliver fuld overdragelse dyr eller umulig. Sørg i stedet for en licens med en klar exit: dataudtræk, rimelige varsler og eventuelt kildekodedeponering, hvor en uafhængig tredjepart opbevarer koden og udleverer den hvis leverandøren lukker.

Det gælder også hvis du overvejer at hyre mig: har du brug for en færdig løsning til fast månedlig pris og uden udvikling, er en standardplatform ofte billigere end at få noget bygget.

Næste skridt

Start med det du kan gøre i dag:

1. Find kontrakten eller vilkårene frem, og tjek om de overdrager rettighederne til koden.
2. Gå tjeklisten ovenfor igennem, og notér de punkter du ikke kan sætte flueben ved.
3. Flyt domæne, repository og konti mens samarbejdet fungerer.
4. Skal du i gang med et nyt projekt, så tag ejerskab op i de første samtaler. Det hører med blandt de spørgsmål du bør stille en udvikler før du hyrer.

Flere greb finder du i guiden om at undgå at blive låst til din udvikler. Har du et system der skal overtages, ryddes op i eller videreudvikles, kan du læse om hvordan jeg arbejder med vedligehold og videreudvikling af eksisterende løsninger. Hos mig ligger koden i dit eget repository fra første dag.

Ofte stillede spørgsmål

Ejer jeg koden hvis jeg ikke har betalt den sidste faktura?+

Ofte ikke, men det afhænger af aftalen. Mange kontrakter lader rettighederne overgå først ved betaling, så indtil fakturaen er betalt, kan udvikleren stadig have ophavsretten. Er du uenig i fakturaen, så sig det skriftligt og betal den del der ikke er uenighed om. Bemærk også at et .dk-domæne ikke kan overdrages til en ny registrant så længe der ligger en ubetalt faktura på domænet.

Må udvikleren genbruge kode fra mit projekt hos andre kunder?+

Ikke den kode der er overdraget til dig, men gerne sin viden og sine metoder. Ophavsretten beskytter selve koden og ikke de idéer og principper der ligger bag. En udvikler må altså godt bygge noget lignende for en anden kunde, så længe koden ikke er kopieret, og dine forretningshemmeligheder ikke bliver brugt. Vil du forhindre mere end det, kræver det en særskilt og snævert afgrænset aftale.

Hvad betyder manglende rettigheder hvis jeg vil sælge virksomheden?+

Det kan koste dig på prisen eller i værste fald hele handlen. En køber eller investor vil i en due diligence (gennemgang før handlen) spørge om virksomheden ejer sin software og bede om de aftaler der viser det. Mangler overdragelsen fra en tidligere freelancer eller et bureau, skal den typisk på plads før handlen kan gennemføres. Det er nemmere at ordne mens du ikke har travlt.

Hvad med udviklerens ideelle rettigheder?+

De følger ikke med en overdragelse. Efter ophavsretslovens § 3 har ophavsmanden ret til at blive navngivet efter god skik og til at værket ikke ændres på en krænkende måde, og retten kan kun frafaldes for en afgrænset brug. For forretningssoftware betyder det sjældent noget i praksis, men aftal gerne at udvikleren ikke skal krediteres i selve produktet.