Oracle v. Google: Federal Circuit tilkjenner funksjonelt opphavsrettslig vern for Javas APIer

Den 9.5.2014 avsa Federal Circuit dom i Oracle v. Google. Saken omhandlet spørsmålet om Google gjennom operativsystemet Android hadde gjort inngrep i opphavsretten til en rekke av APIer knyttet til Oracles programmeringsspråk Java. Federal Circuit behandlet bare spørsmålet om Javas APIer var opphavsrettslig beskyttet (og ikke spørsmålet om inngrep), og kom til at dette var tilfellet.

Sun Microsystems, som senere ble kjøpt opp av Oracle, offentliggjorde i 1996 programmerings­platformen Java. Denne platformen og det til­hørende programmerings­språket med samme navn, tillater brukerne å skrive "platform­uavhengige" pro­grammer, som kan kjøres på eks­empel­­vis flere for­skjellige operativ­systemer uten at man behøver å skrive programmet på nytt for hver plat­form. Dette kommer til uttrykk i Javas slagord "Write once, run anywhere".

Data­maskin­programmer skrives i kilde­kode, som normalt sett kompileres til maskin­kode som deretter kjøres på maskinen. Programmer skrevet i Java kompileres derimot først til byte­kode, en mellom­ting mellom kilde­kode og maskin­kode, som deretter inter­preteres fort­løpende på en virtual machine, som er til­passet den enkelte platformen. Dette kan illustreres som vist til høyre.

Javas APIer er en del av disse virtuelle maskinene. API er en forkortelse for "Application Pro­gramm­ing Interface", og betegner et grense­snitt i en program­vare som gjør at spesifikke deler av denne kan kjøres fra annen programvare. Noe forenklet kan man sammenligne en API med utformingen av en stikkontakt, hvor alle ledninger som skal kobles til denne må ha et plugg som er utformet til å passe i stikkontakten.

Javas APIer  definerer klasser av funksjoner (metoder), som er organisert i "pakker" i form av en rekke APIer. Sun utviklet frem til 2008 i alt 166 slike APIer. Hver API besto av to typer kildekode: (1) "declaring code", som identifiserer de forhåndsdefinerte klassene og metodene på en presis måte, og (2) "implementing code", som implementerer den konkrete funksjonen APIen tilbyr, for eksempel for å lese og skrive filer i zip-formatet (java.util.zip).

Google forhandlet i 2005 med Sun om å anvende Java-platformen i sitt operativsystem for mobile platformer (mobiltelefoner og nettbrett) - Android - og gi Google lisens til å bruke Javas APIer. Forhandlingene brøt imidlertid sammen da Google ikke ville gjøre  implementeringen av sine programmer for Android kompatible med Javas virtual machine, noe Sun anså å være i strid med grunnfilosofien om "write once, run anywhere".

Google utformet deretter sin egen virtual machine tilpasset Android ("the Dalvik virtual machine"). Formålet med dette var å utforme en platform der tredjepartsprogrammerere som var kjente med Java, lett kunne skrive progragmmer for Android. I denne prosessen kopierte Google ordrett "declaring code" fra 37 av Javas APIer. I tillegg til kopiering av den skrevne koden, innebar dette også at Google kopierte den underliggende strukturen og organiseringen av klassene og metodene i APIene. Google skrev imidlertid sin egen "implementing code" for alle de 37 APIene (med unntak av Oracles rangeCheck-funksjon (som besto av ni linjer kode) og åtte dekompilerte sikkerhetsfiler).

Juryen som behandlet saken i første instans, kom, under forutsetning av at APIene hadde opphavsrettsbeskyttelse, til at Googles bruk av disse innebar et inngrep i Oracles opphavsrett. Juryen kom imidlertid ikke til enighet om spørsmålet om Googles bruk av APIene utgjorde fair use. Spørsmålet om APIene i det hele tatt var beskyttet av opphavsretten ble deretter behandlet av Northern District of California, som kom til at de 37 APIene, i form av både den skrevne "declaring code" og strukturen og organiseringen av funksjonene i denne, ikke var opphavsrettslig vernet. 

Saken ble anket, og Federal Circuit kom til at både den skrevne koden og de underliggende strukturene denne ga uttrykk for, var opphavsrettslig beskyttet.

Google og Oracle var enige om at den skrevne "declaring code" oppfylte kravet til originalitet. District Court hadde imidlertid, på bakgrunn av den såkalte merger doctrine, lagt til grunn at den skrevne koden måtte anses som en idé som ikke hadde opphavsrettsbeskyttelse. Merger doctrine angir at det i de tilfeller det bare er et begrenset antall måter å uttrykke en idé på, smelter denne sammen ("merges") med det konkrete uttrykket, hvorpå dette uttrykket anses å være unntatt fra opphavsrettsbeskyttelse. For datamaskinprogrammer innebærer dette at "when specific [parts of the code], even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to infringement".

District Court la til grunn at deklareringen av metodene i "declaring code" måtte anses som APIenes underliggende idé, mens måten disse ble skrevet på ble ansett som APIenes uttrykk. (s. 29). Da District Court la til grunn at det bare var én måte å skrive disse metodene på, ga den skrevne kildekoden bare uttrykk for en ídé som var unntatt fra opphavsrettsbeskyttelse.

Federal Circuit la derimot til grunn at Sun på tidspunktet da APIene ble skrevet, hadde et ubegrenset antall valgmuligheter med hensyn til hvordan de konkrete funksjonene skulle uttrykkes i kildekode innenfor rammene av Java som programmeringsspråk. (s. 30) Det var for eksempel ingenting i veien for at klassen "java.lang.math.max" kunne kalles "Math.maximum" eller "Arith.larger". Det forelå da ingen sammensmelting mellom ideen bak programmet og det skrevne uttrykket i form av kildekoden, som kunne frata denne opphavsrettsbeskyttelse.

Federal Circuit avviste videre District Courts argument om at "[w]ords and short phrases such as names, titles and slogans ... are not subject to copyright protection", og at dette gjorde at kildekoden som var skrevet med slike korte fraser var unntatt fra opphavsrettsbeskyttelse. (s. 33-35)

Federal Circuit avviste til sist Googles argument om at den skrevne koden i Javas APIer måtte anses unntatt fra opphavsrettsbeskyttelse etter den såkalte scenes a faire doctrine, fordi "programmers have become accustomed to and comfortable using the groupings in the Java API packages, those groupings are so commonplace as to be indispensable to the expression of an acceptable programming platform". (s. 36-37) Googles kopiering av den skrevne "declaring code" ble derfor ansett som et opphavsrettsinngrep.

Federal Circuit la til grunn at opphavsretten til datamaskinprogrammers understruktur måtte vurderes på bakgrunn av den såkalte "abstraction-filtration-comparison" test slik denne hadde kommet til uttrykk blant annet i Computer Associates Inc v. Altai (2nd Cir. 1992) og Sega Enters. Ltd. v. Accolade, Inc. (9th Cir. 1992). (s. 23-25) Denne består av tre trinn, der man på det første trinnet – «abstraction» – deler programmets kildekode analytisk inn i enkelte strukturelle elementer på ulike abstraksjonsnivåer. Deretter foretas en «filtration» av alle de elementer som ikke har opphavs rettslig beskyttelse. Dette innebærer en utskilling av idéer og elementer uten verkshøyde. Til sist foretas en «comparison» – en sammenligning mellom det vernede programmet og programmet det påstås at det er gjort inngrep i, for å fastslå om det er tilstrekkelig likhet mellom de vernede elementene og de gjengitte elementene.

District Court hadde lagt til grunn at APIenes understrukturer var original. Strukturene var imidlertid funksjonelle, og måtte derfor utelukkes fra opphavsrettsbeskyttelse som "[a] system or method of operation" etter den amerikanske opphavsrettsloven § 102 (b). (s. 37-38) 

Federal Circuit la til grunn at dette resonnementet ville innebære at funksjonelle elementer var fullstendig unntatt fra opphavsrettsbeskyttelse, noe som var i strid med "abstraction-filtrarion-comparison" test.  (s 40) Datamaskinprogrammer er per definisjon funksjonelle i den forstand at de er skrevet for å utføre en bestemt funksjon. Etter District Courts argumentasjon ville derfor datamaskinprogrammer være utelukket fra opphavsrettsbeskyttelse. Federal Circuit la derfor til grunn at den amerikanske opphavsrettsloven § 102 ikke utelukket APIene fra opphavsrettsbeskyttelse bare fordi de utførte funksjoner.

Google hadde videre argumenter med at Java hadde utviklet seg til en form for bransjestandard, og at hensynet til interoperabilitet tilsa at Javas APIer måtte kunne kopieres i den grad dette var nødvendig for å oppnå slik interoparabilitet. Dette argumentet ble imidlertid bare ansett relevant for spørsmålet om Googles bruk av Oracles APIer utgjorde fair use. Da Federal Circuit ikke hadde tilstrekkelige opplysninger for å ta stilling til dette, ble spørsmålet imidlertid henvist tilbake til District Court for videre behandling. 

Immaterialrettstrollets betraktninger

Avgjørelsen er problematisk, fordi den underspiller betydningen APIer har som grensesnitt for å sikre interoperabilitet mellom datamaskinprogrammer. Et for sterkt opphavsrettsvern av slike grensesnitt vil ikke bare innebære et vern av et opphavsrettslig beskyttede datamaskinprogrammer, men også begrense mulighetene for å skrive programmer som er kompatible med slike programmer.

Federal Circuit betrakter derimot Javas APIer som et hvilket som helst datamaskinprogram, noe som innebærer at kildekoden, og til en viss grad også de underliggende strukturene denne gir uttrykk for, er opphavsrettslig beskyttet. Kopiering av koden vil da innebære et inngrep i opphavsretten. Google vil riktignok kunne benytte en lignende struktur, forutsatt at de skriver sin egen kode som uttrykker denne strukturen. Forutsetningen for å oppnå interoperabilitet er imidlertid ikke bare at man benytter en lignende struktur, men også at man kopierer den underliggende kildekoden og de konkrete funksjonene som kommer til uttrykk i denne. Spørsmålet om interoperabilitet overlates med Federal Circuits avgjørelse til den mer skjønnsmessige vurderingen om Googles bruk av Javas APIer utgjør "fair use".

På bakgrunn av amerikansk praksis om opphavsretten til datamaskinprogrammer er det riktignok vanskelig å komme unna konklusjonen om at Oracles kode er opphavsrettslig beskyttet. Som enkelte kommentarer påpeker, hadde en mulighet muligens vært å anerkjenne opphavsrett for kildekoden og den underliggende strukturen til Javas APIer, men likevel ikke anse Googles bruk av kildekoden som et inngrep i opphavsretten, fordi denne bruken var nødvendig for å oppnå interoperabilitet.

Google vil trolig anke avgjørelsen inn for Federal Circuit i plenum eller videre inn for Supreme Court. Disse vil forhåpentligvis ta større hensyn til den betydning APIer har for interoperabilitet mellom programmer.