Et softwarehus opdager, at et modul fra deres lukkede produkt ligger i et offentligt repository på GitHub under en tidligere samarbejdspartners konto. En anmeldelse til GitHub skal identificere jeres værk, pege på de præcise filer og linjer i kopien, nævne hver fork for sig og forklare, hvad brugeren skal gøre for at rette op. Svaret hviler på GitHubs egen politik og vejledning for anmeldelser efter den amerikanske DMCA-ordning, og på at GitHub offentliggør de anmeldelser, platformen handler på.
Først: er det en kopi, eller er det brugt efter en licens?
GitHub skriver i sin vejledning, at en copyrightmeddelelse fra jer i en fil ikke i sig selv betyder en krænkelse, fordi koden kan være brugt i overensstemmelse med en open source-licens. Har I selv udgivet koden under en licens, er spørgsmålet, om vilkårene er fulgt, og det er en anden sag end en ren kopi af lukket kode. → Open source-licenser, når koden er brugt uden at følge vilkårene beskriver den situation.
Efter ophavsretsloven § 1, stk. 3, hører edb-programmer til de litterære værker, og det er udgangspunktet for, at kode kan beskyttes. Hvor langt beskyttelsen rækker for netop jeres moduler, og om en anmeldelse er den rigtige vej, er advokatens vurdering. Teksten er ikke juridisk rådgivning.
Sikr repositoriet, før nogen reagerer
Et repository på GitHub kan omdøbes, gøres privat, slettes eller få sin historik omskrevet. Sikr derfor det, I kan se udefra, før anmeldelsen sendes.
- Repositoriets forside · navn, ejer, beskrivelse, licensfil og antal forks, gemt med dato og klokkeslæt.
- De berørte filer · hver fil gemt i den version, der vises, med adressen til den konkrete commit, så adressen ikke flytter sig med nye ændringer.
- Historikken · commit-listen for de berørte filer, med forfatternavne og datoer, som de vises.
- En lokal klon · en kopi af hele repositoriet med historik, hentet på samme måde som enhver anden bruger kan gøre det, og gemt urørt.
- Forks · listen over forks, som den ser ud på dagen.
Forfatternavne og datoer i git kan sættes af brugeren selv og er ikke kontrolleret af git. Hvad historikken kan og ikke kan bære, er beskrevet på digitalforensics.dk om git som bevis.
Jeres værk og det kopierede, fil for fil
GitHubs liste over krav begynder med, at anmeldelsen identificerer jeres værk, fx med et link, et registreringsnummer eller en beskrivelse, hvis koden ikke er offentliggjort. For lukket kode er beskrivelsen det eneste, GitHub ser. Gør den konkret.
- Produktet og modulet · navnet på jeres program og det modul eller bibliotek, koden kommer fra.
- Versionen · den udgivelse eller den commit i jeres eget repository, kopien svarer til, med dato.
- Kendetegn · filnavne, funktionsnavne, kommentarer eller særlige fejl, der også står i kopien.
- Omfang · om hele repositoriet er kopieret, eller kun bestemte filer og linjer.
GitHub beder om, at man angiver de konkrete filer og linjenumre, når det kun er en del af et repository, der påstås at krænke, og om at man skriver det udtrykkeligt, hvis alt indhold på en adresse er omfattet. Et repository kan rumme kode fra mange bidragydere, og anmeldelsen skal ramme jeres del. Til jeres eget brug kan I lave en sammenligning af filerne i et bilag, men GitHub vurderer ikke selve kravet. → Sådan sammenligner en IT-sagkyndig to programmer
Forks skal nævnes én for én
GitHub fjerner ikke automatisk forks, når det oprindelige repository bliver deaktiveret. Hver fork, I mener rummer jeres kode, skal stå i anmeldelsen, og I skal bekræfte, at I har undersøgt hver enkelt. Er et helt repository under aktiv forgrening, beskriver GitHub en undtagelse, hvor alle forks, der findes på anmeldelsestidspunktet, kan behandles samlet, når de er identificeret.
Gem derfor fork-listen med dato, og gennemgå de forks, der har ændringer, så I ved, om jeres kode stadig står i dem. En fork, hvor koden senere er fjernet, skal ikke med, men gem gerne den version, hvor den stod, hvis den kan have betydning for sagens omfang.
Det, brugeren skal gøre
Anmeldelsen skal forklare, hvad brugeren skal gøre for at rette op. GitHub giver som udgangspunkt brugeren omkring én arbejdsdag til at slette eller ændre det indhold, anmeldelsen nævner. Er et helt repository påstået krænkende, kan det deaktiveres uden den frist.
Formulér afhjælpningen konkret, fx at bestemte filer fjernes, eller at modulet erstattes. Kan sagen løses med, at en licens eller en kildeangivelse tilføjes, så skriv det, for det kan afgøre, om brugeren retter op med det samme.
Det, der bliver offentligt
GitHub offentliggør fuldstændige anmeldelser, som platformen handler på, i et offentligt repository, efter at personlige kontaktoplysninger er fjernet. Det øvrige indhold redigeres ikke, medmindre afsenderen beder om det. Skriv derfor anmeldelsen, så den kan stå offentligt, og undgå at beskrive forretningshemmeligheder i lukket kode mere detaljeret, end det er nødvendigt. Brugeren kan indgive en modmeddelelse, som GitHub også offentliggør og sender til jer. Vil I holde indholdet nede, skal I inden for en kort frist give GitHub besked om et søgsmål. → Hvornår skal en advokat ind over?
Hvordan en virksomhed griber sagen an, når det er en tidligere medarbejder eller partner, der har taget koden, står på bevissikring-digitalt.dk om kildekode, der er taget.
Det skal I lade være med
- Anmelde hele repositoriet af vane · angiv filer og linjer, når kun en del er jeres.
- Glemme forks · de forsvinder ikke af sig selv.
- Skrive hemmeligheder i anmeldelsen · teksten bliver offentlig.
- Oprette en konto for at kommentere i repositoriet · det advarer ejeren, før alt er sikret.
- Anmelde kode, der er brugt efter jeres egen licens · det er en licenssag, og en grundløs anmeldelse kan give et modkrav.
Hvad dokumentationen kan og ikke kan vise
Det sikrede repository, fork-listen og jeres eget versionsarkiv kan vise, hvilke filer og linjer der svarer til jeres kode, og hvornår de var synlige på GitHub. Hvem der som person har lagt koden op, fremgår ikke, fordi navne i git kan sættes frit, og GitHubs egne logfiler ikke er offentlige. Om ligheden er en krænkelse, afgør en advokat eller en domstol.
Tjekliste
- ☐ Repositoriet, filerne og historikken er gemt med dato
- ☐ En lokal klon ligger urørt
- ☐ Jeres egen version med dato er fundet
- ☐ Filer og linjer i kopien er listet
- ☐ Hver fork er gennemgået og listet
- ☐ Anmeldelsen kan tåle at blive offentliggjort
- ☐ Svar, modmeddelelse og offentliggørelse gemmes
Næste skridt er at lade advokaten se anmeldelsen og bilagene, før den sendes, især når kopien kommer fra en tidligere partner eller medarbejder. → Mistanke om kopieret software: de første skridt
Kilder
- GitHub: Guide to submitting a DMCA takedown notice: krav til anmeldelsen, filer og linjenumre, forks, open source-licenser og offentliggørelse.
- GitHub: DMCA Takedown Policy: fristen for brugeren, deaktivering af hele repositorier, forks, modmeddelelser og offentliggørelse i github/dmca.
- Ophavsretsloven, LBK nr. 1093 af 20. august 2023: § 1, stk. 3, om edb-programmer som litterære værker.
Senest gennemgået: november 2026.
Næste skridt
- Open source-licenser, når koden er brugt uden at følge vilkårene
- Sådan sammenligner en IT-sagkyndig to programmer
Del af: Artikler om kopiering og ophavsret
Læs også: Software og kildekode · Jeres app er kopieret i en appbutik
→ Kontakt · Tlf. 70 13 63 23 · Bevissikring ved kopiering hos Nielco IT
