Oracle proíbe código gerado por IA no OpenJDK, por agora

A Oracle decidiu travar a fundo: contributos para o OpenJDK “não podem incluir conteúdo gerado, no todo ou em parte”, por modelos de linguagem, modelos de difusão ou afins. Vale para tudo, não só para código, mas também texto e imagens submetidos por Git, pull requests no GitHub, e-mails, wikis e issue trackers. A IA pode ser usada em privado para perceber, depurar ou rever código, mas nada de deixar rasto nos patches.

Este tipo de proibição frontal contrasta com o que outros grandes projectos fazem. O kernel Linux aceita contributos assistidos por IA, desde que haja divulgação, testes e um humano a assinar por baixo. O LLVM segue uma linha semelhante, com revisão humana explícita. Até o GraalVM, também da Oracle, permite código escrito com ajuda de IA, desde que fique claro quem é o responsável. No OpenJDK, a regra provisória é mais simples e mais dura: se a IA tocou no conteúdo, não entra.

Segundo Sai Rahul Poruri, CEO da FOSS United, isto é sobretudo uma jogada de propriedade intelectual. A Oracle não quer arriscar ter Java contaminado por treinos de modelos cujo licenciamento ninguém consegue reconstruir a sério. Se já andas a perder horas a tentar perceber o que é compatível com GPL e Apache num único projecto, imagina adicionar à mistura blocos de código cuspidospela IA, treinada em milhões de repositórios com licenças variadas e, muitas vezes, incompatíveis.

O problema é que fazer cumprir esta regra é quase ficção. Um estudo da Universidade de Pequim mostra que agentes de programação só abrem ficheiros de política relevantes em 3,5% das execuções não assistidas, em 106 tarefas de 49 repositórios. E, mais grave, quatro combinações de agentes e modelos testadas tiveram 0% de conformidade com regras que exigiam recusar contributos gerados por IA quando isso era proibido. Proibir é fácil, detetar é outra história. A Oracle está a escrever uma norma que depende, na prática, da honestidade dos contribuidores.

Daí as críticas de dentro da própria comunidade de dados e engenharia. Pratik Ambhore, Head of Data Engineering na R Systems, descreve isto como uma medida de risco intermédia, não um modelo sustentável. Prefere a lógica “confia, mas valida”: exigir divulgação de uso de IA e responsabilização humana, em vez de um veto absoluto. Sathya Narayanan AG vai mais longe na metáfora: “Uma proibição total de IA é como uma barragem a segurar um oceano.” Defende etiquetas de proveniência e um modelo “mostra o teu trabalho”, com foco em filtrar AI slop, não IA em si.

Para quem contribui para Java a partir de Portugal, isto significa duas coisas. A curto prazo, se usas Copilot, CodeWhisperer ou afins para escrever trechos de código, o caminho mais seguro é desligar tudo quando mexes em OpenJDK, ou reescrever manualmente o que veio da máquina. A médio prazo, esta decisão encaixa numa tendência mais larga de grandes actores a fecharem o jogo em torno da IA, da Oracle a restringir contributos ao Google a complicar o acesso ao kernel dos Pixel em nome de controlo, como já contámos em Google complica acesso ao kernel dos Pixel e irrita a comunidade. O open source está a descobrir que o termo “aberto” tem cada vez mais asteriscos quando a IA entra em cena.

Fonte: Open Source For You