Hvad er ophavsretskrænkelser relateret til programmering?

Når man hører udtrykket “ophavsretsspørgsmål”, kan mange først og fremmest tænke på sager som plagiering af logo- og karakterdesign, som designere har arbejdet på. Men faktisk behandles koden, som ingeniører skriver, også som “værker” i henhold til loven, og ophavsretten anerkendes.

Samtidig er det dog sjældent, at ingeniører og programmører kan udvise originalitet natten over. Ofte er det kun ved at lære meget fra koden, som andre har tænkt igennem og skabt, at de selv kan producere produktive output.

I denne artikel vil vi forklare, hvordan man kan trække linjen mellem “at referere til” og “at plagiere” program- og kildekode som værker.

Hvordan er systemudvikling og ophavsret relateret?

Hvad beskytter ophavsretten, og hvad beskytter den ikke?

Først og fremmest, hvad er ophavsret, og hvad er det for? Svaret er faktisk skrevet i ophavsretten selv. I den første artikel af ophavsretten, er dens eksistensgrundlag som følger beskrevet (forfatteren har tilføjet understregning):

Artikel 1: Denne lov fastlægger ophavsrettigheder og rettigheder, der er tilstødende til disse, med hensyn til værker samt præstationer, optagelser, udsendelser og kabeludsendelser, og sigter mod at beskytte ophavsrettigheder og bidrage til udviklingen af kulturen ved at være opmærksom på retfærdig brug af disse kulturelle produkter.

Ophavsretslovens artikel 1

Det vil sige, det er et område, der behandler spørgsmålet om, hvordan man beskytter individets rettigheder som ophavsretshaver, og hvordan man forbinder det med samfundets samlede fordele og bringer harmoni til tingene.

Hvis vi taler om, hvad der er omfattet af ophavsretten i lovens forstand, er der eksempler i paragraf 10, stk. 1, som citeres nedenfor.

Eksempler på værker i denne lov er generelt som følger:

1. Romaner, manuskripter, afhandlinger, taler og andre sprogværker
2. Musikværker
3. Dans eller pantomimeværker
4. Malerier, tryk, skulpturer og andre kunstværker
5. Arkitektoniske værker
6. Kort eller videnskabelige tegninger, diagrammer, modeller og andre grafiske værker
7. Filmværker
8. Fotografiske værker
9. Programværker

Ophavsretslovens artikel 10, stk. 1

I samme paragraf, punkt 9, er det klart angivet, at “programværker” også er omfattet. Det vil sige, ophavsretten gælder også for kildekode. Disse er kun “eksempler”, så det er ikke kun de ting, der er inkluderet her, der er omfattet af loven. Men det er klart, at programmer i det mindste helt sikkert er inden for lovens rækkevidde.

Den faktiske betydning af, at ophavsretten er anerkendt, hvis vi skal forklare det så kortfattet som muligt i konteksten af programmering, er, at kun en bestemt rettighedshaver kan eksklusivt bruge værket i forhold til ting som kopiering (samme lov, artikel 21), offentlig transmission via internettet (samme lov, artikel 23, punkt 1), overførsel (samme lov, artikel 27). Desuden, hvis ophavsretten krænkes, kan rettighedshaveren anmode om en injunktion (ophavsretslovens artikel 112, stk. 1) eller erstatning baseret på erstatningsansvar for ulovlige handlinger (civilretten, artikel 709) som en civilretlig foranstaltning.

Men som nævnt ovenfor er ophavsretten et juridisk område, der sigter mod at balancere to værdier: beskyttelse af individuelle rettighedshavere og fordele set fra et samfundsmæssigt perspektiv. Derfor bør du også kende til “tilfælde, hvor ophavsretten ikke gælder”.

For eksempel, hvis en person, der ikke har ophavsretten til et eksisterende program, blot udfører programmet som en bruger, vil det i princippet ikke være en krænkelse af ophavsretten (ophavsretslovens artikel 47, stk. 8). Desuden, hvis det er inden for rammerne af privat brug, vil det ikke være ulovligt at kopiere eller tilpasse det (ophavsretslovens artikel 47, stk. 3).

Selvom det er vigtigt at beskytte rettighedshaverens position, er det også “kultur” at skabe nye værker inspireret af andres værker og bygge på det. Man kan sige, at det er et juridisk område, der har fortsat at udvikle sig, mens det har problemet med forskellen mellem “at stjæle” og “at referere til” ved roden.

Hvorfor er ophavsret vigtig i systemudviklingsjura?

I arbejde som IT-systemudvikling og programimplementering har der faktisk været sager, hvor spørgsmålet om ophavsretskrænkelse er blevet diskuteret. Det er en strid om, hvorvidt to “meget lignende” programmer “bare refererede til” eller “stjal det oprindelige program”. For eksempel, lad os sige, at en medarbejder, der oprindeligt arbejdede i et systemudviklingsfirma, implementerede et “meget lignende” andet program og gjorde det til et produkt efter at være blevet uafhængig. I sådanne tilfælde er det meget muligt, at leverandørvirksomheden, der er den tidligere arbejdsgiver, vil gøre krav på rettigheder.

Desuden indebærer det faktum, at sådanne konflikter kan opstå, alvorlige risici, ikke kun for den “stjålne” side, men også for den side, der “bliver beskyldt for at stjæle”. Den største risiko i dette tilfælde er, at retten til at anmode om en injunktion kan blive brugt som et forhandlingskort.

Den største grund til, at “ophavsret” er en “stærk ret”, er, at den såkaldte “ret til at anmode om en injunktion” er anerkendt.

Ophavsmanden, ophavsretshaveren, udgiveren, udøveren eller indehaveren af de tilstødende rettigheder kan anmode om ophør eller forebyggelse af krænkelse over for den person, der krænker eller er i fare for at krænke hans ophavsret, ophavsret, udgivelsesret, udøverens personlige rettigheder eller de tilstødende rettigheder.

Ophavsretslovens artikel 112

Den person, der har lidt skade på grund af ophavsretskrænkelse, kan anmode om, at den person, der begår krænkelsen, “stopper” det. Det vil sige, for eksempel, hvis et server-side program, der er i drift, falder ind under ophavsretskrænkelse, kan man anmode om at stoppe serveren, det vil sige at stoppe tjenesten.

Lad os sige, at du får en forhandling om, at “vi vil lade dig fortsætte med at bruge tjenesten i stedet for at stoppe den, men vi vil gerne have dig til at betale brugsgebyret”. I dette tilfælde er der en risiko for, at du kan blive præsenteret for en prisforhandling, der er irrelevant for markedsprisen, på grund af “svagheden” i, at du overtræder ophavsretten. Selv for en ingeniør, der ikke har nogen ond hensigt som at lave en piratkopi, er det på en måde “farligt” at være ligeglad med ophavsretsspørgsmål.

Hvor meget skal et program ligne for at overtræde ophavsretten?

Så hvordan afgøres det i praksis, om der er tale om en overtrædelse af ophavsretten? Lad os se på tidligere domme og retssager.

Domme og retssager, hvor overtrædelse af ophavsretten til et program blev bestridt

I den retssag, der citeres nedenfor, blev det bestridt, om en tidligere medarbejder havde overtrådt ophavsretten til software, han havde udviklet i sit nye job. Resultatet var, at overtrædelsen af ophavsretten blev anerkendt.

Når man sammenligner de ovennævnte 35 sagsøgerfiler med de tilsvarende 36 sagsøgte filer, er koden i de dele, der er markeret med gul (gule markerede dele), fuldstændig identisk. Desuden er de dele, der er markeret med grøn i de ovennævnte beviser (grønne markerede dele), selvom der er forskelle i virksomhedsnavne, variabelnavne, formnavne osv., er de i funktionelle termer for programmet, uden betydning for navneforskellene, og kan i det væsentlige betragtes som den samme kildekode.
Disse gule markerede dele og grønne markerede dele udgør størstedelen af de ovennævnte sagsøgerfiler og sagsøgte filer, og deres andel er ikke mindre end 90% af det samlede antal.

Tokyo District Court, May 26, 2011 (Heisei 23)

Den ovennævnte domstolsafgørelse sigter mod at træffe en beslutning baseret på formålet med ophavsretsloven, ved at gennemgå, om de matchende dele er kreative, samtidig med at der træffes en beslutning baseret på en høj objektiv værdi, såsom matchprocenten.

Den juridiske standard for at afgøre ophavsretskrænkelser

Når man afgør, om et program overtræder ophavsretten i forhold til et andet program, skal man kontrollere følgende punkter.

Hvor meget af det, der matcher (eller ligner), og hvilken andel det udgør

Hvis man ser på disse objektive numeriske indikatorer, kan man sige, at jo højere ligheden er, jo lettere er det at anerkende en overtrædelse af ophavsretten. Objektive sammenligninger og verifikationer, såsom antallet af matchende linjer og tegn, menes at være værdsat i tidligere retssager.

Hvor kreativ er den del, der matcher (eller ligner)?

Hvis den ovennævnte indikator er “form”, kan dette betragtes som “substans”, der tager hensyn til formålet med ophavsretsloven. Det vil sige, selv i de dele, der formelt matcher, vil der blive foretaget en undersøgelse fra synspunktet “om det er et sted, hvor andre udtryksmetoder kan anvendes”. For eksempel, hvis der ikke er nogen realistisk implementeringsmetode ud over at bruge en generisk bibliotek eller funktion, bør det betragtes som blot at have vedtaget en almindelig udtryksmetode individuelt.

Med andre ord, hvis det kun er forskellen i navnerummet (navne på variabler, konstanter, funktioner osv.) der er ændret, er det svært at sige, at det faktisk reducerer ligheden mellem programmerne. Fordi kreativiteten i en programmørs arbejde ikke udtrykkes gennem brugen af sådanne navnerum.

Desuden, hvis der er steder, hvor fejl opstår, og det ikke kan forklares, medmindre man antager, at det hele er “plagieret”, kan det også være en faktor, der understøtter en overtrædelse af ophavsretten.

Punkter at være opmærksom på, når du kæmper for ophavsretskrænkelse i retten

Herunder har vi samlet nogle punkter, du bør være opmærksom på, når du kæmper for ophavsretskrænkelse af et program i retten.

Hvis koden ikke kan opnås, kan det ofte være svært at bevise

Som vi tidligere har nævnt i retssager, er det nødvendigt at sammenligne den faktiske kode, når du hævder ophavsretskrænkelse af et program. Men hvis den anden part nægter at afsløre kildekoden, kan det være svært at bevare beviserne. Derfor, når du kæmper for ophavsretskrænkelse i retten, er det ofte vigtigt at vide, hvordan du skal samle fakta om skaden, hvordan du skal registrere forløbet af tidligere forhandlinger, og hvordan du skal argumentere for behovet for bevisbevarelse, dvs. viden om civilretssager.

Ophavsretten gælder ikke for abstrakte ideer

Paragraf 10, stk. 3 i den japanske ophavsretslov (Copyright Law) indeholder følgende bestemmelse:

3 Beskyttelsen i henhold til denne lov for de værker, der er nævnt i punkt 9 i stk. 1, gælder ikke for det programmeringssprog, regler og løsningsmetoder, der bruges til at skabe værket. I denne forbindelse skal betydningen af disse udtryk bestemmes i henhold til følgende punkter:
1 Programmeringssprog: Tegn og andre symboler og deres systemer, der bruges til at udtrykke et program.
2 Regler: Specielle aftaler om brugen af det programmeringssprog, der er nævnt i det foregående punkt, i et bestemt program.
3 Løsningsmetoder: Metoder til kombination af instruktioner til en elektronisk computer i et program.

Paragraf 10, stk. 3 i den japanske ophavsretslov (Copyright Law)

Med andre ord, ophavsretten gælder ikke for “procedurer”, dvs. hvordan ting behandles, eller “rammer og organisering af opgaver”, såsom mappestruktur. Hvis private monopolrettigheder skulle strække sig til sådanne ting, ville ophavsretten ikke kunne bidrage til “udviklingen af kultur”. Programmeringssprog og algoritmer er mere abstrakte ideer end værker, og ophavsretten gælder ikke for dem. Det er også godt at vide, at da der ikke er nogen ophavsret, kan der heller ikke være nogen “ophavsretskrænkelse” over for dem.

Opsummering

I IT-branchen er der en kompleksitet i diskussionen om forskellen mellem “at tage som reference” og “at plagiere”. Dette kræver en rigdom af perspektiver og en multifacetteret tilgang. Det er selvfølgelig nødvendigt med en videnskabelig holdning, hvor man sammenligner og verificerer begge for at bestemme den objektive lighed. Men diskussionen inkluderer også spørgsmålet om, hvad det betyder at være kreativ, baseret på essensen af den japanske ophavsretslov (“Japansk Copyright Law”).

Kun med en holdning, der tager højde for både form og substans, kan loven måske bidrage til værdien af “kulturel udvikling” i netop disse felter og brancher.