En tidligere partner lancerer et program, der opfører sig mistænkeligt meget som jeres, eller en kunde fortæller, at en konkurrents løsning har de samme fejlmeddelelser som jeres. De første skridt hviler på to ting: at jeres egen kode og historik bliver sikret, så I kan vise, hvad I havde og hvornår, og at det, der er synligt af det andet program, bliver dokumenteret uden at gå over grænsen for, hvad I selv må. Svaret er at sikre begge dele nu og overlade adgangen til modpartens kode til advokaten.
Skriv mistanken ned
Start med et kort notat. Hvad fik jer til at tænke på kopiering, hvem opdagede det, og hvornår? Notatet bliver udgangspunktet for advokaten og senere for en IT-sagkyndig.
- Hvad ligner · skærmbilleder, funktioner, arbejdsgange, tekster i brugerfladen, fejlmeddelelser.
- Hvem står bag · firma, personer og eventuel forbindelse til jer, fx en tidligere medarbejder, en underleverandør eller en tidligere samarbejdspartner.
- Hvornår · hvornår det andet program kom frem, og hvornår forbindelsen til jer ophørte.
- Hvordan I ved det · egne iagttagelser, oplysninger fra kunder eller offentlige kilder.
Skeln mellem det, I har set, og det, I formoder. En notits som “deres eksportfunktion giver samme fejlkode som vores” er nyttig. En notits som “de har helt sikkert taget koden” hjælper ikke.
Hold kredsen lille. Jo flere i virksomheden der kender til mistanken, jo større er risikoen for, at den når modparten gennem en fælles bekendt, en tidligere kollega eller en kunde. Udpeg én person, der samler materialet og fører en log over, hvad der er gjort, af hvem og hvornår. Loggen gør det senere muligt at forklare, hvordan dokumentationen er blevet til, og den forhindrer, at to personer sikrer det samme på forskellig måde.
Sikr jeres egen kode og historik
Den stærkeste del af jeres dokumentation ligger hos jer selv, og den skal sikres, før nogen rydder op. → Bevis for, at I var først: de spor, der holder
- ☐ En komplet kopi af repositoriet med hele versionshistorikken, også gamle grene
- ☐ Udgivelser og builds med datoer, versionsnumre og eventuelle hashværdier
- ☐ Sagsstyring, issues og dokumentation, der viser, hvornår funktioner blev udviklet
- ☐ Adgangslister og log over, hvem der havde adgang til koden og hvornår
- ☐ Aftaler med udviklere, underleverandører og partnere om rettigheder og fortrolighed
Lav kopien sådan, at originalen ikke ændres, og skriv ned, hvem der lavede den, og hvordan. Slet ikke grene, og omskriv ikke historikken, heller ikke for at rydde op. Hvordan Git-historik bruges som dokumentation, er beskrevet på søstersitet om metode. → Kildekode og Git som bevis
Er mistanken rettet mod en tidligere medarbejder, er der særlige spor at sikre om adgang og kopiering af filer. → En udvikler har taget kildekoden med
Dokumentér det, der er offentligt synligt
Det andet program kan ofte iagttages lovligt som almindelig bruger: på producentens hjemmeside, i en offentlig demo, i brugervejledninger og i markedsføring.
- Hjemmeside og dokumentation · sikret med adresse, dato og klokkeslæt. → Sådan dokumenteres en hel hjemmeside, før den ændres
- Brugerfladen · skærmbilleder og skærmoptagelser af skærmbilleder, menuer og fejlmeddelelser.
- Versioner · hvilken version I har set, og hvornår.
- Markedsføring · påstande om funktioner, udviklingstid eller kunder.
Notér, hvordan I fik adgang. Har I købt en licens eller oprettet en prøvekonto, skal I kende og overholde vilkårene. Er I i tvivl, så spørg advokaten først.
Kunder og samarbejdspartnere kan også have oplysninger. En kunde, der har fået en demonstration af det andet program, kan have modtaget materiale eller set noget, der ligner jeres. Bed om at få materialet i den form, det blev modtaget, fx som den oprindelige mail med vedhæftninger, og notér, hvad kunden fortalte og hvornår. Undlad at presse kunden for at hente mere, end vedkommende allerede har.
Grænsen for, hvad I selv må
Teksten er ikke juridisk rådgivning. Ophavsretsloven § 1, stk. 3, regner edb-programmer til de litterære værker, og § 37 tillader kun at fremstille eksemplarer af et programs kode og oversætte kodens form under snævre betingelser, der handler om at få programmer til at fungere sammen. Det betyder, at I ikke selv bør forsøge at skille konkurrentens program ad for at finde jeres kode.
Adgang til modpartens kildekode sker typisk gennem en juridisk proces. Retsplejelovens kapitel 57 a om bevissikring ved krænkelse af immaterialrettigheder er én af de veje, advokaten kan vurdere. → Hvornår skal en advokat ind over?
Er koden udviklet af ansatte, kan § 59 have betydning, fordi ophavsretten til et edb-program, der er frembragt af en arbejdstager under arbejdet, efter bestemmelsen går over til arbejdsgiveren. Er den udviklet af freelancere eller partnere, afgør aftalen meget.
Det skal I lade være med
- Logge ind hos modparten med gamle adgangskoder · selv om adgangen virker, er den ikke jeres at bruge.
- Dekompilere eller analysere deres program på egen hånd · lad advokaten vurdere, hvad der må gøres, og af hvem.
- Rydde op i jeres eget repository · en omskrevet historik er svær at forklare bagefter.
- Konfrontere den tidligere partner · en advarsel kan få spor til at forsvinde. → Derfor skal dokumentationen ligge klar før henvendelsen
- Glemme open source · fælles komponenter kan forklare en del af ligheden. → Open source-licenser, når koden er brugt uden at følge vilkårene
Hvad dokumentationen kan og ikke kan vise
Jeres egen historik kan vise, hvad I havde udviklet, og hvornår. Iagttagelser af det andet program kan vise ligheder i adfærd og brugerflade. Ingen af delene viser alene, at koden er kopieret. Det kræver som regel en sammenligning af selve koden, foretaget af en IT-sagkyndig med en metode, der kan efterprøves. → Sådan sammenligner en IT-sagkyndig to programmer
Hvad sikrer I nu, og hvad er næste skridt?
Skriv mistanken ned, tag en komplet kopi af jeres repository og udgivelser, saml aftalerne, og dokumentér det, der er offentligt synligt af det andet program. Giv materialet til advokaten, og aftal, om en IT-sagkyndig skal se på det, før der tages kontakt til modparten.
Kilder
- Ophavsretsloven, LBK nr. 1093 af 20. august 2023: § 1, stk. 3, om edb-programmer, § 37 om eksemplarfremstilling af kode og § 59 om arbejdstageres edb-programmer.
- Retsplejeloven, LBK nr. 1298 af 7. november 2025: kapitel 57 a om bevissikring ved krænkelse af immaterialrettigheder.
Senest gennemgået: november 2026.
Næste skridt
- Software og kildekode
- Hvem skal sikre: jer selv, advokaten eller en IT-sagkyndig?
- Jeres app er kopieret i en appbutik
Del af: Artikler om kopiering og ophavsret
Læs også: Data hentet fra jeres side med scraping · Kopieret HTML, CSS og skabelon
→ Kontakt · Tlf. 70 13 63 23 · Bevissikring ved kopiering hos Nielco IT
