QEMU define política de “proibição do uso de geradores de código por IA”

• A comunidade do QEMU revisou recentemente sua política. O uso de geradores de código por IA (por exemplo, Copilot, ChatGPT etc.) e o envio de código produzido por essas ferramentas estão proibidos

define policy forbidding use of AI code generators

• O interesse no uso de geradores de código por IA aumentou rapidamente recentemente, mas a interpretação de licenças sobre os resultados gerados por essas ferramentas ainda não é amplamente aceita no setor
• Os principais fornecedores afirmam que não há problema e que é possível escolher livremente a licença, mas existe conflito de interesses por parte deles
• Como os geradores de código por IA são criados a partir de dados treinados sob várias licenças, ainda não há consenso no setor sobre as questões de licença dos resultados gerados
• O QEMU exige, no DCO (Developer Certificate of Origin), que o colaborador tenha claramente o direito de contribuir com o código sob a licença do projeto
  • Também menciona explicitamente que, no caso de código usando geradores de código por IA, é difícil comprovar conformidade com as cláusulas b/c do DCO
  • Portanto, foi adotada uma política de não permitir contribuições de código ao projeto QEMU quando o uso de geradores de código por IA for evidente ou houver suspeita clara

Flexibilidade da política e tratamento de exceções

• Como o desenvolvimento de software assistido por IA ainda está em estágio inicial, há grande possibilidade de que as questões legais sejam resolvidas no futuro
• Com a evolução das ferramentas, espera-se que no futuro algumas delas possam ser usadas com segurança em projetos open source
• Por enquanto, aplica-se primeiro uma política rígida e segura, que poderá ser flexibilizada no futuro conforme necessário
• Pedidos de exceção serão analisados individualmente para decidir se serão permitidos

[GN⁺]

Comentários no Hacker News

• O código gerado por AI é visto como especialmente problemático para software livre e open source caso venha a ser considerado obra infratora ou, ao contrário, domínio público. Se surgir uma situação em que seja preciso distinguir entre edições feitas por AI e por humanos, projetos podem ficar presos por anos em disputas legais, sem sequer ter recursos para custear litígios. Se código feito por AI for modificado por humanos ou integrado a código existente, também vira ponto de discussão se essas edições humanas posteriores poderiam ser tratadas como obra derivada fora de uso justo. Se o código gerado por AI for considerado domínio público, projetos em que apenas parte do código-fonte está sob licenças open source/free software perderiam rapidamente força para agir contra empresas que abusam da licença. Haveria o enorme ônus de provar que o infrator usou justamente o código criado por humanos, isto é, o trecho efetivamente licenciado. Já software proprietário sofreria relativamente menos nesse cenário, porque para alegar cópia indevida de código gerado por AI alguém teria que desmontar o binário e compará-lo com o código original, e já é comum software proprietário conter partes em domínio público
  • Acho até que, para a licença MIT, essa situação pode acabar sendo vantajosa
  • Como desenvolvedor experiente, entendo bem por que muita gente não quer “desenvolvedores” sem conhecimento contribuindo código de AI aleatório. Revisar linha por linha de código de AI por um humano, mesmo deixando a questão legal de lado, já consumiria anos de trabalho. Primeiro, tudo indica que no futuro quase não haverá meios práticos de verificar se um código foi gerado por AI. Segundo, software feito 100% por humanos inevitavelmente perderá competitividade frente a projetos assistidos ou escritos por AI. A única objeção possível seria um colapso apocalíptico em que humanos deixassem de conseguir produzir semicondutores ou eletricidade em escala. Terceiro, mesmo que algum projeto consiga excluir totalmente contribuições com código de AI, no fim alguém vai copiar esse código, remover as partes juridicamente arriscadas e migrar para um novo projeto. Se a licença permitir fork, talvez virem fork direto; talvez prefiram copiar e limpar depois. Ainda há um caminho longo para o open source, e o software do futuro deve explodir em quantidade; 99% pode ser ruim, mas também deve surgir muito software realmente valioso
  • Compartilha links sobre o tema dos direitos autorais de AI, incluindo um artigo recente da news.artnet.com sobre arte de AI e a página da disputa de direitos autorais da selfie do macaco na Wikipédia, dizendo que essa discussão já entrou num caminho sem volta
  • Se um software for realmente open source no sentido mais amplo, do tipo “faça o que quiser com este código, não nos importamos”, então não há absolutamente nada com que se preocupar em relação a AI
• Isso me parece claramente uma posição mais dura do que a política do LLVM. Dá para ver em detalhes na política para desenvolvedores do LLVM. Como um desenvolvedor old school, eu jamais quero revisar código que nem o autor entende e que eu também não entendo
  • É realmente desagradável quando o autor nem entende o próprio código e ainda assim eu tenho que revisá-lo. Já aconteceu de alguém me pedir para fazer algo trazendo uma explicação que recebeu de uma AI e dizendo “ela falou que é assim”, quando seria muito melhor simplesmente dizer “faz isso aqui pra mim”. Chega a soar ofensivo
  • Comecei a adicionar DCO (Developer Certificate of Origin) a todos os projetos open source que mantenho e pretendo colocar a seguinte política para contribuições com LLM no CONTRIBUTING.md

  ---

  Política para Contribuições Geradas por LLM
  A biblioteca Color é uma biblioteca cheia de matemática complexa e decisões sutis. Todo issue ou PR deve ser escrito com profundo entendimento por parte de quem submete e, especialmente no caso de PRs, o desenvolvedor deve atestar DCO para cada commit. Se um PR foi escrito com ajuda de LLM, isso deve ser declarado na mensagem de commit e no PR. Se for detectada ajuda de LLM sem evidência declarada, o PR será rejeitado. Conteúdo gerado por LLM enviado sem revisão será rejeitado em qualquer caso

  Também pretendo colocar no SECURITY.md uma LLM-Generated Security Report Policy, para deixar claro que relatórios de segurança gerados por LLM não serão aceitos em hipótese alguma

  Como alguém que carrega sozinho a responsabilidade por um projeto, tento equilibrar as coisas, mas pessoalmente não gosto de contribuições de código com LLM
  • Eu uso GitHub Copilot em projetos pessoais. Mas não uso de outra forma além de “autocompletar inteligente”. Só aceito quando o que ele sugere é suficientemente parecido com o código que eu já ia digitar. Assim, continuo entendendo 100% do meu código e ainda evito bugs acidentais ou polêmicas de direitos autorais. Usado dessa forma, o Copilot acelera o desenvolvimento. Nem é porque eu digite devagar, e sim porque muitas vezes me distraio ou fico entediado. O Copilot me ajuda a passar mais rápido para a próxima etapa de raciocínio ou de debug.
    Tenho muita dificuldade de imaginar outra pessoa enviando um PR sem entender o próprio código. Por isso fico um pouco incomodado com o fato de políticas como essa poderem restringir até meu uso de LLM no nível de autocompletar, por causa desse tipo de gente.
    Eu até gostaria de pedir ao Copilot tarefas de refatoração automática, mas quando testo normalmente ele quebra tudo e costuma gerar blocos inteiros do zero, o que no fim fica mais lento do que fazer manualmente.
    Curiosamente, se eu estiver escrevendo um bug, o Copilot muitas vezes completa o bug também. Ele até autocompleta erros contextuais óbvios, como nome de variável digitado errado
  • Quando uso LLM em tarefas de programação, é em pedidos do tipo “converta este YAML em structs e extraia padrões repetidos em variáveis”. Dá para fazer isso com ferramenta determinística, mas a AI resolve em 30 segundos de forma limpa, e é fácil testar que o resultado corresponde à entrada
    Eu jamais delegaria meu trabalho de alto nível para AI, mas tarefas repetitivas e menos importantes eu passo para ela para ganhar velocidade. Por exemplo, posso entregar ao Claude Code um CSV com resultados de benchmark de banco de dados e pedir para ligar isso a vários gráficos e análise de outliers; conceitualmente é simples, mas encontrar bibliotecas e configurar tudo consome tempo, e ele acelera bastante
  • Entendo perfeitamente a posição de não querer revisar código se o autor não o entende. Mas, com orientação correta de um humano experiente, ferramentas de AI também conseguem produzir código bastante sofisticado. E elas estão ficando mais poderosas a cada poucos meses; muitas vezes já geram resultado só com instruções em linguagem natural
    Tenho pensado no que exatamente significa “entender” código. Num projeto em que estou trabalhando, estou adicionando um backend de storage totalmente novo a um sistema existente de orquestração de VMs. Não conheço bem o código atual e não tenho tempo de implementar tudo sozinho, mas monto clusters de teste, executo cenários variados e consigo compreender o panorama geral em termos de design e testes
    Eu também sou mantenedor de open source e consigo imaginar o estresse enorme de receber PRs ruins de “slop” de LLM. No fim, o mantenedor precisa revisar o código de qualquer jeito, independentemente de o autor entendê-lo ou não.
    Acho que daqui para frente será preciso descobrir maneiras de usar essas ferramentas adequadamente e também de sinalizar a outros desenvolvedores o nível de qualidade do código enviado. Uma lição que tirei de um bug sutil encontrado no port inicial do ZFS para Linux é que testes rigorosos são extremamente importantes, tanto quanto revisão linha por linha e autoria humana
• O resultado que previ no meu blog “yes i will judge you for using AI” está se tornando real. O open source sempre dependeu muito de sinais implícitos de competência dos contribuidores, e os LLMs fazem até gente sem experiência nenhuma parecer capaz de produzir código competente. Para quem já é experiente, isso é um choque realmente desorientador. Daqui para frente, prova social sem relação direta com o PR em si, como reuniões virtuais ou presenciais, deve se tornar cada vez mais necessária para entrar em projetos grandes
  • Estamos vendo isso também na empresa. Colegas usam LLM para gerar comentários de review de código e, como parecem sofisticados demais, por um momento isso engana. Então eu gasto um tempão validando se os comentários fazem sentido, e acabo consumindo muito mais energia do que a pessoa que só copiou e colou
  • Pede o link do blog
• É uma política assinada principalmente por gente da RedHat. A RedHat é bastante séria e orientada ao mundo corporativo. Talvez a preocupação deles não seja tanto “quem detém direitos autorais sobre algo gerado por AI”, mas sim a possibilidade de código de outros projetos usado no treinamento reaparecer inadvertidamente. A maioria dos hipervisores é closed source, e há muitas empresas litigiosas nesse meio
  • Se o risco é a AI despejar “código de outros projetos” extraído dos dados de treino, então isso me parece um problema aplicável a praticamente todo código que a AI gera
  • Modelos de linguagem frequentemente têm maior risco de introduzir erros lógicos sutis, o que pode até atravessar fronteiras de segurança de um hipervisor. Usuários muito dependentes de ajuda de AI tendem a estar menos preparados para detectar esse tipo de falha, o que torna a situação ainda mais perigosa
• Chama atenção que a política foi assinada principalmente por pessoas da RedHat depois da aquisição pela IBM. A IBM criou o Watson e venceu o Jeopardy em 2011. Fico me perguntando se esse discurso de que software com AI “ainda está só começando” é realmente sério ou se é só mais um caso de destruição por aquisição no estilo IBM.
  O Dotnet Runtime está adotando AI ativamente. Muita gente de fora pode rir, mas vale notar que engenheiros brilhantes como Stephen Toub e David Fowler apoiam isso.
  Às empresas, eu recomendaria procurar parceiros realmente voltados para o futuro quando a próxima IBM aparecer para vender serviços de AI.
  Como alguém da Carolina do Norte, torço para que IBM e RedHat consigam acertar a direção
• Fico pensando se a motivação é mesmo jurídica. Alguns projetos talvez só estejam cansados de reviews de código ruim gerado por AI
  • O QEMU é software absolutamente central para a indústria. É usado em VM de desktop, nuvem, servidores de build, sandbox de segurança, ambientes multiplataforma e muito mais. Mesmo um risco jurídico pequeno pode ter impacto sério no setor
  • A política é clara e restrita. Ela parece enfatizar que não dá para garantir com segurança a titularidade de código gerado algoritmicamente. O uso deliberado de “algoritmicamente” chama atenção. A política atual também parece seguir essa linha e, com a ideia de “começamos hoje da forma mais rígida e segura e relaxamos depois”, já soa razoável desde o início. Pode até ter a ver com rejeitar “grandes volumes de slop”, mas a estratégia parece primeiro organizar risco legal e atribuição. Me parece muito melhor do que a política do curl
  • Cita o caso da Monsanto e sua aplicação agressiva de direitos sobre sementes como alerta
  • Honestamente não sei como a AI vai mudar a qualidade do código de nível intermediário, mas humanos também produzem muito código inútil. Se o volume de commits ficar grande demais e difícil de administrar, talvez os projetos precisem de times de triagem. Acho que a maioria das contribuições é feita de boa-fé.
    Entendo quem evita AI por risco legal, mas também tenho dúvidas sobre se isso não está sendo exagerado. Quem acha que realmente zerou alguma possibilidade ainda não pensou o suficiente sobre o assunto
  • Se isso continuar assim, pode acabar prejudicando o open source. Código de copiar e colar fica fácil demais de produzir, e o tempo gasto para revisar e rejeitar é enorme. Mais projetos podem caminhar para um modelo tipo Android, em que qualquer um pode baixar o código-fonte, mas praticamente ninguém de fora consegue contribuir de verdade
• Tenho esperança de que dê para distinguir entre usar LLM no IDE como autocompletar inteligente e dar instruções de alto nível para gerar grandes blocos de código. Reconheço que há zona cinzenta, mas gostaria que algo no nível de autocompletar do Copilot pudesse ser usado sem risco de copyright. Por exemplo, ao escrever uma série de case, o Copilot pode detectar o padrão e reduzir bastante a digitação
  • Indo além, imagino um futuro em que a AI vire uma espécie de óculos para a mente e o corpo. Do mesmo modo que óculos comuns compensam a visão, óculos inteligentes poderiam ajudar até no pensamento.
    Meu cérebro também foi treinado com muito código closed source, então ironizo que a discussão de copyright em torno de AI tem algo de NIMBY ocidental. Se continuarmos rejeitando tecnologia incrível por causa desses “e se” jurídicos, isso pode enfraquecer a própria civilização ocidental
• Entendo por que esse tipo de política está surgindo, mas acho um erro. Na questão jurídica de AI e copyright, ainda há pouca clareza, e quase não houve legislação ou decisões definitivas.
  Separadamente de proibir contribuições com AI, acho que também seria preciso deixar claro “nestas áreas pode usar AI”. Por exemplo, o setup de CI do QEMU não é uma área central de segurança. Contribuições para casos de teste interessantes ou novos ambientes poderiam muito bem permitir AI sob certas condições
  • Tento pensar quais seriam os riscos de não adotar essa política. O código talvez saia um pouco mais devagar, mas melhor; e para um projeto crítico como o QEMU, vale aceitar esse risco mesmo com perda de velocidade. Não me parece que os autores sejam contra GenAI em si; parece mais cautela diante de algo que, uma vez introduzido, pode não ter volta
  • Simplesmente “esperar até a situação jurídica ficar clara” é a solução mais fácil. Quase todo o código do QEMU é GPL 2.0; se código de GenAI entrar de forma equivocada e depois surgir precedente determinando que a licença do código original precisa ser seguida, isso geraria reversão de código e custo para todo o ecossistema downstream. Mesmo rotular algo como “esta parte é AI, não reutilize” ainda deixaria o problema de uma futura reescrita total.
    No fim, “por enquanto não aceitar” é a decisão menos complexa e menos dramática para todos
    Como material relacionado, anexa links para a licença do QEMU e a lista de licenças não livres
  • Isso não parece uma disputa jurídica que vai durar décadas; já há dezenas de processos relacionados nos tribunais, e deve haver precedentes em poucos anos. O QEMU cresceu muito bem por 22 anos sem AI, então esperar mais alguns anos não tem nada de ruim
  • Aconselha a ler bem o texto e o subtexto da política. Toda ação tem risco jurídico, mas grandes empresas globais assumem esse tipo de risco o tempo todo. O QEMU não está sendo especialmente excêntrico; a leitura é que eles simplesmente não querem usar código de LLM e usam a justificativa “perguntem ao jurídico → há risco legal → não pode usar” para encerrar a discussão. É exatamente o mesmo padrão visto em empresas
  • Na indústria de computação existe há muito tempo uma convenção de não plagiar código. Mesmo quando trechos curtos poderiam se enquadrar juridicamente como uso justo, a cultura ainda assim é não copiar o código original
• A ideia de “começar de forma rígida e segura e depois relaxar” faz bastante sentido
  Mas eu me pergunto se há alguma forma prática de distinguir código gerado por AI de código que um humano copiou de algum lugar. No open source, qualquer pessoa pode contribuir, e humanos também podem ser influenciados por outros códigos
  Do ponto de vista atual, acho que código gerado por AI não tem exatamente uma identidade própria independente; ele está mais para uma ferramenta nas mãos de humanos
  • A comparação é que “código gerado por AI é como uma serra elétrica na mão de um humano”. É uma ferramenta poderosa e por isso pode se tornar perigosa logo depois do próprio humano.
    Mas já sinto que essa metáfora foi esticada demais e nem precisa mais ser usada
• Na prática, esse tipo de política parece completamente impossível de aplicar. Zed, Cursor e VS Code todos oferecem autocompletar com AI, e é impossível distinguir entre o código que eu digitei e a dica de AI que apareceu.
  Seria como eu desenhar um boneco de palito e alguém dizer “talvez esse desenho tenha copiado o boneco de palito de outra pessoa, então você não tem direito de submetê-lo”
  O verdadeiro objetivo da política, no fim das contas, é criar uma justificativa para dizer “não havia o que fazer” quando inevitavelmente alguém enviar algo misturado com código de AI. Acho impossível que quem escreveu a política não saiba que ela é sem sentido
  • Esse tipo de política serve claramente para garantir uma justificativa de isenção de responsabilidade: “se apareceu código suspeito pela política, não podíamos fazer nada”. Nas mensagens de commit ou patches também aparece a posição de que “a questão de licença de geradores de código ainda não está estabelecida juridicamente”.
    Além da questão legal, claramente existem vários outros problemas no uso de código de AI
  • O Neovim não força AI. Você precisa ativar isso manualmente. Se um editor tornar impossível desligar AI, então há algo seriamente errado com o próprio editor