Código de IA racha o open source: Flathub proíbe, QEMU cogita liberar — e ninguém concorda sobre os riscos

Em uma única semana no final de maio de 2026, dois projetos importantes de código aberto tomaram rumos opostos sobre o código gerado por inteligência artificial, escancarando uma divisão que percorre toda a comunidade.

O Flathub, a maior plataforma de distribuição de aplicativos para desktops Linux, endureceu suas regras e passou a proibir praticamente tudo que envolva IA generativa. O QEMU, projeto fundamental de virtualização, começou a trabalhar para relaxar sua própria proibição total e passou a permitir, de forma restrita, contribuições com IA, desde que haja um aviso claro .

Nenhuma das decisões foi sobre se as ferramentas de IA funcionam. Ambas foram sobre quem paga o pato quando elas falham — e quem assume o risco jurídico quando ninguém sabe quem é o dono do código.

A proibição do Flathub: cansaço, não só direitos autorais

No dia 29 de maio de 2026, o Flathub publicou uma atualização na sua documentação com o título "Reformular política de LLM para deixar claro que não é permitido" . A nova política agora barra explicitamente o uso de IA/LLM tanto no aplicativo submetido quanto no próprio processo de submissão — o que inclui manifestos, metadados, patches, scripts de compilação e pull requests .

A mudança vai muito além de uma cautela com direitos autorais. Bart Piotrowski, mantenedor do projeto, reconheceu que os LLMs são ferramentas inevitáveis, mas disse que o verdadeiro estopim foi uma enxurrada de pessoas enviando, com pouco esforço e muita arrogância, aplicativos gerados por IA, criando interações hostis e uma carga de revisão que se tornou insustentável . A decisão foi tomada para proteger os mantenedores, que trabalham de graça, de uma dinâmica que tinha se tornado abusiva.

A política inclui uma exceção estreita para "projetos maduros e bem mantidos", mas a documentação deixa claro que isso não é uma garantia . As submissões podem ser rejeitadas a qualquer momento, e até mesmo aplicativos que já foram aceitos podem ser removidos se for constatado que não cumprem a regra . Os aplicativos antigos que continham código de IA seguem no ar — a proibição não é retroativa —, mas novas submissões com assistência de IA estão, na prática, bloqueadas a partir de agora .

O Flathub não tentou criar regras sutis para separar o uso aceitável do inaceitável. Optou pela proibição total porque a própria triagem já tinha se tornado um custo insustentável. A plataforma escolheu proteger a atenção e a saúde mental dos revisores em vez de tentar consertar um sistema jurídico que ainda nem alcançou essa tecnologia.

A reviravolta do QEMU: testando um meio-termo com transparência

O QEMU havia adotado em meados de 2025 uma das políticas mais rígidas do mundo open source. Suas regras formais de proveniência de código diziam que qualquer contribuição que se acreditasse conter ou derivar de conteúdo gerado por IA — ChatGPT, Claude, Copilot, Llama e similares — seria recusada . A justificativa era que o código de IA não pode satisfazer o Certificado de Origem do Desenvolvedor (DCO), porque não existe um autor humano para fazer as declarações exigidas .

Mas no final de maio de 2026, o projeto começou a andar na direção contrária. Paolo Bonzini, engenheiro ilustre da Red Hat e mantenedor do KVM, propôs autorizar patches com assistência de IA em áreas limitadas e de baixo risco — especialmente aquelas em que as consequências de uma violação de direitos autorais fossem fáceis de reverter e pouco prováveis de se espalhar. O código central (core) continuaria proibido, salvo com autorização prévia do mantenedor .

A justificativa de Bonzini foi pragmática: os projetos que aceitam contribuições assistidas por IA ainda não enfrentaram problemas jurídicos sérios, e a própria equipe jurídica da Red Hat avaliou o risco como aceitável para categorias bem definidas de alterações . A proposta acrescenta ainda a exigência de que o colaborador avise de forma obrigatória quais trechos foram gerados por IA, em vez de escondê-los .

Na prática, o QEMU está apostando que um caminho do meio baseado em transparência pode funcionar — principalmente para contribuições mecânicas, como casos de teste, correções de documentação e pequenos patches — onde uma proibição total gera atrito sem trazer um benefício jurídico proporcional.

Por que o DCO é a linha de falha

Tanto a proibição rígida do Flathub quanto a abertura cautelosa do QEMU giram em torno da mesma pergunta jurídica sem resposta: o que acontece quando o código gerado por IA precisa passar pelo Certificado de Origem do Desenvolvedor?

O DCO exige que quem contribui certifique que "criou" a contribuição ou que "tem o direito" de submetê-la sob a licença do projeto. Mas o código gerado por IA, pela lei atual, não tem um autor humano identificável. Em janeiro de 2025, o Escritório de Direitos Autorais dos EUA decidiu que criações feitas por IA só podem ser protegidas se houver contribuição criativa humana suficiente — e apenas dar comandos para a IA não conta . Em março de 2025, no caso Thaler v. Perlmutter, o Tribunal de Apelações do Distrito de Columbia confirmou que a Lei de Direitos Autorais exige um ser humano como autor, e até março de 2026 a Suprema Corte americana tinha se recusado a reexaminar a questão .

Isso cria um beco sem saída. Um desenvolvedor que submete código gerado por IA pode simplesmente não conseguir assinar o DCO de forma verdadeira. A resposta do kernel Linux — formalizada em abril de 2026 com sua primeira política de assistentes de codificação com IA — foi exigir que apenas humanos adicionem a etiqueta "Signed-off-by" e que o humano assuma total responsabilidade legal por todas as linhas geradas por IA . Mas a proibição original do QEMU partiu do princípio de que afirmar que um código feito por IA cumpre o DCO "não é considerado algo crível", tamanha a ambiguidade do licenciamento .

Até agora, nenhum tribunal definiu, de forma definitiva, se o código gerado por IA pode ter direitos autorais, quem seria o dono desses direitos ou que obrigações de licenciamento recaem sobre quem o utiliza. Os projetos estão cada um fazendo sua própria conta de risco porque o sistema jurídico ainda não deu uma resposta clara.

O custo humano além dos direitos autorais

O debate jurídico é importante, mas o que realmente empurrou o Flathub para o abismo foi o esgotamento dos mantenedores. Vários projetos relatam o mesmo padrão: submissões geradas por IA costumam ser volumosas, porém rasas — arquivos enormes de código, mas com pouca compreensão real do que foi feito —, gerando uma carga de revisão totalmente desproporcional ao valor que entregam .

As extensões do GNOME Shell enfrentaram uma inundação parecida. No final de 2025, os revisores relataram ter recebido, em alguns dias, mais de 15 mil linhas de código de extensão gerado por IA, além de respostas geradas por IA quando faziam perguntas durante a revisão . Bart Piotrowski, do Flathub, resumiu o limite que foi ultrapassado de forma direta, dizendo que a política foi necessária porque algumas pessoas "simplesmente não sabem como se comunicar de forma adequada" .

O custo humano e o custo jurídico são inseparáveis. A questão do DCO importa porque os mantenedores podem ser responsabilizados pelo código que aceitam. A questão do cansaço importa porque os mantenedores são voluntários que trabalham com margens muito apertadas de tempo e boa vontade. As submissões geradas por IA pressionam os dois lados ao mesmo tempo.

Três campos, nenhum consenso

Uma análise feita pela RedMonk em fevereiro de 2026 com 32 organizações de código aberto não encontrou consenso algum . Os projetos se dividiram em três grandes grupos:

• Proibição total: Flathub, Gentoo (decisão unânime do conselho em 2024), NetBSD (que chama o código de IA de "presumivelmente contaminado") e o sistema de revisão EGO do GNOME proíbem contribuições geradas por IA sem exceção .
• Aceitação condicional com aviso: A proposta do QEMU se juntaria ao Apache, Fedora, Linux Foundation e à EFF, que permitem o uso de IA desde que haja uma identificação obrigatória e a palavra final do mantenedor .
• Permissivo com responsabilidade humana: O kernel Linux e a Red Hat permitem o uso de IA se o desenvolvedor humano assumir total responsabilidade, assinar o DCO e identificar a ferramenta usada — mas a assinatura "Signed-off-by" continua sendo algo que só um humano pode fazer .

Esses campos não discordam apenas sobre a política. Eles discordam se o código de IA é uma ferramenta a ser gerenciada ou uma ameaça a ser excluída — e se o custo de gerenciá-la recai sobre os mantenedores ou sobre um sistema jurídico que ainda não está pronto para lidar com isso.

O que vem a seguir

Flathub e QEMU não são exceções. São dois pontos de um espectro que vai ficar cada vez mais largo conforme as ferramentas de IA melhoram e o volume de submissões geradas aumenta. Alguns observadores já notam que, dentro de um ou dois anos, detectar o que é código gerado por IA será praticamente impossível, o que tornaria as proibições ineficazes, independentemente da intenção .

A EFF já concluiu que uma proibição geral não tem como ser colocada em prática, dada a forma como o uso de LLMs se tornou disseminado . Mas a impossibilidade prática de fiscalizar não resolve o problema de esgotamento que motivou a decisão do Flathub.

Até que decisões judiciais ou leis estabeleçam regras claras sobre autoria e responsabilidade para código gerado por IA, cada projeto de código aberto está, na prática, escolhendo sua própria aposta. O Flathub escolheu proteger seus revisores agora, fechando a porta para as ferramentas de IA. O QEMU está escolhendo abrir a porta só uma fresta, com exigência de transparência e uma aposta de que o risco jurídico vale a pena para contribuições de baixo impacto.

Ambos os movimentos são racionais com base no que se sabe hoje. Só refletem respostas diferentes para a mesma pergunta incômoda: em uma comunidade construída com base no trabalho humano e voluntário, o que se faz quando o código chega sem nenhum dos dois?