これ、オープンソースを壊しちゃうかもね。クソみたいなものをすぐに生成できるのに、それをレビューして却下するのに時間がかかるから。Androidみたいに、ソースはダウンロードできるけど、実際には外部の人が貢献できないプロジェクトが増えそう。

彼らは方針が見直し可能だって言ってるし、例外を作ることもできるみたいだね。もしそれが言い訳なら、みんなを優しく失望させるために頑張ってるってことか。

AIが中央値の投稿にどんな影響を与えるかは分からないな。人間もクソみたいなコードを書くことがあるし。もし問題が投稿が多すぎることなら、それを管理するための仕組みが必要だと思う。大量の更新を受け取るプロジェクトにはトリアージチームが必要かも。ほとんどの投稿は善意で行われてると思うけど、法的な問題の可能性を避けるためにAIを使わない人もいるだろうね。そんな問題が起こる可能性は疑わしいけど、リスクを最小限にするよりも、すべてを排除したい人もいる。哲学者としては、何かの可能性を排除したと思ってる人は、ただそれについて十分に考えてないだけだと思う。

このポリシーは簡潔でしっかりとした内容だね。アルゴリズム的に生成されたと思われるソフトウェアコードの著作権を安全に割り当てることはできないって主張してるように思う。アルゴリズム的って言葉を使うのは、「AI lol」よりも強い感じがするから。ポリシーの中で「AIコードジェネレーター」みたいな用語も使ってるけど、そっちも強いかもしれないけど、法的に役立つ用語になるとは思えないな（ほとんど「クラッパムのオムニバスの男」みたいな感じ）。最後に、かなり妥当な締めくくりがあるね。「今設定するポリシーは今日のためのもので、見直しにオープンであるべきだ。厳格で安全に始めてから、徐々に緩めるのがベストだ。」間違いなくいろいろな問題が出てくるけど、まずは法的な角度を閉じたいみたいで、著作権の話から始めるのは妥当だと思う。このプレイブックはcurlのよりずっと良さそうだね。

モンサントが種の権利をどうやって守ってるか見たことある？

可能性はあるけど、QEMUは業界にとって非常に重要なソフトウェアだよ。デスクトップのVMからクラウド/リモートインスタンス、ビルドサーバー、セキュリティサンドボックス、クロスプラットフォーム環境まで、幅広く使われてる。ちょっとした法的リスクでも業界に大きな影響を与えるかもしれない。

これをやらないリスクは何？オープンソースプロジェクトのためにコードは良くなるけど、速度は遅くなる？このプロジェクトにはそのリスクが合ってると思うし、著者たちもGenAIという概念に対して特に否定的じゃないみたい。ただ「一方通行のドア」を通ってるだけ。

コンピュータの世界では、コードを盗用しちゃいけないっていう確立された慣習があるんだ。小さなスニペットでもね。たとえ著作権法がそんな小さなものを「フェアユース」と考えたとしても。

これは、何十年もかかるような他の法的問題とは違うよ。今、裁判所で進行中のケースがいくつもあって、数年以内に著作権に関するいくつかの側面が明らかになるはず。QEMUはAIの助けなしでこの22年間大きな進展を遂げてきたから、あと数年待つくらい問題ないよ。

法的状況がはっきりするまで待つのが一番シンプルな解決策だね。QEMUは（ほとんど）GPL 2.0ライセンスだから、（ほとんどの）コードの寄付はGPL 2.0に適合する必要があるんだ。仮に、非GPL互換のコードから派生したり、記憶したり、コピーしたりしたgen AIコードを含むパッチによって追加されたコード寄付があったとしよう。そうすると、仮に法的なケースがあって、gen AIのFOSSコードは元の派生した/記憶した/コピーしたコードのライセンスを再適用しなければならないという前例ができたら、QEMUのメンテナは互換性のないコード寄付をすべて巻き戻さなきゃいけなくなるだろうね。しばらくすると、そのコード寄付が下流の呼び出し元に影響を与えて、そっちも書き直さなきゃいけなくなるかもしれない（CIコードでも）。最初に「明確に『再利用禁止：AI』とラベル付けされたCIコードだけ」と言うのは可能かもしれないけど、仮にそうなったらメンテナはそのCIコードの部分をすべて見直して書き直さなきゃいけない。さらに、レビューやマージプロセスにも余分な作業が増えるし、関わる全員にとって「今はいいや」と言った方が楽だよ。---- 注意：私は法律の専門家ではないし、ライセンスは私の専門分野ではないけど、いつかはそうなりたいな。

ここでの言いたいことを読み取る必要があると思う。あなたがやることはすべて法的リスクだけど、この特定のリスクは世界の大企業にとっては受け入れられるようだ。QEMUは特別じゃないから、もし彼らがこの立場を取っているなら、他の理由でLLM生成コードを扱いたくないからだろうし、法的リスクを口実にしてメールリストでの無限の議論を避けたいだけなんだ。企業環境でも同じことをやってる。「これが嫌だ」→「弁護士に聞いてみる」→「ああ、法的にリスクがあるからできないよ」。

作者が理解していないコードをレビューしたくない。これ、本当にイライラする。人に「何かやってくれ」って頼まれるんだけど、AIにタスクのやり方を指示させて、その指示を送ってくるんだよね。「ねえ、Xやってくれない？」って言ってくれればいいのに。失礼だよ。

作者が理解していないコードをレビューしたくない。 作者は私と私のシリコンの相棒だよ。私たちはこのことを理解してる。

私は今、私が管理しているすべてのオープンソースコードにDCOを追加し始めていて、CONTRIBUTING.mdにこんな文を追加するつもりだ： --- LLM生成の貢献ポリシー Colorは複雑な数学と微妙な決定が詰まったライブラリです（その中には間違っている可能性のあるものもある）。提出者が問題やプルリクエストをよく理解していることが非常に重要で、特にプルリクエストの場合、開発者は各プルリクエストの開発者証明書に署名できる必要があります（LICENCEを参照）。プルリクエストを書く際にLLMの支援を受けた場合、そのことはコミットメッセージとプルリクエストに記載しなければなりません。そのような宣言なしにLLMの支援の証拠がある場合、プルリクエストは却下されます。未レビューのLLM出力を使用した貢献（バグ、機能リクエスト、プルリクエスト）は拒否されます。 --- これをSECURITY.mdのエントリーにも追加しています： --- LLM生成のセキュリティレポートポリシー LLMエージェントによって生成されたセキュリティレポートは一切受け付けません。 --- ほとんど私一人なので、バランスを取ろうとしているけど、私の好みはLLM生成の貢献には反対です。

コーディングタスクでLLMを使うときは、「このYAMLを構造体に変換して、繰り返しのパターンを再利用する変数に抽出してくれ」って感じだよね。こういう変換は決定論的なツールでもできるけど、AIなら30秒でいい仕事してくれるし、新しい出力が元の入力と同じかどうかをテストするのも簡単。俺の高レベルな仕事はAIに任せるのは絶対無理だけど、AIは面倒なことや低リスクの雑務を手伝ってくれる。先日、Claude Codeにデータベースのベンチマーク結果のCSV用にグラフや外れ値分析を組み合わせてもらったんだけど、概念的には簡単でも、ライブラリを理解して全部接続するのに結構時間がかかるんだよね。CSV処理の専門家じゃないと大変だし。

個人プロジェクトではGitHub Copilotを使ってるよ。でも、 fancy autocomplete以上の使い方は拒否してる。もし提案されたコードが自分が打とうとしてたものに近いなら、受け入れるけどね。これで自分のコードを理解してることが保証されるし、幻覚から生じるバグもないはずだし、もし自分が打とうとしてたものなら著作権の問題もないはず。こうやってCopilotを使うと、作業が早く進むんだ。タイピングが遅いからじゃなくて、タイピング中に飽きたり気が散ったりする癖があるから。Copilotのおかげで次の思考やデバッグの部分に早く進める。誰も自分のコードを理解したくないなんて思わないっていうのが、特にPRを出すつもりならなおさらだよね。そういう人たちの存在が、オープンソースプロジェクトに提出する際にLLMをautocompleteとして使えなくするポリシーを生んでるのがちょっとイライラする。Copilotを他の方法でも使おうとしたこともあるけど、雑なリファクタリングタスクをやってくれるといいなと思ってる。でも、実験するたびにすぐに失敗するか、手動でやるよりも遅くなっちゃうんだ。コードを再生成する必要があるから、編集するだけじゃ済まないし。[1] それに、バグを打ってる最中にCopilotがそのバグのままオートコンプリートしてくれるのが面白い。変数名をタイプミスしてるのが明らかでもね。

あなたはまさに私が一緒に働きたいと思っているタイプの人だ。自己反省ができて、怠惰な行動に反対している。

自由ソフトウェアプロジェクトに関してはこれが面白いと思う。確かに、日常の仕事として貢献している人がたくさんいるけど、楽しみのためにプロジェクトに貢献したり管理したりする場合、AIの雑な部分を片付けることが楽しみを損なう要因になることは間違いない。そういう時は「お引き取り願いたい」って言うのが当然だよ。

言語モデルが微妙な論理エラーを引き起こす可能性が高いのが心配だな。特にハイパーバイザーのセキュリティ境界を侵害するようなエラー。そういうモデルに頼ってコードを書かせるユーザーは、そのエラーを見つける準備が全然できてないと思う。

でも、AIが他のプロジェクトに属するトレーニングセットからコードを吐き出すリスクがあるんだ。これがAIが吐き出すすべてだよ。

もしソフトウェアが「このコードで好きにやってくれ、俺たちは気にしない」という意味で本当にオープンソースなら、AIから恐れるものは何もないよ。

またはパブリックドメイン https://news.artnet.com/art-world/ai-art-us-copyright-office... https://en.wikipedia.org/wiki/Monkey_selfie_copyright_disput... この船はもう出て行ったと思うよ。

経験豊富な開発者が知識のない「開発者」からのランダムなAI貢献を望まない理由はわかるよ。どんな状況でも、人間がAIコードを行ごとにレビューするとなると、それだけで何年もかかるし、法的な問題を無視してもね。#1 初期のモデルを超えてAI生成であることを証明する方法はないよ。#2 何らかの形で100%人間が開発したソフトウェアプロジェクトは、AI支援やAIが書いたプロジェクトと競争できない。唯一の議論の余地があるとしたら、人間が半導体や電気を生産できなくなるような終末的なシナリオだけだね。#3 もしプロジェクトがAIの貢献をうまく排除できたとしても（反AIの熱心なグループに貢献を制限する以外にどうするかは不明だけど）、それはクローンされて、クローンがそれを追い越すだけだよ。ライセンスがフォークを許可していればフォークも可能だけど、クローンして法的な問題を排除する方が好まれるかもしれない。オープンソースプロジェクトにはまだ道があるよ。違う形になるだろうけど、未来にはもっともっとソフトウェアが増えるし、全部がゴミってわけじゃない（99%はそうかもしれないけど）。

あと、AIグラスが自分の心と体の延長になって、画面に表示されているものを含めて、やることすべてに対してヒントやガイダンスをくれるようになってほしい。これらのグラスは、自分の一部になると思ってる。今のダサいメガネが自分の一部で、視力を良くしてくれるように、スマートグラスは視力だけでなく思考も良くしてくれる。自分の脳も多くのプロプライエタリコードで訓練されているし、AIモデルに関する著作権の問題は無意味な西洋のNIMBY思考で、法的な「もしも」を追求し続けると西洋文明の崩壊につながると思う。

最近、同僚がLLMを使ってコードレビューを生成してるのを見かけるようになった。彼らは自分のスキルレベルを超えたコメントを提出してくるから、まるで正しいかのように思わせるんだ。ほんとに熟練した開発者じゃないとこんな提案はしないからね。結局、そういう提案が間違ってることを証明するのにものすごく時間を無駄にしちゃう。提案を出した人がかけた時間よりもずっと多くの時間を使ってるんだよ。

ブログのリンク送ってください。

QEMUは「石器時代」に留まる選択をすることもできるよね。AIのサポートを好む貢献者は、他のところで時間を使えばいいし。実際、いくつかの（多くの基盤的な）OSSプロジェクトは、完全な法的判例が確立されるまでAIを拒否するのが賢明かもしれない。もし彼らが貢献を受け入れ始めて、後で裁判所がこれが第三者の著作権に違反していると判断したら（その結果がどんなに衝撃的でも）、そのプロジェクトは危険にさらされることになる。彼らは訴訟を避けるための資金やリソースもないし、AI導入前の状態に完全に戻すこともできないからね。

誰かがAIの助けを借りてQEMUを自分で書き直せるって言ってるみたいだね。それは面白いかも。