NLnet LabsのLLM利用ポリシー

• NLnet Labsは、プロジェクトへの貢献とコミュニケーションにおけるLLMの利用を制限しており、ポリシー違反の投稿は事前通知なしにクローズまたは削除される可能性がある
• コードとドキュメントへの貢献は人間が直接作成する必要があり、LLMやその他の確率的ツールが生成した内容を含めることはできない
• 脆弱性・バグ報告では、LLMが提案した修正案を例外的に受け付けることがあるが、人間の貢献者が問題と深刻度を検証しなければならない
• Issue、脆弱性報告、フォーラム投稿のようにNLnet Labsとやり取りする際は、LLM利用の開示が必要であり、機械翻訳についても誤訳の可能性があるため開示が推奨される
• LLMをlinting、分析、レビューに活用することはできるが、外部に共有する情報の正確性を理解し検証する責任は引き続き貢献者にある

---

ポリシーの適用範囲と基本義務

• NLnet Labsは、組織およびプロジェクトの文脈における**Large Language Models（LLMs）**の利用方法を制限している
• ポリシーに従わない投稿は、事前通知なしにクローズまたは削除される可能性がある
  • 対象にはPR、Issue、コメント、フォーラム投稿などが含まれる
• このポリシーに加えて、code of conductと各プロジェクトのCONTRIBUTING.mdにも従う必要がある

貢献物作成の原則

• コードとドキュメントへの貢献は人間が作成しなければならない
  • LLMまたはその他の確率的ツールが生成した内容を含めることはできない
  • 脆弱性またはバグ報告に含まれるLLM提案の修正案は例外的に許可される
  • この例外は、初期レビューの際に問題の根本原因をより見つけやすくするためのもの
• PRを開く場合も、LLM生成の貢献は受け付けない
  • 提出するコードはLLMが生成したものであってはならない
  • PRの説明は自分の言葉で簡潔に書く必要がある
  • 一般に、新機能のPRは事前にNLnet Labsへ相談せずに開くべきではない
  • ソフトウェア変更のアイデアは、community forumで自分の考えとして共有できる

LLM利用の開示と翻訳

• NLnet Labsとやり取りする際は、LLMを使ったかどうかを開示しなければならない
  • Issueの作成、脆弱性報告、コミュニティフォーラムへの投稿が含まれる
• 英語が母語でない場合、機械翻訳は役立つことがある
  • 機械翻訳を使用した場合は、誤訳によるコミュニケーション上の問題の可能性を双方が認識できるよう、開示が推奨される
  • 翻訳の正確性を判断できない場合は、母語で書くこともできる
  • LLM翻訳は生成的な性質のため、議論を円滑にするよりも混乱させる可能性が高く、推奨されない

許容される活用と検証責任

• LLMをlinting、分析、レビューに使用することは許可される
• LLMが問題発見や分析を助けたとしても、共有する情報の正確性を理解し検証する責任は利用者にある

脆弱性報告

• NLnet Labsは、LLMで見つけた脆弱性報告を受け付けることがある
  • 報告書にLLM提案の修正案を含めて、問題箇所の特定を助けることができる
  • 人間の貢献者が問題と推定される深刻度を検証しなければならない
  • [e-mail]へ報告する際は、LLM利用を開示する必要がある
  • 脆弱性報告の手順についてはsecurity reportページを参照する必要がある

[GN⁺]

Lobste.rs の意見

• こうしたルールの背景にある論理を聞いてみたい
  たとえば主な動機が法的な不確実性なのか、品質やメンテナンス上の懸念なのか、あるいは別の理由なのかが気になる

  • NLnet Labs の Alex Band が this toot でかなり抑制した形で説明しているように、誰かが優れた必要な機能を貢献しようとして、プロンプトをうまく書き、機能的には意図どおりに見える1万行のコードを生成することはあり得る
    しかし、それを NLnet Labs チームにプルリクエストとして提出する前に、生成されたすべての行をレビューし、理解し、責任を持てるかどうかが核心となる。過去1年の経験では、そうしたケースはまれで、善意の贈り物のようにコードが玄関先に置かれる一方で、それをレビューし、責任を負い、main ブランチへマージする負担はチームに移る。このソフトウェアがインターネットの根幹を成す重要インフラで動くことを考えると、大きな要求だ。レビューの過程では、問題領域と提案された解決策の詳細について、双方が理解を共有した状態で対話できる必要があるが、LLM の使用は提出者にその理解を与えず、長期的なメンテナンスにも悪影響を及ぼす
  • この文書の作成に踏み切った直接の理由は、開発者の時間を守るためだった
    もちろん著作権、品質管理、長期メンテナンス、倫理的な懸念もすべて考慮した

• 人がパッチを書き、人がレビューすることに焦点を当てている点もよいし、脆弱性報告書のパッチ提案は例外としている点もよい
  単純で要点を押さえたものなら、そうした提案は読む価値がある

• 人々が AI 生成物に疲弊する理由は理解できるし、特に規模が大きくなるほどそうだと思う
  私が働く小さなチームでも腹立たしいことが起きる。「なぜこうしたのですか？」と聞くと、「ああ、Claude がそうしました」という答えが返ってくるが、それは答えではない。人々は思考プロセスだけでなく責任まで機械に押しつけているのだ。今のところ保守的に使うのは必ずしも悪いことではなく、この技術を大規模に責任を持って使う方法が分かってから緩和するのが妥当だと思う。現時点では誰もその方法を知らない

• これはNLnet Labs 自体のポリシーにすぎず、NLnet の支援を受けるプロジェクトが必ず採用しなければならないポリシーではない

• こうした判断に至った背景は理解できるが、執行方法が「全部だめ」に近く、視野が狭く見える

  • その規範的判断がどこから来るのか説明してもらえるだろうか。他人が自分のプロジェクトでLLM 生成の提出物を受け入れることに、なぜ利害関係があるのか、彼らや社会が何を得るのかが気になる
    私はこの論理は一貫していて合理的であり、今のような時期には健全な保護措置だと思う。この理由であなたの提出物が拒否されるのを心配しているのか、それともすでにそうした経験をしたのかも気になる。このポリシーに従うのはそんなに難しいことなのだろうか。あなた自身は重要インフラの長期メンテナーとして、毎日 issue トラッカーに押し寄せる低品質なノイズに対処しているのだろうか。人間中心のワークフローで偽陽性の洪水による影響を減らしつつ、モチベーションを維持するにはどうすべきだと思うか
  • 視野が狭いというより、慎重だと呼びたい
  • 関連コミュニティが全員の利害をより正確に反映する、オープンで複雑なルールを受け止められないことが明らかになると、狭く単純なルールが定められるのはかなりよくあることだ
    これは悪いことではない。開発者たちがもう少し成熟すれば、改めて検討できるだろう