Politique d’utilisation des LLM de NLnet Labs
(nlnetlabs.nl)- NLnet Labs limite l’usage des LLM dans les contributions aux projets et la communication, et les soumissions en violation de la politique peuvent être fermées ou supprimées sans préavis
- Les contributions au code et à la documentation doivent être rédigées directement par des humains, et ne peuvent pas inclure de contenu généré par un LLM ou d’autres outils probabilistes
- Dans les signalements de vulnérabilités ou de bugs, des correctifs proposés par un LLM peuvent être acceptés à titre exceptionnel, mais un contributeur humain doit vérifier le problème et sa gravité
- Lors des interactions avec NLnet Labs, comme les issues, les rapports de vulnérabilité ou les messages sur le forum, il est nécessaire de déclarer l’usage d’un LLM ; pour la traduction automatique, cette déclaration est aussi recommandée en raison du risque de contresens
- Les LLM peuvent être utilisés pour le linting, l’analyse et la revue, mais la responsabilité de comprendre et de vérifier l’exactitude des informations partagées à l’extérieur reste à la charge du contributeur
Portée de la politique et obligations de base
- NLnet Labs limite les modalités d’usage des Large Language Models (LLMs) dans le cadre de l’organisation et des projets
- Les soumissions qui ne respectent pas cette politique peuvent être fermées ou supprimées sans préavis
- Cela inclut les PR, issues, commentaires et messages de forum
- En plus de cette politique, il faut aussi respecter le code of conduct et le
CONTRIBUTING.mdde chaque projet
Principes de rédaction des contributions
- Les contributions au code et à la documentation doivent être rédigées par des humains
- Elles ne peuvent pas inclure de contenu généré par un LLM ou d’autres outils probabilistes
- Les correctifs suggérés par un LLM inclus dans un signalement de vulnérabilité ou de bug sont exceptionnellement autorisés
- Cette exception vise à faciliter l’identification de la cause racine du problème lors de la revue initiale
- Lors de l’ouverture d’une PR, les contributions générées par un LLM ne sont pas acceptées
- Le code soumis ne doit pas avoir été généré par un LLM
- La description de la PR doit être rédigée brièvement avec vos propres mots
- En règle générale, une PR de nouvelle fonctionnalité ne doit pas être ouverte sans en avoir d’abord discuté avec NLnet Labs
- Les idées de modification logicielle peuvent être partagées avec vos propres mots sur le community forum
Déclaration d’usage des LLM et traduction
- Lors d’une interaction avec NLnet Labs, il faut déclarer si un LLM a été utilisé
- Cela inclut l’ouverture d’une issue, le signalement d’une vulnérabilité et la publication sur le forum communautaire
- La traduction automatique peut être utile si l’anglais n’est pas votre langue maternelle
- Si vous avez utilisé une traduction automatique, il est recommandé de le déclarer afin que les deux parties soient conscientes du risque de problèmes de communication dus à un contresens
- Si vous n’êtes pas en mesure d’évaluer l’exactitude de la traduction, vous pouvez aussi écrire dans votre langue maternelle
- La traduction par LLM n’est pas recommandée, car sa nature générative risque davantage d’embrouiller les échanges que de les faciliter
Usages autorisés et responsabilité de vérification
- Il est permis d’utiliser les LLM pour le linting, l’analyse et la revue
- Même si un LLM a aidé à détecter ou analyser un problème, l’utilisateur reste responsable de comprendre et de vérifier l’exactitude des informations qu’il partage
Signalement de vulnérabilités
- NLnet Labs peut accepter des signalements de vulnérabilités trouvées à l’aide d’un LLM
- Le rapport peut inclure des correctifs suggérés par un LLM pour aider à localiser le problème
- Un contributeur humain doit vérifier le problème et sa gravité estimée
- Lors d’un signalement à
sep@nlnetlabs.nl, il faut déclarer l’usage d’un LLM - La procédure de signalement des vulnérabilités est décrite sur la page security report
1 commentaires
Avis sur Lobste.rs
J’aimerais connaître la logique de fond derrière ce type de règles
Par exemple, je me demande si la motivation principale est l’incertitude juridique, des inquiétudes liées à la qualité ou à la maintenance, ou autre chose
Mais avant de soumettre cela à l’équipe de NLnet Labs sous forme de pull request, la question essentielle est de savoir s’il a relu, compris et peut assumer la responsabilité de chaque ligne générée. D’après l’expérience de l’année écoulée, c’est rarement le cas : le code arrive sur le pas de la porte comme un cadeau bien intentionné, mais la charge de le relire, d’en assumer la responsabilité et de le fusionner dans la branche main retombe sur l’équipe. C’est beaucoup demander, surtout quand ce logiciel fonctionne dans une infrastructure critique qui constitue l’un des fondements d’Internet. Lors du processus de review, il faut pouvoir discuter avec une compréhension partagée, des deux côtés, du domaine du problème et des détails de la solution proposée ; l’usage des LLM n’apporte pas cette compréhension à la personne qui soumet la contribution et nuit aussi à la maintenance à long terme
Bien sûr, le droit d’auteur, le contrôle qualité, la maintenance à long terme et les préoccupations éthiques ont également été pris en compte
J’apprécie aussi le fait que l’accent soit mis sur l’écriture et la review de patchs par des humains, et que les suggestions de patch dans les rapports de vulnérabilité soient prévues comme exception
Lorsqu’elles sont simples et vont à l’essentiel, ce genre de suggestions mérite d’être lu
Je comprends pourquoi les gens se lassent des productions générées par IA, surtout à mesure que l’échelle augmente
Même dans la petite équipe où je travaille, cela provoque des irritations. Quand on demande « pourquoi avez-vous fait ça ? », on obtient comme réponse « ah, Claude l’a fait comme ça », ce qui n’est pas une réponse. Les gens délèguent à la machine non seulement leur raisonnement, mais aussi leur responsabilité. Pour l’instant, une utilisation conservatrice n’est pas forcément une mauvaise chose ; il sera temps d’assouplir ces règles quand nous saurons utiliser cette technologie de manière responsable à grande échelle. À ce stade, personne ne sait comment faire
Il s’agit uniquement de la politique propre à NLnet Labs ; ce n’est pas une politique que les projets soutenus par NLnet seraient obligés d’adopter
Je comprends les raisons derrière cette décision, mais son mode d’application ressemble presque à un « tout est interdit », ce qui donne une impression de vision étroite
Je trouve ce raisonnement cohérent et raisonnable, et, à l’époque actuelle, c’est une mesure de protection saine. Je me demande si tu crains que tes contributions soient refusées pour cette raison, ou si cela t’est déjà arrivé. Est-ce si difficile de respecter cette politique ? Es-tu toi-même mainteneur à long terme d’une infrastructure critique, confronté chaque jour au bruit de faible qualité qui se déverse dans l’issue tracker ? Selon toi, comment maintenir la motivation dans un workflow centré sur l’humain tout en réduisant l’impact d’un déluge de faux positifs ?
Ce n’est pas une mauvaise chose. Lorsque les développeurs auront un peu gagné en maturité, il sera possible de réexaminer la question