Larry Ellison gasta US$ 70 bilhões em datacenters de IA e diz que “modelos de IA escrevem o código da Oracle”. Mas se você tentar mandar um PR com código gerado por IA para o OpenJDK, vai levar um block na hora. Bem-vindo ao mundo da Oracle, onde a regra vale pra você, não pra eles.

O OpenJDK, que é basicamente o coração open source do Java, publicou uma política provisória que proíbe qualquer contribuição gerada por modelos de linguagem, modelos de difusão ou sistemas similares de deep learning. E quando eles dizem “qualquer”, é qualquer mesmo: código-fonte, documentação, pull requests, emails na lista de discussão, páginas no wiki e até bug reports no JBS (Java Bug System).

A justificativa? Três pilares: segurança, propriedade intelectual e carga de revisão. Vamos destrinchar cada um.

O problema do código “quase certo”

Se você já usou Copilot, Claude ou qualquer assistente de código, sabe que a IA tem um talento especial pra gerar código que parece correto. Compila, passa nos testes básicos, segue o estilo do projeto. Mas tem um off-by-one escondido, um edge case ignorado, ou uma suposição sobre thread safety que não se sustenta em produção.

Agora imagina isso no JDK. Estamos falando do runtime que roda em bilhões de dispositivos, de servidores bancários a aplicações governamentais. Um bug sutil no java.util.concurrent ou no garbage collector não aparece num teste unitário. Ele aparece seis meses depois, numa sexta-feira às 23h, quando o sistema de pagamentos de um banco processa o lote errado.

O Governing Board do OpenJDK argumenta que o código gerado por IA aumenta a carga dos revisores de forma desproporcional. Não porque o código é ruim de cara, mas justamente porque ele é plausível o suficiente pra exigir uma inspeção mais profunda. É mais fácil rejeitar um PR óbviamente quebrado do que auditar linha por linha algo que parece ok mas pode não ser.

A regra dos 10%

Uma das partes mais interessantes da política está no FAQ. A pergunta é direta: “Se eu gerar 100 linhas com IA e editar 10, posso contribuir?”

A resposta: não.

A política é explícita: se a contribuição foi gerada, em parte ou no todo, por um LLM, ela não pode ser submetida. Editar 10 linhas de 100 não muda o fato de que 90 foram geradas por máquina. Pra Oracle, não existe “parcialmente humano” quando se trata de contribuições ao OpenJDK.

Na prática, o que o desenvolvedor pode fazer é usar IA pra entender o código, debugar, revisar e pesquisar. Usar como ferramenta de estudo, basicamente. Mas o output não pode ir pro repositório.

Os contribuidores agora precisam marcar um checkbox de conformidade no Skara, o sistema de PRs do OpenJDK, confirmando que não usaram IA generativa na contribuição.

GraalVM: a mesma Oracle, a regra oposta

Aqui a história fica boa.

O GraalVM é um projeto da Oracle Labs, o braço de pesquisa da Oracle. Ele usa o mesmo Oracle Contributor Agreement (OCA) que o OpenJDK. Mesma empresa, mesmo contrato legal. Mas a política de IA? Completamente oposta.

No GraalVM, contribuidores podem usar assistentes de IA pra rascunhar, transformar, explicar e revisar código e documentação. A abordagem é baseada em responsabilidade humana: o desenvolvedor que submete é responsável por toda a contribuição, precisa entender o código, defender as decisões e manter o que escreveu.

A divulgação de que IA foi usada é “encorajada quando ajuda os revisores”, mas é opcional.

Então me explica: se o OCA exige que o contribuidor tenha os direitos de propriedade intelectual sobre o que submete, e se a incerteza sobre IP de código gerado por IA é justamente o motivo da proibição no OpenJDK, como o GraalVM aceita as mesmas contribuições sob o mesmo contrato?

A resposta curta: o GraalVM não está sob a jurisdição do OpenJDK Governing Board. É um projeto separado, com governança própria. Mas a contradição legal é gritante. Mesmo contrato, mesma empresa, conclusões opostas sobre o mesmo risco.

Larry Ellison e os US$ 70 bilhões

A ironia fica ainda mais pesada quando você olha pro discurso da liderança da Oracle.

No Oracle AI World 2025, Larry Ellison, cofundador e CTO da Oracle, disse abertamente que “nossos modelos de IA estão escrevendo o código da Oracle”. Ele foi além: “nós declaramos a intenção, mas o modelo escreve o procedimento passo a passo, aquela coisa que normalmente chamamos de programa de computador”.

Mike Sicilia, co-CEO da Oracle, complementou dizendo que ferramentas de IA permitem que times menores entreguem soluções mais rápido.

E pra completar, a Oracle está investindo US$ 70 bilhões em expansão de datacenters focados em IA só nesse ano. Um investimento tão agressivo que a S&P rebaixou o rating de crédito da Oracle pra BBB, apenas um nível acima de “junk”, citando incerteza sobre o retorno desses investimentos.

Então vamos recapitular: a Oracle usa IA pra escrever seu próprio código, investe US$ 70 bilhões em infraestrutura de IA, o CEO diz publicamente que IA já programa na empresa. Mas se um desenvolvedor da comunidade Java quiser contribuir com código assistido por IA pro OpenJDK? Proibido.

A questão da propriedade intelectual

O argumento de IP da Oracle não é inventado. Existe uma incerteza real sobre quem detém os direitos autorais de código gerado por IA.

O U.S. Copyright Office já declarou que material “puramente gerado por IA” não tem proteção de copyright. Isso cria um problema concreto: se um contribuidor submete código gerado por IA ao OpenJDK, e esse código não tem copyright, a garantia de IP que o OCA exige fica comprometida.

O contribuidor assina dizendo que tem os direitos sobre o que está submetendo. Mas se a lei diz que ninguém tem direitos sobre output de IA, essa assinatura não vale nada.

É um argumento juridicamente sólido. O problema é que ele se aplica igualmente ao GraalVM e ao código interno da Oracle. Se IA está escrevendo código proprietário da Oracle, quem detém o copyright? A Oracle enfrenta o mesmo risco que está tentando evitar no OpenJDK.

Como outros projetos estão lidando com isso

A Oracle não está sozinha nessa discussão, mas está longe de representar o consenso.

O Linux kernel tomou a decisão mais pragmática. Linus Torvalds e os maintainers estabeleceram uma política formal que permite código assistido por IA, mas com regras claras: o humano que submete é legalmente responsável por cada linha, bugs e falhas de segurança incluídos. Agentes de IA não podem usar a tag Signed-off-by, precisando usar a tag Assisted-by pra transparência.

A filosofia é diferente da Oracle: em vez de proibir a ferramenta, responsabilize o humano. Se o dev mandou um PR com código de IA que quebra algo, ele responde por isso, exatamente como responderia por código escrito à mão que tivesse o mesmo bug.

Até hoje, 77 a 86 organizações open source publicaram políticas formais sobre IA, incluindo Apache, Eclipse, CPython e curl. Não existe consenso. Mas a tendência dominante é permitir com responsabilização, não proibir completamente.

O que ninguém consegue fiscalizar

Aqui está o elefante na sala que ninguém quer discutir: como exatamente a Oracle pretende verificar se um PR foi gerado por IA?

Não existe detector confiável de código gerado por IA. Os detectores de texto já são notoriamente imprecisos, e código é ainda mais difícil de classificar. Se um desenvolvedor usa IA pra gerar uma solução, reescreve trechos, reorganiza, renomeia variáveis e submete como próprio, ninguém vai saber.

O checkbox no Skara é uma declaração de boa-fé, não uma verificação técnica. É como aquela declaração de alfândega onde você marca que não está trazendo nada proibido. Funciona na base da confiança, não da detecção.

Isso cria um incentivo perverso: contribuidores honestos seguem a regra e ficam em desvantagem. Contribuidores que ignoram a regra (e reescrevem o suficiente pra mascarar) continuam submetendo código normalmente. A política pune a transparência.

O precedente Ghostty

Uma abordagem alternativa que surgiu na discussão da comunidade é o modelo do Ghostty, o emulador de terminal criado pelo Mitchell Hashimoto (fundador da HashiCorp).

No Ghostty, contribuidores não são proibidos de usar IA. Mas precisam explicar suas soluções com as próprias palavras. Se um revisor pergunta “por que você escolheu essa abordagem?”, e o contribuidor não consegue responder sem consultar o ChatGPT, o PR é rejeitado.

É um filtro mais inteligente: não importa como o código foi gerado, importa se o humano entende o que está submetendo. Se você usou IA como ponto de partida mas domina a solução, ótimo. Se você colou output do Copilot sem entender, vai ser pego na revisão.

O OpenJDK poderia adotar algo similar, mas escolheu o caminho da proibição absoluta.

O custo escondido: contribuidores desistindo

Existe um efeito colateral que a Oracle pode não ter calculado. Contribuir pro OpenJDK já era difícil antes da política de IA. O processo envolve assinar o OCA, configurar o ambiente de build (que não é trivial), entender as convenções do projeto e passar por revisões rigorosas.

Agora adicione uma camada de paranoia: “será que o revisor vai achar que usei IA nesse trecho?”. Desenvolvedores que escrevem código limpo e bem estruturado podem ter seus PRs questionados simplesmente porque o código “parece bom demais”. É o inverso do problema original: em vez de código ruim passando despercebido, código bom sendo suspeito.

Alguns contribuidores na thread do Hacker News relataram que já estão pensando duas vezes antes de investir tempo em contribuições pro OpenJDK. Não porque discordam da política, mas porque o risco de ter um PR rejeitado por suspeita de IA (mesmo sendo 100% humano) não vale o esforço voluntário.

O Linux kernel, em contraste, está atraindo mais contribuidores justamente por permitir IA com transparência. A tag Assisted-by normaliza o uso de ferramentas sem estigma. Você usou IA? Ok, declara e assume a responsabilidade. Simples.

O que isso significa pra quem programa em Java

Se você contribui ou pretende contribuir pro OpenJDK, as regras são claras agora:

Pode usar IA pra estudar o codebase, entender como o garbage collector funciona, debugar uma race condition, revisar seu próprio código. Tudo isso é permitido.

Não pode usar IA pra gerar o código que vai pro PR. Nem parcialmente. Nem “só a estrutura básica”. A política é binária: se IA gerou, não entra.

Se você programa em Java mas não contribui pro OpenJDK (que é a maioria), essa política não te afeta diretamente. Seu empregador provavelmente não liga se você usa Copilot no código proprietário. Na verdade, se seu empregador for a Oracle, ele encoraja que você use IA.

Pra quem acompanha o ecossistema open source, o precedente é mais importante que a regra em si. Se o OpenJDK, um dos projetos mais influentes do mundo, bane IA, outros projetos podem seguir o exemplo. Se a tendência for outra (como no Linux kernel), o OpenJDK pode acabar isolado.

A política é provisória, mas o sinal é permanente

A Oracle rotulou essa política como “provisória” e disse que está trabalhando em diretrizes definitivas que serão submetidas ao OpenJDK Governing Board. Pode ser que a versão final seja mais flexível, talvez adotando algo no estilo GraalVM com responsabilização humana.

Mas o dano à percepção já está feito. A mensagem que a Oracle enviou foi: “IA é boa o suficiente pro nosso código, mas não pro seu”. E no mundo open source, onde contribuidores trabalham de graça no tempo livre, essa mensagem soa especialmente mal.

O Java completou 30 anos e continua sendo uma das linguagens mais usadas do mundo. O OpenJDK é a base de distribuições como Amazon Corretto, Eclipse Temurin e Azul Zulu. Uma política restritiva no OpenJDK tem efeito cascata em todo o ecossistema.

A questão real não é se código de IA deve ou não entrar no OpenJDK. É se a Oracle vai aplicar pra si mesma o mesmo padrão que exige da comunidade. Enquanto Larry Ellison diz no palco que IA escreve o código da Oracle, e o Governing Board diz que IA não pode escrever o código do OpenJDK, a hipocrisia fala mais alto que qualquer política.

Fonte de inspiração: As Larry Ellison bets the farm, Oracle says it loves AI-written code, just not in OpenJDK (The Register)