QEMU - 「AIコード生成器の使用禁止」ポリシーを策定

• QEMUコミュニティが最近ポリシーを改定。AIコード生成器（例: Copilot、ChatGPT など）の使用およびそれらのツールによるコード提出が禁止された

define policy forbidding use of AI code generators

• 最近、AIコード生成器の利用への関心が急増しているが、それらのツールの出力物に対するライセンス解釈は業界で広く受け入れられていない
• 主要ベンダーは問題はなく、自由にライセンスを選択できると主張しているが、彼らには利益相反が存在する
• AIコード生成器はさまざまなライセンスの下で学習されたデータをもとに作られているため、出力物のライセンス問題について業界の合意がまだ存在しない
• QEMUはDCO（Developer Certificate of Origin）において、コントリビューターがそのプロジェクトのライセンスの下でコードを貢献する権利を明確に持っていることを要求している
  • AIコード生成器を使ったコードの場合、DCOのb/c条項の遵守を立証するのが難しい点を明確に言及している
  • そのため、AIコード生成器が明確に使用された、またはその疑いがある場合、QEMUプロジェクトへのコード貢献を許可しないポリシーを導入した

ポリシーの柔軟性と例外処理

• AI支援ソフトウェア開発は初期段階にあり、法的論点は今後解決される可能性が高い
• ツールの進化により、今後は一部のツールがオープンソースプロジェクトで安全に使用可能になると見込んでいる
• 現在は厳格で安全なポリシーを優先適用し、今後必要に応じて緩和可能としている
• 例外申請は個別に審査して許可可否を判断する予定

[GN⁺]

Hacker Newsのコメント

• オープンソースおよびフリーソフトウェアは、AI生成コードが侵害著作物と見なされたり、パブリックドメインと判断されたりした場合に、とりわけ脆弱だと感じている。もしAIによる編集と人間による編集を区別しなければならない状況になれば、プロジェクトは法的問題で何年も縛られざるを得ず、訴訟費用を用意することもできない。今後AIが作ったコードが人間によって修正されたり既存コードに統合されたりした場合、その後続の人間による編集がフェアユースを外れた二次的著作物と見なされるかどうかも論点である。もしAI生成コードがパブリックドメインだと判断されれば、ソースコードの一部にしかオープンソース／フリーソフトウェアライセンスが適用されないプロジェクトは、ライセンスを悪用する企業に対して強く対処する手段を急速に失う状況になる。ライセンス違反者が人間の作った、つまりライセンスが定められたコードを使った事実まで証明しなければならないという非常に大きな負担になる。一方で、プロプライエタリソフトウェアはこの状況で比較的打撃が小さい。というのも、AI生成コードが無断引用だと主張するには、結局誰かが自社バイナリを分解して元コードと比較しなければならず、すでにプロプライエタリソフトウェアのコードにもパブリックドメインコードが混ざっていることが多いからだ
  • MITライセンスにとっては、むしろこの状況が有利な結果になると思う
  • 経験豊富な開発者の立場として、知識のない「開発者」たちが無作為にAIコードを貢献してくるのを望まない人が多いことには共感する。AIコードを1行ずつ人間が直接レビューするのは、法的問題を離れても何年も人員を縛る仕事になる。第一に、今後それがAI生成コードかどうかを検証する実質的な方法はほとんどないだろう。第二に、本当に100%人間だけで開発されたソフトウェアは、今後AIが支援または作成したプロジェクトより競争力が落ちるのは明らかだ。その唯一の反論は、人間が半導体や電気をもう大量生産できなくなる黙示録レベルの崩壊くらいだ。第三に、仮にあるプロジェクトがAIコードの貢献を完全に排除できたとしても、（どう可能なのかは不明だが、AIに反対の少数派だけが貢献するとしても）結局は誰かがそのコードを複製し、法的に危険な部分だけ取り除いて新しいプロジェクトへ乗り換えるだろう。フォークが許可されたライセンスならそのままフォークされるかもしれないが、複製後に整理するほうが好まれるかもしれない。オープンソースプロジェクトにはまだ道が残っており、未来のソフトウェアは量的に爆発的に増えるだろうし、その99%は粗悪かもしれないとしても、本当に価値あるソフトウェアも多くなる予感がする
  • AI著作権問題に関連する話題として、AIアートに関する米国著作権局の立場を伝える news.artnet.com の最新記事 と、サル自撮り判決のWikipedia を共有し、この議論はすでに後戻りできない道に入っていると言及している
  • もしあるソフトウェアが「このコードで何でも好きにしてよい、こちらは気にしない」という意味での本当のワイドオープンなソースなら、AIによって心配することはまったくない
• LLVMの方針よりも明らかに強硬な立場だという印象を受ける。詳細は LLVM開発者ポリシー で見られる。私は古いタイプの開発者として、作者も理解しておらず自分も理解できないコードをレビューする状況は絶対に望まない
  • 作者が自分のコードすら分かっていないのに、それを自分がレビューしなければならない状況は本当に不快だ。実際、誰かが私にある作業を頼みながら、本人がAIから受け取った説明を伝えて「こうすればいいそうです」と言ってくることがあるが、ただ率直に「これをやってください」と言うほうがずっとましだと思う。むしろ侮辱的に感じる
  • 私が管理するすべてのオープンソースプロジェクトにDCO(Developer Certificate of Origin)を追加し始めており、CONTRIBUTING.md に次のようなLLMコード貢献ポリシーを入れる予定だ

  ---

  LLM-Generated Contribution Policy
  Colorライブラリは複雑な数学と繊細な意思決定に満ちたライブラリである。すべてのIssueやPRは、提出者本人の深い理解のもとで作成されなければならず、とくにPRについては開発者が各コミットについてDCOを証明しなければならない。LLMの助けを受けてPRを作成した場合は、コミットメッセージとPRで明示しなければならない。証拠なしにLLM支援が検出された場合、そのPRは却下される。LLMが作った内容をレビューなしで提出することは無条件で拒否する

  SECURITY.md にも LLM-Generated Security Report Policy として、LLMが生成したセキュリティ報告は無条件で受け付けない方針を入れるつもりだ

  一人でプロジェクトを背負う立場としてバランスを取ろうとしているが、個人的にはLLMによるコード貢献は好まない
  • 私は個人プロジェクトではGitHub Copilotを使っている。ただし、「賢いオートコンプリート」以外の使い方はしない。自分が入力しようとしていたコードと十分似ているときにだけ受け入れる。そのおかげで自分のコードを100%理解でき、うっかりしたバグや著作権論争も避けられる。Copilotをこの使い方で使うと開発は速くなる。実際、タイピングが遅いからではなく、雑念に流されたり退屈したりすることが多いからだ。Copilotのおかげで次の思考またはデバッグのフェーズへ素早く移れる。
    他人が自分のコードすら理解しないままPRを提出できるなど、到底想像しにくい。そういう人たちのせいで、ポリシーのために自分がオートコンプリート程度のLLM利用まで制限される現実には少し不満がある。
    自動リファクタリング課題くらいはCopilotにやらせたいが、試してみるとめちゃくちゃに壊れることが多く、ブロック全体を新規生成する方式が多いため、自分で手作業するよりむしろ遅くなることが多い。
    興味深いのは、もし自分が入力中にバグを書いていると、Copilotがそのバグまでそのまま補完してくることがよくある点だ。変数名のタイプミスのような、文脈上あきらかな間違いまでそのまま自動補完する
  • LLMをコーディング作業で使うときは、たとえば「このYAMLの内容を構造体に変換して、繰り返しパターンは変数に抽出して」といった依頼をする。これは決定論的ツールでもできるが、AIなら30秒できれいにやってくれるし、結果が入力と同一であることもテストしやすい
    自分が行うハイレベルな作業は絶対にAIに任せられないが、反復的で重要度の低い作業はAIに引き受けてもらって速度を上げている。たとえばClaude Codeにデータベースベンチマーク結果のCSVファイルを渡して、各種グラフや外れ値分析をつなげてほしいと頼めば、概念的には簡単でもライブラリ探しやセットアップに時間がかかる作業を素早く片付けてくれる
  • 作者が自分のコードを理解していないならレビューしたくないという気持ちは十分理解できる。ただ、熟練した人間が正しくガイドすれば、AIツールもかなり高度なコードを生み出せる。しかもここ数か月ごとにさらに強力になっており、自然言語の指示だけで成果物を作ることも多い
    コードを「理解する」とは何を意味するのか考えている。自分が取り組んでいるあるプロジェクトは、既存のVMオーケストレーションシステムに新しいストレージバックエンドを完全に新規実装で入れる作業だ。既存コードを知らない立場で、自分で実装する時間もなかなか取れないが、テストクラスターを構築し、さまざまなシナリオを回しながら、設計とテストの観点では全体像を十分把握している
    自分もオープンソースメンテナとして、質の低いLLM「スロップ」PRが来ることがどれほど大きなストレスかは想像できる。結局、作者がコードを理解していようがいまいが、メンテナは必ずコードをレビューしなければならない。
    今後は、こうしたツールを適切に活用し、提出コードの品質水準を他の開発者に伝える方法を模索すべきだと思う。初期のLinux向けZFSポートで見つかった微妙なバグから学んだのは、人間が1行ずつレビューして書くことに劣らず、徹底したテストがきわめて重要だということだ
• 自分のブログ「yes i will judge you for using AI」で予測した結果が現実になった。オープンソースは伝統的に、貢献者の実力を示す隠れたシグナル（competency markers）に大きく依存してきたが、LLMは経験がまったくない人でも実力があるように見えるコードを出せてしまう。経験豊富な人にとっては本当に混乱する衝撃だ。今後は、実際のPRと無関係なソーシャルプルーフ（オンラインまたは対面の会議など）が、大規模プロジェクトに入るうえでますます必要になるだろう
  • 会社でもこの現象を経験している。同僚たちがLLMでコードレビューコメントを作り、レベルが高く見えすぎるので一瞬だまされる。だからコメントが正しいか検証するのに非常に時間を食われ、実際にはコピペした人が払った努力より自分のほうがはるかに多くのエネルギーを消費してしまう
  • ブログのリンクを求めている
• RedHat中心で署名された方針だ。RedHatはかなり真剣で企業志向だ。おそらくRedHatの懸念は「誰がAI生成物の著作権を持てるのか」より、AIが学習過程で取り込んだ他プロジェクトのソースがうっかり飛び出してくる状況なのだろう。大半のハイパーバイザーはクローズドソースで、訴訟好きな企業も多い
  • AIが学習データから「他プロジェクトのコード」をそのまま吐き出す危険のことなら、実際にはAIが生成するほぼすべてのコードに当てはまる問題だと思う
  • 言語モデルはしばしば微妙な論理エラーをより起こしやすく、ハイパーバイザーのセキュリティ境界にまで踏み込むおそれもある。AI支援に大きく頼る利用者は、こうしたミスを見つける準備が不足しているので、より危険だと思う
• IBMに買収されたRedHatの人たちが主にこの方針に署名している点に注目している。IBMはWatsonを作り、2011年にはJeopardy!でも勝った企業だ。「まだ始まったばかり」というAIソフトウェア開発の言説が本当なのか、それともIBM流の買収破壊の一場面なのか疑問だ。
  Dotnet RuntimeはAIを積極的に受け入れている。外部ではあざ笑われるかもしれないが、Stephen Toub や David Fowler のような優れたエンジニアが支持している点に注目すべきだ。
  企業に対しては、次にIBMがAIサービスを売り込みに来たとき、本当に未来志向のパートナーを探したほうがいいと勧めたい。
  North Carolina出身者として、IBMとRedHatが正しい方向を向いてくれることを願っている
• 本当に法的動機なのか気になる。一部のプロジェクトは、単にAIが作る質の低いコードレビューにうんざりしているだけにも見える
  • QEMUは業界で非常に重要なソフトウェアだ。デスクトップVM、クラウド、ビルドサーバー、セキュリティサンドボックス、クロスプラットフォーム環境など、本当にあらゆる場所で使われている。ごく小さな法的リスクでも業界に深刻な影響を与えうる
  • 方針は明確で限定的だ。アルゴリズム的に生成されたコードの著作権帰属を安全に確定できない点を強調しているように見える。あえて「アルゴリズム的に」という語を使っている。現行方針もその趣旨に見えるし、「今日は最も厳格で安全なところから始め、後で緩和する」という文言のように、出発点として合理的に見える。いわゆる「大量のスロップ」を拒否する面もあるだろうが、まずは法的リスクと帰属整理から入る戦略だ。curlの方針よりずっと良いと感じる
  • Monsantoが種子の権利を執拗に行使する事例を挙げて警戒している
  • AIが中程度のコードの質をどう変えるか正直確信はないが、人間もたいてい役に立たないコードを出す。コミットが多すぎて管理が難しいなら、プロジェクトごとにトリアージチームが必要なのではないかと考える。ほとんどの貢献は善意で行われていると思う。
    法的リスクのためにAIを避ける人の気持ちは理解できるが、過度に心配しすぎるのも疑問だ。本当に何らかの可能性をゼロにできたと信じている人は、まだ十分に考え切れていないと思う
  • この流れで行けばオープンソースが壊れるかもしれない。コピペコードがあまりに簡単に出てきて、検討や拒否にかかる時間が多すぎる。今後はさらに多くのプロジェクトが、「誰でもソースコードはダウンロードできるが、外部の人間が実際に貢献するのはほぼ不可能」というAndroid型モデルに変わっていく気がする
• LLMをIDEで賢い自動補完ツールとして使うことと、高レベルの指示を与えてコード全体を大量生成させることは区別されるべきだという希望がある。グレーゾーンであることは認めるが、Copilotのような自動補完程度なら著作権リスクなしに活用させてほしい。たとえば、case 文の列を書くときにCopilotがパターンを検出して入力を大幅に減らしてくれる
  • さらに進んで、自分の思考や身体の一部のようなAIメガネになる未来を夢見ている。いまの普通の眼鏡が視力を補うように、スマートグラスが思考まで補助できるかもしれない。
    自分の脳だって実のところクローズドソースコードをたくさん学習してきたのだから、AIの著作権議論は西洋的なNIMBY（地域エゴ）発想だと皮肉っている。こうした法的な「もしも」を口実にすばらしい技術を拒んでいたら、西洋文明そのものが崩れるかもしれないと懸念している
• こうした方針が出てきた理由は理解できるが、間違いだと思う。AIと著作権の問題については法的判断が不明確で、立法もほとんどないと見ている。
  AI貢献禁止方針とは別に、むしろ「この部分ではAIを使えます」という明確な線引きも必要だと思う。たとえばQEMUのCIセットアップなどはセキュリティを守るべき中核領域ではない。面白く新しいテストケースや環境に対する貢献については、AIを一定条件つきで許可するやり方も十分可能だと思う
  • この方針を導入しなければどんなリスクがあるのか考えている。少し遅くなっても、より良いコードが出てくるだろうし、速度を犠牲にしてでもQEMUのような重要プロジェクトならその程度のリスクは取るべきだと思う。著者たちがGenAI自体に否定的というより、一度始めたら後戻りできない状況なので慎重に進めているように見える
  • 単純に「法的状況が明確になるまで待つ」が最も簡単な解決策だ。QEMUはほぼ全コードがGPL 2.0で、もしGenAIコードが誤って導入され、後に法的に「元のコードライセンスに必ず従わなければならない」という判例が出れば、関連コードのロールバックやダウンストリーム全体に負担が生じる。そもそも「この部分はAI、再利用禁止」のようなラベル付けをしても、後に全面的な書き直しの問題が残る。
    結局、「とりあえず今は受け入れない」が皆にとってより単純で、よりドラマの少ない選択だ。
    関連資料として QEMUライセンス と 非自由ライセンス一覧 のリンクを添えている
  • こうした問題は何十年も続く法的論争ではなく、すでに関連訴訟が何十件も裁判所に上がっているので、数年以内に判例が出る見込みだ。QEMUはAIなしで22年間すばらしく成長してきたのだから、あと数年待ってもまったく悪くない
  • この方針の表と裏をよく読むべきだという助言だ。あらゆる行動には法的リスクがあるが、世界的大企業はむしろこうしたリスクも引き受ける。QEMUが特別なのではなく、実際にはただLLMコードを本当に使いたくないので、こうした立場を打ち出しているように読める。「弁護士に確認しろ → 法的にリスクがある → 使えない」という名目で議論そのものを終わらせようとする戦略だ。会社でもまったく同じパターンが起きている
  • コンピューティング業界には「コードを盗用しない」という古い慣行がある。ごく短いコードでも、法的に『フェアユース』に当たるとしても、元コードをコピーしない文化だ
• 「厳格かつ安全なところから始め、徐々に緩和する」という名目は本当に合理的だ。
  しかし、AI生成コードと人間がどこかから写したコードを実際に区別する方法があるのかは気になる。オープンソースは誰でも貢献できる以上、人間がコードで他のソースの影響を受けるのも同じことだ。
  現時点の見方としては、AI生成コードはそれ自体に独立したアイデンティティがあるというより、人間の手にある道具に近いと思う
  • 「AI生成コードは、人間が握るパワーソー（強力な電動ノコギリ）のようなものだ」という比喩だ。強力な道具なので、人間の次に危険になりうる。
    もうこの比喩も使う必要がないほど長く引っ張ってしまったと感じている
• こうした方針は現実にはまったく実施不可能に見える。Zed、Cursor、VS Code、どのエディタもAIベースの自動補完を提供しており、自分が打ったコードとAIが示したコードの区別はまったく不可能だ。
  まるで自分が棒人間の絵を描いたら、「その絵は誰かの棒人間の絵を真似た可能性があるから提出する権利はない」と言われるようなものだ。
  方針の本当の目的は、結局いつか誰かがAIコードと混ざったものを提出したとしても「仕方がなかった」と言うための免責作りなのだろう。方針立案者たち自身も、その方針が無意味だと分かっていないはずがないと思う
  • こうした方針は、「方針上疑わしいコードが提出されたら、こちらにもどうしようもなかった」という責任回避の名目を明白に確保しようとする性格のものだ。コミットメッセージやパッチに「コード生成器のライセンス問題は法的に確立されていない」という立場も含まれている。
    法的問題以外にも、AIコードを使うことで生じるさまざまな別の問題があるのは確かだ
  • NeovimはAIを強制しない。自分で設定しなければ動かない。もしエディタがAIを無効化できないようにしているなら、そのエディタ自体に深刻な問題があると思う