Forside › Kreative og freelancere · Gennemgået oktober 2026 · Af John Nielsen
Er du freelanceudvikler eller konsulent, og er du blevet uenig med en kunde om, hvem der ejer koden, så gem tre ting nu: aftalen og alt, der ændrede den, dine fakturaer og leverancer, og historikken for koden, som den ligger i dit eget repository eller på kodeplatformen. Ændr ikke historikken, slet ingen repositories, og fjern ikke kundens adgang for at presse en betaling igennem. Spørgsmålet om ejerskab er juridisk, men svaret står ofte i sporene.
Hvorfor spørgsmålet opstår
Tvister om kode handler sjældent om ophavsret i teorien. De handler om penge og om fremtiden. Kunden vil ikke betale den sidste faktura, men vil gerne beholde koden. Du har genbrugt dele af et tidligere projekt, og nu mener kunden, at det hele er deres. Eller du vil bruge et modul hos en ny kunde, og den gamle kunde protesterer.
Som udgangspunkt overgår ophavsretten til et computerprogram, som en ansat laver som en del af sit arbejde, til arbejdsgiveren. Den regel gælder ansatte, ikke selvstændige. Er du freelancer, afhænger det af, hvad I har aftalt, og en aftale kan også fremgå af mails, tilbud og den måde, I har arbejdet sammen på. Den juridiske vurdering skal din advokat lave. Hvordan kopiering af software dokumenteres i en retssag, kan din advokat læse om på digital-bevissikring.dk.
Aftalen er mere end kontrakten
Saml alt, der siger noget om, hvad du skulle levere, og hvem der skulle eje det:
- Kontrakten, rammeaftalen og eventuelle standardvilkår, du eller kunden henviste til.
- Tilbuddet, der ofte beskriver leverancen mere præcist end kontrakten.
- Mails og chats om ændringer, fx “kan du også lave en eksport” eller “vi bruger dit gamle login-modul”.
- Fakturaer og betalinger, der viser, hvad der er betalt for, og hvad der mangler.
Gem mails som hele tråde med vedhæftninger. Chats i Slack, Teams eller Discord, som kunden ejer, kan forsvinde, når din adgang lukkes. Tag skærmbilleder af de vigtigste beskeder nu, mens du stadig har lovlig adgang som en del af opgaven. Hvordan leverance og aftale dokumenteres, når betalingen udebliver, står i kunden betaler ikke.
Det, historikken kan vise
Et versionsstyringssystem som Git gemmer hver ændring som et commit (en registreret ændring med forfatter, tidspunkt og beskrivelse). Historikken kan vise, hvem der skrev hvilke dele, hvornår, og om noget fandtes, før opgaven begyndte. Det sidste er vigtigt, hvis du har genbrugt din egen kode.
Men historikken kan ændres. Tidspunkter i et commit sættes af den computer, der laver det, og historikken kan skrives om. Derfor er det stærkere, når den lokale historik kan holdes op mod kodeplatformens egne logs, fx hvornår noget blev sendt op til platformen. De tekniske detaljer er beskrevet på digitalforensics.dk.
Din egen kode fra før opgaven
Har du et bibliotek, en skabelon eller et modul, du har brugt i mange projekter, så find beviset for, at det fandtes, før du mødte kunden. Det kan være et ældre repository, en tidligere faktura til en anden kunde, en gammel backup eller en filversion med dato. Hvordan du samler den slags spor i en tidslinje, står i bevis for, at du skabte det først.
Din arbejdsproces er også dokumentation
Koden er ikke det eneste spor af dit arbejde. Sager i et opgavestyringssystem, kommentarer i kodegennemgange, timeregistreringer, statusmails og noter fra møder viser, hvem der bad om hvad, og hvem der leverede det. Gem det, der ligger hos dig, fx timesedler, egne noter og mails. Tag skærmbilleder af opgaver og kommentarer i kundens systemer, mens du stadig har adgang som en del af opgaven, og notér datoen.
Har du sat koden i drift, så notér også, hvornår de vigtigste versioner blev leveret, og hvor. Det kan vise, at kunden tog koden i brug, før uenigheden opstod. Brugte kunden koden i drift uden at gøre indsigelse, kan det også sige noget om, hvad I reelt havde aftalt om leverancen.
Ansat i en periode, freelancer i en anden
Nogle udviklere har først været ansat hos kunden og er siden fortsat som selvstændige, eller omvendt. Så kan der gælde forskellige regler for forskellige dele af koden. Lav en oversigt over perioderne med datoer for ansættelse, fratræden og første faktura som selvstændig. Den gør det muligt for din advokat at se, hvilken kode der blev skrevet i hvilken rolle, og historikken kan vise, hvornår hver del kom til.
Hvis kunden lukker din adgang
Mange kunder fjerner udviklerens adgang til deres kodeplatform, når der opstår uenighed. Tag et skærmbillede af meddelelsen, og notér tidspunktet. Prøv ikke at komme ind igen med gamle nøgler eller tokens (koder, der giver adgang uden login). Har du en lokal kopi af koden fra dit arbejde, så lad den ligge uændret, brug den ikke, og tal med din advokat om, hvad der skal ske med den.
Det skal du ikke gøre
- Omskriv ikke historikken, og lav ingen tvungne opdateringer, der overskriver andres ændringer.
- Slet ikke repositories, grene eller brugere, heller ikke dine egne, mens tvisten står på.
- Læg ikke en spærring, en tidsbombe eller en licenskontrol ind i koden for at presse betaling.
- Fjern ikke kundens adgang til drift eller hosting, du administrerer.
- Brug ikke kundens kode hos en ny kunde, før ejerskabet er afklaret.
Det kan du selv
- ☐ Saml kontrakt, tilbud, vilkår og fakturaer i én mappe
- ☐ Gem mails og chats om leverancen og ændringer
- ☐ Notér, hvor koden ligger, og hvem der har adgang
- ☐ Find beviser for den kode, du havde i forvejen
- ☐ Lad din lokale kopi ligge uændret
- ☐ Skriv en tidslinje fra tilbud til uenighed
Her skal en IT-sagkyndig ind
En uvildig IT-sagkyndig er relevant, når kunden bestrider, hvem der har skrevet koden, når historikken ser ud til at være ændret, når det skal vises, at en del fandtes før opgaven, eller når koden hos en anden ser ud til at være kopieret fra din. Så kan repositories og platformens logs sikres, og der kan laves en sammenligning af koden, beskrevet så den kan efterprøves. Resultatet kan samles i en erklæring til din sag.
Nielco IT arbejder aldrig for både dig og kunden i samme tvist, og der laves et konflikttjek, før du får et overslag. Du kan henvende dig via din advokat eller selv tage kontakt.
Kilder og versioner
- Ophavsretsloven (lovbekendtgørelse nr. 1093 af 20. august 2023), § 59 om edb-programmer frembragt i ansættelsesforhold, Retsinformation
- Git-dokumentation: git log
Senest gennemgået: oktober 2026.
Næste skridt
- Bestyrelsesmedlem: gem din egen dokumentation, hvis der rejses ansvar
- Earn-out efter salget: dokumentér grundlaget for din betaling
Del af: Kreative og freelancere
Læs også: Søskende i familievirksomheden: uenighed om ejerskab og adgange · Platformen har lukket din konto: indhold og indtægter som skaber
→ Kreative og freelancere · Kontakt · Hjælp til privatpersoner · Via din advokat eller revisor · Tlf. 70 13 63 23