LLM禁止は実行不可能だと思う。彼らもそれを分かってるはず。明らかに怪しいものを排除して、不完全な証拠があった場合に簡単に人を追い出す手段なのかな？

たぶん、低い努力のLLMコピペを止めようとしてるだけだね。

今のところは、最低限の努力のPRを排除するためのざっくりしたフィルターだと思う。ただ、長続きはしないだろうから、すぐにデフォルトで拒否するポリシーが出てくると思うし、潜在的な貢献者をスクリーニングするためのいろんなアプローチが出てくるだろうね。

進化したLLMのスラップは、普通の人間のスラップと見分けがつかないだろうね。でも、それが狙いなんだ。このヒューリスティックを使えば、プロジェクトは問題のあるスラップを最小限の投資でフラグ付けできるから、低品質で低努力の大量投稿をレビューするコストを避けられる。理想に近い感じだね。アート系の写真サイトでポルノを禁止するのと似ていて、ルールの境界線上の完璧な適用よりも、「見たらわかる」っていうフィルタリング力の方が重要なんだ。しかも、エロいものを売ってる人たちが、オープンクローのボットエージェントの群れを解き放って、何日もかけて議論したり、ブログやメディア記事で個人攻撃してくることはないだろうしね。

それは強制可能だと思うけど、使用を隠そうとする人がいるから防げないってことだよね？ほとんどのルールや法律はそんな感じだし、行動を禁止しても人はそれをやるからね。だから、通常は罰則も定義する必要があるんだ。>「このポリシーは議論の余地がありません。明確にLLM生成とラベル付けされたコンテンツ（問題、マージリクエスト、マージリクエストの説明を含む）は即座にクローズされます。このポリシーを回避しようとする試みは、プロジェクトからの禁止につながります。」

>「LLM禁止は強制できない」 CLA/出所証明書を印刷して、署名して、封筒と切手で郵送することを求めればいいんじゃないかな。彼らが自分の貢献に適切にライセンスを付与していること（(A)GPL、BSD、MITなど）や、その権限があることを証明するだけでなく、貢献にLLMを使用していないことも証明することを求めれば、直接的なLLM使用を強く抑止できると思う。人々がLLM生成のPoCを作って、それを再構築する間接的な使用は、まだ続くと思うし、発見されずに続くかもしれないけど、直接LLMコードをコミットしようとするよりは、道徳的にも（法的にも）問題が少ないよね。ちなみに、開発者の間でライセンスリテラシーが大幅に低下しているのに気づいたし、他の開発者やプロジェクトのライセンス選択に対する尊重も減っているね。LLMが原因かどうかはわからないけど、10年前とは明らかに違う感じがするよ。

ちゃんとした基準を適用してるのが嬉しいね。AIに依存したプロジェクトを依存関係から外し始めたよ。

これは妥当な決定だと思う（ただ、だんだん不十分になっていくかも）。AIに対する立場はどうでもいいけど、問題はOSSのメンテナーにかかるレビューの負担が増えることだよね。昔はコード自体が努力の証みたいなもので、PRには時間と労力をかけないと一目で却下されちゃった。でも今は、LLMが見た目上正しそうなPRをすぐに生成できるから、その状況は変わった。PRにかけた努力はあったかもしれないけど、詳細にレビューしないとそれを判断する方法がない。こういうポリシーは、見た目でLLM生成のコードを拒否することでレビューの負担を減らすのに役立つ。今はかなりの量がそうだと思うけど、時間が経つにつれて難しくなるかもしれないから、最終的には事前に承認されないとPRを提出できないような、もっと信頼ベースのモデルに移行すると思う。たとえLLMが常に十分な品質のコードを生成すると仮定しても、信頼できない人が提出したコードは多くの理由から詳細なレビューが必要になるから、その場合でもメンテナーが他の人の使い方をレビューするより、自分たちでツールを使った方が早いと思う。

ここでのパターンは、コードじゃなくてコンピュートを寄付するって感じかな。エージェントがほとんどのソフトウェアを書いてるなら、他の人のPRをレビューする手間をわざわざかける必要はないよね。自分のエージェントを使えばいいだけなのに。他の人のエージェントの出力をレビューすることになるし。メンテナーは機能リクエストを受け入れて、自分のエージェントを寄付されたコンピュートで使えば、レビューの手間を省けると思う。プロジェクトのスタイルや規約に合ったコードが得られるし、他人のちょっとズレたやり方の後始末をする時間もいらないしね。

明らかにドライブバイの変更を受け入れないのが解決策じゃない？

プロジェクトのメンテナーは、自分のプロジェクトをどう維持するかを決める権利が常にあるし、誰にも「義務」はないよね。とはいえ、2026年に純粋な「雰囲気」で技術を完全に禁止するのは合理的とは言えないと思う。他の人も言ってるけど、実行不可能な可能性が高いし、実用性のためにも不合理だと思う。今の時代に、ドキュメントの追跡や回帰の追跡、セキュリティ、機能の均衡など、注意深く調整された支援で強化できるものを放置するのは良くないよね。これを単に禁止するのは…選択肢だとは思うけど、私の考えでは合理的じゃない。自動化されたものだから使わないって言ってるようなもので、手動でやるって。多くのプロジェクトが適応する方法を見つけると思う。良いガイドラインを作って、コミュニティが最適なツールを最適なタスクに使えるように手助けして、自動化できるところでは自動化を使うべきだよね。結局、雑なものは雑なもの。プレゼンテーションが気に入らなければ、見ないという選択肢もあるし、コードがぐちゃぐちゃだったり、規約に従ってなかったり、PRが+203323行だったりしたら、拒否することもできる。でも、「LLMs、つまりAI」を理由にすると、ただのドラマを招くだけで、良いコンテンツと見た目の良いコンテンツを区別する努力がさらに難しくなるよね。長期的には持続可能じゃないと思う。コードの最適化に良い方法があれば、その最適化がどこから来たかは関係ない。良いことが証明できればいいんだから。要するに、より良い識別ではなく、より良い検証に焦点を当てるべきだし、変更が良いことを証明することに集中すべきだと思う。テストして、学んで、適応することが大事だよ。ドグマは決して良くない。

> たとえLLMが常に十分な質のコードを生成すると仮定しても、信頼できない誰かが提出したコードは、さまざまな理由で詳細なレビューが必要になるだろうから、その場合でもメンテナーが他の人のツールの使い方をレビューするより、自分でツールを使った方が早いと思う。メンテナーが運営するエージェントも同じような厳密さが必要じゃない？エージェントは私の意見では「他の誰か」であって、信頼できるメンテナーではないよ。

GenAIを使った善意のオープンソース貢献について、今のところの私のルールはこんな感じかな：* PRよりもイシューを優先する（イシューを進めた後、君かメンテナーがそれをプロンプトとして使える） * 実装の手間よりもレビューの手間が少ない場合にだけPRを開く。後者が実現可能かどうかはプロジェクト次第だけど、私が関わっているプロジェクトの一つではかなり明らかだよ。そこでは、依存関係や制約を確認するのが主な作業だから、上流のコミットへのリンクはレビューアにとって素晴らしいショートカットになる。

レビューの負担問題は、一般的に内部ツールで起こることと似てるね。チームがAIを使って週末に内部システムを立ち上げて、みんな感心する。でも、6ヶ月後には誰かがそのメンテに半分の時間を使ってる。構築が高いわけじゃない。レビュー、エッジケース、継続的なメンテナンスが本当のコストなんだよ。OSSへの貢献でも、内部ツールでもね。

問題は、怠惰なバグレポートや過激な機能リクエストがすでにあったことだよね。今は怠惰（または過激）なコードが付いてきてる。でも、時間やスキルが足りなくてコードが添付されていない、ちゃんと書かれたバグレポートもあった。それが、アプリケーションやエンジニアリングの知識、善意を持って扱えば、今後有用なPRに変わる可能性があるんだ。

> AIに対するあなたのスタンスはどうでもいいけど、問題はOSSメンテナのレビュー負担が増えてることだよね。でも、メンテナもレビューのためにAIを使えるしね。

出所証明のあるLLMが必要だと思う。たとえば、GPLコードだけで訓練されたGPL LLMで、ソースデータがすべて知られていて、出力もすべてGPLになるようなやつ。分散した努力で実現できると思う。

悪いアイデアではないけど、今ここでの大きな問題は、コードを提出する側とレビューする側の努力の非対称性が増していることと、何も対策をしなければメンテナーにかかるレビューの負担が持続不可能になることだと思う。

ライセンスの問題が主な問題だとは思わないけど、スパムがね。

むしろ、GPLコードを含まないLLMのことだね。

正直なところ、そのGPLモデルは能力的にSOTAよりずっと劣るだろうから、具体的にどんな用途があるの？優れたLLMを使えるのに、わざわざ劣ったLLMを使おうとする人がいるのかな？

> 明らかにLLM生成とラベル付けされたコンテンツ（問題、マージリクエスト、マージリクエストの説明を含む）は即座に閉じられます。「明らかに」という言葉に注目。英語を母国語とする自分にとって、この表現はポリシーをあまり厳しく感じさせない。潜水艦LLMの提出はどうなるの？Redox OSには特に問題はないけど、彼らの成功を願ってる。これってOSSの美徳シグナルの最新形態みたいに感じる。

それは「疑わしきは罰せず」と解釈したよ。それは合理的な立場だね。

英語が母国語の私から見ると、これは二つの部分に分かれてると思う。明らかなら、反応は即座で議論の余地はない。明らかでないなら、二つ目の部分に入る - 「このポリシーを回避しようとする試みは、プロジェクトからの禁止につながる」。もし潜水艦の提出が発覚すれば、禁止されるだろうね。「バーチャルシグナリング」という言葉は、文化戦争の中で自分の意見を示す以外には意味がなくなった。10年前、デイビッド・シャリアトマダリは「誰かをバーチャルシグナリングで非難する行為自体が、バーチャルシグナリングの行為である」と書いてる。

「聞かざる言わざる」は合理的なポリシーに見えるね。もし誰も君のコードがLLMによって書かれたって分からなかったら、君が著作権を主張するのは、結局は君の良心の問題だよ。

> 潜水艦LLMの提出についてはどう思う？それは彼らのポリシーを回避しようとする試みになるから、プロジェクトからの禁止処分につながるよ。つまり、LLMの使用を明確にラベル付けしないことが禁止事項になるってことだね。

もうすぐ面白い状況になると思う。プロジェクトのメンテナーがLLMを使うことは本当に役立つ場合が多いけど、ユーザーがLLMをどう指導したかをレビューできないから、貢献者を禁止することになるんじゃないかな。

LLMにコードを書くように誘導するのは、彼らが自分でコードを書くのを簡単にすると思うよ。

将来的には、機能リクエストのために詳細な研究や仕様、変更計画を提出する方向性があるかもしれないね。人間が評価できて、両方のスライドで動作するコードに変えられるようなもの。

現在のボトルネックはこんな感じだよ：* 問題を理解すること * 既存のモデリングやアーキテクチャと整合性のある解決策をモデル化し、モデリングとアーキテクチャを正しい方向に進めること * 解決策の実装が偶発的な複雑さを引き起こしていないか確認すること これらはLLMがまだ得意じゃないことだよ。ここに貢献が最も評価されるんだ。コードを生産することは含まれないよ、メンテナーたちは自分のLLMサブスクリプションを持ってるから。

「興味深い状況」は、メンテナーたちが良い貢献と雑な貢献を安く区別できないから、外部からの貢献を受け入れなくなるってことだね。これによって、業界への本当の入り口の一つが閉ざされてしまう。必要なのはただの才能だけだったのに。

PRの著者がLLMでコードを生成しただけなら、GitHubのPRはリポジトリのオーナーとLLMの間の非常に非効率的なインターフェースになっちゃう。オーナーの時間をもっと有効に使うなら、LLMに直接やり取りした方がいいよ。LLM生成のPRに返信して、更新を待って、また返信する、なんてやってる場合じゃない。

GPLは「ソフトウェアの修正のための好ましい形式」について話してるけど、LLMエージェントを使う場合は、ユーザーが与えたテキストも含めるべきだと思い始めてる。プロンプトとかね。もちろん、それでも再現性はないし、プロプライエタリなソフトウェアが必要になるけど！

何らかのLLM監査トレイルが必要だね（使用したプロンプト、モデル識別子、LLMによって書かれたすべてのコードをマークする）。LLMプロバイダーにサインしてもらうこともできるけど（でもローカルモデルではうまくいかない）。PRに含めるべき必須の標準フォーマットとして、追加のみの形式が必要だよ。完璧ではないけど（例えば、ログを完全に削除すること）、コードレビューには役立つかもしれない。これによって、LLMが何を（どうやって）書いたのかを確認するのに役立つと思う。悪質な行為者を捕まえるためではなくてね。

それ、もう起こってるよね。実際の問題は偽善じゃなくて、メンテナが自分のLLMの出力をレビューする時、何を頼んだのかの全体像を把握してて、自分のコードベースのメンタルモデルと照らし合わせて確認できることなんだよね。ランダムな貢献者のLLMの出力は基本的に検証不可能で、どんなプロンプトから生まれたのかも分からないし、その人が提出してるコードを理解してるかどうかも分からない。

一般的に、LLMを使って何かを生成したい人が、LLMが生成したものを消費したい人よりもずっと多いんだ。もっと楽観的な人たちは、この明らかなトレンドについてもう少し考えた方がいいよ。

Redox OSが依存している上流のコードには、すでにLLMコードが含まれていると100%確信してるよ。

そうだけど、それは彼らの選択であり、維持するための負担でもあるね。

ZigもLLM禁止の方針に似たスタンスを取ってるよ。 https://codeberg.org/ziglang/zig#strict-no-llm-no-ai-policy

そうだね、だからバグを修正した私のフォークは https://github.com/pmarreck/zigimg/commit/52c4b9a557d38fe1e1... みたいに、絶対にアップストリームには戻らないよ。LLMがやったからって理由でね。ダサいけど、仕方ないよね。彼らの損失だし。これもバカらしいよ、こんな修正を求める人は、私のようなフォークを探さなきゃいけなくなるから、メンテナンスの負担が増えるだけだし。

LLMに頼ってたら、絶対にうまくいかないよ。数学のテストで自分の解き方を見せた人は、計算機の使い方しか知らない人よりも9割は人生でうまくやってる。じゃあ、計算機の使い方を学ぶ必要すら感じてない人はどうなると思う？GPSや地図アプリなしでナビゲートする能力を失った人たちと同じように、しっかりしたコードを書く能力や問題を解決する能力、ひょっとしたら読む力すら失うよ。老後も頭をしっかり保ちたいし、実際に99%のソフトウェア開発者とは違ってコードを書くのが好きなんだ（なんでお前らはこの仕事を始めたのか全然理解できないけど）。自分でコードを書き続けるよ！億万長者に思考機械のためにお金を払うのはやめよう、うまくいかないから。

そもそも、なんで人たちはOSSにAIのクソみたいなプルリクエストをスパムするんだろう？自分のAIのゴミがプロジェクトに何か価値があると思ってるの？完全にクソ野郎みたいに振る舞って、メンテナーに負担をかければ仕事のオファーが来ると思ってるのかな？やっぱり、何時間もおべっかを使うLLMとやり取りしてると、頭が腐るんだろうね。はっきり言うと、君のAI生成コードには全く価値がない。実際、それ以下だよ。生成することで環境を破壊する手助けをしてるからね。もしその問題がLLMを使って解決できるなら、メンテナーたちは自分でプロンプトを出して、君よりずっと良い結果を得られるよ。だって、彼らは実際にコードを知ってるから。AIは「オープンソースに入る手助け」をしてくれないよ。オープンソースプロジェクトをスパムしても、何も学べないからね。

一つには、雇用主にとってあなたのGitHubプロフィールが見た目上魅力的になるからかな（少なくとも表面的にはね）。時々、あなたのGitHubプロフィールが何らかの広告みたいになってることもあると思う。

それから、プロフィールに「1000のFOSSプロジェクトに貢献してます」って書けるようになる。前はスペーシングの変更みたいなゴミだったのに。

みんなが何をやってるか気になるなら、100以上の主要なソース利用可能プロジェクトを調査したんだけど、その中でAI支援のコミットを禁止してるのは4つ（NetBSD、GIMP、Zig、qemu）だったよ。一方で、AI支援のコミットをしてるプロジェクトにはLinux、curl、io_uring、MariaDB、DuckDB、Elasticsearchなどが簡単に見つかる。調査した112のプロジェクトのうち、70がすでにAI支援のコミットをしてた。

ありがとう。これでどのソフトウェアを避けるべきか分かった：正当なツールの使用を禁止するもの。こういう保護主義的な禁止には全く敬意を払わない。125年前には、まだ自動車に慣れてないからって馬車を運転し続けるべきだって主張する人たちだよ。