Comitê gestor do GCC anuncia política de IA

A nova política de IA do GCC, que restringe o uso de modelos de linguagem grandes (LLMs) para código “juridicamente significativo” enquanto permite seu uso para testes, descoberta de bugs e pequenas alterações, tornou-se um ponto de tensão para preocupações mais amplas sobre IA em infraestrutura central. Comentadores ponderam riscos legais e de licenciamento — especialmente para a GPL e a possibilidade de direitos autorais de código gerado por IA — contra ganhos de produtividade, contrastam a postura cautelosa do GCC com a abordagem mais permissiva do LLVM de “humano no loop”, e debatem se tais regras protegem a qualidade do software ou apenas empurram o trabalho assistido por IA para forks separados e ecossistemas proprietários.

Visão geral da política de IA do GCC

  • O GCC adota uma política relativamente rígida: não permite código de implementação gerado por LLM “juridicamente significativo” (≈>15 linhas), mas permite o uso de LLMs para testes, depuração, descoberta de bugs e revisão.
  • As mensagens de commit devem indicar a assistência de LLM. Os humanos continuam responsáveis e devem compreender e explicar as contribuições.
  • Muitos comentaristas veem isso como uma política moderada, bem escrita e respeitosa, especialmente em comparação com declarações mais moralizantes em outros lugares.

Direitos autorais, GPL e risco jurídico

  • Forte foco em GPL/direitos autorais:
    • Preocupação 1: LLMs podem regurgitar código protegido por direitos autorais ou GPL, expondo projetos a alegações de violação.
    • Preocupação 2: código totalmente gerado por IA pode não ser passível de direitos autorais (especialmente sob interpretações da UE/EUA que exigem autoria humana), enfraquecendo a aplicabilidade da GPL e “diluindo” as proteções do software livre ao longo do tempo.
  • Outros argumentam que ações judiciais contra projetos por código gerado por LLM são improváveis e que a indenização oferecida por grandes fornecedores de IA sugere baixo risco prático.
  • Há divergência sobre se a jurisprudência atual (por exemplo, decisões de fair use) resolve de fato essas questões; o cenário é visto como em evolução e parcialmente incerto.

Qualidade, “slop” e carga para mantenedores

  • Mantenedores relatam ondas de PRs de baixa qualidade, totalmente dirigidos por agentes (incluindo código gerado por IA e até revisões de código geradas por IA), muitas vezes sem que os autores as entendam ou testem.
  • O tempo de revisão é escasso; muitos veem proibir ou restringir fortemente as saídas de LLM como uma defesa contra um “DoS amplificado” via envios massivos baratos de PRs.
  • Outros contrapõem que LLMs, usados com cuidado, podem ajudar em tarefas monótonas (testes, boilerplate, código de integração corporativa) e que o problema real é impor padrões e responsabilização, não a ferramenta.

Aplicação e dinâmica social

  • Muitos observam que a aplicação é inerentemente difusa: as pessoas podem mentir ou usar LLMs e “ajustar” as saídas para parecerem humanas.
  • Deterrentes propostos: pressão social, banimento de mentirosos, escrutínio extra para novos contribuidores e exigência de que contribuidores respondam a perguntas detalhadas sobre suas mudanças.
  • Alguns temem que as políticas desestimulem apenas usuários honestos de IA, sem impedir atores mal-intencionados.

Ideologia, polarização e divisão do ecossistema

  • A discussão destaca uma polarização intensa em torno da IA: acusações de “religião”, pensamento escatológico e identidade pessoal ligada ao uso ou à rejeição de LLMs.
  • Alguns preveem uma divisão entre uma stack OSS “humanista” e uma stack “assistida por máquina”, possivelmente com forks de grandes projetos fortemente orientados por IA.
  • Outros argumentam que os ideais do software livre deveriam empurrar na direção de LLMs livres/abertos, em vez de resistência generalizada à tecnologia.