I en sag om kopieret software er sammenligningen af kildekode ofte det tekniske bevis, som resten af sagen hviler på. Alligevel bliver mange af de afgørende valg truffet, før den sagkyndige går i gang: hvilke versioner der sammenlignes, hvad der frasorteres, hvem der må se koden, og hvordan resultatet skal præsenteres. De valg ligger i høj grad hos advokaten.
Denne artikel handler om de beslutninger og om, hvordan en sammenligning læses kritisk. Hvilke tegn på kopiering der typisk er stærke og svage, og hvordan klientens egen kode sikres, er beskrevet i Ophavsret og software: dokumentation af kopiering. Den tekniske metode i detaljer findes på digitalforensics.dk: Kodelighed: metode til sammenligning.
Hvad der er beskyttet, og om ligheden udgør en krænkelse, er juridiske spørgsmål. Edb-programmer er beskyttet som litterære værker efter ophavsretsloven, og efter direktiv 2009/24/EF om retlig beskyttelse af edb-programmer er idéer og principper bag et program ikke beskyttet. Den sondring har direkte betydning for, hvordan sammenligningen skal tilrettelægges.
Beslutning 1: Hvad skal sammenlignes?
Software ændrer sig hele tiden. Et program kan have været en tæt kopi i én version og være omskrevet i den næste. Derfor skal det fastlægges præcist:
- Hvilke versioner af klientens kode? Typisk den version, der fandtes, da modparten påstås at have fået adgang.
- Hvilke versioner af modpartens kode? Den første version, der blev markedsført, den nuværende, eller alle versioner i en periode?
- Hvilke dele? Hele programmet, et bestemt modul eller bestemte funktioner?
En sammenligning af to nuværende versioner kan undervurdere en kopiering, der fandt sted tidligt og siden er sløret. Modsat kan en sammenligning af tidlige versioner vise lighed, der ikke længere har betydning for et forbud. Valget hænger sammen med sagens påstande og bør træffes sammen med den sagkyndige.
Beslutning 2: Hvad skal frasorteres?
Lighed mellem to programmer kan have mange lovlige forklaringer. Uden filtrering ser resultatet ofte mere alvorligt ud, end det er. Typisk frasorteres:
- open source-komponenter og biblioteker, som begge parter kan have brugt,
- kode, der er genereret automatisk af værktøjer eller frameworks,
- kode, som et sprog, en standard eller en grænseflade dikterer,
- korte, almindelige konstruktioner.
Filtreringen er et metodevalg, og den skal beskrives. Modparten vil ofte angribe netop den. Har den sagkyndige frasorteret for lidt, ser ligheden for stor ud. Har den sagkyndige frasorteret for meget, kan kopieret kode være forsvundet i filtreringen. Bed om, at rapporten oplyser, hvad der er frasorteret, med hvilken begrundelse, og hvor stor en del af koden det udgjorde. → Open source-licensbrud: SBOM som bevis
Beslutning 3: Hvilken metode?
Der findes flere tilgange, og de finder forskellige ting:
- Tekstsammenligning · Finder: Direkte kopierede linjer, kommentarer og stavefejl · Overser: Kopi, hvor navne og formatering er ændret
- Sammenligning af kodens elementer · Finder: Kopi med ændrede variabelnavne og formatering · Overser: Omskrivning af struktur og logik
- Strukturel sammenligning · Finder: Samme opbygning og samme forløb af funktioner · Overser: Kopi oversat til et andet programmeringssprog
- Manuel gennemgang · Finder: Særheder, fejl og sammenhænge, værktøjer ikke ser · Overser: Store mængder kode, hvis den står alene
En robust sammenligning kombinerer værktøjer og manuel gennemgang. Værktøjerne udpeger kandidater, og den sagkyndige vurderer dem enkeltvis. En rapport, der kun angiver et værktøjs samlede procentsats, bør give anledning til spørgsmål.
Er koden oversat til et andet sprog, eller findes kun det færdige program, skal metoden tilpasses. Det kan være relevant at sammenligne opførsel, datastrukturer og fejlmeddelelser frem for kode.
Beslutning 4: Hvem må se koden?
Begge parters kildekode er typisk forretningshemmeligheder. Det giver et dilemma: Modparten skal kunne efterprøve sammenligningen, men ingen af parterne ønsker at udlevere kode til konkurrenten.
Mulige løsninger:
- Kun sagkyndige ser koden. Parterne aftaler, eller retten bestemmer, at koden kun stilles til rådighed for de sagkyndige, og at rapporten kun gengiver de konkrete uddrag, der er nødvendige.
- Undersøgelse i et kontrolleret miljø. Koden udleveres ikke, men kan undersøges på en maskine uden mulighed for kopiering.
- Fortrolighed under sagen. Dele af bevisførelsen holdes for lukkede døre. → Lukkede døre og forretningshemmeligheder i retten
Aftal ordningen, før koden udleveres, og beskriv den skriftligt. Det sparer tvister om fremgangsmåden senere.
Beslutning 5: Partsindhentet erklæring eller syn og skøn?
En partsindhentet sammenligning kan være nødvendig for at vurdere, om der overhovedet er en sag, og for at begrunde en begæring om adgang til modpartens kode. Men i en verserende sag vil en skønserklæring ofte have større vægt. Mange sager har begge dele: en indledende vurdering og senere et skøn. → Partsindhentet erklæring eller skønserklæring?
Er der en partsindhentet sammenligning, bør skønstemaet ikke blot bede skønsmanden bekræfte den. Lad skønsmanden fastlægge metoden selvstændigt, men bed om stillingtagen til konkrete forhold, som den indledende sammenligning har udpeget.
Sådan læses en rapport om kodelighed
Uanset om rapporten kommer fra egen side eller modparten, kan den gennemgås med de samme spørgsmål:
- Versioner: Er de sammenlignede versioner identificeret præcist, fx med commit-id eller hashværdi?
- Integritet: Hvordan er koden modtaget, og kan det vises, at den ikke er ændret? → Git-platformens auditlog og kloning
- Filtrering: Hvad er frasorteret, og med hvilken begrundelse?
- Metode: Hvilke værktøjer og indstillinger er brugt, og kan sammenligningen gentages?
- Eksempler: Er konkrete eksempler vist med filnavne og linjenumre, eller kun som tal?
- Alternative forklaringer: Har den sagkyndige overvejet fælles kilder, fælles tidligere arbejdsgiver, fælles open source eller AI-genereret kode? → AI-kodeassistenter: spor i kildekoden
- Retning: Påstår rapporten, hvem der har kopieret fra hvem? Det kan sammenligningen alene sjældent vise. Det kræver tidsspor fra historik og metadata.
- Konklusioner: Holder rapporten sig til tekniske iagttagelser, eller konkluderer den om krænkelse?
→ Sådan læser du en IT-sagkyndig rapport · Modpartens IT-sagkyndige
Præsentation for retten
Retten skal kunne forstå ligheden uden at læse kode. Gode præsentationer bruger få, udvalgte eksempler, hvor koden vises side om side med markering af de identiske dele, sammen med en forklaring af, hvorfor netop det eksempel er usædvanligt. Et tal for den samlede lighed kan supplere, men det bør ikke stå alene. → Digitale beviser i retssalen: skærme, tidslinjer og visualiseringer
Spørgsmål til skønsmanden
- “Findes der i program B, version [x], kodedele, der er identiske med eller afledt af program A, version [y], efter frasortering af open source og genereret kode? Angiv konkrete eksempler.”
- “Hvilken metode og hvilke værktøjer er anvendt, og hvad er frasorteret?”
- “Findes der i program B særheder, fejl eller navne, som har en naturlig forklaring i program A, men ikke i program B?”
- “Kan ligheden forklares ved fælles brug af komponenter, standarder eller frameworks?”
→ Skabelon: skønstema i en IT-sag
Typiske faldgruber
- Versionerne er ikke fastlagt, så parterne taler forbi hinanden.
- Filtreringen er ikke beskrevet, og modparten angriber hele resultatet.
- Rapporten bygger på en samlet procentsats uden konkrete eksempler.
- Koden udleveres, før fortrolighedsordningen er aftalt.
- Sammenligningen bruges som bevis for, hvem der kopierede, uden tidsspor.
- Den sagkyndige drager juridiske konklusioner om krænkelse.
Tjekliste
- ☐ Sammenlignede versioner og dele er fastlagt og sikret
- ☐ Filtrering af open source og genereret kode er aftalt og beskrevet
- ☐ Metode og værktøjer er valgt og dokumenteret
- ☐ Fortrolighedsordning er aftalt før udlevering
- ☐ Konkrete eksempler er udvalgt til præsentation
- ☐ Tidsspor understøtter spørgsmålet om, hvem der kopierede
En uvildig IT-sagkyndig kan gennemføre sammenligningen eller efterprøve modpartens. → IT-sagkyndig og skønsmand i civile sager
→ Send en sag · Tlf. 70 13 63 23 · IT-sagkyndig bistand til advokater hos Nielco IT
