Política de uso de LLM de NLnet Labs

• NLnet Labs restringe el uso de LLM en contribuciones y comunicaciones de proyectos, y los envíos que infrinjan la política pueden cerrarse o eliminarse sin previo aviso
• Las contribuciones de código y documentación deben ser escritas directamente por personas, y no pueden incluir contenido generado por LLM u otras herramientas probabilísticas
• En reportes de vulnerabilidades y bugs, se pueden aceptar excepcionalmente correcciones sugeridas por un LLM, pero una persona contribuidora debe verificar el problema y su gravedad
• Al interactuar con NLnet Labs, por ejemplo en issues, reportes de vulnerabilidades o publicaciones en foros, es necesario declarar el uso de LLM; también se recomienda declarar el uso de traducción automática por la posibilidad de errores de traducción
• Se pueden usar LLM para linting, análisis y revisión, pero la responsabilidad de entender y verificar la exactitud de la información compartida externamente sigue siendo de quien contribuye

---

Alcance de la política y obligaciones básicas

• NLnet Labs restringe la forma de usar Large Language Models (LLMs) en el contexto de la organización y sus proyectos
• Los envíos que no cumplan con la política pueden cerrarse o eliminarse sin previo aviso
  • Esto incluye PR, issues, comentarios, publicaciones en foros, entre otros
• Además de esta política, también deben seguirse el code of conduct y el CONTRIBUTING.md de cada proyecto

Principios para redactar contribuciones

• Las contribuciones de código y documentación deben ser escritas por personas
  • No pueden incluir contenido generado por un LLM u otra herramienta probabilística
  • Se permiten excepcionalmente las correcciones sugeridas por LLM incluidas en reportes de vulnerabilidades o bugs
  • Esta excepción tiene como objetivo facilitar encontrar la causa raíz del problema durante la revisión inicial
• Al abrir un PR, tampoco se aceptan contribuciones generadas por LLM
  • El código enviado no debe haber sido generado por un LLM
  • La descripción del PR debe escribirse de forma concisa y con palabras propias
  • En general, no se deben abrir PR de nuevas funcionalidades sin hablar primero con NLnet Labs
  • Las ideas de cambios de software pueden compartirse con palabras propias en el community forum

Declaración de uso de LLM y traducción

• Al interactuar con NLnet Labs, debe declararse si se usaron LLM
  • Esto incluye abrir issues, reportar vulnerabilidades y publicar en el foro de la comunidad
• Cuando el inglés no es la lengua materna, la traducción automática puede ser útil
  • Si se usó traducción automática, se recomienda declararlo para que ambas partes sean conscientes de posibles problemas de comunicación causados por errores de traducción
  • Si no se puede evaluar la exactitud de la traducción, también se puede escribir en la lengua materna
  • La traducción con LLM no se recomienda porque, por su naturaleza generativa, es más probable que genere confusión que facilite la discusión

Usos permitidos y responsabilidad de verificación

• Se permite usar LLM para linting, análisis y revisión
• Aunque un LLM haya ayudado a encontrar o analizar un problema, la responsabilidad de entender y verificar la exactitud de la información compartida recae en la persona usuaria

Reportes de vulnerabilidades

• NLnet Labs puede recibir reportes de vulnerabilidades encontradas mediante LLM
  • El reporte puede incluir una corrección sugerida por un LLM para ayudar a ubicar el problema
  • Una persona contribuidora debe verificar el problema y la gravedad estimada
  • Al reportar a [e-mail], debe declararse el uso de LLM
  • Para el procedimiento de reporte de vulnerabilidades, debe consultarse la página de security report

[GN⁺]

Opiniones en Lobste.rs

• Me gustaría escuchar la lógica de fondo detrás de estas reglas.
  Por ejemplo, me pregunto si la motivación principal es la incertidumbre legal, preocupaciones de calidad o mantenimiento, u otra razón.

  • Como Alex Band, de NLnet Labs, explicó de forma bastante moderada en este toot, alguien puede escribir un buen prompt y generar 10 mil líneas de código que, funcionalmente, parezcan cumplir con la intención para contribuir una función excelente y necesaria.
    Pero antes de enviarlo como pull request al equipo de NLnet Labs, lo clave es si revisó todas las líneas generadas, las entiende y puede hacerse responsable de ellas. Según la experiencia del último año, eso ha sido poco frecuente: el código aparece en la puerta como un regalo de buena fe, pero la carga de revisarlo, asumirlo y fusionarlo en la rama main recae sobre el equipo. Considerando que este software corre en infraestructura crítica, parte de los cimientos de Internet, es una exigencia grande. En el proceso de revisión, ambas partes deberían poder conversar entendiendo tanto el dominio del problema como los detalles de la solución propuesta, pero el uso de LLM no le da al remitente ese entendimiento y también perjudica el mantenimiento a largo plazo.
  • La razón directa para redactar este documento fue proteger el tiempo de los desarrolladores.
    Por supuesto, también se consideraron derechos de autor, control de calidad, mantenimiento a largo plazo y preocupaciones éticas.

• Me gusta que se enfoque en que las personas escriban y revisen parches, y también que deje como excepción las propuestas de parche en reportes de vulnerabilidades.
  Si son simples y van al punto, vale la pena leer esas propuestas.

• Entiendo por qué la gente se cansa del contenido generado por IA, especialmente cuando escala.
  Incluso en el equipo pequeño donde trabajo pasan cosas molestas. Cuando pregunto “¿por qué lo hicieron así?”, me responden “ah, Claude lo hizo así”, y eso no es una respuesta. La gente está delegando en la máquina no solo el proceso de pensamiento, sino también la responsabilidad. Por ahora, usarla de forma conservadora no me parece necesariamente malo; lo correcto sería flexibilizarlo recién cuando sepamos cómo usar esta tecnología de manera responsable a gran escala. Por ahora, nadie sabe cómo hacerlo.

• Esta es solo una política propia de NLnet Labs y no es una política que los proyectos apoyados por NLnet deban adoptar necesariamente.

• Entiendo el contexto detrás de tomar una decisión así, pero la forma de aplicarla se acerca a un “no a todo”, así que parece de visión estrecha.

  • ¿Puedes explicar de dónde sale ese juicio normativo? Me pregunto qué interés tienes en que otra persona acepte contribuciones generadas por LLM en su propio proyecto, y qué ganan ellos o la sociedad con eso.
    Yo veo esta lógica como coherente y razonable, y en tiempos como los actuales, como una medida de protección saludable. También me pregunto si te preocupa que rechacen tus contribuciones por este motivo, o si ya te pasó. ¿Será tan difícil seguir esta política? ¿Tú, como mantenedor a largo plazo de infraestructura crítica, lidias todos los días con ruido de baja calidad que llega al issue tracker? ¿Cómo crees que se debería mantener la motivación en un flujo de trabajo centrado en personas, reduciendo al mismo tiempo el impacto de una avalancha de falsos positivos?
  • Más que de visión estrecha, yo lo llamaría prudente.
  • Cuando queda claro que la comunidad relacionada no puede manejar reglas abiertas y complejas que reflejen con mayor precisión los intereses de todos, es bastante común que se establezcan reglas estrechas y simples.
    Eso no es algo malo. Cuando los desarrolladores maduren un poco más, se podrá volver a revisar.