Google LLC v. Oracle America, Inc. -Google LLC v. Oracle America, Inc.
| Google LLC v. Oracle America, Inc. | |
|---|---|
| |
| Argumentado em 7 de outubro de 2020, decidido em 5 de abril de 2021 | |
| Nome completo do caso | Google LLC v. Oracle America, Inc. |
| Arquivo nº | 18-956 |
| Citações | 593 US ___ ( mais ) |
| História de caso | |
| Anterior |
|
| Questões apresentadas | |
| |
| Contenção | |
| A cópia do API Java SE pelo Google, que incluía apenas as linhas de código necessárias para permitir que os programadores colocassem seus talentos acumulados para trabalhar em um programa novo e transformador, foi um uso justo desse material como uma questão de lei. | |
| Filiação ao tribunal | |
| |
| Opiniões de caso | |
| Maioria | Breyer, acompanhado por Roberts, Sotomayor, Kagan, Gorsuch, Kavanaugh |
| Dissidência | Thomas, acompanhado por Alito |
| Barrett não tomou parte na consideração ou decisão do caso. | |
Google LLC v. Oracle America, Inc. foi um caso legal nos Estados Unidos relacionado à natureza do código de computador e à lei de direitos autorais . A disputa centrou-se na utilização de partes da linguagem de programação Java 's interfaces de programação de aplicativos (APIs) e cerca de 11.000 linhas de código fonte , que são de propriedade da Oracle (através da subsidiária, Oracle America, Inc., proveniente da Sun Microsystems ), dentro primeiras versões do sistema operacional Android pelo Google . Desde então, o Google fez a transição do Android para um mecanismo livre de direitos autorais, sem o código-fonte, e admitiu usar as APIs, mas afirmou que era um uso justo .
A Oracle iniciou a ação argumentando que as APIs eram protegidas por direitos autorais, exigindo US $ 8,8 bilhões em indenização por vendas e licenciamento do Google de versões anteriores do Android que infringiam as leis. Embora dois julgamentos de júri em nível de tribunal distrital tenham decidido a favor do Google, o tribunal federal revogou ambas as decisões, afirmando que as APIs são protegidas por direitos autorais e que o uso do Google não se enquadra no uso justo. O Google entrou com uma petição bem-sucedida na Suprema Corte para ouvir o caso no mandato de 2019, com foco na capacidade de copyright das APIs e subsequente uso justo; o caso foi adiado para o prazo de 2020 devido à pandemia COVID-19 . Em abril de 2021, a Suprema Corte decidiu em uma decisão de 6–2 que o uso das APIs Java pelo Google se enquadrava nos quatro fatores de uso justo, ignorando a questão sobre a capacidade de copyright das APIs. A decisão reverteu a decisão do Circuito Federal e reenviou o caso para revisão posterior.
O caso tem sido de interesse significativo nas indústrias de tecnologia e software, já que vários programas de computador e bibliotecas de software, particularmente em código aberto , são desenvolvidos pela recriação da funcionalidade de APIs de produtos comerciais ou concorrentes para ajudar os desenvolvedores na interoperabilidade entre diferentes sistemas ou plataformas .
Fundo
Desenvolvimento Java
Java foi originalmente desenvolvido na Sun Microsystems a partir de dezembro de 1990. Incluía uma nova linguagem de programação , uma máquina virtual e um conjunto de bibliotecas para uso com a linguagem. Essas bibliotecas são documentadas para programadores por meio de interfaces de programação de aplicativos (APIs), que dizem aos programadores quais informações fornecer às funções da biblioteca e quais resultados esperar de volta, eliminando qualquer necessidade de o programador saber como a biblioteca que estão usando faz o que faz. Juntas, essas bibliotecas fornecem a "máquina virtual Java" que os programadores escrevem programas para usar (executar). A maneira comum em que um conjunto comum de bibliotecas é usado em todas as "máquinas virtuais Java" permite a interoperabilidade ou, conforme comercializado pela Sun, " Escreva uma vez, execute em qualquer lugar "; um programador precisa apenas criar uma versão de seu software que, devido ao único grupo de APIs comum a todas as máquinas virtuais Java, pode ser executado em qualquer plataforma de computação que suporte Java.
A linguagem Java foi lançada ao público em 1995, sob a Sun Community Source License , tornando o código-fonte disponível gratuitamente, mas exigindo que os produtos que usam o código fossem mantidos no padrão Java e que quaisquer trabalhos derivados comerciais fossem licenciados pela Sun. Embora qualquer pessoa pudesse programar na própria linguagem, a Sun manteve as bibliotecas Java Platform, Standard Edition (Java SE) e Mobile Edition (Java ME), fornecidas aos usuários como bytecode Java pré-compilado e suas respectivas APIs, bem como a tecnologia Kits de compatibilidade (TCKs) que testaram uma implementação em relação ao padrão Java. Durante 2006 e 2007, devido à pressão dos desenvolvedores, a Sun alterou a licença de vários pacotes Java para usar a GNU General Public License com uma "exceção de caminho de classe" , permitindo aos desenvolvedores o acesso necessário para fazer trabalhos derivados e a capacidade de lançar aplicativos sob uma licença diferente. Isso levou ao OpenJDK (Open Java Development Kit), lançado pela primeira vez em 2007. A Sun manteve forte controle sobre a linguagem e os próprios padrões, licenciando os elementos necessários como TCKs para usuários comerciais. Nesse momento, o modelo de negócios da Sun mudou para se concentrar no licenciamento da plataforma Java para dispositivos integrados , especialmente telefones celulares, e já havia feito acordos de licenciamento com a Nokia , Motorola e Research In Motion .
Desenvolvimento Android
Android, Inc. foi fundada em 2003 por Andy Rubin , Rich Miner , Nick Sears e Chris White para desenvolver uma plataforma de telefone móvel . O Google comprou o Android em 2005 e continuou desenvolvendo o sistema operacional Android . Durante o desenvolvimento do Android, o Google queria incorporar as bibliotecas Java SE. O presidente executivo do Google, Eric Schmidt , abordou o presidente da Sun, Jonathan I. Schwartz, sobre o licenciamento das bibliotecas Java para uso no Android. A Sun ofereceu um acordo de licenciamento entre US $ 30 e 50 milhões . Schmidt disse que o Google teria pago por essa licença, mas eles estavam preocupados que a Sun também tivesse solicitado algum controle compartilhado do Android junto com a taxa. O Google afirma que queria mais controle para abrir o código - fonte da linguagem e permitir que terceiros tirassem melhor proveito de seu código; A Oracle afirma que a Sun recusou porque a intenção do Google era essencialmente bifurcar o Java para uma versão do Google da linguagem e evitar que fosse interoperável com outras versões, uma ideia que era "anátema" para a base de "escrever uma vez executado em qualquer lugar" o idioma. Por causa dessas diferenças de visão, as negociações não chegaram a um acordo e a Sun recusou ao Google uma licença para o Java.
Nesse momento, a implementação do OpenJDK oferecida pela Sun não era tão madura ou completa quanto o Java Standard Edition. Em vez de licenciar o Java, o Google optou por desenvolver uma versão de sala limpa das bibliotecas Java Standard Edition, desenvolvendo as bibliotecas de um começo completamente novo, sem qualquer acesso ao código da Sun. Este se tornou o motor por trás da máquina virtual Dalvik do Android , uma parte central do novo sistema. Parte da máquina virtual incluía 37 chamadas de API e cerca de 11.500 linhas de código consideradas centrais para Java, que foram retiradas do Apache Harmony , uma implementação Java de sala limpa de código aberto desenvolvida pela Apache Software Foundation (ASF). Antes disso, a ASF havia tentado obter as licenças necessárias da Sun para apoiar o projeto Apache Harmony a ponto de chamá-lo de implementação oficial do Java, mas não conseguiu, em parte devido ao licenciamento incompatível com a GNU General Public License e ASF's Apache License , nem poderia obter acesso aos TCKs Java para validar o projeto Harmony em relação à implementação da Sun. Embora o Google tenha declarado que usou esse código para garantir a interoperabilidade com o Java Standard Edition para outros programadores, durante a segunda audiência de apelação, o Google afirmou que tinha usado esse código para fins comerciais para concluir rapidamente o Android e evitar o "trabalho penoso" de recriar o código. A ASF parou de manter o Apache Harmony em 2011, levando o Google a assumir a manutenção dessas bibliotecas.
O Google lançou uma versão beta da plataforma Android em 5 de novembro de 2007 e, uma semana depois, o kit de desenvolvimento de software (SDK), que eles notaram, incluía algumas tecnologias Java. O presidente da Sun, Schwartz, deu os parabéns ao Google no mesmo dia, dizendo que eles "amarraram outro conjunto de foguetes ao impulso da comunidade - e à oportunidade que define a visão em nossos (e outros) planetas". Durante o teste, Schwartz disse que na época do lançamento do Android, apesar de saber que o Google pode ter contornado seus requisitos de licenciamento, "Decidimos cerrar os dentes e apoiá-lo para que qualquer pessoa que o apoiasse nos veria como parte da cadeia de valor".
A Oracle anunciou que compraria a Sun em abril de 2009 por US $ 7,4 bilhões e concluiu a aquisição em janeiro de 2010. Além de permitir que eles entrassem no negócio de hardware, o CEO da Oracle, Larry Ellison, chamou a linguagem Java de "o ativo de software mais importante que já adquirimos " A Oracle continuou a desenvolver Java e buscar oportunidades de licenciamento após a aquisição da Sun.
Com o lançamento do Android KitKat (v4.4) em 2013, o Google removeu a máquina virtual Dalvik e a substituiu pelo Android Runtime , que havia sido construído dentro do Google sem nenhum código-fonte Java. No entanto, o Android continuou a usar as APIs JavaSE ao longo do litígio do caso até o Android Nougat, quando foi totalmente substituído pelo OpenJDK .
Primeira fase: direitos autorais e patentes da API
A primeira fase do caso durou de 2010 a 2015. A Oracle estabeleceu com sucesso que as APIs podem ser protegidas por direitos autorais, mas suas alegações de violação de patente foram rejeitadas. O Google entrou com uma petição na Suprema Corte em outubro de 2014 para revisar o caso, mas foi negado.
Primeiro julgamento no Tribunal Distrital
Em 13 de agosto de 2010, a Oracle processou o Google por violação de direitos autorais e patente no Tribunal Distrital do Distrito Norte da Califórnia . A Oracle afirmou que o Google estava ciente de que havia desenvolvido o Android sem uma licença Java e copiado suas APIs e que, portanto, o Google infringia os direitos autorais da Oracle. A Oracle também citou sete patentes anteriores relacionadas à tecnologia Java criada pela Sun e agora de propriedade da Oracle, das quais o Google deveria estar ciente, pois havia contratado ex-desenvolvedores da Sun que trabalhavam em Java. A Oracle buscou indenização monetária e uma injunção para impedir o Google de usar os materiais supostamente infratores.
O caso foi atribuído ao juiz William Alsup , que o dividiu em três fases: direitos autorais, patente e danos.
A fase de direitos autorais começou em 16 de abril de 2012 e consistiu em várias reivindicações distintas de violação: uma função rangeCheck de nove linhas, vários arquivos de teste, a estrutura, sequência e organização (SSO) do Java (API) e a documentação da API .
A Oracle alegou violação de 37 APIs Java separadas que derivaram do projeto Apache Harmony. Após duas semanas de depoimento, o júri concluiu em 7 de maio de 2012 que o Google havia infringido os direitos autorais relacionados ao código, SSO e documentação das APIs, bem como a função rangeCheck, mas foram travados sobre se esses usos se enquadravam uso justo . O júri também concluiu que o Google tinha motivos suficientes para acreditar, com base na conduta da Sun e da Oracle, que eles não precisavam licenciar o Java da Sun ou da Oracle, mas não confiaram nisso ao desenvolver o Android. A Oracle solicitou um julgamento legal (JMOL) para que o caso rejeitasse qualquer defesa de uso justo, uma vez que o júri foi dividido, bem como para anular a decisão do júri sobre oito arquivos relacionados à segurança que eles revisaram e consideraram não violadores, mas que o Google declarou ter copiado literalmente; Alsup concordou. O Google pediu um JMOL semelhante relacionado ao rangeCheck, mas Alsup negou o pedido.
A fase de patentes teve início em 7 de maio de 2012, com o mesmo júri. No momento do julgamento, o caso de patente da Oracle compreendia reivindicações de duas patentes, 6.061.520 (Método e sistema para realizar a inicialização estática) e RE38104 (Método e aparelho para resolver referências de dados no código gerado). O Google buscou uma defesa sem violação. Para a patente 6061520, eles argumentaram que estavam usando a análise para otimizar a inicialização estática, em vez de "simular a execução" como a reivindicação exigia. Para a patente RE38104, eles argumentaram que a instrução não incluía uma referência simbólica. Em 23 de maio de 2012, o júri considerou a não violação em todas as reivindicações de patentes.
O juiz Alsup emitiu o veredicto final para ambas as fases em 31 de maio de 2012. Embora o júri tenha decidido pela Oracle em relação à violação de direitos autorais das APIs, Alsup determinou que as APIs não eram protegidas por direitos autorais em primeiro lugar:
Contanto que o código específico usado para implementar um método seja diferente, qualquer um está livre sob a Lei de Direitos Autorais para escrever seu próprio código para realizar exatamente a mesma função ou especificação de quaisquer métodos usados na API Java. Não importa se a declaração ou as linhas de cabeçalho do método são idênticas.
Alsup concordou com o júri que a função rangeCheck e oito arquivos de segurança eram uma violação de direitos autorais, mas a única reparação disponível eram danos legais até um máximo de US $ 150.000
Como resultado dessas decisões e de uma estipulação, não houve fase de indenização do júri. As partes concordaram em zero dólares em danos legais pela pequena quantidade de código copiado até junho de 2012.
Primeira decisão de apelação
Logo após a conclusão do caso do Tribunal Distrital, ambas as partes tentaram arquivar JMOLs adicionais sobre os elementos da decisão que a Alsup rejeitou, levando a Oracle a apelar da decisão e o Google a entrar com um recurso cruzado sobre a reclamação de cópia literal. Como o caso envolvia reivindicações relacionadas a patentes, o recurso foi automaticamente atribuído ao Tribunal de Apelações dos Estados Unidos para o Circuito Federal . A audiência foi realizada em 4 de dezembro de 2013, e a sentença foi lançada em 09 de maio de 2014.
O tribunal observou que a Lei de Direitos Autorais fornece proteção a "obras originais de autoria fixadas em qualquer meio de expressão tangível" (p. 17). A história legislativa explica que as obras literárias incluem "programas de computador na medida em que incorporam a autoria na expressão do programador de ideias originais, distintas das próprias ideias" (p. 18). Para se qualificar para proteção de direitos autorais, uma obra deve ser original. 17 USC § 102 (a). O tribunal foi, portanto, "o primeiro a avaliar se a expressão é original do programador" (p. 24), algo que o Google já havia concedido (p. 21). Isso levou o tribunal a concluir "que a estrutura geral dos pacotes de API da Oracle é criativa, original e se assemelha a uma taxonomia" (p. 14). Portanto, reverteu a decisão do tribunal distrital sobre a questão central, declarando que a " estrutura, sequência e organização " de uma API é protegida por direitos autorais. Também julgou pela Oracle quanto à pequena quantidade de cópia literal, sustentando que não era de minimis . O caso foi devolvido ao Tribunal Distrital para um segundo julgamento, para considerar se o uso do Google era aceitável de qualquer maneira, de acordo com a doutrina do uso justo , uma vez que o caso original não trouxe os fatos relacionados ao uso justo o suficiente para o Tribunal de Apelação decidir nesse ponto.
Em outubro de 2014, o Google entrou com uma petição na Suprema Corte dos EUA para ouvir o caso; este pedido foi negado em junho de 2015.
Segunda fase: uso justo
Uma segunda petição do Google em janeiro de 2019 incluiu o julgamento de que as APIs podem ser protegidas por direitos autorais. A Suprema Corte concordou em revisar esta parte da sentença em novembro de 2019.
Julgamento do segundo tribunal distrital
Conforme determinado pelo Tribunal de Recursos, um novo julgamento no tribunal distrital começou em 9 de maio de 2016, sobre a questão de saber se as ações do Google eram de uso justo, dada a decisão anterior de que as APIs eram protegidas por direitos autorais. As alegações de encerramento foram concluídas em 23 de maio de 2016 e o júri deu início às deliberações. A Oracle estava pedindo indenização de até US $ 9 bilhões. Em 26 de maio de 2016, o júri concluiu que o Android não infringe direitos autorais de propriedade da Oracle porque sua reimplementação de 37 APIs Java foi protegida pelo uso justo. A Oracle anunciou sua intenção de apelar, mas antes de fazê-lo, tentou fazer movimentos sem sucesso para desconsiderar o veredicto do júri e, em seguida, realizar um novo julgamento. A Oracle interpôs seu recurso oficialmente em 26 de outubro de 2016.
Segunda decisão de apelação
O recurso da Oracle foi ouvido pelo Tribunal de Recursos do Circuito Federal dos Estados Unidos em 2017. Em 27 de março de 2018, o Tribunal decidiu a favor da Oracle. A decisão analisou os aspectos de uma reclamação de "uso justo" que deveriam ser decididos por um juiz e júri, respectivamente. Em seguida, examinou as questões factuais a que, era de se presumir, o júri havia chegado e suas implicações jurídicas. Ele observou que em um caso "misto" de fato e direito, como o presente litígio, o papel do júri de julgamento é decidir sobre os fatos. O juiz Alsup citou o caso da Suprema Corte Campbell v. Acuff-Rose Music, Inc. 510 U.S. 569 (1994) em sua opinião, observando que:
verdade, na literatura, na ciência e na arte, existem, e podem haver, poucas, se houver, coisas que, em um sentido abstrato, são estritamente novas e originais. Cada livro de literatura, ciência e arte, toma emprestado e deve necessariamente tomar emprestado e usar muito do que era bem conhecido e usado antes
A função do Tribunal de Apelação é avaliar se um júri razoável poderia ter chegado às conclusões que ele fez e se a decisão do juiz poderia ser correta e razoável na lei. A revisão padrão de questões mistas de direito e fato dizia respeito a três componentes: "(1) determinar o padrão jurídico que rege a questão colocada e que tipos de fatos históricos são relevantes para esse padrão; (2) descobrir quais são os fatos históricos no caso em e (3) avaliar se os fatos históricos encontrados satisfazem o teste jurídico que rege a questão a ser respondida "(Decisão, p. 19). Exceto por erros claros, o papel do júri é limitado a determinar 'fatos históricos' em disputa (2). Os fatos não são discutidos. "É indiscutível que o Google copiou literalmente o código de declaração dos 37 pacotes de API Java 11.500 linhas do código protegido por direitos autorais da Oracle. Ele também copiou o SSO dos pacotes de API Java. (Decisão p. 10)" Também está estabelecido e o Google reconhece que o software copiado é criativo e original.
O Tribunal concluiu que, por uma questão de lei, o uso de Java pelo Google não poderia ter se enquadrado no uso justo, mesmo se todas as questões factuais decididas pelo júri tivessem sido a favor do Google. O Tribunal de Apelações concluiu que o uso do Google de declarações de código de API não atendeu a nenhum dos quatro critérios atuais para uso justo, mas foi meramente uma reutilização não transformada. Não foi transformador, uma vez que foi usado para os mesmos fins, mesmo sem alterações ou reescritas mínimas. Não foi mínimo, pois foi acordado que apenas 170 linhas das 11.500 linhas copiadas eram necessárias para os propósitos do Google. Não estava dentro de nenhum exemplo de transformação, nem pretendia permitir a interoperabilidade de terceiros, uma vez que o Google não havia feito esforços substanciais para usá-los para fins de interoperabilidade de terceiros. (Na verdade, ele descobriu que o Google havia tentado impedir a interoperabilidade com outro Java e tinha anteriormente recusado uma licença da Sun por esse motivo.) Também não foi transformador no sentido de uma nova plataforma, uma vez que outros smartphones Java são anteriores ao Android. Era plausível que o uso tivesse prejudicado a Sun / Oracle - talvez em grande medida se a Oracle fosse acreditada - uma vez que, como resultado, os fornecedores começaram a esperar que a Oracle competisse em preço com um derivado disponível gratuitamente de sua própria linguagem e exigisse descontos muito elevados e termos contratuais indesejáveis. Portanto, o uso do código Java e APIs pelo Google não atendeu a todos os quatro critérios atualmente aceitos sob os quais o uso justo seria possível.
Em vez disso, o Tribunal concluiu que o objetivo do Google era aumentar a atratividade de sua plataforma Android nascente para os desenvolvedores existentes, que muitas vezes estavam familiarizados com Java, e evitar o "trabalho penoso" de reescrever o código (o que eles poderiam ter feito) necessário para implementar o 170 linhas de detalhes da API que eram realmente necessários. "Facilitar para si mesmo", observou o tribunal, está bem estabelecido para não se enquadrar nos fundamentos válidos para o uso justo. O Tribunal concluiu que "O fato de o Android ser gratuito não torna não comercial o uso dos pacotes de API do Java pelo Google". Oráculo
desenvolveu um esquema de licenciamento para atrair programadores e, ao mesmo tempo, comercializar a plataforma. Na parte relevante, a Oracle cobra uma taxa de licenciamento de quem deseja usar as APIs em uma plataforma concorrente ou integrá-las em um dispositivo eletrônico. Para preservar a filosofia "grave uma vez, execute em qualquer lugar", a Oracle impõe requisitos de compatibilidade estritos aos licenciados.
O objetivo era comercial, os fatos históricos estabelecidos pelo júri não satisfaziam nenhum dos critérios de uso justo, e o Tribunal reenviou o caso ao Tribunal Distrital do Distrito Norte da Califórnia para determinar a quantidade de danos que o Google deveria pagar Oráculo.
Suprema Corte
.jpg)
O Google entrou com uma petição de mandado de certiorari na Suprema Corte dos Estados Unidos em janeiro de 2019 para contestar as duas decisões tomadas pelo tribunal de apelações em favor da Oracle. Em sua petição, o Google centrou seu caso em se o copyright se estende a uma interface de software como uma API, e se o uso da API Java pelo Google se enquadra no uso justo, conforme encontrado nos julgamentos do júri. Em despachos emitidos em abril de 2019, o Tribunal solicitou ao Procurador-Geral dos Estados Unidos que apresentasse um amicus brief para definir a posição do governo sobre o caso. A administração Trump apoiou a Oracle e instou o Tribunal a negar o certiorari. Microsoft , Mozilla Corporation , Red Hat Inc. e outros entraram com amicus briefs em apoio à posição do Google. A IBM , a Computer & Communications Industry Association , a Internet Association , a Auto Care Association e um grupo coletivo de mais de 150 acadêmicos e profissionais de informática também entraram com documentos de apoio à posição do Google, alertando que uma decisão a favor da Oracle prejudicaria o mundo da computação, pois um todo.
A Suprema Corte concedeu certiorari em 15 de novembro de 2019, e esperava-se que o caso fosse ouvido em 24 de março de 2020. No entanto, a Suprema Corte adiou sua sessão de argumentação de março em 16 de março devido às preocupações em torno do COVID-19 , e posteriormente anunciou que Google v. Oracle foi um dos vários casos do período 2019-2020 a ser adiado até a primeira semana do período 2020-2021. Após o atraso, o Tribunal solicitou às partes que apresentassem documentos adicionais relacionados à questão da Sétima Emenda levantada pelo Google, visto que o tribunal do Distrito Federal anulou algumas das conclusões dos fatos que o júri concluiu em seu caso no nível distrital.
Argumentos orais foram ouvidos por teleconferência devido à pandemia de COVID-19 em andamento em 7 de outubro de 2020. A juíza Ruth Bader Ginsburg havia morrido no mês anterior e sua substituição, a juíza Amy Coney Barrett , ainda não havia sido confirmada, então Barrett não participou no processo. Os observadores do tribunal descobriram que, embora os juízes parecessem estar do lado da Oracle nos argumentos de direitos autorais, eles também aceitaram os argumentos apresentados pela Microsoft, que estava do lado do Google no caso. A Microsoft argumentou em amicus brief que uma decisão a favor da Oracle poderia derrubar a indústria de software. Várias questões focaram em como as APIs se enquadram na distinção entre idéia e expressão de direitos autorais e se a doutrina de fusão se aplicaria. O juiz Gorsuch também se concentrou fortemente nos argumentos da Sétima Emenda e se a decisão do Circuito Federal de anular o veredicto do júri do tribunal foi adequada.
Decisão
O Tribunal emitiu sua decisão em 5 de abril de 2021. Por uma maioria de 6–2, o Tribunal decidiu que o uso de APIs Java pelo Google estava dentro dos limites do uso justo, revertendo a decisão do Tribunal Federal de Recursos de Circuito e devolvendo o caso para uma nova audiência . O juiz Stephen Breyer escreveu a opinião da maioria. A opinião de Breyer começou com a suposição de que as APIs podem ser protegidas por direitos autorais e, assim, procedeu com uma revisão dos quatro fatores que contribuíram para o uso justo:
- A natureza do trabalho protegido por direitos autorais: a análise de Breyer identificou que as APIs serviam como código de declaração em vez de implementação e que, no contexto dos direitos autorais, serviam a uma "função de organização" semelhante ao Sistema Decimal de Dewey , no qual o uso justo é mais aplicável.
- O propósito e caráter do uso: Breyer afirmou que o Google pegou e transformou as APIs Java "para expandir o uso e a utilidade dos smartphones baseados em Android" que "criaram uma nova plataforma que poderia ser prontamente usada por programadores". Breyer também escreveu que o Google se limitou a usar as APIs Java "conforme necessário para incluir tarefas que seriam úteis em programas de smartphone".
- A quantidade e a substancialidade do material protegido por direitos autorais: Breyer disse que o Google usou apenas cerca de 0,4% do código-fonte Java total e era mínimo. Sobre a questão da substancialidade, Breyer escreveu que o Google não copiou o código que estava no centro de como o Java foi implementado e que "o Google copiou essas linhas não por causa de sua criatividade, beleza ou mesmo (em certo sentido) porque de seu propósito. Ele os copiou porque os programadores já haviam aprendido a trabalhar com [Java SE] e teria sido difícil ... atrair programadores para ... Android ... sem eles. "
- O efeito de mercado da obtenção de direitos autorais. Breyer disse que no momento em que o Google copiou as APIs Java, não estava claro se o Android teria sucesso e não deveria ser considerado um substituto do Java, mas um produto operando em uma plataforma diferente. Breyer afirmou ainda que se eles tivessem encontrado a Oracle, isso "arriscaria prejudicar o público", já que "somente a Oracle seria a chave. O resultado poderia ser altamente lucrativo para a Oracle (ou outras empresas que detêm direitos autorais sobre interfaces de computador) ... [mas] o bloqueio interferiria, e não além, nos objetivos básicos de criatividade dos direitos autorais. "
Breyer determinou que o uso das APIs pelo Google atendeu a todos os quatro fatores, e que o Google usou "apenas o que era necessário para permitir que os usuários colocassem seus talentos acumulados para trabalhar em um programa novo e transformador". Breyer concluiu que "consideramos que a cópia aqui em questão, no entanto, constitui um uso justo. Portanto, a cópia do Google não violou a lei de direitos autorais." Esta conclusão tornou desnecessária a necessidade de avaliar os direitos autorais da API.
O juiz Clarence Thomas escreveu uma opinião divergente que se juntou ao juiz Samuel Alito . Thomas escreveu que a opinião da maioria criou uma nova distinção entre implementar código e declarar código que o Congresso rejeitou e, portanto, "o resultado desta análise distorcida é uma opinião que torna difícil imaginar qualquer circunstância em que declarar código permanecerá protegido por direito autoral." Thomas afirmou ainda que, em sua própria análise de uso justo, "o uso que o Google fez desse código protegido por direitos autorais foi tudo menos justo".
Impacto
Google v. Oracle foi um caso observado de perto pela indústria de tecnologia, já que uma decisão favorável à Oracle poderia ter efeitos significativos no desenvolvimento de software no passado e no futuro, devido ao uso prolífico de APIs. Os oponentes da decisão do tribunal federal, incluindo o Google e outros desenvolvedores de software baseado em Android, levantaram várias preocupações, incluindo o impacto sobre a interoperabilidade , inovação de software e o potencial de malfeitores obterem os direitos de software antigo e abrirem processos contra empresas que construíram seu software com base no que se supôs serem padrões abertos. Caso esta decisão fosse mantida, acreditava-se que as empresas seriam forçadas a implementar padrões deliberadamente incompatíveis para se protegerem do risco de litígios complexos , afastando-se das tendências atuais no desenvolvimento de software que se concentraram em melhorar a interoperabilidade entre diferentes serviços permitindo aplicativos para se comunicarem entre si, criando plataformas mais integradas para os usuários finais.
Especialistas jurídicos e da indústria afirmaram que uma vitória da Oracle poderia ter criado um efeito inibidor no desenvolvimento de software, com os detentores de direitos autorais usando os direitos autorais nas APIs para evitar seu uso no desenvolvimento de alternativas interoperáveis por meio de engenharia reversa , comum no desenvolvimento de software de código aberto. Ao mesmo tempo, especialistas alertaram que um julgamento favorável à posição do Google pode enfraquecer a proteção de direitos autorais para desenvolvedores de código de software, permitindo que concorrentes com melhores recursos desenvolvam produtos aprimorados de empresas menores e reduza o motivo de inovação na indústria.
Um exemplo identificado pela Wired é o sistema operacional Linux . Embora o Linux seja totalmente de código aberto , ele é baseado em POSIX , um conjunto de APIs que imita aquelas do sistema operacional Unix comercial que permite altos níveis de interoperabilidade para desenvolvedores; um programador só precisa escrever um conjunto de código que pode ser compilado em qualquer sistema que tenha a mesma API, mesmo se a arquitetura de computação dos sistemas for diferente. Se a jurisprudência favorecesse a Oracle, os atuais proprietários do Unix, Micro Focus , poderiam ter buscado indenização de qualquer desenvolvedor de sistema operacional baseado em POSIX que pretendesse usar o sistema operacional para uso comercial.