オープンソースと AI 支援による開発：法的課題への対応

本シリーズの前回の投稿では、AI がソフトウェアの開発方法をどのように変化させているかについて紹介しました。今回は、オープンソースの開発者自らが AI 支援による開発に関して提起している主な法的 (または準法的な) 問題のいくつかに焦点を当てます。 

これは AI に関連するすべての法的問題を包括的にまとめたものではありません。たとえば、AI 規制への準拠に関するお客様の懸念や AI を活用した製品の契約に関連する法的責任などは扱いません。むしろ、オープンソース・コミュニティ内で活発に議論されている問題に焦点を当てます。 

これらの問題に関する Red Hat の見解は、AI テクノロジーを責任ある方法で使用するという Red Hat のコミットメントと「オープンを基本とする (default to open)」理念を反映しています。Red Hat は、協調的で透明性の高いアプローチが、これらの懸念を建設的に解決する最善の方法であると考えています。

帰属とマーキング 

帰属表示はオープンソースにおける中核的な法的および文化的規範です。ライセンスは一般的に、著作権および著作者表示を保持し、著作者に関する誤解を招く主張を避けることを要求します。 

AI 支援による開発は、これをさらに複雑にします。著作権法上、AI システムは「著作者」とは見なされないため、技術的には、これが帰属する対象が存在しません。しかし、開発者が大部分が AI 生成の出力を純粋に自らの作品として提示することは、依然として誤解を招く行為です。 

そのため、合成メディアのラベリングなど、他の分野の開示基準からヒントを得て、AI 支援によるコントリビューションに関する開示ルールを導入するオープンソース・プロジェクトが増えています。「マーキング」によるコントリビューションの明示は、法的な明確さとコミュニティの信頼の両方を維持し、レビュー担当者がコンテキストに沿ってコードを評価するのに役立ちます。

Red Hat ではマーキングに対応していますが、過度に規範的なものにする必要はないと考えています。AI の比較的に単純な使用方法 (変数名の自動補完やドキュメント文字列の提案など) であれば、開示の必要はありません。しかし、より本格的に使用される場合、マーキングはソースコードのコメント、マージリクエストのメモ、または Assisted-by: などの commit trailer と同様に単純なものを使用できます (一部のプロジェクトで使用される他の候補には、Generated-by: や Co-authored by: などがあります)。  

著作権およびライセンス方式

帰属表示が重要であるとはいえ、オープンソースは明確なライセンス許諾にさらに大きく依存しています。ここで、コントリビューションに著作権で保護されていない AI 生成物が含まれている場合、ライセンス通知はどのように機能するべきかという実際的な問題が生じます。

ほとんどの場合、ライセンス通知がリポジトリまたは個々のソースファイルにすでに存在する場合は、何も変更する必要はありません。コードは高度な機能を備えているため、ソースファイルはすでに一般に著作権保護の対象となる素材と著作権保護の対象とならない素材が混在しています。しかし、オープンソースライセンスの許諾は著作権で保護されている部分にのみ適用されます。AI 生成による大規模なコントリビューションについては、マーキングによる開示が既存のライセンス通知を補完し、誤解を生じさせることを防ぐ適切な方法になります。 

より困難なケースとなるのは、ソースファイル全体、さらにはリポジトリ全体が AI によって生成される場合です。この場合、人のコントリビューションによってファイルが著作権で保護される著作物に転換されるまで、著作権表示およびライセンス通知を追加することが適切でないことがあります。しかし、オープンソースのリポジトリにはグローバル LICENSE ファイルが必要であるというのが通常であることを考慮すると、技術的には著作権の存在を前提とするとしても、極めて制約の少ないオープンソースライセンス (Unlicense など) を AI 生成リポジトリのグローバルライセンスとして追加するのが合理的です。人のコントリビューションが加わるにつれ、保守担当者はこの初期のライセンス選択を見直すことができます。これ以前にコントリビューションを行った人がいない場合は、オープンソースプロジェクトのライセンスが変更される一般的なシナリオよりも容易になります。Red Hat では、今後も法律における変更と AI ツールに関するコミュニティの経験が蓄積されることにより、実践方法が変化していくことを予想しています。  

AI ツールは「盗作マシン」? 

一部のオープンソース開発者は、AI 支援による開発に対して懐疑的で、時には敵対的でさえあり、AI モデルを「盗作マシン」や「著作権ロンダリング」の仕組みであると非難します。 

この懸念には 2 つの側面があります。1 つ目は、実用的な側面です。AI ツールがオープンソースプロジェクトに、非公開（またはライセンスと互換性のない）コードの断片を密かに挿入する可能性があり、これにより保守担当者やユーザーに法的リスクが生じる恐れがあります。2 つ目は、より広範で哲学的な側面です。膨大な量のオープンソースソフトウェアでトレーニングされた大規模言語モデルが、本質的にコミュニティの成果を不正流用し、オープンソースライセンスが要求する義務が排除された成果物を生成するという指摘です。   

これらの懸念は、真摯に受け止める必要があると考えています。大規模言語モデルが、場合によっては、そのトレーニングデータから非自明な抜粋を生成する能力を有することは事実です。それが頻繁に発生するか、または避けられない動作である場合は、これらのツールの使用を完全に回避すべき十分な理由になります。 

しかし、証拠はそうではないことを示唆しています。GitHub Copilot がリリースされた際、そこからの提案がオープンソースプロジェクトからコピーしたものであるという主張が広く報じられました。既知のコードをそのまま再現するよう意図的にツールを誘導する試みがなされる場合には、これらの主張が実証される可能性がありますが、これは通常の使用方法ではありません。これまでのところ、広く利用されている AI 開発ツールが、著作権上の懸念を引き起こすほど十分な、トレーニングデータの一部を体系的に複製していることを示す信頼できる証拠は確認されていません。

「盗作マシン」論の根底にある誤解は、生成 AI モデルがトレーニングデータの損失を伴う圧縮のように捉えられている点にあります。実際には、モデルの通常の動作は、学習した統計的パターンに基づいて新しいテキストを生成します。オープンソースコードでトレーニングされているからといって、出力がそのコードの再現であることを意味する訳ではありません。 

とはいえ、時折の再現の可能性は無視できません。AI ツールを使用する開発者はこのリスクに注意を払い、AI によって生成された出力を他のコントリビューションと同様に注意して確認する必要があります。AI 開発ツールが既存のオープンソースコードと一致する長い提案を検出したり、フラグ付けしたりする機能を提供する場合は、それらの機能を有効にする必要があります。情報開示のプラクティスと人的監視を組み合わせることで、これらの手順は、再現性の懸念を軽減する実用的な方法となり、すべての AI の使用が本質的に問題を生じさせるものとみなす必要はなくなります。 

AI 支援によるコントリビューションと DCO (開発者証明書)

Developer Certificate of Origin (DCO：開発者証明書) を使用するプロジェクトは、AI 支援を活用したコントリビューションに関する懸念を示しています。DCO は、長い間オープンソース開発のベストプラクティスとして推奨しているもので、コントリビューターには、プロジェクトのライセンスに基づいて成果物を提出する権利があることを証明することが求められます。AI ツールの出力には未知または未公開の素材が含まれている可能性があるため、AI 支援コードに対する DCO 承認を正当に行える者はいないと主張する開発者もいます。このような考え方により、DCO を使用する一部のプロジェクトでは、AI 支援によるコントリビューションを完全に禁止する動きも見られます。 

この懸念は理解できますが、DCO についても、コントリビューションのすべての行が、コントリビューター本人や他の開発者による個人的な創造的表現である必要があると解釈されたことは一度もありません。多くのコントリビューションには定型的な、著作権の対象とならない素材が含まれていますが、開発者は依然としてそれらを承認しています。DCO については、責任が本質的な論点となるでしょう。コントリビューターは、特定のオープンソースライセンスによって (著作権で保護された要素に関して) 規定される作品でコントリビューションを使用する権利があると考えます。また、プロジェクト保守担当者には、コントリビューターが何らかのデューデリジェンスを行って認証を行っているという合理的な期待があります。開示と人による細心の注意、さらにコードの類似性をチェックするツールの支援を可能な限り活用した監視を実施することにより、AI 支援によるコントリビューションを DCO の精神と完全に両立させることができます。

しかし、これらはいずれも、プロジェクトが AI 支援によるコントリビューションを許可しなければならないという意味ではありません。各プロジェクトは独自のルールを定め、独自の許容範囲を設定する権利を有しており、あるプロジェクトが当面の間 AI 支援によるコントリビューションを禁止する決定を下したならば、その決定は尊重されるべきです。このような方向性を選択するプロジェクトは、自らが表明している懸念が AI に特有の新たなものなのか、または AI に特有ではない懸念なのかを認識している必要があります。何年にもわたり、オープンソースを使用するリスク回避型の商用ユーザーの間には、「ロンダリングされる」コード、すなわち非公開で、問題のある規約の下で著作権保護素材を隠蔽するコントリビューションに関する懸念がありました。しかし、時の経過と共に、その懸念は根拠のないものであることが判明しました。AI 支援によるコントリビューションには、未開示の著作権で保護された素材が含まれる可能性はあるものの、経験上、これは管理可能なリスク事象であり、オープンソースが過去に直面し、対処してきた課題と本質的に異なるものではありません。 

言い換えれば、DCO はこれまでと変わらず、AI の時代においてもオープンソース開発における信頼と法的な明確性を維持するための実用的かつ効果的なツールです。

信頼を確立する

ソフトウェア開発における AI に関連した議論の多くは、それが法的、技術的、または倫理的な議論のいずれであっても、その根底にあるのは信頼の問題です。信頼は、人間の根本的な関心事であり、あらゆる成功したオープンソースプロジェクトに不可欠な要素です。オープンソース開発に AI を導入すると、複数の次元で新たな信頼の問題が提起されます。すなわち、コントリビューターが AI を責任を持って使用していること、AI を責任を持って使用する人が非難されることはないということ、また AI を構築し、AI の利用を促進する企業は公共の利益に資する形でこれを行っている点に対する信頼です。Red Hat を含むこれらの企業が AI の成功に商業的利益があることを認めることも、技術変革における自社の役割について透明性を保つ上で極めて重要な要素です。

テクノロジーに対する信頼を築くという課題は新しいものではありません。Ken Thompson 氏の 1984 年の画期的な講義である「Reflections on Trusting Trust」は、人間の判断と組織の一貫性がソフトウェア自体をいかに支えているかを理解する上で、今なお有効な基準となります。AI は、これらの概念を再び鮮明に浮き彫りにします。信頼は、一貫した目に見える行動を通して獲得されるものです。Red Hat はアップストリームコミュニティとの信頼関係を大切にしています。また、透明性、コラボレーション、説明責任に根ざしたオープンソース開発モデルが、AI とオープンソースの未来を共に築いていく中で、信頼を持続するための最善の方法であると確信しています。

将来を見据えて

ここで議論したマーキング、ライセンス通知、トレーニングデータの複製に関する懸念、および DCO は、オープンソース開発者が現在最も注力している法的な課題です。AI の使用に関する開示、人による監視、プロジェクト規則の尊重を通じて、AI 支援による開発は、オープンソースの法的基盤と文化的価値の両方と調和させることが可能です。 私たちは、これらの利害関係を均衡させる他のアプローチを含む、アップストリームプロジェクトにおけるコラボレーションを歓迎します。各プロジェクトは、独自の選択を自由に行える必要があります。オープンソースコミュニティは、これらの課題から距離を置くのではなく、自らこれに取り組むことで、自らをさらに強化していくことができます。