Google LLC v. Oracle America, Inc. -Google LLC v. Oracle America, Inc.
| Google LLC v. Oracle America, Inc. | |
|---|---|
| |
| Argumentat pe 7 octombrie 2020 Hotărât pe 5 aprilie 2021 | |
| Numele complet al cazului | Google LLC v. Oracle America, Inc. |
| Dosarul nr. | 18-956 |
| Citații | 593 SUA ___ ( mai multe ) |
| Istoricul cazului | |
| Prior |
|
| Întrebări prezentate | |
| |
| Deținere | |
| Copierea de către Google a API-ului Java SE, care a inclus numai acele linii de cod care erau necesare pentru a permite programatorilor să-și pună talentele acumulate la lucru într-un program nou și transformator, a fost o utilizare corectă a materialului respectiv ca materie de drept. | |
| Calitatea de membru al instanței | |
| |
| Opiniile cazului | |
| Majoritate | Breyer, alături de Roberts, Sotomayor, Kagan, Gorsuch, Kavanaugh |
| Disidență | Thomas, alături de Alito |
| Barrett nu a luat parte la examinarea sau decizia cazului. | |
Google LLC v. Oracle America, Inc. a fost un caz legal în Statele Unite legate de natura codului computerului și a legii drepturilor de autor . Disputa s-a centrat pe utilizarea unor părți ale interfețelor de programare a aplicațiilor (API)ale limbajului de programare Java și a aproximativ 11.000 de linii de cod sursă , care sunt deținute de Oracle (prin intermediul unei filiale, Oracle America, Inc., provenind de la Sun Microsystems ), în versiunile anterioare ale sistemului de operare Android de către Google . De atunci, Google a făcut tranziția Android la un motor neîncărcat de drepturi de autor fără codul sursă și a recunoscut că a folosit API-urile, dar a susținut că acest lucru a fost utilizat în mod corect .
Oracle a inițiat procesul susținând că API-urile erau protejate prin drepturi de autor, căutând daune de 8,8 miliarde USD din vânzările Google și acordarea licențelor pentru versiunile anterioare de Android care încalcă drepturile. În timp ce două procese din juriu la nivel de instanță judiciară au fost găsite în favoarea Google, instanța federală a circuitului a anulat ambele decizii, afirmând că API-urile sunt protejate prin drepturi de autor, iar utilizarea Google nu intră sub incidența utilizării corecte. Google a solicitat cu succes Curții Supreme să audieze cazul în termenul din 2019, concentrându-se asupra dreptului de autor al API-urilor și al utilizării corecte ulterioare; cazul a fost amânat până la termenul din 2020 din cauza pandemiei COVID-19 . În aprilie 2021, Curtea Supremă a decis într-o decizie 6–2 că utilizarea de către Google a API-urilor Java se încadrează în cei patru factori ai utilizării corecte, ocolind întrebarea privind dreptul de autor al API-urilor. Decizia a anulat hotărârea Circuitului Federal și a retras cazul pentru o revizuire ulterioară.
Cazul a avut un interes semnificativ în industria tehnologiei și a software-ului, deoarece numeroase programe de calculator și biblioteci de software, în special în sursă deschisă , sunt dezvoltate prin recrearea funcționalității API-urilor din produsele comerciale sau concurente pentru a ajuta dezvoltatorii în interoperabilitatea între diferite sisteme sau platforme .
fundal
Dezvoltare Java
Java a fost dezvoltat inițial la Sun Microsystems începând din decembrie 1990. Acesta a inclus un nou limbaj de programare , o mașină virtuală și un set de biblioteci pentru utilizare cu limbajul. Aceste biblioteci sunt documentate pentru programatori prin intermediul interfețelor de programare a aplicațiilor (API-uri), care le spun programatorilor ce informații să ofere funcțiilor bibliotecii și ce rezultate să se aștepte înapoi, eliminând orice nevoie ca programatorul să știe cum biblioteca pe care o utilizează face ce face. Aceste biblioteci oferă împreună „mașina virtuală Java” pe care programatorii scriu programe pentru a le folosi (rula). Modul comun în care un set comun de biblioteci sunt utilizate în toate „mașinile virtuale Java” permite interoperabilitatea sau, după cum este comercializat de Sun, „ Scrie o dată, rulează oriunde ”; un programator trebuie să creeze o singură versiune a software-ului său care, datorită grupului unic de API-uri comune tuturor mașinilor virtuale Java, poate fi astfel rulat pe orice platformă de calcul care acceptă Java.
Limbajul Java a fost lansat publicului în 1995, sub licența sursă comunitară Sun , făcând codul sursă disponibil în mod liber, dar cerând ca produsele care utilizează codul să fie menținute la standardul Java și ca orice lucrare comercială derivată să fie licențiată de Sun. În timp ce oricine ar putea programa în limbajul propriu-zis, Sun a întreținut bibliotecile Java Platform, Standard Edition (Java SE) și Mobile Edition (Java ME), furnizate utilizatorilor ca cod bytec Java precompilat , precum și API-urile respective, precum și tehnologia Kituri de compatibilitate (TCK) care au testat o implementare în raport cu standardul Java. În 2006 și 2007, din cauza presiunii din partea dezvoltatorilor, Sun a schimbat licența diferitelor pachete Java pentru a utiliza licența publică generală GNU cu o „excepție classpath” , permițând dezvoltatorilor accesul necesar pentru a face lucrări derivate și capacitatea de a lansa aplicații sub o licență diferită. Acest lucru a dus la OpenJDK (Open Java Development Kit), lansat pentru prima dată în 2007. Sun a păstrat un control puternic asupra limbajului și a standardelor în sine, acordând licență elementelor necesare, cum ar fi TCK-urile, pentru utilizatorii comerciali. În acest moment, modelul de afaceri al lui Sun s-a transformat în concentrarea pe licențierea platformei Java pentru dispozitive încorporate , în special telefoane mobile, și a încheiat deja acorduri de licențiere cu Nokia , Motorola și Research In Motion .
Dezvoltare Android
Android, Inc. a fost fondată în 2003 de Andy Rubin , Rich Miner , Nick Sears și Chris White pentru a dezvolta o platformă de telefonie mobilă . Google a achiziționat Android în 2005 și a continuat dezvoltarea sistemului de operare Android . În timpul dezvoltării Android, Google a dorit să încorporeze bibliotecile Java SE. Președintele executiv al Google, Eric Schmidt , se adresase președintelui Sun, Jonathan I. Schwartz, despre licențierea bibliotecilor Java pentru utilizarea în Android. Sun a oferit un acord de licențiere între 30 și 50 de milioane de dolari SUA . Schmidt a spus că Google ar fi plătit pentru licența respectivă, dar erau îngrijorați de faptul că Sun a solicitat și un anumit control partajat al Android, împreună cu taxa. Google afirmă că doreau mai mult control pentru a deschide limba sursă și a permite terților să profite mai bine de codul său; Oracle afirmă că Sun a refuzat deoarece intenția Google a fost în esență de a forța Java la o versiune Google a limbii și de a împiedica interoperabilitatea cu alte versiuni, o idee care a fost „anatemă” pentru „scriere odată executată oriunde”. limba. Din cauza acestor diferențe de vedere, negocierile nu au reușit să ajungă la o înțelegere și Sun a refuzat Google o licență pentru Java.
În acest moment, implementarea OpenJDK oferită de Sun nu era la fel de matură sau completă ca Java Standard Edition. În loc să acorde licențe Java, Google a ales să dezvolte o versiune pentru camere curate a bibliotecilor Java Standard Edition, dezvoltând bibliotecile de la un început complet nou, fără niciun acces la codul Sun. Acesta a devenit motorul din spatele mașinii virtuale Dalvik de la Android , o parte esențială a noului sistem. O parte din mașina virtuală a inclus 37 de apeluri API și aproximativ 11.500 de linii de cod considerate centrale în Java, care au fost preluate de la Apache Harmony , o implementare Java open-source pentru cameră curată dezvoltată de Apache Software Foundation (ASF). Înainte de aceasta, ASF a încercat să obțină licențele necesare de la Sun pentru a sprijini proiectul Apache Harmony ca să-l numească implementare oficială Java, dar nu a putut, parțial din cauza licențierii incompatibile cu licența publică generală GNU Java și licența ASF Apache , nici nu ar putea avea acces la TCK-urile Java pentru a valida proiectul Harmony împotriva implementării Sun. Deși Google a declarat că a folosit acest cod pentru a asigura interoperabilitatea cu Java Standard Edition pentru alți programatori, în timpul celei de-a doua ședințe de apel, Google a declarat că a folosit acest cod din motive comerciale pentru a finaliza rapid Android și pentru a evita „oboseala” de a recrea cod. ASF a încetat să mai mențină Apache Harmony în 2011, determinând Google să preia întreținerea acestor biblioteci.
Google a lansat o versiune beta a platformei Android pe 5 noiembrie 2007, apoi, o săptămână mai târziu, kitul de dezvoltare software (SDK) despre care au menționat că include unele tehnologii Java. Președintele lui Sun, Schwartz, l-a felicitat pe Google în aceeași zi, spunând că „au legat un alt set de rachete de impulsul comunității - și de viziunea care definește oportunitatea pe planetele noastre (și alte).” În timpul procesului, Schwartz a spus că, în momentul lansării Android, deși știa că Google ar fi putut să-și ocolească cerințele de licențiere, „Am decis să strângem din dinți și să-l susținem, astfel încât oricine îl susține să ne vadă ca parte a lanțului valoric”.
Oracle a anunțat că va achiziționa Sun în aprilie 2009 pentru 7,4 miliarde de dolari SUA și a finalizat achiziția în ianuarie 2010. Pe lângă faptul că le-a permis să intre în afacerea cu hardware, CEO-ul Oracle, Larry Ellison, a numit limbajul Java „cel mai important activ software pe care l-am dobândit vreodată ". Oracle a continuat să dezvolte Java și să urmărească oportunități de licențiere după achiziționarea companiei Sun.
Prin lansarea Android KitKat (v4.4) în 2013, Google a eliminat mașina virtuală Dalvik și a înlocuit-o cu Android Runtime , care a fost construit în cadrul Google fără niciun cod sursă Java. Cu toate acestea, Android a continuat să utilizeze API-urile JavaSE până la litigiile cazului până la Android Nougat, când a fost complet înlocuit de OpenJDK .
Prima fază: drepturi de autor API și brevete
Prima fază a cazului a durat din 2010 până în 2015. Oracle a stabilit cu succes că API-urile sunt protejate prin drepturi de autor, dar pretențiile lor de încălcare a brevetelor au fost respinse. Google a solicitat Curții Supreme în octombrie 2014 să revizuiască cazul, dar acest lucru a fost respins.
Primul proces judecătoresc
La 13 august 2010, Oracle a dat în judecată Google pentru încălcarea drepturilor de autor și a brevetelor de judecată la Tribunalul Districtual pentru Districtul de Nord din California . Oracle a afirmat că Google știa că au dezvoltat Android fără licență Java și că au copiat API-urile sale și că, prin urmare, Google a încălcat drepturile de autor ale Oracle. Oracle a citat, de asemenea, șapte brevete anterioare legate de tehnologia Java creată de Sun și acum deținută de Oracle, despre care Google ar fi trebuit să fie conștient deoarece angajaseră foști dezvoltatori Sun care lucrau pe Java. Oracle a solicitat atât despăgubiri bănești, cât și o hotărâre judecătorească pentru a opri Google să folosească materialele care ar presupune că încalcă drepturile.
Cazul a fost repartizat judecătorului William Alsup , care a împărțit cazul în trei faze: drepturi de autor, brevet și daune.
Faza drepturilor de autor a început la 16 aprilie 2012 și consta în mai multe revendicări distincte de încălcare: o funcție rangeCheck pe nouă linii, mai multe fișiere de testare, structura, secvența și organizarea (SSO) Java (API) și documentația API .
Oracle a pretins încălcarea a 37 de API-uri Java separate care proveneau din proiectul Apache Harmony. După două săptămâni de mărturie, juriul a constatat, la 7 mai 2012, că Google a încălcat drepturile de autor legate de cod, SSO și documentația API-urilor, precum și funcția rangeCheck, dar au fost blocate dacă aceste utilizări se încadrează în utilizarea corectă . Juriul a constatat, de asemenea, că Google avea suficiente motive să creadă, bazându-se pe comportamentul lui Sun și Oracle, că nu aveau nevoie să licențieze Java de la Sun sau Oracle, dar nu se bazau pe acest lucru atunci când dezvoltau Android. Oracle a solicitat o hotărâre în materie de drept (JMOL) prin care cazul respinge orice apărare de utilizare echitabilă din moment ce juriul a fost împărțit, precum și să anuleze decizia juriului cu privire la opt dosare legate de securitate pe care le-au examinat și au considerat că nu încalcă, dar pe care Google le-a declarat că au copiat textual; Alsup a fost de acord. Google a solicitat un JMOL similar legat de rangeCheck, dar Alsup a respins această cerere.
Faza brevetului a început pe 7 mai 2012, cu același juriu. La momentul procesului, cazul brevetului Oracle conținea revendicări din două brevete, 6.061.520 (Metodă și sistem pentru efectuarea inițializării statice) și RE38104 (Metodă și aparat pentru rezolvarea referințelor de date în codul generat). Google a urmărit o apărare fără încălcarea dreptului comunitar. Pentru brevetul 6061520, ei au susținut că foloseau analiza pentru optimizarea inițializării statice, mai degrabă decât „simularea execuției” după cum cerea cererea. Pentru brevetul RE38104, ei au susținut că instrucțiunea nu include o referință simbolică. La 23 mai 2012, juriul a constatat neîncălcarea tuturor cererilor de brevet.
Judecătorul Alsup a emis verdictul final pentru ambele faze pe 31 mai 2012. În timp ce juriul a constatat pentru Oracle referitor la încălcarea drepturilor de autor a API-urilor, Alsup a stabilit că API-urile nu erau protejate prin drepturi de autor:
Atâta timp cât codul specific utilizat pentru a implementa o metodă este diferit, oricine este liber în baza Legii drepturilor de autor să își scrie propriul cod pentru a îndeplini exact aceeași funcție sau specificație a oricăror metode utilizate în API-ul Java. Nu contează că declarația sau liniile de antet ale metodei sunt identice.
Alsup a fost de acord cu juriul că funcția rangeCheck și opt fișiere de securitate au constituit o încălcare a drepturilor de autor, dar singura scutire disponibilă a fost daunele legale până la maximum 150.000 USD
Ca urmare a acestor hotărâri și a unei prevederi, nu a existat o fază de daune a juriului. Părțile au fost de acord cu zero dolari în daune legale pentru cantitatea mică de cod copiat până în iunie 2012.
Prima hotărâre de apel
La scurt timp după încheierea cauzei instanței de district, ambele părți au încercat să depună JMOL-uri suplimentare cu privire la elementele hotărârii pe care Alsup le-a respins, ceea ce a condus la Oracle care a contestat decizia și la Google a formulat un recurs incident cu privire la cererea de copiere literală. Deoarece cazul a implicat revendicări legate de brevete, apelul a fost repartizat automat Curții de Apel din Statele Unite pentru Circuitul Federal . Ședința a avut loc la 4 decembrie 2013, iar hotărârea a fost publicată la 9 mai 2014.
Instanța a menționat că Legea drepturilor de autor oferă protecție „operelor originale de autor fixate în orice mediu tangibil de exprimare” (p. 17). Istoria legislativă explică faptul că operele literare includ „programe de calculator în măsura în care încorporează autorul în exprimarea de către programator a ideilor originale, distinse de ideile în sine” (p. 18). Pentru a beneficia de protecția drepturilor de autor, o lucrare trebuie să fie originală. 17 USC § 102 (a). Prin urmare, instanța a fost „prima care a evaluat dacă expresia este originală pentru programator” (p. 24), ceva ce Google a recunoscut deja (p. 21). Acest lucru a determinat instanța să concluzioneze „că structura generală a pachetelor API Oracle este creativă, originală și seamănă cu o taxonomie” (p. 14). Prin urmare, a inversat decizia instanței de district cu privire la problema centrală, considerând că „ structura, secvența și organizarea ” unui API sunt protejate prin drepturi de autor. De asemenea, s-a pronunțat pentru Oracle cu privire la cantitatea mică de copiere literală, considerând că nu era de minimis . Cazul a fost retrimis la Curtea Districtuală pentru un al doilea studiu, să ia în considerare dacă utilizarea de către Google a fost oricum acceptabil, sub doctrina de utilizare corectă , deoarece cazul inițial nu a scos faptele legate de utilizarea loială suficient pentru Curtea de Apel la regula asupra acestui punct.
În octombrie 2014, Google a solicitat Curții Supreme a SUA să audă cazul; această cerere a fost respinsă în iunie 2015.
A doua fază: utilizarea corectă
O a doua petiție adresată de Google în ianuarie 2019 a inclus hotărârea potrivit căreia API-urile sunt protejate prin drepturi de autor. Curtea Supremă a fost de acord să revizuiască această parte a hotărârii în noiembrie 2019.
Procesul Judecătoriei a II-a
După cum a fost ordonat de Curtea de Apel, un nou proces judecătoresc districtual a început la 9 mai 2016, cu privire la întrebarea dacă acțiunile Google au fost folosite corect, având în vedere decizia anterioară potrivit căreia API-urile erau protejate prin drepturi de autor. Argumentele de încheiere au fost finalizate pe 23 mai 2016 și juriul a început deliberările. Oracle a solicitat daune de până la 9 miliarde de dolari SUA. Pe 26 mai 2016, juriul a constatat că Android nu încalcă drepturile de autor deținute de Oracle, deoarece reimplementarea sa de 37 de API-uri Java a fost protejată de o utilizare corectă. Oracle și-a anunțat intenția de a face apel, dar, înainte de a face acest lucru, a încercat moțiuni nereușite pentru a ignora verdictul juriului și apoi pentru a re-judeca. Oracle și-a depus oficial contestația la 26 octombrie 2016.
A doua hotărâre în apel
Apelul Oracle a fost audiat de Curtea de Apel a Statelor Unite pentru Circuitul Federal în 2017. Pe 27 martie 2018, Curtea a decis în favoarea Oracle. Decizia a analizat aspectele unei cereri de „utilizare echitabilă” care urmau să fie hotărâte de un judecător și, respectiv, de un juriu. Apoi a analizat aspectele de fapt la care, trebuia presupus, ajunseseră juriul și implicațiile lor în drept. Acesta a menționat că, într-un caz „mixt” de fapt și drept, precum prezenta dispută, rolul juriului de proces este de a decide asupra faptelor. În opinia sa, judecătorul Alsup a citat cauza Curții Supreme Campbell împotriva Acuff-Rose Music, Inc. 510 SUA 569 (1994), menționând că:
adevărul, în literatură, în știință și în artă, există și pot fi, puține, dacă există, lucruri care, într-un sens abstract, sunt strict noi și originale în toată lumea. Fiecare carte din literatură, știință și artă împrumută și trebuie să împrumute în mod necesar și să folosească multe lucruri bine cunoscute și folosite înainte
Rolul Curții de Apel este de a evalua dacă un juriu rezonabil ar fi putut ajunge la concluziile pe care le-a făcut și dacă decizia judecătorului ar putea fi corectă și rezonabilă în drept. Revizuirea standard a problemelor mixte de drept și de fapt a vizat trei componente: „(1) determinarea standardului juridic care guvernează problema pusă și ce tipuri de fapte istorice sunt relevante pentru acel standard; (2) constatarea faptelor istorice din caz la mână sunt; și (3) evaluarea faptelor istorice constatate îndeplinesc testul juridic care reglementează întrebarea la care trebuie răspuns ”(Decizia p. 19). Cu excepția unei erori clare, rolul juriului se limitează la determinarea „faptelor istorice” contestate (2). Faptele nu sunt discutate. "Este de necontestat că Google a copiat textual codul de declarare al celor 37 de pachete Java API 11.500 de linii din codul protejat prin drepturi de autor al Oracle. De asemenea, a copiat SSO-ul pachetelor Java API. (Decizia p. 10)" De asemenea, este stabilit și Google recunoaște că software-ul copiat este creativ și original.
Curtea a constatat că, din punct de vedere al dreptului, utilizarea Java de către Google nu ar fi putut intra sub incidența utilizării corecte, chiar dacă toate aspectele de fapt hotărâte de juri ar fi fost în favoarea Google. Curtea de Apel a constatat că utilizarea de către Google a declarațiilor de cod API nu a îndeplinit niciunul dintre cele patru criterii actuale de utilizare loială, ci a fost doar o reutilizare netransformată. Nu fusese transformator, deoarece era folosit în aceleași scopuri, fără modificări sau rescrieri minime. Nu a fost minim, deoarece s-a convenit că doar 170 de linii din cele 11.500 de linii copiate erau necesare pentru scopurile Google. Nu se afla în niciun exemplu de transformare și nici nu intenționa să permită interoperabilitatea terților, deoarece Google nu a depus eforturi substanțiale pentru a le utiliza în scopul interoperabilității terților. (De fapt, a constatat că Google a încercat să prevină interoperabilitatea cu alte Java și că anterior i-a fost refuzată o licență de către Sun din acest motiv.) Nu a fost nici transformator în sensul unei noi platforme, deoarece alte smartphone-uri Java au precedat Android. Era plauzibil ca utilizarea să fi afectat Sun / Oracle - poate într-o mare măsură dacă Oracle ar fi de crezut - deoarece, ca urmare, vânzătorii au început să se aștepte ca Oracle să concureze cu prețul cu un derivat disponibil gratuit din propria limbă și să solicite reduceri foarte abrupte și condiții contractuale nedorite. Prin urmare, utilizarea de către Google a codului Java și a API-urilor nu a îndeplinit toate cele patru criterii acceptate în prezent în baza cărora ar fi posibilă utilizarea corectă.
În schimb, Curtea a constatat că scopul Google a fost de a spori atractivitatea nașterii platformei sale Android pentru dezvoltatorii existenți, care erau adesea familiarizați cu Java, și de a evita „oboseala” de rescriere a codului (ceea ce ar fi putut face) necesar pentru implementarea 170 de linii de detalii API care erau într-adevăr necesare. „Facilitatea pentru sine”, a menționat instanța, este bine stabilită pentru a nu se încadra în motive valabile pentru o utilizare loială. Curtea a constatat că „Faptul că Android este gratuit nu face ca Google să folosească pachetele API Java necomercial”. Oracol
a conceput o schemă de licențiere pentru a atrage programatori în timp ce comercializa simultan platforma. În partea relevantă, Oracle percepe o taxă de licențiere pentru cei care doresc să utilizeze API-urile pe o platformă concurentă sau să le încorporeze într-un dispozitiv electronic. Pentru a păstra filosofia „scrie o dată, rulează oriunde”, Oracle impune licențiatelor cerințe stricte de compatibilitate.
Scopul a fost comercial, faptele istorice stabilite de către juriu nu au îndeplinit niciunul dintre criteriile de utilizare loială, iar Curtea a retrimis cauza în fața Tribunalului Districtual din Districtul de Nord al Californiei pentru a stabili cuantumul daunelor pe care Google ar trebui să le plătească. Oracol.
Curtea Supremă de Justiție
.jpg)
Google a depus o cerere pentru cererea de autorizare la Curtea Supremă a Statelor Unite în ianuarie 2019 pentru a contesta cele două hotărâri pronunțate de curtea de apel în favoarea Oracle. În petiția sa, Google și-a concentrat cazul asupra faptului că drepturile de autor se extind la o interfață software cum ar fi un API și dacă utilizarea API-ului Java de către Google a intrat în utilizarea corectă, așa cum s-a constatat la procesele cu juriu. În ordinele emise în aprilie 2019, Curtea a solicitat Solicitorului General al Statelor Unite să depună un dosar amicus pentru a prezenta poziția guvernului cu privire la caz. Administrația Trump a susținut Oracle și a cerut Curții să nege certiorari. Microsoft , Mozilla Corporation , Red Hat Inc. și alții au depus rapoarte amicus în sprijinul poziției Google. IBM , Computer & Communications Industry Association , Internet Association , Auto Care Association și un grup colectiv de peste 150 de academicieni și profesioniști în domeniul computerelor au depus, de asemenea, rapoarte care susțin poziția Google, avertizând că o decizie în favoarea Oracle ar afecta lumea computerelor, deoarece un întreg.
Curtea Supremă a acordat certiorari la 15 noiembrie 2019 și era de așteptat să audă cazul la 24 martie 2020. Cu toate acestea, Curtea Supremă a amânat sesiunea de discuții din martie pe 16 martie în lumina preocupărilor legate de COVID-19 și a anunțat ulterior că Google v. Oracle a fost unul dintre mai multe cazuri din perioada 2019-2020 care a fost amânată până în prima săptămână a termenului 2020-2021. În urma întârzierii, Curtea a solicitat părților să prezinte rapoarte suplimentare referitoare la întrebarea cu privire la al șaptelea amendament ridicată de Google, având în vedere că instanța din districtul federal a depășit unele concluzii ale faptelor pe care juriul le-a încheiat în cazul lor la nivel de district.
Argumente orale au fost ascultate prin teleconferință din cauza pandemiei COVID-19 în curs de desfășurare pe 7 octombrie 2020. Judecătoarea Ruth Bader Ginsburg a murit luna precedentă, iar înlocuitorul ei, judecătorul Amy Coney Barrett , nu fusese încă confirmat, așa că Barrett nu a luat parte în procedură. Observatorii instanțelor au constatat că, în timp ce judecătorii păreau să fie de partea Oracle cu privire la argumentele privind drepturile de autor, aceștia au respectat și argumentele prezentate de Microsoft, care a luat partea Google în acest caz. Microsoft a argumentat într-un comunicat amicus că hotărârea în favoarea Oracle ar putea răsturna industria software-ului. Câteva întrebări s-au concentrat asupra modului în care API-urile se încadrau în distincția idee-expresie a dreptului de autor și dacă s-ar aplica doctrina fuziunii . Justiția Gorsuch s-a văzut, de asemenea, că se concentrează foarte mult pe argumentele celui de-al șaptelea amendament și dacă hotărârea Circuitului Federal de a revoca verdictul juriului instanței de fond a fost corectă.
Decizie
Curtea a emis decizia la 5 aprilie 2021. Cu o majoritate de 6-2, Curtea a decis că utilizarea de către Google a API-urilor Java se încadra în limitele utilizării corecte, anulând hotărârea Curții de Apel a Circuitului Federal și reexaminând cazul pentru o nouă audiere. . Judecătorul Stephen Breyer a scris opinia majoritară. Opinia lui Breyer a început cu presupunerea că API-urile pot fi protejate prin drepturi de autor și, prin urmare, a continuat cu o revizuire a celor patru factori care au contribuit la utilizarea corectă:
- Natura lucrării protejate prin drepturi de autor: analiza lui Breyer a identificat faptul că API-urile au servit mai degrabă ca cod de declarare decât de implementare și că, în contextul dreptului de autor, a îndeplinit o „funcție de organizare” similară cu sistemul zecimal Dewey , în care utilizarea corectă este mai aplicabilă.
- Scopul și caracterul utilizării: Breyer a declarat că Google a preluat și transformat API-urile Java „pentru a extinde utilizarea și utilitatea smartphone-urilor bazate pe Android”, care „au creat [o nouă platformă care ar putea fi ușor utilizată de programatori”. Breyer a mai scris că Google s-a limitat la utilizarea API-urilor Java „după cum este necesar pentru a include sarcini care ar fi utile în programele smartphone”.
- Cantitatea și substanțialitatea materialului protejat prin drepturi de autor: Breyer a spus că Google a folosit doar aproximativ 0,4% din totalul codului sursă Java și că este minim. În ceea ce privește substanțialitatea, Breyer a scris că Google nu a copiat codul care se afla în centrul modului în care a fost implementat Java și că „Google a copiat acele linii nu datorită creativității, frumuseții lor sau chiar (într-un anumit sens), deoarece le-a copiat deoarece programatorii au învățat deja să lucreze cu [Java SE] și ar fi fost dificil ... să atragă programatori către ... Android ... fără ei. "
- Efectul pe piață al preluării drepturilor de autor. Breyer a spus că, în momentul în care Google a copiat API-urile Java, nu era clar dacă Android va avea succes și nu ar trebui considerat ca un înlocuitor pentru Java, ci ca un produs care funcționează pe o altă platformă. Breyer a mai afirmat că, dacă ar fi găsit pentru Oracle, „ar risca să dăuneze publicului”, întrucât „Oracle ar deține singur cheia. Rezultatul s-ar putea dovedi extrem de profitabil pentru Oracle (sau alte firme care dețin drepturi de autor asupra interfețelor computerului) ... [dar] încuietoarea ar interfera, nu mai departe, cu obiectivele de bază ale creativității dreptului de autor. "
Breyer a stabilit că utilizarea de către Google a API-urilor a îndeplinit toți cei patru factori și că Google a folosit „doar ceea ce era necesar pentru a permite utilizatorilor să-și pună talentele acumulate într-un program nou și transformator”. Breyer a concluzionat că "considerăm că copierea în cauză constituie totuși o utilizare echitabilă. Prin urmare, copierea Google nu a încălcat legea drepturilor de autor". Această concluzie a făcut inutilă evaluarea dreptului de autor al API-ului.
Judecătorul Clarence Thomas a scris o opinie divergentă la care s-a alăturat judecătorul Samuel Alito . Thomas a scris că opinia majorității a creat o nouă distincție între codul de punere în aplicare și codul de declarare pe care Congresul le-a respins și, prin urmare, „rezultatul acestei analize denaturante este o opinie care face dificilă imaginația oricărei circumstanțe în care declararea codului va rămâne protejată de drepturi de autor." Thomas a mai afirmat că, în propria sa analiză a utilizării corecte, „utilizarea de către Google a codului protejat prin drepturi de autor nu era decât corectă”.
Impact
Google v. Oracle fusese un caz atent urmărit de industria tehnologiei, întrucât o hotărâre care favoriza Oracle ar fi putut avea efecte semnificative asupra dezvoltării software-ului trecut și viitor, având în vedere utilizarea prolifică a API-urilor. Oponenții hotărârii instanței federale, inclusiv Google și alți dezvoltatori de software bazat pe Android, au ridicat mai multe îngrijorări, inclusiv impactul asupra interoperabilității , inovația software și potențialul actorilor răi de a prelua drepturile la software vechi și de a depune cereri împotriva companiilor care și-au construit software-ul pe ceea ce se presupune că sunt standarde deschise. Dacă această hotărâre ar fi lăsată să rămână valabilă, s-a crezut că companiile vor fi forțate să pună în aplicare standarde deliberat incompatibile pentru a se proteja de riscul unor litigii complexe , îndepărtându-se de tendințele actuale în dezvoltarea de software care s-au concentrat pe îmbunătățirea interoperabilității între diferite servicii care să permită aplicații pentru a comunica între ele, creând platforme mai integrate pentru utilizatorii finali.
Experții din industrie și juridici au declarat că o victorie Oracle ar fi putut crea un efect îngrozitor în dezvoltarea software-ului, deținătorii drepturilor de autor folosind drepturile de autor pentru API-uri pentru a împiedica utilizarea lor în dezvoltarea alternativelor interoperabile prin inginerie inversă , ca de obicei în dezvoltarea de software open source. În același timp, experții au avertizat că o hotărâre care favorizează poziția Google poate slăbi protecția drepturilor de autor pentru dezvoltatorii de coduri software, permițând concurenților cu resurse mai bune să dezvolte produse îmbunătățite de la firme mai mici și să reducă motivul pentru inovație în industrie.
Un exemplu identificat de Wired este sistemul de operare Linux . În timp ce Linux este complet open source , se bazează pe POSIX , un set de API-uri care imită cele ale sistemului de operare comercial Unix care permit niveluri ridicate de interoperabilitate pentru dezvoltatori; un programator ar trebui să scrie doar un set de cod care apoi poate fi compilat pe orice sistem care are același API, chiar dacă arhitectura de calcul a sistemelor este diferită. Dacă jurisprudența ar favoriza Oracle, actualii proprietari ai Unix, Micro Focus , ar fi putut cere daune oricărui dezvoltator de sisteme de operare POSIX care intenționează să utilizeze sistemul de operare pentru uz comercial.
