I en tvist om kopieret software er det sjældent nok, at to programmer ligner hinanden. Lighed kan skyldes fælles biblioteker, samme framework eller samme opgave løst på samme måde. Det, der dokumenterer kopiering, er konkrete spor: identiske særheder i koden, en versionshistorik, der viser, hvornår koden kom ind, og metadata, der peger tilbage på originalen.
Spørgsmålet om, hvad der er beskyttet, og hvad der udgør en krænkelse, er advokatens felt.
Nielco IT tager kun civile sager, ikke straffesager.
Før sagen: spørgsmål til klienten
Det første møde afgør, hvad der skal sikres, og hvor hurtigt. Spørg konkret:
- Hvilket program eller hvilke dele af det mener klienten er kopieret?
- Hvor ligger klientens kode i dag, og hvem har administratoradgang til repository og hosting?
- Hvornår blev de relevante dele skrevet, og af hvem? Ansatte, freelancere eller en underleverandør?
- Hvordan er modpartens program kommet frem? Er det solgt, demonstreret, lagt på en app-butik eller kun beskrevet?
- Har en tidligere medarbejder eller samarbejdspartner haft adgang til koden, og hvornår ophørte adgangen?
- Er der aftaler om ejerskab til koden, fx i ansættelseskontrakter eller udviklingsaftaler?
Svarene bestemmer rækkefølgen. Ligger sporene hos en hostet tjeneste med begrænset logopbevaring, skal de sikres først. → Tjekliste til første klientmøde
Tre typer beviser
- Sammenligning af kildekode · Hvad det kan vise: Lighed i struktur, navne, kommentarer og fejl · Typisk svaghed: Lighed kan have andre forklaringer
- Versionshistorik · Hvad det kan vise: Hvornår kode blev tilføjet og af hvem · Typisk svaghed: Historik kan omskrives
- Metadata · Hvad det kan vise: Oprindelse, forfatter, tidspunkter · Typisk svaghed: Kan være ændret eller mangle
De stærkeste sager kombinerer alle tre.
Kildekodesammenligning
En sammenligning bør laves systematisk med værktøjer, der finder lighed, også når variabelnavne er ændret, eller koden er flyttet rundt. Men værktøjets resultat er kun udgangspunktet. Den sagkyndige skal vurdere, hvad ligheden består i.
Stærke tegn på kopiering:
- identiske kommentarer, stavefejl eller tekst i koden,
- samme fejl eller mærkelige løsninger, der ikke giver mening hos modparten,
- død kode eller ubrugte funktioner, der også findes i originalen,
- interne navne, stier eller kundenavne fra originalen.
Svage tegn:
- lighed i kode fra open source-biblioteker,
- lighed, som et framework eller en standard dikterer,
- korte, almindelige kodestykker.
Open source er et særligt opmærksomhedspunkt. Begge parter kan have brugt de samme komponenter lovligt. Sammenligningen skal frasortere dem.
Hvad en sammenligning ikke kan vise
En procentsats for lighed lyder præcis, men den siger lidt i sig selv. Den afhænger af, hvilket værktøj der er brugt, hvad der er sorteret fra, og hvordan koden er inddelt. Bed derfor om, at rapporten beskriver metoden, og at de konkrete eksempler på lighed fremgår med filnavn og linjer.
En sammenligning kan heller ikke alene vise, hvem der har kopieret fra hvem. Det kræver tidsspor fra historik og metadata. Og den kan ikke vise, at modparten har haft adgang til originalen. Det skal dokumenteres på anden måde, fx via adgangslog eller ansættelsesforhold.
Versionshistorik
Systemer som Git gemmer historikken for hver ændring. Det kan vise:
- hvornår en bestemt fil eller funktion første gang optræder,
- hvilken brugerkonto der tilføjede den,
- om store mængder kode kom ind på én gang.
Hvis modpartens kode pludselig vokser med tusindvis af linjer i ét commit kort efter en medarbejders fratrædelse, kan det være et vigtigt spor.
Men historikken kan omskrives, og tidsstempler i commits kan sættes manuelt. Sikr derfor også data fra den hostede tjeneste, fx GitHub, GitLab eller Azure DevOps, hvor serverens egne logs kan være mere pålidelige. → Cloud-forensic: sikring via API og administratoreksport
Den tekniske gennemgang af, hvordan Git-historik læses og efterprøves, er beskrevet her: → Git og kildekode som bevis
Metadata
Metadata kan findes i filer, i kompilerede programmer og i projektfiler. → Hvad er metadata?
Eksempler:
- forfatter- og firmanavn i projektfiler,
- stier fra udviklerens computer, der er bygget ind i programmet,
- tidsstempler, der ligger før modpartens påståede udviklingsstart.
Når der kun findes et færdigt program
Ofte har klienten kun modpartens færdige program, fx en app eller en installationsfil. Det kan stadig undersøges. Tekststrenge, fejlmeddelelser, indbyggede stier og navne på interne funktioner kan være synlige uden kildekoden. Det kan være nok til at begrunde en begæring om adgang til selve koden. Vær opmærksom på, at licensvilkår kan begrænse, hvordan et program må undersøges.
Sikring af egen kode
Klientens egen kode skal også sikres, så det kan dokumenteres, hvad der fandtes og hvornår.
- ☐ Kopi af repository med fuld historik
- ☐ Eksport fra den hostede tjeneste, inklusive adgangslog
- ☐ Hashværdier for det sikrede → Hashværdier forklaret
- ☐ Liste over udviklere og deres adgang
- ☐ Revisionslog, der viser download eller kloning af repository
Bed klienten om ikke at rydde op i repository, omskrive historik eller slette gamle grene, mens sagen verserer. Det gælder også, selvom det er god praksis i det daglige udviklingsarbejde. → Bevarelsespligt og litigation hold
Adgang til modpartens kode
Modpartens kildekode er sjældent offentlig. Adgang kræver typisk edition eller fogedretlig bevissikring. → Fogedretlig bevissikring: IT-sagkyndiges rolle
Kildekode er ofte en forretningshemmelighed. Det kan være relevant at foreslå, at kun en uvildig sagkyndig får adgang og alene rapporterer om ligheden. → Editionsbegæring set fra IT-siden
Når adgangen er givet, bør begæringen eller aftalen beskrive præcist, hvad der skal sikres: hvilke repositories, hvilke grene, hvilken periode og om build-servere og issue-trackere er omfattet. En snæver, præcis beskrivelse er lettere at gennemføre og giver færre indsigelser end “al kildekode”. → Forretningshemmeligheder og bevissikring
Rækkefølge og tidsforbrug
- Sikr klientens egen kode og logs hos den hostede tjeneste. Det kan typisk gøres hurtigt og uden modpartens medvirken.
- Sikr modpartens offentlige spor: program, app, hjemmeside, dokumentation og eventuelle offentlige repositories.
- Lav en foreløbig vurdering af, om der er stærke tegn på kopiering. Den er grundlaget for at beslutte, om der skal søges adgang til modpartens kode.
- Søg adgang til modpartens kode via edition, bevissikring eller aftale.
- Fuld sammenligning og rapport. Det er det mest tidskrævende trin og afhænger af kodens størrelse og af, hvor meget open source der skal frasorteres.
Tidsforbruget i trin 5 kan sjældent fastlægges, før koden er set. Bed om et overslag efter trin 3. → Omkostninger ved IT-sagkyndig bistand
Typiske fejl
- Klienten sender koden som en zip-fil uden historik. Historikken er ofte den vigtigste del.
- Der sammenlignes på et tidspunkt, hvor begge programmer er videreudviklet, uden at det er klart, hvilke versioner der sammenlignes.
- Open source og genereret kode er ikke frasorteret, så ligheden ser større ud, end den er.
- Adgangslog hos den hostede tjeneste er ikke sikret, før den udløber.
Spørgsmål til skønsmanden
Gode spørgsmål er konkrete og efterprøvelige:
- Findes der kodedele i program B, som er identiske med eller afledt af program A?
- Hvor stor en del udgøres af open source eller standardkomponenter?
- Hvornår optræder de pågældende kodedele første gang i program B’s historik?
- Er der tegn på, at historikken i program B er omskrevet, eller at tidsstempler er ændret?
- Findes der i program B navne, stier, kommentarer eller fejl, som kun giver mening i program A’s sammenhæng?
Handler sagen om, hvem der først udviklede en teknisk løsning, er dokumentationen af udviklingsforløbet beslægtet. → Patentsager: dokumentation af udviklingsforløb
→ Send en sag · Tlf. 70 13 63 23 · IT-sagkyndig bistand til advokater hos Nielco IT
