Se dio a conocer hace poco la noticia de que la Fundación NetBSD, ha establecido una serie de nuevas reglas para modificar su árbol de fuentes, incluyendo una cláusula que prohíbe la inclusión de código generado por herramientas de inteligencia artificial como ChatGPT, GitHub Copilot y Code Llama, sin la aprobación previa por escrito del Core Team.

Se menciona que el motivo y la inquietud principal, es debido a la naturaleza de las IA, ya que estas el modo en el que se entrenan es mediante el uso de una amplia variedad de información, incluyendo código protegido por derechos de autor y bajo diferentes licencias.

Por otra parte, está el tema de que al generar código a través de herramientas de IA, la información no siempre se tiene en cuenta, lo que puede llevar a considerar el código generado como derivado del código utilizado para el entrenamiento del modelo y distribuido bajo ciertas licencias.

Además de ello, cuando un modelo de IA se entrena con código bajo licencias que requieren atribución, el código generado por las herramientas de IA puede no cumplir con este requisito, lo que podría interpretarse como una violación de varias licencias abiertas como GPL, MIT y Apache. También pueden surgir problemas de compatibilidad de licencias al integrar código generado por modelos entrenados en código copyleft en proyectos bajo licencias permisivas como BSD.

Es por ello que esto genera preocupaciones, en especial sobre los derechos de autor y sobre todo en el cumplimiento de las políticas de licencia de NetBSD. Es por ello que la Fundación NetBSD ha definido una serie de nuevas directrices que definen los estándares para realizar «commits» en su repositorio de código fuente.

En cuanto a las nuevas directrices para realizar «commits» en el proyecto NetBSD:

• Familiaridad con el código: Se requiere que los desarrolladores únicamente realicen «commits» de código con el que estén familiarizados. Si existen dudas acerca de la aceptabilidad del código a ser comprometido, se recomienda solicitar una revisión a un desarrollador experimentado en esa área específica.
• Código aprobado: No se debe comprometer código que no haya sido escrito por el propio desarrollador, a menos que se haya verificado que la licencia de dicho código permite su importación en el repositorio de código fuente de NetBSD y su libre distribución. Código generado por grandes modelos de lenguaje u tecnologías similares se considera como código comprometido y no se debe comprometer sin previa aprobación escrita por parte del Team Core.
• Origen del código: Se prohíbe comprometer código proveniente de árboles de código fuente externos. Todo el código debe ser obtenido exclusivamente desde cvs.NetBSD.org.
• Nivel de aprobación requerido: La magnitud de los cambios determina el nivel de aprobación necesario. Además, la introducción de nuevas características o la inclusión de nuevos paquetes requiere discusión previa en una lista de correo técnica específica y aprobación por parte del core.
• Pruebas del código: Antes de comprometer el código, es necesario realizar pruebas exhaustivas para garantizar su correcto funcionamiento. Es crucial probar el código en una variedad de escenarios y entornos, y asegurarse de que no cause regresiones a largo plazo.
• Agrupación de «Commits»: Si varios «commits» forman parte de una misma corrección, se deben agrupar en un único «commit».
• Cada «Commit» como una entidad separada: Cada «commit» debe representar una sola corrección, adición, o modificación. Se debe Evitar agrupar múltiples cambios en un solo «commit» simplifica el proceso de extracción a ramas de desarrollo y facilita la revisión de los cambios por parte del equipo de lanzamiento (releng).
• Documentación clara en el log de «Commits»: Es crucial proporcionar una documentación detallada de las razones detrás de cada cambio en los registros de «commits». Esta información es invaluable para comprender el propósito y el contexto de un cambio en el futuro.
• Dar el crédito adecuado: Cada «commit» debe otorgar crédito adecuado a los contribuyentes, ya sea por correcciones presentadas en reportes de problemas o por código obtenido de otros proyectos de código abierto.
• Proceso de reversión de «Commits»: Se recomienda no revertir los «commits» de otros desarrolladores sin una discusión o acuerdo previo. En caso de desacuerdo, se debe contactar al Equipo Principal (Core Team) como autoridad de mediación.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.