Dez anos após a Oracle ter processado pela primeira vez o Google por causa do código na plataforma Android, os dois gigantes da tecnologia estão finalmente enfrentando o Supremo Tribunal. Desde então, já houve três julgamentos e dois recursos. Bilhões de dólares estão em jogo; muitos milhões foram provavelmente gastos em um desfile de litigantes experientes, testemunhas especializadas e exibições bizarras de julgamentos destinados a explicar a programação para jurados não técnicos. Tudo isso pode estar chegando a um encerramento anticlimático na quarta-feira de manhã, com uma teleconferência oral da Suprema Corte no meio de uma pandemia.
Quando o Google desenvolveu o Android pela primeira vez, ele decidiu tornar a plataforma móvel compatível com Java. Na época, as aplicações para o ambiente iOS eram escritas em Objective-C, uma linguagem similar ao ubíquo C, mas que de resto só era utilizada no contexto do desenvolvimento de aplicações iOS. A Apple tinha um avanço significativo em mobile.
Google tinha como objetivo tornar o Android competitivo, tornando a plataforma interoperável com Java, uma linguagem de programação popular com uma comunidade de desenvolvedores robusta. Para isso, a empresa reimplantou várias APIs Java, incluindo as 37 que estão em questão na ação judicial. Para a Oracle e o Google, o processo é sobre se a Oracle – que possui o Java Standard Edition – tem agora direito a um pedaço de Android, ao som de bilhões de dólares. Para todos os outros, o processo é sobre se a compatibilidade da linguagem é equivalente à violação de direitos autorais.
Para dizer o mínimo, era um mundo diferente quando o caso foi apresentado pela primeira vez. Ambas as empresas mudaram de mãos – a ação judicial começou enquanto Larry Ellison ainda estava no comando da Oracle e Eric Schmidt era o CEO do Google. A Google é agora uma subsidiária da Alphabet. O Android está na versão 11. A única coisa que parece ter ficado na mesma é a popularidade do Java como linguagem de programação.
Mas longe do Vale do Silício, houve uma mudança radical que engloba muito mais do que meros 6 bilhões de dólares e o futuro da lei de direitos autorais. Desde a última vez que o Google pediu ao Supremo Tribunal que revisasse o seu caso, três vagas na Suprema Corte foram preenchidas. Em 2014, o SCOTUS negou o certiorari, enviando o caso de volta para o tribunal distrital de São Francisco para um novo julgamento. Desde então, um juiz se aposentou e dois faleceram – mais recentemente, a juíza Ruth Bader Ginsburg.
A parte menos importante do legado de Ginsburg é que ela foi o voto mais confiável nos casos de direitos autorais, tendendo a votar a favor dos detentores de direitos. Sua perda também significa que o Google v. Oracle está sendo ouvido por oito juízes e, portanto, propenso a um tribunal dividido. (No caso Lotus vs. Borland, em 1996, um tribunal de oito juizes dividiu uniformemente e não conseguiu estabelecer precedente nacional).
Quando o Google vs. Oracle começou em 2010, ele envolveu sete patentes bem como uma reivindicação de direitos autorais; em 2012, o caso tinha sido reduzido a apenas 37 APIs Java, compostas de cerca de 11.500 linhas de código. As 11.500 linhas de código em questão foram escritas em uma “sala limpa”, um silo de projeto afastado do código existente, eles estavam fazendo engenharia reversa. Este feito de engenharia tornou-se necessário quando as negociações entre o Google e a Sun Microsystems – que era proprietária da plataforma Java – falharam. A Oracle adquiriu a Sun no início de 2010; em agosto, ela havia entrado com uma ação contra o Google.
Uma interface de programação de aplicativos (API) neste contexto é uma coleção de interações bem definidas na programação de software. É uma abreviação para acessar rapidamente serviços, bibliotecas, e outras funções. Uma API pode condensar código comumente usado ou verboso, permitindo aos programadores construir sem ter que reinventar a roda.
Uma API não é exatamente um dicionário, mas está perto o suficiente de uma que Oracle v. Google coloca um enorme problema. Tecnicamente, você pode programar em Java sem usar os 37 pacotes da API Java em questão. Mas você provavelmente não estaria escrevendo nada útil, já que essas APIs incluem java.lang e java.util, pacotes básicos que oferecem funções como fazer contas ou representar datas e horas. Eu também posso tecnicamente escrever este artigo sem metáforas ou similes, mas não é algo que eu gostaria de fazer, ou que qualquer um gostaria de ler.
Para ser claro, as 37 APIs Java foram reimplementadas em uma sala limpa. A Oracle não está afirmando que elas são literalmente as mesmas, mas sim que a “estrutura, seqüência e organização” das APIs são tão parecidas a ponto de violar a lei de direitos autorais. Com isso, significa que os pacotes, classes e métodos dessas APIs são nomeados da mesma forma. Uma linha de código escrita para rodar em Java Standard Edition não necessariamente rodará no Android, mas ficará muito mais perto do que estaria de outra forma.
A primeira execução na ação judicial resultou em um julgamento bifurcado em 2012 – um julgamento para as reivindicações de patentes, e um segundo julgamento apenas para as reivindicações de direitos autorais. No julgamento de patentes, o júri decidiu que o Google não tinha infringido nenhuma patente. No julgamento de direitos autorais, dois pontos legais distintos estavam em questão: primeiro, se o código declarante e a “estrutura, sequência e organização” das APIs eram passíveis de direitos autorais; e segundo, se o uso do Google era um uso justo. O juiz decidiu sobre a questão dos direitos autorais e enviou a questão do uso justo para ser avaliada pelo júri.
O júri decidiu sobre o uso justo. Mas o juiz – que coincidentemente escreveu código como hobby – decidiu que o código declarante e o SSO das APIs não estavam cobertos por direitos autorais, afinal. O Copyright Act não se aplica a nenhuma “idéia, procedimento, processo, sistema, método de operação”, e a forma como os pacotes, classes e métodos foram nomeados e ordenados era funcional demais para ser considerada digna de copyright.
Foi esta decisão específica que foi anulada pelo Circuito Federal em 2014. Como o primeiro júri tinha pendurado no uso justo, um júri inteiramente novo teve que ser convocado para mais um julgamento sobre o uso justo em 2016. O Júri, ao lado do Google.
Mas em 2018, a Circunscrição Federal – o mesmo tribunal de apelação que em 2014 tinha enviado o caso de volta ao Júri – decidiu que o veredicto do Júri tinha de ser anulado a favor do Oracle, porque as provas apresentadas no julgamento indicavam claramente que não se podia chegar a uma determinação de uso justo e, portanto, não deveria ter ido a um júri em primeiro lugar.
Depôr de lado um veredicto do júri é o Big Judge Energy, de uma forma que é provável que seja controversa para a Suprema Corte, e é provável que a argumentação oral de quarta-feira apresente uma boa dose de discussão sobre o papel do juiz contra o júri em um caso de direitos autorais. A questão de quem decide o uso justo, e quando, é algo que pode ser extrapolado para muitos casos legais diferentes (que SCOTUS ama) e também não tem nada a ver com matemática (que SCOTUS não ama).
Felizmente o verdadeiro coração do caso está na parte com toda a matemática e tal. A decisão da Suprema Corte no Google v. Oracle pode ter enormes ramificações para a indústria de software, mais importante porque a Suprema Corte pode estar revisitando a questão da copyrightability – a questão de se o código declarante e a estrutura, seqüência e organização das APIs Java estão cobertas pela lei de copyright – que não está em jogo desde 2014.
Esta disputa de décadas entre Google e Oracle não é totalmente racional. A reimplementação das APIs Java pelo Google faz parte de uma longa tradição de iteração que era, na sua maioria, tida como certa até agora. Produtos como o MySQL da própria Oracle foram criados como iterações do SQL.
Isto não quer dizer que o copy-pasting seja o coração do Silicon Valley. Mas há um ponto em que se quer encorajar as coisas a parecerem iguais, em vez de serem diferentes por uma questão de diferença. Colocando as coisas de forma aproximada: a codificação é o processo de falar com a máquina. Mas muito poucas pessoas que desenvolvem software nos dias de hoje realmente falam diretamente com a máquina. O software existe em camadas sobre camadas iterativas, um jogo de sussurros que eventualmente chega ao metal nu do computador. Novas linguagens são derivadas das antigas; novas bibliotecas são construídas sobre as existentes; dependências são empilhadas umas sobre as outras como um jogo de Jenga que está prestes a terminar a qualquer momento. E Google v. Oracle é um caso que está acontecendo em um dos níveis mais baixos de um jogo em andamento de Jenga.
Estamos prestes a descobrir se o Supremo Tribunal sabe disso.
Correção: Uma versão anterior do artigo não mencionava que a base do código Android era biliões de linhas de código. Está na casa dos milhões. Nós lamentamos o erro.