Na sua opinião, faria sentido se um restaurante que tem em seu cardápio o item “hambúrguer” abrisse processo contra outros restaurantes que também vendem hambúrgueres? Ou uma fábrica que faz cabeças de martelo entre com uma ação contra outras que produzem peças do mesmo item?
Pois se essas analogias parecem tanto simplórias quanto óbvias, o caso Oracle v. Google, a respeito de patentes sobre a API do Java, pode te surpreender. Esses foram alguns dos argumentos e analogias feitas para contextualizar o que são APIs e reimplementações de software para um júri de leigos.
Um júri cuja decisão pode colocar em risco o futuro do desenvolvimento de software no mundo.
O QUÊ, ONDE E POR QUÊ?
Em 2007, o Google lançou sua primeira versão do Android, com a reimplementação de partes do código fonte da linguagem de programação Java. Essa linguagem é proprietária, e naquele momento, era de posse da Sun Microsystems.
Três anos de prosperidade e crescimento da plataforma Android depois, a Sun foi adquirida pela Oracle, e com isso, todos os direitos relacionados ao Java. Meses depois, foi aberto o processo da Oracle contra o Google, por infringimento de patentes das tecnologias Java.
Desde 2010 já foram tomadas três decisões judiciais nesse processo: primeiro, a favor do Google, e em seguida, da Oracle. Em novo processo, aberto em maio de 2016, o Google ganhou novamente.
Essa terceira decisão foi feita há cerca de três meses, em maio. E neste mês, os advogados da Oracle voltaram a entrar com pedido para um novo julgamento. Será mais uma fase da batalha, que já tem até um novo capítulo marcado para o dia 22 de setembro: na data, será debatida a divulgação de informações financeiras confidenciais feita pela advogada da Oracle em janeiro – o Google quer que sejam aplicadas sansões à advogada.
Nesse meio tempo, a Oracle também toma medidas agressivas, como afirmar-se como uma das financiadoras do “The Google Transparency Project”, grupo que tem como objetivo investigar lobbies da gigante de buscas no governo americano.
O CONTEXTO DO PROCESSO
Trocando em miúdos, o processo original era por infringimento de patentes. A Oracle alegava que o Google havia utilizado a linguagem Java indevidamente, para criar o sistema Android, com base em lucro.
É claro que o Google não fez um Ctrl C, Ctrl V das APIs do Java, e colocou tudo dentro do Android. O que eles fizeram na criação do sistema operacional foi reimplementar a API, usando uma forma semelhante, com protótipos parecidos para os métodos e uma lógica e estrutura geral que seguia a mesma linha.
Assim, a aceitação por parte de novos desenvolvedores da plataforma Android seria praticamente imediata: qualquer um que soubesse Java automaticamente saberia programar para Android também. A compatibilidade de ferramentas e recursos também seria facilitada.
Ainda mais: na época em que o Android começou a ser desenvolvido, o CEO da Sun Microsystems, Jonathan Shwartz, parabenizou o Google pelo Android, dizendo que era um grande passo para a comunidade, já que o Java era livre e gratuito para o uso. Isso ocorreu em 2007, anos antes de a Sun ser comprada pela Oracle.
Porém, somente alguns meses depois da aquisição, o processo foi aberto. No total, a Oracle afirmava que havia 37 diferentes infrações às APIs do Java, incluindo a estrutura e implementação do Java. Também estava evidente que a estratégia da Oracle em relação ao Java já era bem diferente da forma com que a Sun encarava sua linguagem.
A PRIMEIRA DECISÃO
Em 2012, o júri decidiu que APIs, por seu caráter altamente funcional, não poderiam ser alvo de patentes. A Lei de Patentes dos EUA (Copyright Act) indica que processos, métodos e sistemas de produção não podem ser patenteados, e as APIs alvo do processo se encaixariam nessa definição.
Nesse momento, chegamos à primeira grande dúvida e discussão aberta por todo esse processo: o que são APIs, do ponto de vista criativo, produtivo e, é claro, judicial? São métodos? São obras criativas, como é a arte?
Ou será que somente a estrutura e organização da API pode ser patenteada? Ou as APIs são como qualquer outro tipo de software, e devem ser protegidas contra cópias e pirataria?
Em particular, chega-se a um impasse, já que esse tipo de discussão ainda não avançou fortemente em praticamente nenhum tribunal do mundo.
Nos Estados Unidos, a maioria das decisões em casos anteriores, envolvendo disputas em torno de software, haviam sido tomadas com base no Copyright Act, encaixando o software (ou a cópia) em casos de plágio de obras criativas tradicionais, como se decide a respeito de cópias de obras de arte ou processos industriais.
A SEGUNDA DECISÃO
Após a primeira decisão, houve apelação por parte da Oracle, no circuito Federal de Tribunais dos EUA, que decidiu a favor da Oracle com base na mesma lei. A prerrogativa usada foi que APIs são um trabalho de criação original, e que assim, a estrutura, sequência e organização desse tipo de software podem ser objeto de patente.
Essa decisão, tomada em maio de 2014, colocou o Google contra a parede, obrigando-os a usar a defesa do “Uso Justo” (Fair Use) como último recurso.
Dentro da legislação norte americana, o Fair Use possibilita o uso criativo de trabalhos anteriores, desde que certas condições sejam satisfeitas. Por exemplo, um filme que faça paródia de outro, ou textos que contenham citações e trechos copiados (com a devida fonte, é claro).
Assim, o processo de patentes se transformou em um processo de Fair Use. Isso não apenas deixou a questão do infringimento das patentes no ar, como abriu uma discussão totalmente nova: a reimplementação de uma API é considerada uma cópia? Uma inspiração? Um novo trabalho criativo?
Nesse contexto, chegamos à terceira e final (por enquanto) dessa disputa judicial.
A TERCEIRA DECISÃO
Uma nova disputa foi aberta, dessa vez com a tentativa de defesa do Google, baseada no Fair Use. Esse julgamento ocorreu esse ano, em maio. A Oracle procurava ressarcimento de 9 bilhões de dólares.
Esse novo julgamento deixou tudo ainda mais confuso. A política de Fair Use dificilmente seria adequada para um debate sobre software, ainda mais um software de interface de linguagem de programação, como foi o caso.
O julgamento mostrou muita criatividade dos advogados que apelaram para descrições e analogias como as que coloquei na Introdução. A defesa do Google se sustentou sobre exemplos cotidianos, como o mesmo nome para pratos em diferentes restaurantes, o que também acontece nas duas implementações da API Java.
Por exemplo, a biblioteca java.security existe tanto na implementação do Android quanto da Oracle, e mostra ao desenvolvedor que ele irá encontrar métodos para proteger e transferir dados de forma segura.
Nessa lógica, um processo sobre uma API faria tanto sentido quanto uma empresa que produz parafusos processar outra que esteja lucrando com a venda de uma máquina montada com esses parafusos. Afinal, eles têm forma de parafuso e função de parafuso, porque são parafusos.
Não é o mesmo código, não são idênticos, mas têm forma e função parecidos, porque é assim que deveria ser. Com essa argumentação, o Google procurou mostrar que estava usando o conceito de Fair Use para gerar novas criações.
Juridicamente, a decisão sobre algo ser coberto pelo Fair Use recai sobre certos questionamentos, que envolvem tanto o trabalho criado originalmente quanto o modificado. Por exemplo:
• Quão grande foi a modificação do trabalho original?
• O trabalho original foi impactado em seu mercado ou oportunidades geradas para seus criadores?
• A cópia teve fins comerciais?
Aplicar o Fair Use é afirmar que o material em questão é protegido por copyright, mas que seu uso não autorizado serve a uma necessidade pública maior.
O problema é que aplicar esse conceito a APIs não é uma das melhores ideias, porque APIs são elementos funcionais: mesmo após implementadas, se não estão sendo usadas, não servem para nada, mesmo que o sistema por trás (o Java, no caso) esteja em funcionamento.
Sendo assim, o Fair Use, criado para proteção de trabalhos criativos sobre cópias não autorizadas não se encaixa bem, porque APIs são essencialmente funcionais.
Mas como as APIs do processo já haviam sido declaradas patenteáveis (e houve código patenteado parcialmente copiado pelo Google) em 2012, essa era a única forma de defesa das acusações da Oracle.
Em 26 de maio de 2016, o júri responsável pela decisão deu ganho de causa para o Google, já que sua reimplementação servia ao caso de Fair Use.
E é claro, a Oracle pretende apelar, como já fez após a primeira decisão.
E POR QUE DEVO ME IMPORTAR COM ISSO?
A vitória da Oracle poderia abrir precedentes para casos bastante complicados no mundo do TI. E isso poderia afetar de forma imprevisível toda a economia mundial.
Afinal de contas, reimplementações de APIs são comuns desde que APIs existem. A própria Oracle já lançou mão dessa estratégia de engenharia de software, tendo produtos com reimplementações do SQL (linguagem para buscas em bancos de dados), vindas de código originalmente criado pela IBM.
Até as próprias APIs do Java, criadas pela Oracle, são reimplementações de linguagens de programação como Perl 5 e C. Irônico, não?
O resultado favorável à Oracle poderia dar o poder de limitar, através de processos judiciais, diversas startups e projetos open source, com a liberdade de derrubar tais projetos.
Há vários outros exemplos, que foram usados pelo Google em sua defesa, para indicar que essa é uma prática comum e recorrente no mercado, e que sua proibição seria uma quebra de paradigmas nunca antes vista, colocando em risco toda a estrutura de TI conhecido.
Se reimplementações são infrações às patentes de APIs, toda a indústria de tecnologia e API passará a ter as mãos sujas. Dificilmente os grandes negócios sobreviveriam.
A inovação possivelmente seria interrompida ou teria sua velocidade fortemente reduzida, no que envolve diferentes implementações e integrações entre software.
Startups e projetos de código aberto provavelmente não teriam a inércia necessária para saírem do papel.
O futuro do software e de muito da economia pode depender disso. No primeiro julgamento no circuito Federal de Tribunais, a decisão foi a favor da Oracle. E agora?
Só o futuro dirá. Mas por ora, é bem possível que a relevância de Java no cenário de desenvolvimento diminua, e já vemos alguma movimentação em direção a outras linguagens, sendo o Node.js uma delas.
Outra tendência é que as APIs tenham seus termos de uso e condições jurídicas bem esclarecidas. Já falamos sobre isso no post do blog da Sensedia: Blocos de Construção para Exposição de APIs.
Antes a dúvida pairava somente se o fornecedor da API poderia mudar a interface dela sem avisar, causando uma quebra do seu código. Agora, é necessário também avaliar mais cuidadosamente se você realmente pode usar essa API, sob quais regras e para qual finalidade.
Fonte: www.abcdoabc.com.br
