Når man hører om “opphavsrettsproblemer”, tenker mange kanskje først og fremst på saker om plagiat av logo- eller karakterdesign laget av designere. Men faktisk er også koden som ingeniører skriver, juridisk sett behandlet som “opphavsrettsbeskyttet verk” og er underlagt opphavsrett.
Samtidig er det slik at ingeniører og programmerere sjelden kan utvise originalitet over natten. Ofte blir de produktive først etter å ha lært mye fra koden som andre har tenkt nøye gjennom og utviklet.
I denne artikkelen forklarer vi hvordan man kan skille mellom å “referere til” og å “plagiere” programvarekildekode som et opphavsrettsbeskyttet verk.
Hvordan henger systemutvikling og opphavsrett sammen?
Hva beskytter opphavsrettsloven, og hva beskytter den ikke?
Hva er egentlig opphavsrettsloven, og hvorfor eksisterer den? Svaret på dette finnes faktisk i selve loven. I den første paragrafen av opphavsrettsloven står det som følger (understreking er lagt til av forfatteren):
§ 1. Denne loven fastsetter opphavsmannens rettigheter og tilgrensende rettigheter i forbindelse med verk, fremføringer, lydopptak, kringkasting og kabelsending, og har som mål å beskytte opphavsmannens rettigheter og bidra til kulturens utvikling ved å sikre rettferdig bruk av disse kulturelle produktene.
Japansk opphavsrettslov § 1
Med andre ord, opphavsrettsloven beskytter individuelle rettigheter som opphavsrettsinnehaver, samtidig som den tar sikte på å balansere disse rettighetene med samfunnets samlede interesser for å fremme harmoni.
Når det gjelder hva som dekkes av opphavsretten, gir § 10, første ledd, en eksemplifisering:
Eksempler på verk som omfattes av denne loven er som følger:
1. Romaner, manuskripter, avhandlinger, foredrag og andre språklige verk 2. Musikalske verk 3. Danse- eller pantomimeverk 4. Malerier, trykk, skulpturer og andre kunstverk 5. Arkitektoniske verk 6. Kart eller vitenskapelige tegninger, diagrammer, modeller og andre grafiske verk 7. Filmverk 8. Fotografiske verk 9. Programvareverk
Japansk opphavsrettslov § 10, første ledd
Som det fremgår av punkt 9, er “programvareverk” tydelig inkludert. Dette betyr at opphavsrettsloven også gjelder for kildekode. Selv om listen kun er eksempler, er det klart at programvare faller innenfor lovens rekkevidde.
Den praktiske betydningen av at opphavsrett er anerkjent, kan forklares kortfattet i konteksten av programvare. Kun spesifikke rettighetshavere har enerett til å bruke verket i forbindelse med reproduksjon (Japansk opphavsrettslov § 21), offentlig overføring via nettverk (Japansk opphavsrettslov § 23, første ledd), og overdragelse (Japansk opphavsrettslov § 27). Ved brudd på opphavsretten kan rettighetshaveren søke sivile tiltak som forbud (Japansk opphavsrettslov § 112, første ledd) og erstatningskrav basert på ulovlig handling (Japansk sivilrett § 709).
Som nevnt tidligere, tar opphavsrettsloven sikte på å balansere individuelle rettigheter med samfunnets samlede interesser. Derfor er det viktig å også forstå situasjoner hvor opphavsretten ikke gjelder.
For eksempel, hvis en bruker uten opphavsrett til et eksisterende program kjører programmet, anses dette i prinsippet ikke som et brudd på opphavsretten (Japansk opphavsrettslov § 47-8). Videre er reproduksjon og tilpasning tillatt innenfor rammen av privat bruk (Japansk opphavsrettslov § 47-3).
Selv om det er viktig å beskytte rettighetshaverens posisjon, er det også viktig å anerkjenne at kultur ofte utvikles gjennom inspirasjon fra andres verk. Opphavsrettsloven har utviklet seg med dette i tankene, og balanserer mellom “plagiat” og “inspirasjon”.
Hvorfor er opphavsrettsloven viktig i systemutviklingsjuss?
Innen IT-systemutvikling og programvareimplementering har det vært tilfeller hvor opphavsrettsbrudd har blitt diskutert. Tvister kan oppstå om hvorvidt to “lignende” programmer er resultatet av inspirasjon eller plagiat. For eksempel kan en tidligere ansatt i et systemutviklingsselskap, etter å ha startet for seg selv, utvikle et “lignende” program. Dette kan føre til at det tidligere selskapet hevder rettigheter til programmet.
Slike tvister kan være alvorlige risikoer, ikke bare for den som hevder å ha blitt plagiert, men også for den som blir anklaget for plagiat. En av de største risikoene er at motparten kan true med å bruke forbudskrav i forhandlinger.
Grunnen til at opphavsrett anses som en “sterk rettighet” er nettopp fordi forbudskrav er anerkjent.
Opphavsmannen, opphavsrettsinnehaveren, utgiveren, utøveren eller innehaveren av tilgrensende rettigheter kan kreve at den som krenker eller truer med å krenke deres rettigheter, stopper eller forhindrer krenkelsen.
Japansk opphavsrettslov § 112
Den som har blitt utsatt for opphavsrettsbrudd kan kreve at krenkelsen stoppes. For eksempel, hvis et server-side program som er i drift krenker opphavsretten, kan man kreve at serveren stoppes, noe som betyr at tjenesten må stanses.
Hvis en tjeneste som genererer inntekter blir truet med stans, kan man bli tvunget til å forhandle om lisensavgifter. Dette kan føre til at man må akseptere urettferdige vilkår på grunn av svakheten ved å ha krenket opphavsretten. Selv uten onde hensikter, kan det være “farlig” for en ingeniør å være uvitende om opphavsrettsproblematikk.
Hvor likt må et program være for å utgjøre et brudd på opphavsretten?
Så hvordan avgjøres det juridisk om det foreligger et brudd på opphavsretten? La oss se på tidligere rettsavgjørelser og dommer.
Rettsavgjørelser og dommer om opphavsrettsbrudd på programvare
I den følgende rettsavgjørelsen ble det diskutert om en tidligere ansatt hadde brutt opphavsretten ved å utvikle programvare hos sin nye arbeidsgiver. Resultatet var at opphavsrettsbruddet ble anerkjent.
Ved å sammenligne de 35 filene fra saksøker med de 36 filene fra saksøkte, (utdrag) er de gule markerte delene i koden helt identiske. De grønne markerte delene, selv om de har forskjellige firmanavn, variabelnavn og formnavn, er funksjonelt sett uten betydning og kan betraktes som identisk kildekode. Disse gule og grønne markerte delene utgjør størstedelen av både saksøkers og saksøktes filer, og utgjør ikke mindre enn 90 % av det totale innholdet.
Tokyo District Court, 26. mai Heisei 23 (2011)
Den ovennevnte dommen baserer seg på en objektiv vurdering av høy samsvarsprosent, samtidig som den vurderer om de samsvarende delene er kreative uttrykk, for å ta en beslutning i tråd med formålet med den japanske opphavsrettsloven.
Juridiske kriterier for å vurdere opphavsrettsbrudd
For å avgjøre om et program utgjør et brudd på opphavsretten i forhold til et annet program, må følgende punkter vurderes:
Hvor mye og i hvilken grad samsvarer (eller ligner) de aktuelle delene?
Jo høyere grad av objektiv likhet, desto mer sannsynlig er det at opphavsrettsbrudd vil bli anerkjent. Objektive sammenligninger som antall linjer eller tegn som samsvarer, har også blitt vektlagt i tidligere rettssaker.
Hvor kreative er de samsvarende (eller lignende) delene?
Hvis den forrige indikatoren er “formell”, kan denne betraktes som “substantiv” i lys av den japanske opphavsrettslovens betydning. Det vil si at man også vurderer om de formelt samsvarende delene kunne vært uttrykt på andre måter. For eksempel, hvis det ikke er noen realistisk måte å implementere en funksjon på uten å bruke en generisk bibliotek eller funksjon, bør dette betraktes som en vanlig uttrykksmåte.
Med andre ord, hvis bare navneområdet (variabel- eller konstantnavn, funksjonsnavn osv.) er endret, er det vanskelig å hevde at dette reduserer den reelle likheten mellom programmene. Programmererens kreativitet kommer ikke til uttrykk gjennom slike navneendringer.
Videre, hvis det er deler av koden hvor feil oppstår som ikke kan forklares uten å anta “plagiat”, kan dette også være en faktor som støtter opphavsrettsbrudd.
Viktige punkter å merke seg når man bestrider brudd på opphavsrett i retten
Her er noen viktige punkter å merke seg når man bestrider brudd på opphavsrett for programmer i retten.
Det kan være vanskelig å bevise uten tilgang til koden
Som nevnt i tidligere rettsavgjørelser, er det nødvendig å sammenligne den faktiske koden når man påstår brudd på opphavsrett for programmer. Men hvis motparten nekter å avsløre kildekoden, kan det bli vanskelig å sikre bevis. Derfor er det viktig å ha kunnskap om sivilprosess, inkludert hvordan man dokumenterer skadefakta, registrerer tidligere forhandlinger, og argumenterer for nødvendigheten av bevisbeslag når man bestrider brudd på opphavsrett i retten.
Opphavsrett gjelder ikke for abstrakte ideer
Artikkel 10, paragraf 3 i den japanske opphavsrettsloven (1970) har følgende bestemmelse:
3. Beskyttelsen gitt av denne loven til verkene nevnt i første ledd, niende punkt, gjelder ikke for programmeringsspråk, konvensjoner og løsninger som brukes til å lage disse verkene. I dette tilfellet skal betydningen av disse termene være som definert i følgende punkter: 1. Programmeringsspråk: Tegn og systemer som brukes som midler til å uttrykke programmer. 2. Konvensjoner: Spesielle avtaler om bruken av programmeringsspråk i spesifikke programmer. 3. Løsninger: Metoder for å kombinere kommandoer til datamaskiner i programmer.
Japansk opphavsrettslov, artikkel 10, paragraf 3 (1970)
Med andre ord, opphavsrett gjelder ikke for “prosedyrer” for hvordan man utfører oppgaver eller “rammeverk og organisering av problemer” som mappestrukturer. Hvis private monopoler skulle omfatte slike ting, ville opphavsrettsloven ikke kunne bidra til “kulturell utvikling”. Programmeringsspråk og algoritmer er abstrakte ideer, ikke verk, og opphavsrett gjelder ikke for dem. Derfor er det også viktig å vite at det ikke kan være noe “brudd på opphavsrett” for disse elementene.
Oppsummering
Diskusjonen om forskjellen mellom “å referere til” og “å plagiere” i IT-bransjen krever rikelig med perspektiver og en flerdimensjonal tilnærming. Her er det nødvendig med en vitenskapelig holdning for å sammenligne og undersøke begge sider for å avgjøre objektiv likhet. I tillegg må man inkludere diskusjoner om hva det vil si å være kreativ, med utgangspunkt i essensen av den japanske opphavsrettsloven.
Kun ved å bygge argumenter basert på både form og substans kan loven bidra til verdien av “kulturell utvikling” i nettopp slike felt og bransjer.
An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.