Forside · Gennemgået oktober 2026 · Af John Nielsen
Et værktøj til kodesammenligning giver et tal og en liste over ens afsnit, men tallet afhænger af værktøjets type, dets indstillinger og det materiale, det får. To sagkyndige kan sammenligne de samme kodebaser og nå til meget forskellige procenter uden at nogen af dem har regnet forkert. Derfor skal valget af værktøj, parametrene og forbehandlingen dokumenteres lige så omhyggeligt som resultatet.
Selve metoden, fra sikring af kodebaserne til filtrering af forventet lighed og stærke og svage spor, er beskrevet i kodelighed: sammenligning af to kodebaser. Denne artikel handler om værktøjerne: hvad de forskellige typer måler, hvordan de skal indstilles, og hvor de leder analysen på afveje. Den juridiske ramme for ophavsret til software står på digital-bevissikring.dk.
Fem typer værktøjer
- Hash og filsammenligning · Hvad det sammenligner: Hele filer bit for bit · Typisk brug: Find identiske filer hurtigt
- Tekstbaseret diff · Hvad det sammenligner: Linjer og blokke · Typisk brug: Vis ændringer side om side
- Tokenbaseret · Hvad det sammenligner: Sekvenser af sprogets elementer efter normalisering · Typisk brug: Find omdøbt og omformateret kode
- Syntakstræ og klondetektion · Hvad det sammenligner: Strukturen i koden · Typisk brug: Find omstruktureret kode
- Licens- og oprindelsesscannere · Hvad det sammenligner: Kode mod kendte open source-projekter · Typisk brug: Skil tredjepartskode fra
Hash og filsammenligning er det første trin. En hashværdi pr. fil, fx med sha256sum eller Get-FileHash, viser straks, om filer er bitidentiske. Det fanger kun direkte kopier, men det er stærke fund, når de findes. Se hash af en fil.
Tekstbaseret diff, som git diff eller diff -r, er godt til at præsentere fund, men dårligt til at finde dem. Ændres indrykning, linjeskift eller et variabelnavn, ser to ens funktioner forskellige ud.
Tokenbaserede værktøjer omsætter koden til en sekvens af tokens, fx nøgleord, operatorer og pladsholdere for navne, og søger efter fælles sekvenser over en minimumslængde. Derved forsvinder omdøbninger og formatering. JPlag er et neutralt eksempel: det er open source, understøtter en række sprog, kører lokalt og har indstillinger for minimumslængde af et fund og for basiskode, der skal udelades.
Syntakstræbaserede værktøjer og klondetektorer sammenligner kodens struktur. De kan finde kode, hvor rækkefølgen af sætninger er ændret, eller hvor en løkke er skrevet om. Til gengæld giver de flere falske fund i kode, der af natur har samme struktur.
Licens- og oprindelsesscannere sammenligner ikke de to parters kode med hinanden, men hver kodebase med kendte open source-projekter. De bruges til at identificere kode, som begge parter kan have hentet samme sted fra, så den kan filtreres ud før selve sammenligningen. Se også open source-licenser og SBOM som bevis.
Indstillingerne afgør resultatet
Et tokenbaseret værktøj har typisk en minimumslængde for et fund. Er den lav, bliver korte, generiske sekvenser som en standardløkke eller en typisk fejlhåndtering talt med, og ligheden stiger. Er den høj, forsvinder korte, men særegne fund. Der findes ikke én korrekt værdi. Den skal vælges ud fra sprog og kodestil og begrundes i rapporten.
Andre indstillinger med stor betydning:
- Basiskode. Kode, som begge parter har fået fra samme kilde, fx et framework, en skabelon eller kundens egen kode, kan angives som basis og udelades af beregningen. Glemmes det, tæller den fælles basis som lighed.
- Normalisering. Om kommentarer, strengkonstanter og navne normaliseres, ændrer både tallet og hvilke fund der bliver synlige. Identiske kommentarer er ofte et stærkt spor og bør derfor ikke forsvinde i en normalisering uden at blive undersøgt for sig.
- Filudvælgelse. Hvilke filtyper og mapper der indgår. Genererede filer, kopierede afhængigheder og testdata skal ud eller vises for sig.
- Sprogmodul. Kode i flere sprog eller indlejret kode, fx SQL i strenge eller skabeloner med HTML, håndteres forskelligt af værktøjerne og kan falde helt uden for sammenligningen.
Kør gerne sammenligningen med to eller tre indstillinger og vis, hvordan resultatet ændrer sig. Er konklusionen den samme, er den robust. Ændrer den sig markant, er det en vigtig oplysning i sig selv.
Fortrolighed: hvor kører værktøjet?
Kildekode er ofte begge parters vigtigste forretningshemmelighed. Nogle udbredte værktøjer er webtjenester, hvor koden sendes til en ekstern server og resultatet hentes derfra. MOSS fra Stanford er et kendt eksempel, oprindeligt lavet til at finde plagiat i programmeringsundervisning. Det kan være praktisk, men i en tvist betyder det, at begge parters kode forlader det kontrollerede miljø, og at man ikke selv styrer opbevaringen.
Brug derfor værktøjer, der kører lokalt på en isoleret arbejdsstation, medmindre parterne udtrykkeligt har aftalt andet. Det samme gælder AI-tjenester: at indsætte kode i en sprogmodel for at få en vurdering af lighed er både et fortrolighedsproblem og et efterprøvelighedsproblem. Se AI-kodeassistenter i kildekodetvister for den anden side af det spørgsmål.
Hvor parterne ikke må se hinandens kode, kan analysen foregå hos en uvildig, og rapporten kan vise udvalgte uddrag frem for hele filer. Den processuelle side af lukkede døre og forretningshemmeligheder er beskrevet på digital-bevissikring.dk.
Faldgruber i værktøjernes output
Procenttal uden nævner. “62 % lighed” siger intet, før det er klart, om procenten er regnet af den ene kodebase, den anden, gennemsnittet eller kun af de filer, der blev sammenlignet. Værktøjer regner forskelligt, og nogle viser den største af to procenter som standard.
Parvis sammenligning af mange filer. Sammenligner værktøjet alle filer med alle, vil der statistisk være tilfældige ligheder mellem korte filer. Fund i små filer skal vægtes lavt, medmindre de rummer særegne træk.
Rangordning frem for vurdering. Værktøjer sorterer typisk efter lighed. Det er en prioriteringsliste til den manuelle gennemgang, ikke en konklusion. Hvert fund, der bærer en konklusion, skal være set og vurderet af et menneske.
Fund i fælles tredjepartskode. Har begge parter brugt samme open source-bibliotek eller samme eksempel fra dokumentationen, giver det store, ens blokke. Uden filtrering ligner det kopiering.
Forskellige versioner. Sammenlignes den ene parts kode fra i dag med den anden parts kode fra for tre år siden, kan senere ændringer skjule eller skabe lighed. Versionen af hver kodebase skal være fastlagt med commit-id og hashværdi; se kildekode og Git som bevis.
Kun kode, ikke resten. Værktøjerne ser normalt kun kildekoden. Databaseskemaer, konfiguration, oversættelsesfiler og byggeskripter kan rumme de mest sigende spor og må ofte sammenlignes særskilt.
Kontrol af værktøjet
Et værktøj, der bruges til en konklusion i en tvist, bør kunne vise, at det virker som forventet på det konkrete materiale. En enkel kontrol er at lave et lille testsæt: en fil, en kopi med omdøbte navne, en kopi med omflyttede funktioner og en uafhængigt skrevet fil, der løser samme opgave. Finder værktøjet de to første, og vurderer det den sidste som forskellig, er indstillingerne rimelige. Testsættet og resultatet gemmes sammen med sagen.
En kontrolkodebase fra en tredje, uafhængig kilde i samme domæne giver et mål for den lighed, der kan forventes uden kopiering. Det er ofte den mest overbevisende måde at vise, at et tal er højt eller lavt.
Dokumentation, der kan efterprøves
Rapporten bør for hvert værktøj angive:
- navn og præcis version, og om det kørte lokalt
- alle indstillinger, herunder minimumslængde, normalisering og basiskode
- hvilke filer og mapper der indgik og blev udeladt, med begrundelse
- commit-id og hashværdi for hver sammenlignet kodebase
- rå output, gemt med hashværdi, så en modparts sagkyndige kan gentage kørslen
Fund præsenteres side om side med lighederne markeret og med fil og linjenumre. Et udvalg af de stærkeste fund overbeviser mere end en lang liste, men listen skal være tilgængelig. Gennemgår modparten senere materialet, er det netop indstillingerne og udvælgelsen, der bliver prøvet; se gennemgang af modpartens rapport.
Hvad værktøjerne kan og ikke kan
Værktøjerne kan hurtigt og systematisk finde kandidater til kopiering i store kodebaser og gøre lighed målbar på flere niveauer. De kan ikke skelne mellem kopiering og uafhængig udvikling med samme forudsætninger, og de kan ikke vurdere, om en lighed angår beskyttet udtryk eller blot fælles idéer og funktionalitet. Den vurdering kræver en sagkyndig gennemgang af fundene i sammenhæng med historik, tidsfølge og den juridiske ramme.
Kilder og versioner
- JPlag: projektside og dokumentation
- Schleimer, Wilkerson og Aiken: Winnowing, lokal fingeraftryksteknik til dokumentlighed
- SPDX License List
Senest gennemgået: oktober 2026.
Næste skridt
- GitHub, GitLab og Azure DevOps: auditlogs for kloning, forks og tokens
- Massesletning efter en tvist er opstået: tekniske tegn
Læs også: Kildekodegennemgang: metode, omfang og dokumentation · Open source-licenser og SBOM som bevis i licens- og ophavsretstvister
→ Uvildig IT-sagkyndig med forensic-baggrund · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
