Política de uso de LLMs da NLnet Labs

• A NLnet Labs restringe o uso de LLMs em contribuições de projeto e na comunicação, e envios que violem a política podem ser fechados ou removidos sem aviso prévio
• Contribuições de código e documentação devem ser escritas diretamente por humanos, e não podem incluir conteúdo gerado por LLMs ou outras ferramentas probabilísticas
• Em relatórios de vulnerabilidades e bugs, correções sugeridas por LLMs podem ser aceitas excepcionalmente, mas um colaborador humano deve validar o problema e sua gravidade
• Ao interagir com a NLnet Labs, como em issues, relatórios de vulnerabilidade e posts no fórum, é necessário informar o uso de LLMs, e também é recomendado informar o uso de tradução automática por causa da possibilidade de erros de tradução
• LLMs podem ser usados para linting, análise e revisão, mas a responsabilidade de entender e verificar a precisão das informações compartilhadas externamente continua sendo do colaborador

---

Escopo da política e obrigações básicas

• A NLnet Labs restringe a forma de uso de Large Language Models (LLMs) no contexto da organização e de seus projetos
• Envios que não seguirem a política podem ser fechados ou removidos sem aviso prévio
  • Isso inclui PRs, issues, comentários e posts no fórum
• Além desta política, também é necessário seguir o code of conduct e o CONTRIBUTING.md de cada projeto

Princípios para criação de contribuições

• Contribuições de código e documentação devem ser feitas por humanos
  • Não podem incluir conteúdo gerado por LLMs ou outras ferramentas probabilísticas
  • Como exceção, correções sugeridas por LLMs incluídas em relatórios de vulnerabilidade ou bug são permitidas
  • Essa exceção existe para facilitar a identificação da causa raiz do problema durante a revisão inicial
• Mesmo ao abrir um PR, contribuições geradas por LLM não são aceitas
  • O código enviado não pode ter sido gerado por LLM
  • A descrição do PR deve ser escrita de forma concisa, com suas próprias palavras
  • Em geral, PRs de novos recursos não devem ser abertos sem antes conversar com a NLnet Labs
  • Ideias de mudanças no software podem ser compartilhadas com suas próprias palavras no community forum

Divulgação do uso de LLMs e tradução

• Ao interagir com a NLnet Labs, é preciso informar se houve uso de LLM
  • Isso inclui abertura de issues, relatórios de vulnerabilidade e posts no fórum da comunidade
• Tradução automática pode ser útil quando o inglês não é sua língua nativa
  • Se você usou tradução automática, é recomendável informar isso para que ambos os lados estejam cientes da possibilidade de problemas de comunicação causados por erros de tradução
  • Se você não conseguir avaliar a precisão da tradução, também pode escrever em sua língua nativa
  • A tradução com LLM não é recomendada, pois sua natureza generativa tende mais a confundir a discussão do que a facilitá-la

Usos permitidos e responsabilidade de verificação

• É permitido usar LLMs para linting, análise e revisão
• Mesmo que um LLM tenha ajudado a encontrar ou analisar um problema, a responsabilidade de entender e verificar a precisão das informações compartilhadas continua sendo do usuário

Relatórios de vulnerabilidade

• A NLnet Labs pode aceitar relatórios de vulnerabilidades encontrados com ajuda de LLM
  • O relatório pode incluir correções sugeridas por LLM para ajudar a localizar o problema
  • Um colaborador humano deve validar o problema e a gravidade estimada
  • Ao reportar para [e-mail], é necessário informar o uso de LLM
  • O procedimento de reporte de vulnerabilidades deve seguir a página security report

[GN⁺]

Opiniões no Lobste.rs

• Gostaria de ouvir a lógica por trás dessas regras.
  Por exemplo, fico curioso se a principal motivação é incerteza jurídica, preocupações com qualidade ou manutenção, ou algum outro motivo.

  • Como Alex Band, da NLnet Labs, explicou de forma bastante comedida em este toot, alguém pode usar bem um prompt para gerar 10 mil linhas de código que pareçam, funcionalmente, fazer o que se pretendia ao tentar contribuir com um recurso ótimo e necessário.
    Mas, antes de enviar isso como pull request para a equipe da NLnet Labs, a questão central é se a pessoa revisou e entendeu cada linha gerada e se pode se responsabilizar por ela. Pela experiência do último ano, isso raramente aconteceu; o código aparece na porta como um presente bem-intencionado, mas o ônus de revisá-lo, assumir responsabilidade por ele e mesclá-lo na branch main recai sobre a equipe. Considerando que esse software roda em infraestrutura crítica que sustenta a internet, é uma exigência grande. No processo de revisão, é preciso que ambas as partes consigam conversar entendendo tanto o domínio do problema quanto os detalhes da solução proposta; o uso de LLM não dá esse entendimento ao autor do envio e também prejudica a manutenção de longo prazo.
  • O motivo imediato para redigir esse documento foi proteger o tempo dos desenvolvedores.
    É claro que direitos autorais, controle de qualidade, manutenção de longo prazo e preocupações éticas também foram todos considerados.

• Gosto do foco em patches escritos e revisados por pessoas, e também acho bom que sugestões de patch em relatórios de vulnerabilidade sejam tratadas como exceção.
  Quando são simples e vão direto ao ponto, essas sugestões valem a pena ser lidas.

• Dá para entender por que as pessoas estão ficando cansadas de conteúdo gerado por IA, especialmente quando isso ganha escala.
  Até na pequena equipe em que trabalho acontecem coisas irritantes. Quando pergunto “por que isso foi feito assim?”, a resposta é “ah, foi o Claude que fez assim”, mas isso não é uma resposta. As pessoas estão transferindo para a máquina não só o processo de raciocínio, mas também a responsabilidade. Por enquanto, usar de forma conservadora não é necessariamente ruim; acho que só faz sentido flexibilizar depois que soubermos como usar essa tecnologia em larga escala de maneira responsável. No momento, ninguém sabe como fazer isso.

• Esta é apenas uma política da própria NLnet Labs; não é uma política que projetos apoiados pela NLnet sejam obrigados a adotar.

• Entendo o contexto que levou a essa decisão, mas a forma de aplicação parece quase um “nada é permitido”, então parece estreita demais.

  • Você pode explicar de onde vem esse juízo normativo? Fico curioso por que alguém teria interesse em aceitar contribuições geradas por LLM no projeto de outra pessoa, e o que essas pessoas ou a sociedade ganham com isso.
    Eu vejo essa lógica como coerente e razoável e, em tempos como os atuais, como uma medida saudável de proteção. Também fico curioso se você está preocupado que suas contribuições sejam rejeitadas por esse motivo, ou se isso já aconteceu com você. Seguir essa política seria tão difícil assim? Você, como mantenedor de longo prazo de infraestrutura crítica, lida todos os dias com ruído de baixa qualidade despejado no issue tracker? Como acha que se deve manter a motivação em um fluxo de trabalho centrado em pessoas, reduzindo o impacto de uma enxurrada de falsos positivos?
  • Eu chamaria isso de cauteloso, não de visão estreita.
  • Quando fica claro que a comunidade relevante não consegue lidar com regras abertas e complexas que reflitam com mais precisão os interesses de todos, é bastante comum que se adotem regras estreitas e simples.
    Isso não é algo ruim. Quando os desenvolvedores amadurecerem um pouco mais, isso poderá ser reavaliado.