QGIS propõe proibir contribuições feitas com IA: 289 pontos e 299 comentários no HN

O QGIS, o sistema de informação geográfica de código aberto mais conhecido, colocou em discussão a proibição de contribuições criadas com ajuda de IA. A proposta está no pull request nº 387 do repositório QGIS-Enhancement-Proposals, onde a equipe analisa grandes mudanças nas regras e na arquitetura do projeto. Até 12 de outubro de 2026, o link do PR havia reunido 289 pontos e 299 comentários no Hacker News. Para um tema tão especializado quanto SIG, é bastante.

Uma ressalva importante: o material de origem traz apenas o link do PR e as métricas do HN, sem o texto da política. As formulações exatas (o que conta como ajuda de IA, como verificar isso, quais sanções estão previstas) e o status final da proposta precisam ser consultados no próprio pull request. O título no HN fala em proibição, mas o processo de decisão no repositório de QEPs pode incluir votação e revisões.

Por que decisões desse tipo surgem justamente agora

O QGIS é hospedado no GitHub, escrito principalmente em C++ e Python e distribuído sob GPL. O projeto depende de um número limitado de mantenedores, que revisam manualmente patches enviados por centenas de pessoas. Qualquer ferramenta que barateia a produção de código, mas não barateia a revisão, pressiona o ponto mais estreito do processo: o tempo do revisor.

Além da carga de trabalho, há dois problemas, um jurídico e outro técnico. O primeiro é a origem do código. Os modelos foram treinados em enormes volumes de repositórios, e os mantenedores não têm como garantir que um trecho gerado não reproduza código alheio com licença incompatível. Para um projeto GPL, isso é uma questão de integridade do licenciamento. O segundo é a responsabilidade. Quem envia um patch precisa entender o que está enviando e saber defender a solução na revisão. Se a pessoa não escreveu o código e não o domina por completo, a conversa vira uma troca de mensagens repassadas entre o revisor e um chatbot.

Não é o primeiro projeto a adotar esse caminho

O QGIS se junta a um grupo que já é considerável. Em 2024, o Gentoo proibiu a aceitação de código escrito com modelos generativos. No mesmo ano, o NetBSD declarou o código de LLMs potencialmente “contaminado” do ponto de vista das licenças e passou a exigir aprovação prévia. Em 2025, o QEMU também deixou de aceitar esses patches, citando questões de direitos autorais e do certificado de origem do desenvolvedor (DCO). Outros projetos seguem um caminho mais brando: permitem o uso de IA, mas exigem que ele seja declarado e atribuem a responsabilidade ao autor.

O que as métricas mostram

• Objeto da discussão: pull request nº 387 em qgis/QGIS-Enhancement-Proposals.
• Plataforma da discussão: Hacker News, 289 pontos.
• Atividade: 299 comentários, ou seja, cerca de um por ponto. O tema é polêmico e não há consenso na thread.
• Licença do projeto: GPL, o que torna a questão da origem do código especialmente sensível.
• Data de publicação no agregador: 12 de outubro de 2026.

Implicações práticas para contribuidores e equipes

Se você contribui com o QGIS ou com plugins para ele, leia o texto final da política antes de enviar o próximo patch. Descubra se a proibição vale para autocompletar no editor, geração de testes e documentação, tradução e correção de erros de digitação, ou apenas para código de conteúdo substancial. Em documentos desse tipo, a fronteira costuma ser difusa, e é melhor combinar os casos duvidosos com os mantenedores com antecedência.

Para mantenedores de outros projetos abertos, o próprio formato é útil: a regra foi levada a um processo público de propostas, em vez de ser definida por uma decisão fechada da equipe principal. Isso reduz o número de conflitos mais adiante. Equipes que usam o QGIS internamente e enviam patches ao upstream devem criar uma regra própria sobre o que, do código interno gerado com IA, pode ser enviado para fora. O caminho mais simples é manter essas mudanças em um fork ou plugin próprio.

O veredito final só sai depois da discussão no próprio PR. Mas os 299 comentários no HN mostram que a pergunta “devemos aceitar código de IA em projetos abertos?” há muito deixou de se limitar às disputas em torno de um único repositório.