EU-domstolen i C‑13/20 Top System: Datamaskinprogrammer kan dekompileres for å rette feil i programmet

EU-domstolen avsa 6.10.21 dom i C‑13/20 Top System. Det ble her lagt til grunn at retten til dekompilering av et datamaskinprogram ikke er begrenset til tilfeller hvor formålet er å oppnå interoperabilitet etter programvaredirektivet artikkel 6 (åvl. § 42), men også kan gjøres for å rette feil i programmet etter artikkel 5 (åvl. § 41 første ledd). Dekompilering etter artikkel 5 er imidlertid begrenset til tilfeller hvor dekompilering er nødvendig for å rette feil i programmet. 

Sakens bakgrunn

Det gamle programvaredirektivet (91 /250/EØF) artikkel 5 (åvl. § 41 første ledd) gir rettmessig bruker av et datamaskinprogram rett til å fremstille eksemplar av programmet og endre dette for å bruke programmet i samsvar med formålet. Dette omfatter også rett til å rette feil i programmet. Direktiv 91/250/EØF er senere erstattet av et nytt programvaredirektiv (2009/24/EF), men de relevante bestemmelsene er uendret.

Foto: Pixabay

Datamaskinprogrammer som er klare til å kjøres på en datamaskin er imidlertid skrevet i såkalt maskinkode («0» og «1»). For å endre programmet for å rette feil i dette må man i praksis ha tilgang til programmets kildekode, som i praksis ikke gjøres tilgjengelig for kommersielle programmer. Det er imidlertid til en viss grad mulig å reversere prosessen hvor kildekoden oversettes til maskinkode gjennom en prosess med såkalt «dekompilering». Dette gjør det mulig å endre programmet, blant annet for å rette feil.

 

Slik dekompilering innebærer imidlertid at det fremstilles eksemplar av programmet i endret form. Opphaver har enerett til å fremstille varige og midlertidige eksemplar av et datamaskinprogram etter programvaredirektivet artikkel 4 nr. 1 og enerett til å oversette og bearbeide programmet etter artikkel 4 nr. 2. Slik dekompilering krever derfor samtykke fra opphaver eller et annet rettslig grunnlag. 

 

Programvaredirektivet artikkel 6, som er gjennomført i åvl. 42, gir tillatelse til dekompilering, men bare for å oppnå interoperabilitet med andre programmer. Artikkel 5 nr. 1, som er gjennomført i åvl. § 41 første ledd, gir derimot tillatelse til å endre datamaskinprogrammet der dette er nødvendig for å bruke programmet i samsvar med formålet. Og denne retten til endring omfatter også feilretting.

 

Top System utviklet datamaskinprogrammer for Selor, et belgisk forvaltningsorgan. I 2008 inngikk Selor en avtale med Top System om utvikling av et nytt datasystem og integrering av Selors programmer i det nye systemet. Det oppsto problemer med det nye systemet, og Selor dekompilerte da deler av programmet for å kunne deaktivere enkelte funksjoner i dette. 

 

Top System anla sak med påstand om erstatning for opphavsrettsinngrep i programmet. Selor anførte at dekompileringen var lovlig i henhold til programvaredirektivet artikkel 6. Belgiske domstoler var imidlertid ikke overbevist om at artikkel 6 var anvendelig i saken. Og da saken sto for cour d’appel de Bruxelles ble det derfor stilt spørsmål til EU-domstolen om dekompilering også kan skje etter programvaredirektivet artikkel 5 og om slik dekompilering i så fall måtte skje med de begrensninger som følger av artikkel 6.

 

EU-domstolens avgjørelse 

EU-domstolen tok utgangspunkt i at enerettene til eksemplarfremstilling og bearbeidelse av et datamaskinprogram i artikkel 4 begrenses av artikkel 5, som gir rett til eksemplarfremstilling og bearbeidelser av et datamaskinprogram der dette er nødvendig for å bruke programmet i samsvar med formålet, inkludert for å rette feil i programmet (avsnitt 31). 

 

Eksempel på en dekompileringsprosess

Selv om dekompilering ikke er uttrykkelig nevnt blant enerettene i artikkel 4 eller i begrensningene i artikkel 5, er det likevel klart at dekompilering innebærer eksemplarfremstilling og endring av et datamaskinprogram som faller innenfor artikkel 4 og 5 (avsnitt 39­–41). Dette innebærer at rettmessig bruker av et datamaskinprogram kan dekompilere dette for å endre feil ved programmet som påvirker normal bruk av dette (avsnitt 42)

 

Dette endres ikke av at artikkel 6 gir en uttrykkelig rett til dekompilering for å oppnå interoperabilitet (avsnitt 43). Fortalen punkt 20 og 21 (2009/24/EF, punkt 15) angir riktignok at dekompilering etter artikkel 6 bare kan skje under «disse ganske bestemte omstændigheder» som angis i artikkelen. Lest i lys av fortalen punkt 19 og 20, er det imidlertid klart at disse begrensningene bare knytter seg til nødvendigheten av dekompilering for å oppå interoperabilitet (avsnitt 46). Dette støttes av at artikkel 6 nr. 2 og 3 forbyr bruk av informasjon man har fått gjennom dekompilering til andre formål (avsnitt 47). Artikkel 5 og 6 har dessuten ulike formål: Mens artikkel 6 har interoperabilitet som formål, har artikkel 5 som formål å muliggjøre rettmessig bruk av programmet (avsnitt 49).

 

For det andre fremgår det av forarbeidene til direktivet at formålet med forslaget til artikkel 6, uttrykkelig var å regulere interoperabilitet mellom programmer (avsnitt 50, jf. Generaladvokatens anbefaling avsnitt 59). 

 

For det tredje vil en forståelse av artikkel 5 som utelukker dekompilering, begrense den retten en rettmessig bruker av et datamaskinprogram er gitt til å rette feil i programmet etter artikkel 5 (avsnitt 51).

 

Programvaredirektivet artikkel 5 gir derfor rett til dekompilering av et datamaskinprogram dersom dette er nødvendig for å rette feil i programmet for å få dette til å fungere i samsvar med formålet.

 

Dette reiste spørsmål om dekompilering etter artikkel 5 forutsetter at begrensningene i retten til dekompilering i artikkel 6 oppfylles. Artikkel 6 nr. 1 og 2 (åvl. § 42) legger blant annet begrensninger på hvem som kan dekompilere programmet og hvordan de opplysningene som er hentet ut ved gjennom dekompilering kan utnyttes.

 

Dette besvares benektende av EU-domstolen. Artikkel 6 har et annet formål og rekkevidde enn artikkel 5 (avsnitt 55, jf. 49), og begrensningene som ligger i artikkel 6 får derfor ikke anvendelse ved dekompilering etter artikkel 5.

 

Artikkel 5 legger imidlertid selv begrensninger på når dekompilering kan skje og hva informasjonen man får gjennom dekompilering kan brukes til. For det første kan dekompilering etter artikkel 5 bare skje for å rette feil i programmet, ikke til andre formål (avsnitt 57) 

 

For det andre må dekompilering etter ordlyden i artikkel 5, være «nødvendig» for å rette feil som forhindrer bruk av programmet i samsvar med formålet (avsnitt 56-61).

 

For det tredje kan retten til å rette feil reguleres gjennom avtale. Rettighetshaver vil riktignok ikke kunne forby kjøring av programmet eller retting av feil gjennom avtale (avsnitt 65-66). Rettighetshaver vil derimot kunne regulere hvordan feilretting skjer gjennom avtale, for eksempel ved selv å tilby retting av feil, og dermed avskjære brukers rett til å dekompilere (avsnitt 67).

 

For det fjerde kan informasjon som er oppnådd gjennom dekompilering etter artikkel 5, ikke brukes til andre formål enn feilretting (avsnitt 69).

 

Immaterialrettstrollets betraktninger 

Foto: Pixabay

EU-domstolen bekrefter gjennom sin avgjørelse i C‑13/20 Top System at dekompilering etter programvaredirektivet ikke bare kan skje for å oppnå interoperabilitet, men også for å rette feil i programmet.

 

Dette har vært et omdiskutert spørsmål, og synspunktet har i stor grad vært at artikkel 5 ikke omfatter en rett til dekompilering (se, Rognstad 2019 s. 353 og Schønning 2016 s. 438, motsatt, Bjerke 1994 s. 100-101 og tilsynelatende, Walter og von Lewinsky 2010 s. 155 rn. 5.5.34).  Dette begrunnes i at artikkel 6 (§ 42) må anses som en spesialregulering av retten til dekompilering, og at artikkel 5 nr. 1 (§ 41 første ledd) må leses innskrenkende på bakgrunn av denne, slik at dekompilering bare kan skje etter artikkel 6.

 

EU-domstolen velger motsatt tilnærming: Det er det ingenting i artikkel 5 lest i sammenheng med artikkel 4, som tilsier en slik begrensning. Artikkel 6 stilling som spesialbestemmelse blir da snarere et argument for at artikkel 6 bare regulerer rett til dekompilering for å oppnå interoperabilitet og at dette taler for en rett til dekompilering også etter artikkel 5. Denne løsningen støttes også av hensynet til rettmessige brukere av datamaskinprogrammer, noe EU-domstolen også understreker i avsnitt 51.

 

Sentralt her er også at retten til feilretting ikke kan fraskrives ved avtale. Retten etter artikkel 5 gjelder bare «[m]edmindre andet udtrykkeligt er fastsat ved aftale» (åvl. § 41 første ledd er derfor også deklaratorisk, jf. femte ledd). Det følger likevel av fortalen til det gamle programvaredirektivet punkt 18 (2009/24/EF, punkt 13)  at «handlinger som indlæsning og kørsel, der er nødvendige for anvendelsen af en kopi af et program, som er lovligt erhvervet, herunder rettelse af fejl deri, ikke må forbydes ved aftale». EU-domstolen har tidligere slått fast at handlinger som knytter seg til innlasting og kjøring av programmet ikke kan fraskrives ved avtale (C‑406/10 SAS Institute, avsnitt 59). I Top System slås det nå uttrykkelig fast at dette også gjelder for retten til feilretting (avsnitt 66).

 

Retten til dekompilering for å rette feil etter programvaredirektivet artikkel 5 er imidlertid ikke ubegrenset. Den mest sentrale begrensingen her er at dekompilering må være «nødvendig». Brukeren har naturligvis ikke rett til dekompilering dersom han er gitt tilgang til kildekoden på annen måte (avsnitt 63). Nødvendighetskravet har også en side til formålet om retting av feil. EU-domstolen definerer i avsnitt 59 feil ved et datamaskinprogram som «en defekt, der påvirker et edb-program, og som er årsagen til, at edb-programmet fungerer forkert».

 

I den konkrete saken var det spørsmål om å deaktivere en funksjon i programmet som ikke fungerte, noe som ligger klart innenfor rammene for feilretting. Bruker må imidlertid også kunne gå lenger, og faktisk rette funksjoner i programmet som ikke fungerer. Men her vil det nok gå en grense mot utvikling av nye og forbedrede funksjoner.

 

Selv om rettighetshaver ikke kan forby dekompilering for feilretting i avtalen, vil han imidlertid kunne begrense brukers rett til dekompilering ved å legge til rette for prosedyrer for feilretting i avtalen (avsnitt 67). Dette kan for eksempel skje ved å avtalefeste bestemte prosedyrer for feilretting. Dersom retting likevel ikke skjer innen rimelig tid, må bruker derimot kunne påberope seg retten til å dekompilere for selv å rette.

 

Et annet spørsmål er om rettighetshaver kan begrense retten til dekompilering gjennom å tilby feilretting, selv om dette ikke er spesifisert i avtalen. EU-domstolen uttaler riktignok i avsnitt 68 at dekompilering uten videre kan skje dersom det ikke er avtalt prosedyrer for feilretting. 

 

Dersom rettighetshaver uttrykkelig har tilbudt feilretting, for eksempel ved å legge ut en «patch» for nedlasting som retter feilen, vil det gjøre at dekompilering ikke lenger er «nødvendig». Det er derimot tvilsomt om bruker av programmet er forpliktet til å gi rettighetshaver mulighet til å rette dersom dette ikke er regulert i kontrakten.

 

Dersom det derimot har vært kontakt mellom partene og rettighetshaver tilbyr retting, kan dekompilering neppe anses som «nødvendig» i perioden hvor rettighetshaver forsøker å rette feilen. Dersom feilretting ikke har skjedd innen rimelig tid må dekompilering imidlertid anses som «nødvendig», slik at bruker kan dekompilere for selv å rette feilen. 

G 1/19: EPO BoA henviser spørsmål om patenterbarheten til datamaskinsimuleringer til behandling ved EPOs utvidede appellkammer

Foto: Thomas Hawk - CC BY-NC 2.0

Et av EPOs tekniske appell­kamre henviste 22.2.19 tre spørsmål om patenter­bar­heten til data­maskin­simu­leringer til behandling ved EPOs utvidede appellkammer (EPO EBoA) . Oppfinnelsen i T 489/14 CONNOR/Pedestrian simu­lation rettet seg mot en data­maskin­implemen­tert frem­gangs­måte for å simulere hvordan fot­gjengere beveger seg i et område med sikte på hvordan man skal utforme et slikt område.

Tidlig praksis fra EPOs appellkamre forutsatte at oppfinnelser som rettet seg mot datamaskinsimulering måtte ha en fysisk tilknytning, typisk ved at fysisk produksjon av en simulert gjenstand måtte inngå som en del av patentkravet (se for eksempel T 453/91 IBM/VLSI-chip design).

Nyere praksis godtar derimot patentering av fremgangsmåter for simulasjon i seg selv, uten at produksjon av den simulerte gjenstanden må inngå. Appellkamrene har med grunnlag i dette blant annet godtatt patentering av en fremgangsmåte for testing av ytelsen av integrerte kretser gjennom simulasjon av støy ved anvendelse av en matematisk metode (T 1227/05 INFINEON/Circuit simulation I) og en fremgangsmåte for å beregne en optimal sammen¬setning av brenselcellene i en kjernefysisk reaktor (T 914/02 GENERAL ELECTRIC/Nuclear core loading). Disse oppfinnelsene ble ansett å løse tekniske problemer i den forstand at de hadde klart definerte tekniske formål der resultatet av simulasjonen kunne utnyttes relativt umiddelbart på et teknisk område. 

Derimot har blant annet fremgangsmåter for simulasjon av sikkerhetskontroll med passasjerer med bagasje (T 531/09 ACCENTURE/Checkpoint simulation), simulering av et callsenter (T 1265/09 IEX/Call center) ikke blitt ansett patenterbare. Disse oppfinnelsene ble ikke anses å løse tekniske problemer, og det eneste tekniske elementet i dem var i praksis at simuleringen ble gjennomført ved hjelp av en datamaskin.

Umiddelbart synes oppfinnelsen i T 489/14 CONNOR/Pedestrian simulation å ha mest de felles med de sistnevnte oppfinnelsene, og derfor må være unntatt fra patenterbarhet. Appellkammeret legger imidlertid til grunn at T 1227/05 INFINEON/Circuit simulation I kan forstås slik at 

Appellkammeret legger imidlertid til grunn at utformingen av et «miljø» som fotgjengere beveger seg gjennom har en fysisk eksistens og at utformingen kan anses som et teknisk problem med grunnlag i T 1227/05 INFINEON/Circuit simulation I (jf. T 489/14, avsnitt 18). Appellkammeret er skeptisk til å ville akseptere en slik løsning, og henviste derfor følgende spørsmål til det utvidede appellkammeret:

1. In the assessment of inventive step, can the computer-implemented simulation of a technical system or process solve a technical problem by producing a technical effect which goes beyond the simulation's implementation on a computer, if the computer-implemented simulation is claimed as such?
2. If the answer to the first question is yes, what are the relevant criteria for assessing whether a computer-implemented simulation claimed as such solves a technical problem? In particular, is it a sufficient condition that the simulation is based, at least in part, on technical principles underlying the simulated system or process?
3. What are the answers to the first and second questions if the computer-implemented simulation is claimed as part of a design process, in particular for verifying a design?

Dette immaterialrettstrollet vil nok mene at appellkammeret trekker den mulige rekkevidden av T 1227/05 INFINEON/Circuit simulation I vel langt. Oppfinnelsen i saken dreide seg som nevnt om informasjon som direkte kunne anvendes i design og konstruksjon av en integrert krets. Samtidig understrekes det i T 531/09 ACCENTURE/Checkpoint simulation at den omstendighet at simuleringen involverte fysiske gjenstander som metalldetektorer og røntgenmaskiner ikke innebar at simuleringen var teknisk. Samtidig er det ikke til på komme bort fra at oppfinnelsen i T 489/14 CONNOR/Pedestrian simulation på en annen måte enn oppfinnelsen i ACCENTURE gir informasjon som kan brukes til utforming av et fysisk område.

Diskusjonen illustrerer dermed teknikkbegrepets iboende vaghet. Det er derfor bra at det utvidede appellkammeret får anledning til å ta stilling til disse spørsmålene på et mer prinsipielt grunnlag.

Supreme Court avviser anke i Oracle v. Google: Funksjonelt opphavsrettslig vern for Javas APIer består i amerikansk rett

Den 9.5.2014 avsa Federal Circuit dom i Oracle v. Google. (Omtalt av Immaterialrettstrollet her) Saken omhandlet spørsmålet om Javas APIer er opphavsrettslig beskyttet, og Federal Circuit kom til at dette var tilfellet.

Avgjørelsen ble anket til Supreme Court, som nå har nektet anken fremmet. Dette innebærer at Federal Circuits avgjørelse blir stående, og saken sendes tilbake til førsteinstansdomstolen, som må ta stiling til om Googles bruk av Oracles APIer utgjør et opphavsrettsinngrep og om bruken i så fall utgjør «fair use».

«Fair use» er et lovfestet unntak fra opphavsretten i den amerikanske opphavsrettsloven § 107, som tillater «rimelig» («fair») bruk av et åndsverk uten samtykke fra opphavsmannen, til bruk blant annet (men ikke begrenset) til kritikk, journalistikk og undervisning. Ved vurderingen av om en bestemt bruk av et opphavsrettsbeskyttet verk utgjør «fair use» skal man blant annet ta i betraktning 1) formålet med og karakteren av bruken, herunder om bruken er kommersiell; 2) karakteren til det opphavsrettsbeskyttede verket; 3) hvor stor del av det opphavsrettsbeskyttede verket som er utnyttet; 4) hvordan bruken påvirker den reelle eller potensielle markedsverdien til det opphavsrettsbeskyttede verket. For APIer vil det særlig være karakteren av disse som verktøy for interoperabilitet (2) som tilsier at bruken av disse kan utgjøre «fair use».

Selv om det er fullt mulig å argumentere for at visse typer bruk av  en opphavsrettsbeskyttet API utgjør slik «fair use» av et opphavsrettsbeskyttet datamaskinprogram, er dette et argument det kan være vanskelig å nå frem med; og som det uansett vil være kostbart å få prøvd rettslig.

Den amerikanske opphavsrettsbeskyttelsen av funksjonelle elementer i datamaskinprogrammer skiller seg ganske markant fra den europeiske tilnærmingen til tilsvarende spørsmål. I C-406/10 SAS v. World Programming legger EU-domstolen nemlig til grunn at hverken et programs funksjonalitet, filformater eller det programm­erings­språk programmet uttrykkes i, utgjør opphavs­rettslig beskyttede elementer i et datamaskinprogram. 

SAS var innehaver av programvare­systemet SAS analytical software system - et integrert sett av programmer som lot brukeren utføre en rekke av databehandlingsoppgaver, hovedsakelig i form av statistisk analyse. Sentralt i dette program­vare­systemet lå «Base SAS», som lot brukeren skrive og kjøre egne bruker-programmer («scripts») for å lettere kunne behandle data. Disse var skrevet i et eget programnmeringsspråk – «SAS language».

Uten å ha tilgang til koden til SAS analytical system, hverken i form av den originale kildekoden eller gjennom dekompilert maskinkode, utviklet World Programming sitt eget program for statistisk analyse - World Programming System (WPS). Dette ble gjort gjennom å studere dokumentasjonen og gjennom å analysere hvordan SAS analytical system fungerte. WPS hadde tilsvarende funksjonalitet som SAS analytical system, og tillot på samme måte brukeren å skrive egne programmer i SAS’ programmeringsspråk.

EU-domstolen slo fast at opphavsrettsvernet av datamaskinprogrammer etter program­vare­direktivet omfattet kildekoden, maskinkoden og dokumentasjonen til programmet. (punkt 35 og 37) Dersom vernet også skulle utstrekkes til å omfatte funksjon¬elle elementer, ville dette derimot innebære en mulighet til å monopolisere ideer, noe som kunne hemme den tekniske utviklingen. (punkt 41)

Java Jawa

EU-domstolen påpekte at en av de fremhevede fordelene ved opphavsrettslig beskyttelse av datamaskinprogrammer i kommi­sjonens direktivforslag, nettopp var at opphavsrettsvernet er begrenset til den konkrete utformingen av et program og dermed ikke forhindrer andre fra å frem­bringe tilsvarende eller identiske programmer så lenge det ikke skjer gjennom en direkte kopiering av det opphavs­retts­beskyttede programmer. (punkt 41) EU-domstolen la derfor til grunn at «hverken et edb-programs funktion­alitet eller det programmeringssprog og det datafilformat, der anvendes i et edb-program til at udnytte visse af dets funktioner, udgør en form, hvori dette edb-program udtrykkes, hvorfor det ikke i kraft heraf er ophavsretlig beskyttet som edb-program». (punkt 46)

EU-domstolen tok riktignok ikke stilling til om dette også gjaldt når man ikke bare hadde skrevet et tilsvarende program med samme funksjonalitet, men også (som Google i Oracle v. Google) hadde kopiert den «deklarerende» koden til et API. Skal man følge EU-domstolens resonnement vil det imidlertid være nærliggende å si at denne koden utelukkende gir uttrykk for et data­maskin­programs funksjonalitet på et abstrakt nivå, og derfor ikke er opphavsrettsbeskyttet.

Et PhD-troll fra Orkanger?

Medtroll Kielland skal forsvare sin PhD-avhandling om patentering av informasjonsteknologiske oppfinnelser den 3. oktober. Anbefaler alle som er i Bergensområdet å ta turen innom  Magnus Lagabøtes plass den aktuelle dagen. Undertegnede skal definitivt.

Lenke til UiB sine hjemmesider med nærmere informasjon

Pressemelding fra UiB:

Programvare kan patenteres

Torger Kielland disputerer fredag 3.10.2014 for PhD-graden ved Universitetet i Bergen med avhandlingen «Patentering av informasjonsteknologiske oppfinnelser».

Patenter meddeles etter patentloven § 1 første ledd, jf. § 2 første ledd på «oppfinnelser» innenfor ethvert teknisk område. Etter patentloven § 1 andre ledd er imidlertid en rekke frembringelser unntatt fra patenterbarhet, deriblant «noe som bare utgjør … programmer for datamaskiner». Patentloven § 1 er en implementering av Den europeiske patentkonvensjonen artikkel 52, og må tolkes i lys av konvensjonen og praksis knyttet til denne.

I internasjonal og utenlandsk praksis har bestemmelsen imidlertid lenge blitt forstått slik at den ikke utelukker patentering av oppfinnelser som bare benytter seg av et datamaskin­program. Slik utnyttelse kan bestå i bruk av et datamaskin for å automatisere en industriell prosess, men kan også bestå i styring av interne prosesser i en datamaskins operativsystem, for eksempel en fremgangsmåte for bruk av en utklippstavle som gjør det mulig å dele data ved å klippe ut bilder og lime dem inn i et tekstbehandlingsdokument.

Avhandlingen påviser imidlertid at adgangen til å patentere informasjonsteknologiske oppfinnelser går lenger enn dette, og også omfatter oppfinnelser som retter seg mot måten en datamaskin håndterer data, uavhengig av formålet med oppfinnelsen. Dette medfører for eksempel at Googles algoritmer for rangering av websider, vil anses patenterbare.

Dette innebærer at programvare, til tross for unntaket for «noe som bare utgjør … programmer for datamaskinprogrammer» i patentloven § 1 andre ledd, ikke bare kan patenteres, men at man også kan få patent på «ren programvare».

U.S. Supreme Courts avgjørelse i Alice v. CLS Bank – er amerikansk patentrett på vei mot et krav til teknisk karakter etter europeisk modell?

Amerikansk patentrett har til nå godtatt patentering av forretningsmetoder som er implementert på en datamaskin, uavhengig av om oppfinnelsens nyhet ligger i selve forretningsmetoden. I dommen i Alice Corp. v. CLS Bank International, avsagt 19.6.2014, slår U.S. Supreme Court imidlertid enstemmig (9-0) fast at en generisk dataimplementering ikke er tilstrekkelig til å gjøre en abstrakt idé innholdsmessig patenterbar. 

Kilde: Wikimedia Commons

Saken omhandlet en fremgangsmåte for finansiell trading, hvor oppgjøret ble gjennomført via en tredjemann, slik at risikoen for betalingsmislighold ble redusert. Opp­finnelsen var patentert i fire patenter, som krevde opprinnelsen i form av flere frem­gangsmåte­krav, som utførte frem­gangs­måten på en datamaskin, flere system­krav, som rettet seg mot et datasystem som utførte frem­gangs­måten og flere programkrav, som rettet seg mot et datamaskinprogram som utførte frem­gangs­måten som var lagret på et fysisk medium.

CLS Bank tok i bruk tilsvarende fremgangsmåter i 2002, og inngikk etter hvert i forhandlinger med Alice Corp. om lisensiering av patentene. Da disse forhandlingene ikke førte frem, gikk CLS i 2007 til sak mot Alice Corp. med påstand om fastsettelsesdom på at patentene var ugyldige, samt at CLS ikke hadde gjort inngrep i dem. Alice Corp. gikk til motsøksmål med påstand om at CLS’ anvendelse utgjorde inngrep i patentene.

United States District Court for the District of Columbia avsa i 2011 dom hvor patentene ble kjent ugyldige etter den amerikanske patentloven § 101, fordi de rettet seg mot “an abstract idea” i form av et "basic business or financial concept", og at "a computer system" som bare var "configured to implement an abstract method” ikke var mer patenterbar enn "an abstract method that is simply ‘electronically’ implemented"

Saken ble anket til United States Court of Appeals for the Federal Circuit, som i 2012, under dissens 2-1, kom til motsatt resultat. Det ble her slått fast at en informasjonsteknologisk oppfinnelse er innholdsmessig patenterbar etter den amerikanske patentloven § 101 såfremt det ikke «manifestly evident that a claim is directed to a patent ineligible abstract idea» (s. 1352).

Saken ble tatt opp til fornyet behandling ved Federal Circuit i plenum (en banc), hvor retten i grove trekk delte seg 5-5. Avgjørelsen fra District Court, hvor patentene ble kjent ugyldige, ble derfor stadfestet. Saken ble deretter anket til U.S. Supreme Court.

Supreme Courts avgjørelse i Alice Corp. v. CLS Bank International
Etter den amerikanske patentloven § 101 skal patent meddeles til enhver som "invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof". Dette innebærer at en fysisk gjenstand, for eksempel en datamaskin, i prinsippet anses innholdsmessig patenterbar som et "product" etter § 101, uavhengig av hva maskinen gjør. Amerikanske domstoler har imidlertid lenge lagt til grunn at i alle fall "laws of nature, natural phenomena, and abstract ideas" er utelukket fra patentbeskyttelse etter amerikansk rett. (slip. op. s. 5)

Clarence Thomas

Supreme Court, anført av dommer Thomas, tok utgangspunkt i sin tidligere avgjørelse i Mayo v. Prometheus, som omhandlet spørsmålet om en fremgangsmåte for dosering av medisiner ved måling av pasienters stoffskifte var patenterbar etter § 101. Det legges her til grunn at man ved spørsmålet om en oppfinnelse er patenterbar etter § 101 først skal (1) ta stilling til om patentkravene retter seg mot et noe som er unntatt fra patenterbarhet, typisk et naturlig fenomen eller en abstrakt idé, for deretter å (2) ta stilling til om kravene inneholder et oppfinnerisk konsept som omformer naturfenomenet eller den abstrakte ideen til en innholdsmessig patenterbar anvendelse av disse.

Mayo v. Prometheus – kriterium (1) – «abstract idea»
Hva angikk det første kriteriet, la Supreme Court til grunn at «[t]he abstract ideas category embodies the longstanding rule that an idea of itself is not patentable». (slip op. s. 7) Dette omfattet blant annet matematiske algoritmer (jf. Gottschalk v. Benson fra 1972 og Parker v. Flook fra 1978) og fremgangsmåter for finansiell «hedging» (jf. Bilski v. Kappos fra 2010). Patenthaver, Alice Corp., argumentert riktignok med at «abstrakte ideer» var begrenset til «preexisting, fundamental thruths that exist in principle apart from any human action (slip op. s. 10) Supreme Court fant imidlertid at dette sto i direkte motstrid til den tidligere avgjørelsen i Bilski v. Kappos, hvor en fremgangsmåte for finansiell «hedging» ble ansett som en abstrakt idé, selv om det her var snakk om «a method of organizing human activity» og ikke «a truth about the natural world that has always existed». (slip op. s. 10) Ut over dette fant Supreme Court ikke grunn til å ta nærmere stilling til hva som utgjorde en «abstrakt idé», ut over å konstatere at Bilskis fremgangsmåte for «hedging» måtte anses som «a fundamental economic practice». Alice Corps fremgangsmåte for oppgjør gjennom tredjemann skilte seg ikke vesentlig fra denne, da begge fremgangsmåtene falt «squarely within the realm of abstract ideas as we have used that term». (slip op. s. 10)

Mayo v. Prometheus – kriterium (2) – «inventive concept»
Hva angikk det andre kriteriet, la Supreme Court, med støtte i Mayo v. Prometheus, til grunn at et krav «that recites an abstract idea must include additional features features to ensure that the claim is more than a drafting effort designed to monopolize an abstract idea”. (slip. op. s. 11) Anvendelsen av en datamaskin kunne imidlertid i seg selv ikke gjøre en abstrakt idé til et oppfinnerisk konsept.

Supreme Court fant støtte for dette i tre tidligere avgjørelser. I Gottschalk v. Benson, som omhandlet en datamaskinstyrt fremgangsmåte for konvertering av binært kodede desimaltall til rene binærtall. Denne fremgangsmåten ble ansett som abstrakt idé, og anvendelsen av denne måtte derfor innebære en «new and useful application». Datamaskinimplementeringen av fremgangsmåten kunne imidlertid «be carried out in existing computers long in use»,  og bidro derfor ikke tilstrekkelig til et oppfinnerisk konsept. (slip. op. s. 11-12)

Det samme var tilfellet i avgjørelsen i Parker v. Flook, som omhandlet en fremgangsmåte for å anvende en matematisk formel for å beregne grenseverdier (relatert for eksempel til temperatur og trykk) som signaliserte ineffektivitet eller farlige nivåer i en katalysator. Den matematiske formelen ble også her ansett som en abstrakt idé hvor  datamaskinimplementeringen var helt konvensjonell. (slip. op. s. 11)

I avgjørelsen i Diamond v. Diehr ble derimot en datamaskinstyrt fremgangsmåte for vulkanisering av syntetisk gummi ansett innholdsmessig patenterbar. Dette ble gjort ved at den ubehandlede gummien ble plassert i en form som ble satt under trykk, og deretter varmebehandlet inntil gummien var vulkanisert. Denne prosessen ble tidligere utført ved at formen ble åpnet manuelt på bestemte tidspunkt, på grunnlag av en kjent matematisk algoritme. Dette var imidlertid ikke uproblematisk, fordi åpningen av formen gjorde målingen av temperatur som lå til grunn for beregningen, unøyaktig. Den patentsøkte oppfinnelsen løste dette problemet ved å måle temperaturen inne i formen, og programmerte en datamaskin til automatisk å åpne formen på riktig tidspunkt i henhold til algoritmen. Dette gjorde at fremgangsmåten matte anses som en oppfinnerisk anvendelse av den matematiske algoritmen. Annerledes formulert: “[T]he claims in Diehr were patent eligible because they improved an existing technological process, not because they were implemented on a computer.” (slip op. s. 13, kursivert her)

Dette innebar at “the mere recitation of a generic computer cannot transform a patent-ineligible abstract idea into a patent-eligible invention”. (slip op. s. 13) Man måtte da vurdere om “the claims … do more than simply instruct the practitioner to implement the abstract idea of intermediated settlement on a generic computer”. (slip op. s. 14) Dette var ikke tilfellet for fremgangsmåtekravene, da “the function performed by the computer at each step of the process” måtte anses som “purely conventional”. Bruk av en datamaskin for å “create and maintain shadow records amounts to electronic recordkeeping – one of the most basic functions of a computer. På samme måte matte “the use of a computer to obtain data, adjust account balances and issue automated instructions” anses som “computer functions” som var “well-understood, routine, conventional activites previously known in the industry”. Hvert skritt i fremgangsmåten gjorde da ikke noe annet enn å “require a generic computer to perform feneric computer functions” (slip op. s 15)

Det samme var tilfellet for systemkravene og programkravene, da disse på samme måte som fremgangsmåtekravene måtte anses å «add nothing of substance to the underlying abstract idea». (slip op. s 17) Alle kravene i saken ble da ansett ikke-patenterbare etter den amerikanske patentloven § 101, og Federal Circuits avgjørelse i saken ble stadfestet.

Hva er egentlig en «abstrakt idé» - innebærer Alice v. CLS et unntak for forretningsmetoder?
Det som  er klart etter Alice v. CLS Bank, er at implementering på en datamaskin ikke er tilstrekkelig til å gjøre en abstrakt idé innholdsmessig patenterbar. Dommen etterlater imidlertid flere ubesvarte spørsmål. Det første er hva som egentlig utgjør en «abstrakt idé». Supreme Court definerer ikke dette nærmere, men nøyer seg med å vise til tidligere avgjørelser som unntar matematiske metoder og en fremgangsmåte for finansiell «hedging» fra patenterbarhet som abstrakte ideer. Dette reiser spørsmål om forretningsmetoder mer generelt må anses som «abstrakte ideer» som er unntatt fra patenterbarhet.

Begrunnelsen for at Bilskis fremgangsmåte for «hedging» og Alices fremgangsmåte for oppgjør gjennom tredjemann utgjør en «abstrakt idé» synes imidlertid å være at disse utgjør «fundamental economic practices». Forstått på denne måten er det tilsynelatende fremgangsmåtenes altomfattende karakter, i den forstand at de omfatter så å si alle former for «hedging» og alle former for oppgjør gjennom tredjemann, som gjør dem til abstrakte ideer.

Flertallet av dommerne i Supreme Court synes også å være skeptiske til å trekke unntaket for abstrakte ideer så langt at det innebærer et forbud mot patentering av forretningsmetoder. I Bilski v. Kappos, avviste dommerne Kennedy, Roberts, Thomas og Alito et slikt unntak, og ga samtidig uttrykk for at slike metoder stort sett ville være innholdsmessig patenterbare. Dommerne Stevens, Ginsburg, Breyer og Sotomayor ville på sin side knesette et kategorisk unntak for forretningsmetoder. (Dommer Scalia gikk ikke inn for et slikt unntak, men gikk ikke fullt så langt som de fire førstnevnte dommerne i å anse forretningsmetoder patenterbare.) Dommerne Sotomayor, Ginsburg og Breyer, gjentar i sin tilleggsbemerkning i Alice v. CLS standpunktet om at «any claim that merely describes a method of doing business does not qualify as a process under § 101». Lest i sammenheng med Bilski v. Kappos, er dette åpenbart et standpunkt de øvrige dommerne ikke fullt ut kan slutte seg til.

Omforming fra abstrakt idé til oppfinnerisk konsept som et form for krav til teknisk karakter?
Det andre steget i Mayo-tilnærmingen – omformingen fra en abstrakt idé til et oppfinnerisk konsept – er, om mulig, enda mer uavklart. Det som er klart at implementeringen av en abstrakt idé på en datamaskin i seg selv, ikke er tilstrekkelig til å gjøre en oppfinnelse innholdsmessig patenterbar. Man må da ta stilling til hva som skal til ut over en ren implementering på en datamaskin.

Én måte å forstå kravet til omforming til et oppfinnerisk konsept, er som en forutsetning om at patentkravene ikke skal «uttømme» utnyttelsen av en abstrakt idé, og dermed gi patenthaver en enerett til å utnytte den abstrakte ideen. Det vil da muligens være tilstrekkelig at utnyttelsen av en abstrakt idé er begrenset til visse former for utnyttelse på en datamaskin, for eksempel utnyttelse på en bestemt datamaskinarkitektur. Et slikt krav fremstår imidlertid noe vilkårlig, da det er vanskelig å forstå hvorfor for eksempel begrensning til implementering på en x86-arkitektur utgjør noen reell begrensning. Man må i så fall kreve en mer omfattende begrensning.

"When I use the word "technical", it means just
what I choose it to mean - neither more nor less."

Henvisningen til at oppfinnelsen i Diamond v. Diehr ble ansett patenterbar fordi den forbedret «an existing technological process» leder imidlertid tankene i retning av et form for krav til teknisk karakter etter europeisk modell. Av amerikanske kommentarer til Alice v. CLS Bank, argumenterer blant annet Chisum for en slik forståelse av dommen. Hva dette egentlig vil innebære, er imidlertid uklart. I og med at det neppe er meningen å utelukke alle forretningsmetoder fra patenterbarhet, må "a technological process" nødvendigvis være noe mer enn en ren datateknisk implementering. Når man tar i betraktning vanskelighetene ved å fastlegge hva som anses som "teknisk" i europeisk praksis, er dette muligens en vurdering man i amerikansk rett vil være bedre tjent med å gjøre uavhengig av begreper som "technological" og "teknisk".

Dette reiser imidlertid et tredje spørsmål, relatert til forholdet mellom innholdsmessige kravene og de kvalitative kravene til patenterbarhet. For at en patentsøkt frembringelse skal være patenterbar, må den ikke bare oppfylle kravene til innholdsmessig patenterbarhet i den amerikanske patentloven § 101 og EPC artikkel 52. Frembringelsen må også kvalitativt sett være ny og skille seg vesentlig fra det som er kjent på søknadstidspunktet, jf. den amerikanske patentloven §§ 102 og 103 og EPC artikkel 54 og 56.

Både oppbygningen av den amerikanske patentloven og EPC legger tilsynelatende opp til en trinnvis vurdering, hvor man først vurderer om en patentsøkt frembringelse er innholdsmessig patenterbar etter § 101 og artikkel 52, og deretter vurderer om denne er ny og har oppfinnelseshøyde etter §§ 102 og 103 og artikkel 54 og 56. Dette kan man betegne som en helhetstilnærming, da begge vurderingene foretas for oppfinnelsen som helhet.

Ved å legge vekt på at implementeringen av fremgangsmåten for oppgjør via tredjemann «merely require generic computer implamentation» trekker Supreme Court tilsynelatende en nyhetsvurdering inn i vurderingen av om oppfinnelsen er innholdsmessig patenterbar etter § 101. (se tilsvarende uttalelsene om at implementeringen var «conventional», slip op. s. 11, 12 og 15) Man forutsetter med dette tilsynelatende at implementeringen i seg selv må være ny og ha oppfinnelseshøyde.

Amerikansk rett har imidlertid lenge vært skeptisk til denne typen utelukkelsestilnærminger, hvor man forutsetter at bare deler av en patentsøkt frembringelse kan bidra til nyhet og oppfinnelseshøyde. Problemet er imidlertid at et substansielt krav til implementering av en abstrakt idé på en datamaskin på mange måter vil forutsette en reell vurdering av hva implementeringen består i. Dersom man forutsetter at implementeringen skal være noe mer en generisk eller konvensjonell implementering på en datamaskin, kan det imidlertid være vanskelig å komme unna en vurdering av om implementeringen er ny og har oppfinnelseshøyde.

Ut over å slå fast at implementering av en abstrakt idé på en datamaskin i seg selv ikke er tilstrekkelig, er Alice v. CLS imidlertid så åpent formulert at den videre utviklingen kan bli alt fra en forsiktig justering av dagens praksis til en mer radikal endring i europeisk retning. Immaterialrettstrollet heller i retning av det første, men rettstilstanden som Supreme Court etterlater seg er likevel såpass uavklart at han ikke vil bli overrasket om domstolen får en ny sak om informasjonsteknologiske oppfinnelser til behandling innen tre-fire år.

Gjestebloggpost: T-488/11 Sarc v. Kommisjonen - programvarelisensiering som statsstøtte

Immaterialrettstrollet beveger seg ikke så ofte inn i konkurranseretten og dens tilliggende rettsområder. En sak for Underretten om programvarelisensiering som statsstøtte vekket imidlertid hans interesse. Han har derfor fått Malgorzata Cyndecka til å skrive et gjesteblogginnlegg om saken.

Kilde: Wikimedia Commons

12. juni 2014 traff Underretten avgjørelse i sak T-488/11 Sarc mot  Kommisjonen, som omhandlet spørsmål om opphevelse av Kommisjonens avgjørelse om at en avtale om lisensiering av et datamaskin­program mellom det neder­landske Technische Universi­teit Delft (“TUD”) og selskapet Delftship BV (“DS”), ikke innebar statsstøtte. Under­retten opprett­holdt Kommisjonens avgjørelse, og avviste klagen fra Sarc, et nederlandsk selskap som utvikler og
markedsfører programvare for skipsdesign og som er i direkte konkurranse med DS.

Saken hadde sitt utgangspunkt i datamaskinprogrammet «Delftship», som var utviklet av to tidligere ansatte ved TUD. De hadde etter fratredelsen opprettet selskapet DS, som hadde fått lisens til å utnytte kildekoden til programmet. Sarc anførte at denne avtalen var inngått på gunstigere vilkår enn det som kunne oppnås i markedet, og dermed utgjorde statsstøtte.

På samme måte som artikkel 107(1) Traktaten om Den europeiske unions virkemåte (TEUV) setter artikkel 61(1) EØS-avtalen skranker for mulighetene staten har til å gi støtte til næringsvirksomhet; her: det statlige universitetet og et privat foretak.

Offentlig støtte til enheter som utøver økonomisk virksomhet utgjør statsstøtte etter TEUV artikkel 107 (1) og EØS-avtalen artikkel 61 (1) dersom den innebærer støtte i form av tildeling av en 1) økonomisk fordel som 2) er gitt av statsmidler, 3) som begunstiger enkelte foretak eller produksjonen av enkelte varer eller tjenester, 4) som vrir eller truer med å vri konkurransen og 5) som er egnet til å påvirke samhandelen innen EØS-området.

Samtlige fem vilkår må være oppfylt for at et offentlig tiltak skal anses som statsstøtte iht. TEUV artikkel 107 (1) EØS-avtalen artikkel 61 (1). Grovt sett tolkes den økonomiske fordelen som statlige investeringer, lån, garantier, avtaler o.l. som er gitt eller inngått på vilkår som er gunstigere for det aktuelle foretaket enn det som det kunne ha oppnådd i markedet. Det offentlige må med andre ord i sin rolle som eier, investor eller långiver, opptre på samme måte som en sammenlignbar markedsaktør under liknende omstendigheter og under normale markedsvilkår.

Kommisjonen traff 10.5.2011 avgjørelse hvor det ble konkludert med at avtalen ikke innebar statsstøtte til DS, siden den ikke resulterte i en økonomisk fordel til DS  iht. TEUV artikkel 107(1). TUD oppfylte med andre ord kravene i det såkalte markedsinvestorprinsippet (MEIP).

Kommisjonen la til grunn at «Delftship» (programmet) hadde blitt utviklet av TUD mellom 1997 og oktober 2006, og at det hadde blitt brukt av studenter og de ansatte til undervisningsformål. I juni 2006 varslet ingeniøren som utviklet «Delftship» at han skulle gå av som TUD-ansatt. Samtidig opplyste TUD at det ikke hadde de nødvendige ressursene til å videreutvikle programmet. Derfor begynte TUD å forhandle med grunnleggerne av DS om en avtale om lisensiering av «Delftship».

22.11.2007 inngikk TUD og DS en avtale om eksklusiv og ikke-overførbar lisens for utnyttelse av «Delftship». Iht. avtalen ble DS forpliktet til blant annet å videreutvikle programmet, vederlagsfritt gi TUD tilgang til oppdaterte versjoner, samt å betale royalties til TUD på 5% av inntektene på salg og viderelisensiering.

Ifølge Kommisjonen var retningslinjene for offentlig støtte til forskning og utvikling og innovasjon (FoUoI) av 2006 ikke direkte relevante i den aktuelle saken. Etter å ha vurdert de angivelig gunstigere avtalevilkårene, konkluderte Kommisjonen at TUD gjennom de forskjellige forhandlingsetappene hadde forbedret sin posisjon som avtalepart. TUD tok i betraktning mange faktorer blant annet erfaring til ingeniøren som hadde utviklet programmet. Ifølge Kommisjonen var avgiften som DS skulle betale under lisensavtalen lik markedspris.

Underretten kom til samme konklusjon som Kommisjonen. Ifølge Underretten hadde Kommisjonen rett til å konkludere at måten TUD forhandlet på og resultatet til disse forhandlingene med DS tydet på at avtalen ble inngått på markedsvilkår. TUD oppfylte dermed kravene som stilles i henhold til markedsinvestortesten og man kunne utelukke statsstøtte.

Delftship-saken er et interessant eksempel på anvendelsen av MEIP på en avtale om kompensasjon for immaterielle rettigheter mellom en offentlig undervisningsinstitusjon og et privat foretak. I den aktuelle saken kan man trekke frem mangel på både en åpen anbudskonkurranse og en uavhengig ekspertvurdering i forkant av avtalen. Som riktig påpekt av Sarc anbefaler Kommisjonen en av de to metodene til å etablere markedspris når det offentlige skal inngå en salgsavtale. Se XXIII Report on the Competition Policy of 1993, the Communication on State aid elements in sales of land and buildings by public authorities of 1997 og FoUoI av 2006. Underretten forklarte likevel at Kommisjonen ikke var forpliktet til å bruke disse metodene i den aktuelle saken som gjaldt en avtale om lisensiering av et datamaskinprogram.

Som EU-domstolen understreker i Seydaland av 2010, vil mangel på en åpen anbudskonkurranse eller en ex ante ekspertvurdering ikke automatisk resultere i statsstøtte. Selv om det faktum at avtalen ble inngått etter eksklusive forhandlinger mellom TUD og DS gir rimelig grunn til å spørre om avtalen innebar statsstøtte, hadde Kommisjonen rett i å legge vekt på at kunnskapene til DS-grunnleggerne, som de hadde oppnådd under utviklingen av Delftship-datamaskinprogrammet, var avgjørende for deres kompetanse til å videreutvikle dataprogrammet og tilpasse det til TUDs behov. Ikke desto mindre var avgiften DS betalte lik markedspris.

Malgorzata Agnieszka Cyndecka

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.