Forside · Gennemgået oktober 2026 · Af John Nielsen
Når en part hævder, at en anden har kopieret kildekode, skal to kodebaser sammenlignes. En teknisk sammenligning kan måle lighed på flere niveauer, fra identiske filer til ens struktur trods omdøbte navne. Men lighed er ikke det samme som kopiering. Kode, der løser samme opgave i samme sprog med samme biblioteker, ligner hinanden af naturlige grunde, og en sammenligning uden filtrering af den forventede lighed giver et misvisende billede.
Den juridiske ramme for ophavsret til software er beskrevet på digital-bevissikring.dk. Historikken i Git og dens begrænsninger er beskrevet i kildekode og Git som bevis.
Niveauer af lighed
Kodelighed kan måles på forskellige niveauer, og hvert niveau fanger forskellige former for kopiering:
- Hele filer (hash) · Hvad det fanger: Bitidentiske filer · Hvad det overser: Enhver ændring, selv et mellemrum
- Tekstlinjer · Hvad det fanger: Ens linjer og blokke · Hvad det overser: Omformatering og omdøbte navne
- Tokens · Hvad det fanger: Ens sekvenser efter at navne og formatering er normaliseret · Hvad det overser: Omstrukturering, ændret rækkefølge
- Struktur · Hvad det fanger: Ens syntakstræer eller kontrolflow · Hvad det overser: Genskrivning med samme idé
- Arkitektur · Hvad det fanger: Ens opdeling i moduler, datamodeller og grænseflader · Hvad det overser: Ofte forventelig lighed
En grundig sammenligning bruger flere niveauer. Identiske filer er stærke spor, men sjældne, når der er tale om bevidst kopiering. Token- og strukturbaseret sammenligning fanger kode, der er omdøbt og omformateret. Arkitekturlighed er sjældent stærk i sig selv, fordi mange løsninger i samme domæne er opbygget ens.
Forberedelse af materialet
- Sikr begge kodebaser med fuld historik og hashværdier, så det er klart, præcis hvilke versioner der sammenlignes.
- Fastlæg tidspunkterne. Hvilken version af den oprindelige kode var tilgængelig for den anden part, og hvilken version af den nye kode sammenlignes?
- Opdel i lag. Adskil egen kode, tredjepartsbiblioteker, genereret kode, konfiguration og testdata.
- Fjern støj. Afhængigheder, der er kopieret ind i repositoriet, byggede filer og auto-genereret kode skal ud af sammenligningen eller vises for sig.
Filtrering af forventet lighed
Det vigtigste metodiske skridt er at filtrere det, der ville ligne hinanden uanset kopiering:
- Tredjepartsbiblioteker og open source, som begge parter kan have hentet uafhængigt. Kendte biblioteker kan identificeres med hashlister over kendte filer, som beskrevet i hashlister og kendte filer.
- Skabeloner fra frameworks, fx projektstrukturer, der oprettes af værktøjer, og standardkonfiguration.
- Genereret kode fra værktøjer, ORM’er eller API-definitioner.
- Generisk kode, som stort set kun kan skrives på én måde, fx simple datastrukturer, standardalgoritmer og getters og setters.
- Kode fra offentlige kilder, fx eksempler fra dokumentation eller kendte spørgsmål-og-svar-sider, som begge kan have brugt.
- AI-assistenter, der kan foreslå næsten ens kode til to uafhængige udviklere, der løser samme opgave.
Det, der er tilbage efter filtrering, er den lighed, der skal forklares.
Stærke og svage spor
Visse træk ved kode er særligt sigende, fordi de er tilfældige eller personlige og derfor sjældent opstår to steder uafhængigt:
- identiske kommentarer, også stavefejl og interne henvisninger,
- særegne navne på variabler, funktioner og konstanter, især med tastefejl,
- ens fejl og fejlhåndtering, der ikke giver mening i den nye sammenhæng,
- død kode og ubrugte funktioner, der går igen,
- ens magiske tal, interne testdata eller hardkodede stier,
- rester af den oprindelige virksomheds navn, domæner eller interne systemer.
Svage spor er ens arkitektur, ens valg af biblioteker og ens navngivning efter almindelige konventioner. De kan indgå i et samlet billede, men bærer ikke en konklusion.
Fuzzy hashing og lighedsmål
Fuzzy hashing og lignende teknikker kan give et tal for, hvor ens to filer er, også når de ikke er identiske. Det er nyttigt til at finde kandidater i store kodebaser, men tallet er ikke et mål for kopiering, og forskellige algoritmer giver forskellige tal. Se fuzzy hashing. Specialiserede værktøjer til kodelighed arbejder typisk på tokens eller syntakstræer og er bedre egnede end generelle fuzzy hashes til kildekode.
Uanset værktøj skal resultatet kontrolleres manuelt. Værktøjet peger på kandidater, og analytikeren vurderer dem i sammenhæng.
Historik og tidsfølge
Lighed alene siger ikke, hvem der kopierede fra hvem. Retningen skal underbygges med tidsfølge: Fandtes koden i den ene kodebase, før den dukkede op i den anden? Her bruges commit-historik, platformens tidsstempler, backups og andre udgaver af koden. Commit-tidspunkter kan sættes frit, så platformens egne tidsstempler og uafhængige kopier vejer tungere.
Et andet spor er den måde, koden opstår på. Kode, der er udviklet, vokser typisk over mange commits med fejlrettelser undervejs. Kode, der er kopieret ind, optræder ofte i store blokke i få commits, færdig fra start.
Når koden er oversat eller omskrevet
Kopiering sker ikke altid som direkte kopi. Koden kan være oversat til et andet programmeringssprog, flyttet til et andet framework eller omskrevet med hjælp fra værktøjer. Tekst- og tokenbaseret sammenligning finder sjældent noget i de tilfælde. Her må sammenligningen ske på et højere niveau: datamodeller, navne på tabeller og felter, algoritmernes trin, rækkefølgen af valideringer, fejlmeddelelser og konstanter.
Det er sværere at vise kopiering på dette niveau, fordi ligheden i højere grad kan forklares med fælles krav og domæneviden. Særegne detaljer bliver derfor endnu vigtigere: en usædvanlig beregningsrækkefølge, en bestemt håndtering af en sjælden undtagelse eller en fejl, der optræder i begge løsninger.
Ikke-kode-filer er ofte overset. Databaseskemaer, konfigurationsfiler, oversættelsesfiler med tekster, testdata og dokumentation kan indeholde særegne spor, som er lettere at sammenligne end selve koden.
Præsentation i rapporten
Resultatet bør vises, så en ikke-teknisk læser kan følge det: udvalgte uddrag side om side med ligheder markeret, en oversigt over, hvor stor en del af den nye kodebase der har lighed med den oprindelige efter filtrering, og en forklaring af, hvad der er filtreret fra. Procenttal uden forklaring af grundlaget er lette at misforstå og bør undgås som overskrift.
Bias og blind sammenligning
Den, der ved, hvilken part der påstår kopiering, kan let komme til at se ligheder, der ikke er sigende. Metodiske værn kan være at definere kriterierne for stærke spor, før sammenligningen begynder, at lade en anden kontrollere de vigtigste fund, og at inddrage en kontrolkodebase fra en tredje, uafhængig kilde i samme domæne. Ligner den nye kode den oprindelige mere end kontrolkodebasen, styrker det konklusionen. Se bias i forensisk analyse.
Fortrolighed
Kildekode er ofte en forretningshemmelighed for begge parter. Sammenligningen kan derfor være nødt til at foregå uden, at parterne får adgang til hinandens kode. Rapporten kan vise de relevante uddrag og statistik uden at gengive hele kodebaser, og selve analysen kan ske hos en uvildig på et isoleret system.
Hvad sammenligningen kan og ikke kan bevise
En sammenligning kan vise, hvor meget og hvilken kode der er ens efter filtrering af forventet lighed, og hvor særegne lighederne er. Med historik kan den underbygge en tidsfølge. Den kan ikke afgøre, om ligheden er en krænkelse, og den kan sjældent alene udelukke uafhængig udvikling. Konklusionen bør angives med en begrundet grad af sikkerhed, som beskrevet i konklusionsgrader, og med en beskrivelse af, hvad der er filtreret fra og hvorfor.
Kilder og versioner
- NIST: National Software Reference Library (NSRL)
- Schleimer, Wilkerson og Aiken: Winnowing, lokal fingeraftryksteknik til dokumentlighed
- ssdeep: fuzzy hashing
Senest gennemgået: oktober 2026.
Næste skridt
Læs også: GitHub, GitLab og Azure DevOps: auditlogs for kloning, forks og tokens · Telematik og flådestyring: GPS-logs teknisk
→ Uvildig IT-sagkyndig med forensic-baggrund · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
