NVIDIA Open Model Licenseのオープンソース性と利用における問題点のメモ

先日、NVIDIAがリリースしたオープンウェイトのAIモデル「Nemotron 3」に関し、それをオープンソースだとして誤って報道するメディアが散見される。それらによってNemotron 3のライセンスであるNVIDIA Open Model License Agreement(2025年10月24日版:以下、NVIDIAライセンス)の利用リスクを無視する動きが懸念されるため、ここでそのオープンソース性と特に大企業におけるモデル利用時のライセンス上のリスクについて整理する。

  1. NVIDIA Open Model License Agreementのオープンソース性
  2. 企業でのモデル利用においてライセンスから生じるリスク
    1. NVIDIAに対する補償義務:
    2. 利用規約組み込みによる用途制限:
    3. ガードレール回避によるライセンス自動終了:
    4. 輸出規制・経済制裁への対応義務:
    5. ライセンス内容の一方的更新および米国法準拠:
    6. グループ企業全体への広範な適用:
    7. 再頒布時の表示義務の重さ:
  3. まとめ
  4. 参考

NVIDIA Open Model License Agreementのオープンソース性

NVIDIAライセンスは、モデルの学習済みウェイト等に適用される独自ライセンスであり、Open Source Initiative(OSI)が定める「オープンソースの定義」(Open Source Definition:OSD)に基づいてその定義に適合するかを検討する必要がある。一見すると、確かにNVIDIAライセンスでは、モデルの商用利用や派生モデルの作成や頒布に対して一定の自由を許諾しており、また、モデルの出力に対してはNVIDIAライセンスではNVIDIAが権利を主張しないことが明記されている。OSDはソフトウェアの利用・改変・再頒布に関する要件を定義するものであり、モデル出力の帰属を直接規律する条項はない。もっとも一般に、成果物に対する権利関係は成果物自体の性質や第三者権利の有無に依存し、ライセンス条件が当然に出力へ波及すると整理されるとは限らないが、NVIDIAライセンスでは「NVIDIA claims no ownership rights in outputs」と明記しており、この点は利用者に有利な条項であり、またこのような出力の自由を併せてNVIDIAライセンスはオープンソース的な特徴をある程度持っているとは言えるだろう。

しかし一方で、NVIDIAライセンスには利用目的や利用者に対する制限条項が含まれており、OSDに照らし合わせると明らかに適合しない。具体的には、NVIDIAライセンス第2条において、NVIDIAの定める倫理規定への準拠が要求されている。NVIDIAは「Trustworthy AI」という利用規約において「違法な監視」「違法な生体情報収集」「違法な嫌がらせや詐欺目的」での利用を禁止しており、それらはNVIDIAライセンスに参照により準拠が求められるため、Trustworthy AI側の改定が実務上の義務内容に影響し得る。この種の利用における用途制限は、「特定の分野での利用を制限しない」というOSD第6条と衝突することになる。そして、輸出規制・制裁の条項は結果的に「特定の人や集団に対する差別禁止」(OSD第5条)との緊張関係があると言えるし、また、NVIDIAライセンスでは、モデルに組み込まれた安全策(ガードレール)を回避あるいは無効化した場合に自動的にライセンスが終了するとも定められているが、このようなガードレール回避禁止条項は派生物の改変や頒布を許諾するOSD第3条やソースコード完全性に関するOSD第4条の趣旨とも緊張関係にあるとも言える。さらに、NVIDIAが法規制への対応のためとしてライセンス内容を一方的に改訂でき、利用者は改訂版に従うか利用を止めるか選ぶ必要がある旨が定められているが、このようなライセンス条件の変更留保もオープンソースライセンスが原則として不変かつ事前に公開されているという前提と相いれない。さらにNVIDIAライセンスでは契約的な受諾を強く示唆する条文があり、再頒布時に追加のライセンス受諾不要とするOSD第7条の観点での論点も生じるだろう。

以上の点から、OSIによる正式な審査を待つまでもなく、NVIDIAライセンスはオープンソースの定義には明らかに適合しないと言える。従って、NVIDIAライセンス下で公開されたモデルを「オープンソース」と呼ぶのは誤りである。

企業でのモデル利用においてライセンスから生じるリスク

NVIDIAライセンスは単にOSI未承認であるというだけでなく、特に企業での利用に際して注意すべき独自のリスク要因を含んでいる。特にグループを形成するような大企業全体での利用や顧客への提供を想定すると、以下のような点でオープンソースライセンスには無い負担や法的リスクが生じると考えられる。ここでは重大と考えられる順に列挙していく。

NVIDIAに対する補償義務:

NVIDIAライセンス第8条では、モデルや派生モデルあるいは出力の利用に関連して第三者からクレームが発生した場合に、利用者(ライセンシー)がNVIDIAを補償し防護する義務を負うと規定されている。これはOSI承認の典型的なオープンソースライセンスでは一般的ではない極めて厳しい責任転嫁であるだろう。素直に条文を受け取れば、モデルの出力が原因で訴訟や損害賠償請求が生じた場合、企業は自社が被告となるだけでなくNVIDIAに対してまで補償責任を負う可能性がある。企業規模が大きく社会的影響力が強い企業グループであるほどこのリスクは重大であり、重要なサービスでNVIDIAライセンスを適用するモデルを利用するには何らかの追加リスクヘッジ策が必要となるだろう。保険のような仕組みが欲しくなるところである。

利用規約組み込みによる用途制限:

前節で述べているように、NVIDIAライセンスはNVIDIAの定める「Trustworthy AI」(2024年6月27日版)という利用規約を組み込む形でモデルの用途を制限している。これは他の米国企業のオープンウェイトにも見られる仕組みであるが、この仕組みによってライセンシーである企業は自社内の利用のみならず、そのモデルを組み込んだ製品やサービスを顧客に提供する場合にも、顧客やエンドユーザーによる利用が規約違反とならないよう管理する義務を事実上課される。

そして、肝心のTrustworthy AIの内容からは、監視用途や生体認証、ハラスメント目的への利用が「違法」と見なされるか否かが問題視されることとなり、それらは文脈や司法管轄によって解釈の幅があることから最終的にはNVIDIAの判断に委ねられる余地があるのも難点である。大企業がこのモデルを利用・提供するには、少なくとも利用規約や契約書において下流のユーザーにもTrustworthy AIと同等の禁止事項を課し、さらにその遵守を技術的あるいは運用的に監視する仕組みが必要になるだろう。これに含まれるのは、ログの記録、不正利用の検知の仕組み、通報窓口の設置などとなる。これはモデルを利用する製品実装上の負担になるだけでなく、仮に下流で不適切な利用が行われた場合に自社も契約違反を問われるリスクがあるだろう。

ガードレール回避によるライセンス自動終了:

NVIDIAライセンス第2.1条では、モデルに内蔵された技術的制限や安全ガードレール(および関連するハイパーパラメータ等)を迂回・無効化または効果を減殺した場合にライセンスが自動的に終了すると定めている。ガードレールを外さないことはモデル利用者に課された必須条件であり、たとえ悪意なく安全設定やフィルタを調整しただけでもNVIDIAの解釈次第で「効果を減じた」とみなされれば契約違反となり得ると考えられる。つまり、大企業において複数部門がモデルを改変若しくはチューニングして利用するような場合、意図せずこの条項に抵触しライセンス喪失(契約の自動終了)を招く事故も起こりかねない。特に第三者にモデルや派生モデルを再頒布・提供する際には、提供先での設定変更による違反も含め慎重な対策が必要となる。

輸出規制・経済制裁への対応義務:

NVIDIAライセンス第11条では、米国の輸出管理規則や経済制裁法令を含む適用される全ての輸出入関連法令に従うことが「明示的」に求められている。具体的には、提供先の国やユーザー、用途が規制対象に該当しないかを企業自身が確認あるいは担保する必要があるということである。

海外拠点を多数持つ大企業やグローバルにサービス提供を行う企業においては、この条項への対応に相応のコストと体制整備が必要となる。例えば、特定国からのアクセス制限を設けたり、顧客のエンドユーザーやエンドユースをいわゆる輸出管理上の該非判定や取引審査といった事前審査するプロセスを組み込むことが求められる可能性があるだろう。従来のオープンソースソフトウェアでは利用者自身が法令遵守する責任はあるものの、ライセンス条項としてここまで明文化されることは基本的にはない。NVIDIAライセンス適用モデルを利用する企業は、モデルの提供形態によっては輸出管理上の設計・運用を追加で検討しなければならず、違反すればライセンス違反のリスクを負うことになる。ただし、それは同時に法令違反のリスクも生じているので、ライセンスでも明文化されているという以上の制約でしかないと考えることもできる。

ライセンス内容の一方的更新および米国法準拠:

NVIDIAライセンスではNVIDIAが「法規制遵守のため」であればライセンス条項を一方的に変更できる旨が規定されており、利用者は変更後のライセンスに従うかモデルの使用あるいは頒布を中止するかをその都度に選択せねばならない。

大企業が自社プロダクトに組み込んで長期運用することを考えると、ライセンス条件が将来改訂される不確実性は無視できないリスクであるだろう。改訂内容によっては追加の制限や義務が課され、従来の利用形態が認められなくなる可能性もある。また、準拠法は米国デラウェア州法とされ、紛争解決はカリフォルニア州サンタクララ郡の裁判所専属管轄と定められている。日本企業を含む非米国企業にとって、何らかの紛争が発生した際に米国の法律に基づき米国の法廷で争わねばならないのは大きな負担であり、管轄受諾により将来の訴訟リスクも背負うことになる。企業規模が大きいほど係争に発展するリスクやコストも大きくなり得るため、これは経営判断上看過できない要素である。

グループ企業全体への広範な適用:

NVIDIAライセンスの定義上、「Legal Entity」(法的実体)には契約当事者本人のみならず、支配関係下にある全ての関連企業(親会社・子会社・グループ会社)が含まれる。そのため、例えば大企業グループの一社が本モデルを利用すると、グループ全体で統一してライセンス条項を遵守する必要が生じる可能性がある。仮にグループ内のある特定の事業部門や子会社がNVIDIAライセンス条件に反する利用をしてしまうと、同一「Legal Entity」とみなされる他の関連会社も含めライセンス違反の問題が波及しかねない構造である。大企業では事業部や子会社ごとに利用実態を把握あるいは統制をすることは難しく、だからといって運用が徹底されなければ思わぬところから違反が発覚するリスクが高まることになる。結果として、グループ全社レベルでモデル利用の可否やポリシーを調整し、一元管理する体制が必要となる点に注意が必要である。これはオープンソース利用におけるOSPOの設立動機と似ているが、AIモデルの利用はそれよりも深刻かつ喫緊の課題であるだろう。

再頒布時の表示義務の重さ:

NVIDIAライセンス第3条は、モデルや派生モデルを頒布・提供する際の義務も定めているが、その中で特に注目すべきはNVIDIAへのクレジット表示義務である。ライセンスのコピー添付やNoticeファイルでの所定の表示(「NVIDIA Open Model Licenseの下でライセンスされています」等)に加え、対象がNVIDIA Cosmosモデルである場合には製品やサービスのWebサイト、UI、ドキュメント等に「Built on NVIDIA Cosmos」の文言を表示することが求められている。

一般的なオープンソースライセンスでも著作権表示等の義務はあるが、NVIDIAライセンスのようにユーザー向けUIやWeb上への明示的な出自表示まで要求するケースは多くない。このため企業プロダクトに組み込む際には、表示場所とその方法を含めてライセンス遵守のための追加作業が発生すると考えられる。しかし、これ自体は上記の他リスクと比べれば対処可能であり、社内のコンプライアンス部門や法務部がガイドラインを作成し遵守すれば解決できる問題である。ただし、仮に表示を失念すると契約違反となり得るため、他の条項と合わせて見落としなく対応すべきである。

まとめ

本稿ではNVIDIAライセンスのオープンソース性と企業におけるリスクをまとめたが、そもそもNVIDIAライセンス第4条においてオープンソース等のライセンスとの共存の場合の優先関係を妥当な形で定めていることから、NVIDIA自身はNVIDIAライセンスとオープンソースの関係を理解していると考えられる。また、NVIDIA自身もモデルをオープンソースとは少なくとも公式発表等においては称しておらず、オープンソースと喧伝するメディアとSNS上で活動する驚き屋と称される者らの責任である可能性が高いだろう。とは言え、NVIDIAライセンスは自由な利用ができるように見えつつも、特に企業にとっては本稿で解説したリスクに対処するための追加措置の負担は大きく、それはオープンソースライセンスを適用するモデルとの利用とは雲泥の差となり得る。この点を認識した上で、正しいAIモデルの利用における仕組みを企業内に構築することになるのだろう。

参考

生成AIツールを利用して開発されたソースコードにはどこから著作権が発生するのか?

GitHub Copilotが登場した頃、多くの開発者はコーディングの補助ツールと捉えていた。「役に立つのは分かるが、コーディングの全てを任せるようなツールではない」というのが多くの開発者の素直な感想だっただろう。しかし、この2025年においては、「バイブコーディング」という用語が急激に一般化し、多くの開発者が様々なAIコーディングツールを併用して、より多くの作業をAIツールに頼るようになっている。コーディングのみならず、開発プロセスにおけるほとんどの工程をAIを頼る傾向は今後さらに高まることは間違いないだろう。

ここで多くの開発者が気にするのは開発(生成)されたコードの著作権であろう。ソースコードの権利を制御するのは基本的に著作権だと考えられているが、「AI生成によるコードには著作権が発生しない」という話を耳にした開発者も多いと思う。そうであれば、「自分がAIツールに作成を指示したコードには著作権が全く発生しないのではないか?」と疑問を持つのが一般的な感覚であろう。一方で「AI生成物の権利は全て指示者にある」という感覚を持つ者もおり、この両極端な捉え方が特にネット上において諍いの種の一つにもなっているようにも見える。

そこで本稿では、プログラム著作物に特化して、AIツールを利用して開発を行ったソースコードがどのような場合に著作物性(著作権保護に値する創作性)が発生するのかという疑問に対して、日本法ならびに米国法の両面から詳細に解説する。さらに、実際のソフトウェア開発の現場(クローズドな商用開発)やオープンソース開発の実務において、開発者がどのように対処すべきかについても簡単に触れることにする。

  1. 日本法におけるAI生成コードの著作物性
    1. AI生成物の著作物性
    2. プログラム著作物特有の事情
    3. ケース別の著作物性有無の境界線
      1. 明らかに著作物性が認められないと考えられるケース
      2. 著作物性が認められる可能性がある境界的なケース
  2. 米国法におけるAI生成コードの著作物性
    1. AI生成物の著作物性
    2. プログラム著作物特有の事情
    3. ケース別の著作物性の有無の境界線
  3. クローズドな商業的ソフトウェア開発における実務
  4. オープンソース開発における注意点
  5. 余談
  6. 参考

日本法におけるAI生成コードの著作物性

まず、日本法においてAIツールを利用してコードを生成した場合、そのコードに著作物性が認められるのはどのような場合であるか、基本的な考え方を整理する。

AI生成物の著作物性

日本の著作権法上、著作物とは「思想又は感情を創作的に表現したもの」(著作権法2条1項1号)をいう。この定義に照らせば、AIが生成したコードであっても人間による創作的表現が認められる場合には著作物となり得る。しかし反対に、人間の関与なしに自律的に生成されたコードには著作物性が認められない可能性が高い。文化庁のガイドラインとなる「AIと著作権に関する考え方」(令和6年3月公表)でも、生成AIに対する人間の指示が表現に至らないアイデア止まりであるような場合には、当該AI生成物に著作物性は認められないと整理されている。例えば、「◯◯な機能を実装せよ」といった抽象的な指示だけでは、生成されたコードに著作権は発生しないと考えられる。

もっとも、日本においてはAIを創作のための道具として用い、人間が創作へ関与した部分については著作物性を個々のケースにおいて判断することになるというのが文化庁の「考え方」による立場であろう。AI生成物の著作物性は個別かつ具体的に判断することになり、単なる作業量のようなものではなく、生成指示者に「何かを表現しよう」という主体的な創作意図が存在するかという点を前提として、人間がAIに対して単なるアイデアの提示に留まらない具体的な表現に至るまでの工夫としての創作的寄与が積み重ねられているかで総合的に判断されると考えられる。

ここで重要なのは特にネット上で流布される「道具として用いる」をクリアすればAI出力に著作物性が認められるという単純な話ではなく、最終的な結果物に対して人間の創作的寄与が含まれているのであればAIを道具として用いているとみなせるということである。繰り返すが、肝心なのは結果物に対して人間による創作性が生じているかどうかである。

AIを利用して作成された作品が著作物と言えるかどうかは、文化庁の「考え方」で示されている内容に若干の私見を加えていくと、以下のように人間による「創作的寄与」の有無を総合的に考慮して判断することになると考えられる。

  • A. 指示(プロンプト等)の具体性:
    • ユーザーがAIに対して出す指示内容が、作品の表現内容に踏み込んで具体的であればあるほど人間の創作的寄与があったと評価されやすくなるが、その反対に、どれだけ長い指示を書いても表現に至らない抽象的アイデアの提示に留まるような内容では、創作的寄与とは認められない。例えば「面白いものを作って」といった漠然とした依頼や、機能的な要件を箇条書きしただけのプロンプトでは人間の具体的な表現による寄与があったとは言えないと考えられる。
  • B. 生成過程での試行錯誤(フィードバックと修正):
    • AIに何度も生成を繰り返させた回数そのものは、創作的寄与の有無に直接影響しない。しかしながら、出力結果を都度確認し、それに応じて指示内容を修正しつつ再生成を繰り返すといったプロセスを経ている場合には注意が必要となる。このような試行錯誤のプロセスにおいて、ユーザーの創作上の判断や工夫が反映されている可能性が考えられ、結果として得られたAI生成物に対して人間の著作物性が認められる可能性がある。
  • C. 複数生成結果からの選択:
    • AIが一度に多数のバリエーションを出力し、その中から指示者が単に選択していくだけでは、その選択結果には創作的寄与とは言えない。これは、選択行為そのものは機械的な判断に留まりがちであり、創作的表現の産物とはみなされにくいからである。しかし、選択が関わる場面で編集・構成など他の創作行為と結び付いている場合には考慮の余地が生じると考えられる。指示者が何らかの意図をもって選択し、それらの組み合わせによって一つの作品となるような場合に人間の創作的寄与の要素の一つになり得ると考えられる。
  • D. 人間による加筆・修正:
    • AIの出力に対して人間が創作的表現と言える修正や加筆を行った部分については、通常その部分に対しては人間の著作物性が認められる。AI出力そのものが人間の創作性を欠くとしても、人間による修正部分の著作物性が失われるわけではなく、修正後の結果物には総体として人間の著作権が含まれる。ただし、この場合は保護され得るのは人間が創作した部分に限られる。

以上の文化庁の「考え方」から援用したポイントを踏まえると、著作物と認められるか否かの事実上の条件は「人間の創作的寄与」があったかどうかに尽きる。人の関与がない純粋な自律生成部分については現時点の議論において著作物性が否定される可能性が高く、やはり人間による独自の創作的な表現がAI生成物へ反映された場合に著作物性が生じることになる。総じて、日本法におけるAI生成コードの著作物性は一律に判断されるものではなく、ケースバイケースで上記のような要素の積み重ねを精査した上で、人間による創作性が発揮されているかどうかで判断されるのが基本的な考え方と言えるだろう。

プログラム著作物特有の事情

次に、ソースコード(プログラム)特有の著作物性判断の事情を確認する。日本の著作権法では、著作物を「思想又は感情を創作的に表現したもの」と定義しているが、プログラム著作物においてもこの要件を満たす場合に著作物として保護対象となるのは同一である。他方で、プログラムのアイデアと表現の区別が条文上で明確に規定されており、著作権法10条3項ではプログラム言語(プログラムを記述する記号や体系)、規約(記法上の取り決め)及び解法(アルゴリズム)については「その著作物を作成するために用いるもの」に過ぎず、著作権保護の対象には及ばないと規定されている。つまり、プログラムにおいて創作的な「表現」と認められる部分のみが著作権で保護され、処理手順、アルゴリズム、入出力仕様、フレームワークの設計思想などは、たとえ創意工夫があったとしてもアイデア・表現二分論によりそのままでは著作権保護の対象にはならない。

この点に関し、ソフトウェアの創作性が争点となったシステムサイエンス事件(東京高裁平成元年6月20日決定)は重要なリーディングケースとなっている。同事件で東京高裁は、プログラムはそれを表現する記号が極めて限定され文法も厳格であるため、コンピュータをより効率的に機能させようとすれば指令の組合せが必然的に類似してしまう部分が少なくない、と指摘した。従って、プログラム著作物における著作権侵害の判断は慎重になされるべきであるとも判示されている。この趣旨は、プログラムの表現は本質的に制約が多く、「効率性・互換性の要請など外部要因によりほぼ一通りに定まる」ありふれた表現や「必要不可欠な表現」の類似は直ちに著作権侵害につながるものではないことを示したものといえる。

その後の裁判例では、プログラムの創作性についてさらに踏み込んだ基準が示されている。とりわけ電車線設計用プログラム事件(東京地裁平成15年1月31日判決)は、プログラムの具体的記述が創作的表現といえるかどうかを判断するにあたり、次のようなコードは作成者の個性が発揮されておらず創作性が認められないと判断した:

  • 誰が作成してもほぼ同一になるようなプログラムの記述
  • 簡単な内容を極めて短い表記法で記述したプログラムの記述
  • 極めてありふれた定型的なプログラムの記述

本事件では、定型的若しくは平凡なコードまで著作物として保護してしまうと、電子計算機の広範な利用や技術の発展を不当に妨げ、結果的にプログラムの機能やアイデアそのものを独占的に保護することになりかねないとも指摘している。要するに、プログラムのソースコードであっても、ありふれた手法の寄せ集めに過ぎない部分には独自性がなく、著作物たりえないという整理である。

さらに、宇宙開発事業団プログラム事件(知財高裁平成18年12月26日判決)もこの考え方を明確にしている。本件判決は、法が保護するのはあくまで「表現したもの」であり、思想およびアイデア自体や表現に至る手法は保護されないとの原則を確認した上で、プログラムについて表現上の選択肢が十分にあり、それが凡庸でなく作成者の個性が表れていることが著作物性の要件であると判示している。そして、表現に選択の余地がないか著しく限られる場合には作者の個性が表れる余地もなくなり著作物性が否定されるとも述べている。また、プログラムの指令手順自体も単なるアイデアに過ぎず、それを実現するアルゴリズムも「解法」として著作権の保護対象外であることを改めて明言している。これらの裁判例の積み重ねにより、プログラムにおける表現の保護範囲は絵画、音楽、映像といった他の伝統的著作物に比べて相当に限定的であることが司法上も確認されてきていると言えるだろう。

実務的に見ても、プログラム開発の現場では創作性が発揮される余地が限られる場合が多い。効率や機能実現のためにコードの書き方が定型化しやすく、結果として同種のプログラムでは似たような記述が生じるのは避け難い。実際、著作権法が保護し得るプログラム上の表現の範囲は一般に考えられている以上に狭いものとなっているのが実情だろう。

以上のようなプログラム著作物特有の事情を踏まえると、生成AIツールを利用して開発されたソースコードにおいてどのようにすれば著作権が発生し得るのかという観点においては、創作性の判断基準を慎重に適用する必要があるだろう。

なお、生成AI以降における自動的なツールに出力コードの著作物性の問題に注目が集まってきたのは、そもそも生成AI以前のコード補完やコード自動生成ツールは創作性が非常に薄く著作物性がないと考えられるコードを出力し、人間が残りの創作性を発揮しやすい領域を担当していたからである。生成AIツールはコーディングにおいて人間が創作性を発揮してきた領域を自動化してきており、著作権を意識する場合には人間の創作性がどこにあるのかを認識せざるを得なくなっていると言える。

ケース別の著作物性有無の境界線

これまでに述べた制約を前提として、どういった場合にAI生成コードに著作物性が認められ、どういった場合に認められないかを具体的なケースに即して考えていく。

明らかに著作物性が認められないと考えられるケース

既にデフォルトの状態でAI出力には著作物性は生じないと書いているが、中でもほぼ著作物性がないと判断できるようなケースは下記のプログラム著作物特有のケースとAI生成出力に特有のケースの二つになるだろう。

  • ごく短い定型コードの自動生成:
    例えば「Hello Worldを表示するコードを書いて」とプロンプトを入れてAIが出力した数行のコードなど、誰が書いても同じになるようなごく短いコード断片は創作性がなく、著作物ではないと判断されるだろう。これは人間の創作的寄与への関与云々以前に表現上の独自性がない典型例となる。
  • 抽象的な指示による標準的実装の生成:
    「ソート関数を書いて」「ボタン押下時に現在時刻を表示して」等のアイデアレベルの指示だけをAIに与え、AIが一般的な実装コードを出力した場合、人間が出力の内容の具体的表現には寄与しておらず、また出力されたコードもありふれた標準実装に過ぎないため、著作物性は生じない。

著作物性が認められる可能性がある境界的なケース

前述の状態を踏まえて、文化庁の「考え方」に合わせ、具体的にどのような人間による行為が行われているのであれば著作物性が生じるかという境界線を探ると以下のようになると考えられる。

A. 指示・設計が具体的な「表現」に踏み込む場合:

人間によるAIへのプロンプトや指示の段階で、単なる機能要求に留まらず具体的なコード上の表現まで踏み込んだ指示を行った場合である。

例えば「○○アルゴリズムのこの部分をこういう手法で実装せよ」と細部にわたり指定したり、関数名や変数名、あるいはコメント文に至るまでクリエイティブなアイデアを盛り込んだプロンプトを作成した場合が該当する。文化庁の「考え方」においても、創作的表現と言えるものを具体的に示す詳細な指示は創作的寄与があると評価される可能性を高めるとされている。このような場合、出力されたコードの中にプロンプト作成者である人間の創作的な表現である指示内容が反映されている部分があれば、その部分について著作物性が認められると考えられる。判断にあたっては、平易ではない独自の実装やユニークなコメント表現などの指示者の個性が完成したコード中に表れている箇所があるかを着目することになる。

プロンプトによる指示が「表現」としてソースコード中に痕跡として残ることがポイントと言えるが、著作物性が認められる安全度は概ね次のような順になるのではないかと考える。

  • 指示テキストが出力と同一 (高):
    • 関数名や識別子の体系、コメント文、メッセージ文言、ヘッダ書式等を具体的な文言で指示し、そのままAI出力に反映された場合、人の記述が可視化され、著作物性が肯定されやすい。
  • 構造や配列を具体的に指定 (中):
    • モジュール分割、クラス/関数の順序、例外の配置、処理の組み合わせ、設定ファイル/ディレクトリの構成等の指定が出力へほぼ追随される場合、構成として表現が定着したとみなしやすい。この場合、典型的な解から外れるほど可能性が高まる。
  • 設計意図のみの指定 (低):
    • 「高速」「RESTらしく」等の抽象的要件に指示が留まる場合、実装が定石に収斂しやすく、典型的な解に近い出力となると考えられる。出力がありふれたコードに落ち着けば、アイデアに近いものとして著作物性は弱まる。

要するに、指示において具体的な文言や配置を指定し、AIの出力にそれらが人間の目で分かるような状況であれば著作物性が生じるわけである。

B. 試行錯誤とリファクタリングが「構成上の選択」に結実した場合:

AIによるコード生成を一度で終わらせず、何度もプロンプトを試行錯誤し出力を取捨選択あるいは修正しながら最適なコードに仕上げていった場合である。

一度目の出力を見てプロンプトを変え、二度目を出力させ、それらを部分的に組み合わせたり不要な箇所を削除したりする反復作業の過程が、人間の開発者による構成上の創意工夫が最終コードに反映されたと評価できる場合には、そのコード全体もしくは特定の組み合わせ方に著作物性が認められる可能性が生じる。また、最終的なコードだけを見ると凡庸に見えても、実は人間が複数の候補から取捨選択し構成したものであればそこには編集著作物的な創作性が生じ得る。ただしこの場合、自身の創作的関与を後から説明もしくは立証できるように、プロンプトの履歴や出力結果の差分などを記録しておくことが実務上望ましいと考えられる。そうしたログがない場合、第三者から「人間が何も創作していないのではないか?」と疑われたときに反証が難しくなるためである。

ただし、結局のところ試行回数の多寡はノイズに過ぎず、構造的な変化と人の判断の関係性をログやコメント等で可視化できないと、著作物性が否定寄りに評価されがちになるのではないかと考える。

C. 選択・配列・体系化が「通常解」を超えるとき:

生成AIが大量のコードを吐き出し、それらの中から人間が取捨選択して組み合わせた結果、一般的に想定される実装を超える独創的な構成になった場合である。

単に複数の生成結果から一つのコードを「選ぶ」だけでは創作的寄与とは言えないと考えられているが、例えば、各生成結果から一部ずつを取り出してモジュール化し、全体を独自の構成に再構築したような場合には完成したコード全体として編集著作物(素材の選択・配列に創作性がある著作物)たり得るかもしれない。この場合の判断のポイントは、そのコードの構成もしくは体系が他の開発者であれば一般にはしないような非自明的な組み合わせになっているかどうかであるだろう。オープンソースの既存コードを寄せ集めた場合に近いが、AI生成コードの場合も人間がどのように素材としてのコード断片を取捨選択・配置したかによって創作性の有無が決まると考えられる。フレームワークの既定テンプレに沿ってそのまま並べた、あるいはフレームワークによって事実上決定されてしまうような場合には、やはり著作物性は低いと考えられる。

また、このCの形式が開発現場で最も起こり得るパターンであると考えられるが、編集著作物で保護されるのは「選択・配列・体系化という構成の表現」だけであり、AI出力そのままの断片や一般的な処理ロジック自体には及ばないことに注意が必要となる。

D. 既存コードへの加筆・修正で「創作的部分」が追加された場合:

既に自分または自社が権利を有する既存のコードやオープンソースなどの第三者権利のコードに対して、AIツールを利用しつつ新たなコードを付け加えたり書き直したりした場合である。

例えば、既存プロジェクトに新機能を実装する際においてAIツールに補助させてコードを書き足したようなケースでは、追加もしくは変更部分に人間の創作性が存在すればその部分について著作権が発生する。AIの提案をそのままコピペしただけでは創作的寄与はほぼないと考えられるが、AIに提案コードをベースに手作業でリファクタしたり自分のコードと統合したりすれば、人間の創作性が付加されると考えられる。このような場合、変更差分の中に人間の独自性のあるコードがあるかが判断のポイントとなる。著作物性が生じる改変の典型としては、処理の入替や再編、機能の追加、コメント/ログ/メッセージ等の文言の独自の創作的記述、識別子体系の再編等であると考えられるが、無改変のコード採用(コードを見ただけ)、変数やライブラリの改名といった軽微な改変には逆に著作物性が生じないと考えられる。

なお、元の既存コード部分は元から著作物であれば引き続き保護されるし、そうでなければ保護外である。AIの利用によって既存部分の法的性質が変わることはない。

以上のように、総じて日本法では人間が創作的関与をした部分に着目して著作物性の有無を判断することになる。「AIが書いたからすべて著作物性がない」あるいは「人間が指示したからすべて人間の権利」といった極端な判断ではなく、最終的な結果物におけるどの部分が誰による創作によるものかを細かく見極めていくアプローチになる点に注意が必要である。


米国法におけるAI生成コードの著作物性

ここまでは日本法における考え方を整理してきたが、ここで米国法の下でAI生成コードの著作物性がどのように考えられているかを整理する。ソフトウェア分野においては特にオープンソース開発をはじめ米国法の影響が非常に大きいため、米国での著作物性の扱いを理解することは実務上も重要である。

AI生成物の著作物性

米国著作権法においては、基本的に人間が創作したもののみを保護するという立場を明確に打ち出している。AIが自律生成した画像の著作権登録を巡る訴訟として近年話題となったThaler v. Perlmutterでも、D.C.巡回区控訴裁判所は一貫して「人間の著作物性は著作権の根幹を成す要件である」と判示し、純粋にAIだけで作られた作品には著作権を認めないとの結論を下している。この点は、日本法では明文化されていないものの実質的には同様に考えられている部分ではあるが、米国では判例と条文解釈の運用上により明確に人間の著作者性が要求されると言えるだろう。

また、米国著作権局は2023年3月にAI生成物を含む作品の著作権登録ガイダンスを公表し、AIツールを用いて作成された作品を著作権登録申請する際には人間が創作した部分とAIが生成した部分を明確に区別し申告するよう求めている。そのガイダンスでは、著作権は人間が創作したオリジナルな表現部分のみを保護し、純粋にAIが生成した部分には及ばないとはっきり示され、また、単にテキストのプロンプトをAIに与えただけでは生成物に対する「十分な創作的制御」を人間が及ぼしたとは言えないとも述べられている。つまり、プロンプトを入力しただけの出力コードには原則として著作権保護は及ばないと判断できる。なお、著作権局のガイダンスはあくまで「著作権登録実務における判断基準」であって、裁判所を形式的に拘束するものではないが、Thaler訴訟等に見られるように、現時点では裁判所もほぼ同じ方向を採用しているので、現在の実務上は「事実上の標準」として扱い得るだろう。

もっとも米国法においても、人間が創作に関与した部分については引き続き権利保護されることには変わりはない。米国著作権局のガイダンスによれば、人間が作成した文章やコード断片を組み込んだケースなど、AI生成物の中に人間の著作物が知覚できる形で表れている場合や人間が生成物を創造的に選択・配列・編集した場合、あるいは生成物を創作的に改変した場合には、その人間が行った創作部分について著作権を認めるとされている。実際、米国著作権局は、AI生成物を土台に人間が修正を加えた画像などの人間がAIを補助的なツールとして用いて作成した作品の著作権登録を個別に認め始めており、「人間が最終的な創作的判断を下した部分」が存在するかどうかが重要視されている。つまり、米国法下でも人間が創作的寄与をした範囲に限って保護する枠組みであることに違いはないが、その線引きをより明示的に「ケースバイケースで判断する」という立場であると言えるだろう。

プログラム著作物特有の事情

米国におけるソースコードに関しての著作権の考え方は、基本的に日本法と共通する部分が多い。すなわち、コード中のアイデアや処理手順、機能そのものは保護されず、具体的な表現のみが保護対象となる。米国連邦著作権法(17 U.S.C.)の§102(b)において、「著作物の保護はいかなる場合も、アイデア、手続、過程、システム、運用方法、概念、原理または発見そのものには及ばない」と明文的に規定しており、プログラム中の機能的要素は著作権で保護しないことが法律条文的に明らかにされている。

さらに、Computer Associates v. Altai(第2巡回区控訴裁判所)において有名な抽象化・濾過・比較テスト(AFCテスト)が示され、プログラムの非文字的要素(構造やUIなど)が著作権保護されるかを判断する枠組みが確立した。このテストは、まずプログラムを抽象度の高い構造まで分解し、次にその中から効率上の必要に迫られた要素、外部仕様から要求される要素、パブリックドメイン領域から取得された要素を順次取り除き、そうして最後に残った部分が創作的表現として保護され得る部分であり、その部分について他の作品との実質的類似性を比較検討するという手法である。要するに、機能的あるいは規範的な要素をフィルタリングして純粋な表現部分を抽出するという考え方であり、表現とアイデアの切り分けを厳密に行う点が特徴である。米国法はこの点について日本法よりも制度的および判例上明文化されている分、判断手法が洗練されているとも言える。

ケース別の著作物性の有無の境界線

前項までの米国法の考え方を踏まえ、日本法において整理したケースA、B、C、Dを米国法で考えるとどうなるか、相違点を中心に確認していく。

  • プロンプトのみで生成されたケース(日本のケースA該当):

人間が具体的表現に踏み込んだ指示を行ったかどうかが問題となる点は日米共通ではある。しかし、米国では例え詳細なプロンプトを作成したとしても「プロンプト自体は通常、生成物に対する十分な制御とはみなされない」との立場が明確であり、人間による創作的表現が実際の出力コード上に現れていない限り人間の著作物とは認められない可能性が高い。このため、単にAIツールにコードを書かせただけの場合、日本法以上に著作権保護が否定されやすい点に注意が必要であり、実際、著作権局はプロンプトによる出力物のみの登録申請を軒並み拒絶している。

他方で、人間が提示した具体的コード片や擬似コードがそのまま出力に組み込まれているような場合は、その部分は人間の著作物として保護され得る。

  • 複数回の生成と取捨選択・編集を経たケース(日本のケースBおよびC該当):

人間がAI出力を選別・編集・構成した場合、それによって生じた創作性は米国法でも評価される。米国著作権法は、「編集著作物」として素材の選択や配列に創作性があれば著作物となることを認めているため、AIが生成した複数のコード断片を人間が創造的に取捨選択し配置したようなケースでは、その配置や組み合わせ自体に著作権が発生し得る。

日本法のケースBに相当する試行錯誤による改良も、最終的な結果として人間がコードの表現上の構成を決定したのであれば、著作者は人間だと言える。日米の違いとしては、米国ではその人間の寄与部分を明確に切り出して保護する意識が強い点であろう。つまり、完成したコード全体ではなく、並べ替えという行為や編集結果が創作性を持つと分析する形になる。総じて、主張立証のハードルは日本より高いと考えられるが、出力における人間の創作的工夫が具体的に何かを特定しやすい分、保護の結論自体は日本法と大きく変わらない。

  • 既存コードへの加筆修正(日本のケースD該当):

人間の著作者が既存コードにAI支援を受けて新たな表現を付け加えた場合、その付加もしくは改変部分に人間の創作性があれば米国法でも保護される点は同じである。米国法では人間が他人の著作物を元に改変を加えたものは二次的著作物として保護されるが、AIが出力したコードも広義には「他者が作った素材」と言えなくもない。しかし、前述の通りAIの出力部分自体には保護が及ばないため、人間が実際に書いて創作性が生じた部分のみが新たな創作部分として扱われることになる。例えば、AIが生成したコードに開発者が肉付けしてユニークな挙動を実装したのであれば、そのユニークな部分が人間の著作物となる。つまり、これに関しては日本法とほぼ同様であり、人間による創作的改変を加えたか否かがカギとなる。

以上のように、米国法も「人間が創作したか否か」という軸でAI生成コードの著作物性を判断しており、大枠では日本法と共通すると考えられる。ただし、米国では著作権局のガイドラインや裁判の判例を通じてそのスタンスがより明確化されているため、プロンプトだけではダメだとか編集すればOKといった線引きを公式に確認できる点で実務上の予見性が高いと言える。一方、日本では文化庁のガイドラインはあるものの判例の蓄積がなく、グレーに感じる部分も残されている。いずれにせよ、日米ともケースバイケースの個別判断をせざるを得ない状況には変わりなく、今後の具体的な事例の集積が待たれるところである。


クローズドな商業的ソフトウェア開発における実務

AIコーディングツールの活用が劇的な速度で進む中、企業内のクローズドなソフトウェア開発の実務では著作権管理をどう考えるべきだろうか?

まず、大前提として、企業内で大規模な体制でクローズドに開発されるようなソフトウェアにおいては、従来からプログラム著作物の権利の保護範囲は限定的であったということである。前述の通り、コードの中にはアイデアや機能に過ぎない部分、あるいは誰が書いても同じような表現部分といった権利保護されない部分が多分に含まれる。したがって、AIの有無に関わらずソフトウェア全体の中で著作権侵害を主張できるような「創作的表現と呼べる島」は部分的であるケースが多い。大海に浮かぶ島々の部分だけが著作権が認められるということであるわけだが、AI生成ツールの現場への導入によって、この権利保護が生じる島が部分的になる傾向は更に強まる可能性が高いだろう。というのも、現状のAIは大量の既存コードを学習し、定型的若しくは汎用的なコードを出力することが多いと考えられるため、開発者が人力でイチから書いた場合に比べて独自性の低いコードが増えると考えられるからである。例えば、システムにおいて典型的なCRUD処理やAPI呼び出しコードなどは、AIに書かせれば大同小異なコードが生成されるだろう。このような部分はそもそも創作性が乏しく著作権で保護されにくいため、AI利用によって著作権で保護される範囲が相対的に減少することにもなる。

もっとも、商業ソフトウェア開発におけるソースコードにおいて、全く創作的な表現がなくなるわけではない。要求仕様が複雑化すればコード全体の構造や特定のアルゴリズム部分で開発者の創意工夫が現れる場面は依然として存在するし、AIの定型的な提案を鵜呑みにせず人間が調整あるいは工夫を凝らした部分は創作性が認められるだろう。そうした大海の中に浮かぶ著作権が発生する島々を繋なぎ合わせるアプローチが重要であり、そのため、著作権を意識したビジネスを行うのであれば、企業としてはプロジェクト内でどの部分が創作的表現かを意識しつつ管理する必要があるだろう。具体的には、AIツールによる生成箇所についてはその旨をコメント等で記録したり、生成時のプロンプト・出力ログを保存しておき、万が一、後に著作権紛争になった場合に備えて、「この部分は人間が創作した」「この部分は創作性がない(誰の著作物でもない)」と説明できるようにしておくのが望ましい。

加えて、このAIによる変革により、今後は著作権よりも契約および秘密管理の重要性が一層高まると考えられる。著作権だけでは保護が薄くなり、帰属が不明確なコード断片についても、契約上の取り決めによってその利用を制御したいのであれば、やはり契約手法が最も重要になるだろう。企業が自社内で開発したソースコードであれば、そのコードに実質的な独自性がなく著作物として認められにくい場合であっても、秘密保持契約(NDA)によって第三者への開示や利用を制限したり、自社サービスの利用規約でコードの転載や複製を禁止するといった対応が可能になる。また、開発委託契約や雇用契約の中で、成果物にAI生成部分が含まれる可能性を踏まえた著作権の帰属や利用許諾の範囲といった権利処理を明記する動きも出てくるだろう。ソフトウェア製品としてリリースする場合には、商標や不正競争観点による保護も相まって、仮にコード自体の著作権保護が弱くても模倣品の排除は一定程度可能である。総じて、著作権単体では薄くなった権利の保護層を、契約+営業秘密保護+商標等といった他の法的枠組みを動員して補完する方向にシフトせざるを得ないのが今後の実務と考えられる。


オープンソース開発における注意点

最後に、オープンソース開発にAI生成のコードを取り入れる場合の注意点を述べる。基本的に、第三者の権利を侵害していない限りAIツールが出力したコードを自由に利用すること自体は法的に問題ない。何故なら、AI生成コードにはそもそも著作権が発生しない可能性が高く、言わば誰の権利にも属さないパブリックドメイン的なコードとして扱い得るからである。したがって、既存のオープンソースプロジェクトに対してAI生成コードをもって貢献したとしても、その貢献コード単体では誰かの権利を侵害することにもならない可能性が高い。

しかし、実務上はそれで済むほど単純ではない。第一に懸念されるのは貢献時の「著作者」表明との矛盾である。多くのオープンソースプロジェクトでは、開発者がコードを貢献する際にDCO(Developer Certificate of Origin:開発者証明)やCLA(Contributor License Agreement:貢献者ライセンス契約)への署名が求められ、自分自身が貢献コードを作成し、そのコードを適切に権利処理済みであることを証明する宣言を行う。しかし、仮にコードが純粋なAI生成物であり人間の創作性が皆無だとすると、「自分が作成した」と言えるのかという問題が生じる。法的に著作物でないものを「自分の作品だ」と主張するのは厳密には誤りであり、そこに法的な不確実性が生じることになるのである。まさにこの点について、QEMUプロジェクトではAI生成コードによる貢献を一律に拒否する方針を打ち出している。QEMUプロジェクトの見解では、AI生成コードは各国法で著作物と認められない可能性が高く、自分が著作者であることを求めるDCOの要件を満たせないため受け入れないということである。Linuxカーネルのように割と多くのプロジェクトはAI生成コードとの共存を目指しているものの、QEMU以外のプロジェクトでも同様の方針を採る例が増えるとも予想され、しばらくはオープンソースプロジェクトにおけるAI利用のポリシーに混乱が続くと思われる。

このような法的な矛盾以前の問題として、多くの貢献者によるコードの集合体であるオープンソースのプロジェクトにおいては、貢献コードの一つ一つに著作権が生じているかどうかという観点は些細な問題であり、個々の貢献コードの責任が誰にあるのか?という観点の方が問題となり得る。AI生成コードに誰の著作権も生じないのであれば、最終的な責任者が誰であるか分からないコードが増えることにつながり、その観点での影響はまだ未知の領域であると言えるだろう。

また、第二に注意すべき点としてライセンス適合性の問題もあるだろう。AIが学習に使ったオープンソースのコードの一部をそのまま出力してしまうケースは完全に否定できるものでもなく、万が一、GNU GPL等の強いコピーレフト性のあるライセンスのコード断片がAI出力に含まれていた場合、それを知らずに他のライセンスのプロジェクトに混入させてしまうことでライセンスの矛盾を引き起こす可能性があるだろう。もっとも近年はGitHub Copilotに代表されるように、出力コードを既存コードと照合して酷似箇所を検出する仕組みがAIツール側に導入されつつあり、このリスクは低減しつつある。しかし、それでも「このコードは他人の著作物に由来しないコードである」と人間が保証することは非常に困難であるのが現状であり、であればオープンソースプロジェクト側としてはAIによる貢献には慎重にならざるを得ないだろう。

では、オープンソースコミュニティとしてAI生成コードを活用していくにはどうすれば良いのだろうか?

現実的なアプローチとしては、人間が一定の創意工夫を施してから貢献することが挙げられる。すなわち、AIが提案したコードをそのままコピペするのではなく、きちんと自分自身で内容を理解および検証を行い、必要に応じてリファクタリングやコメント追加を行った上で自分の責任によるコードとして投稿するということである。こうすれば、法律上も実態上も「自分が作成したコードだ」と胸を張って言えるし、DCOとの矛盾も生じにくいだろう。

また、プロジェクトによっては貢献時に「AIツールを使用したかどうか」を申告させるところも出てきているが、そのようなプロジェクトのポリシーに沿った透明性の確保も重要である。例えばLinuxカーネルのコミュニティはAI利用に関する行動規範を示しつつあるが、基本的にはAIツールの使用を詳細に明示していく流れが強まるのだろう。オープンソースプロジェクトのメンテナーは、自分たちのプロジェクトにおいてAI生成コードを受け入れるか否か、あるいは「AI起源のコードであることをコメントで明示する」「生成物の出所証明を添付する」等の利用条件を早めに議論し、プロジェクトの方針を定めておく必要があるだろう。

以上、オープンソース分野での注意点を述べたが、ここには本稿では書ききれていない実務上の課題も数多く存在するため、オープンソースの開発コミュニティにおけるAIツール利用の是非やプラクティスについては、近いうちにより踏み込んだ解説記事を書くことにしたい。


余談

本稿では、プログラム著作物に特化して、どのような場合にAIツールの出力に著作物性が発生し得るかを日本法と米国法に基づいて検討したが、結局のところ、双方共に人間の創作性がコードに表れているか否かという軸でAI生成コードの著作物性を判断するという方向性で共通していると考えられる。また、日米ともケースバイケースの個別判断をせざるを得ない状況であることも変わりはなく、まだまだ不明瞭な点が多いことは間違いない。また、日米以外の法域に注目すれば、コンピュータ生成作品について50年の保護期間を設けている英国のCDPA第9条といった単純なAI出力にも著作物性を認め得る考え方も存在するわけであり、日米のスタイルが主流になるかは定かではない。AIを巡る情勢は日進月歩であり、本稿での記述が数年先に全く異なるものとなる可能性すらあるだろう。


参考

GPLコードを学習したAIモデルにGPLが伝播するという理論の現在地

2021年にGitHub Copilotが登場した当時、そのモデルの学習データにGitHub上のあらゆる公開されたオープンソースのソースコードが含まれていることが大きな注目を集め、ライセンスに関する議論が活発にされた。ほとんどのライセンスで規定される帰属表示などの条件の問題もあるが、特にGNU GPL(GNU General Public License)のようなコピーレフトライセンスの条件がモデルにも伝播し、モデル全体を同じライセンスで公開する必要があるという言説が多く飛び交った。GPLの伝播性自体は現代の多くのソフトウェアエンジニアが自然に受け入れているものであり、エンジニアの素朴な感覚としては何らかの形でGPLコードが含まれるのであれば当然コピーレフトが適用され、ライセンスが伝播すると考えるのはごく自然な成り行きである。

しかし、この2025年現在において、オープンソースのコードを学習したAIモデルにコードのライセンスが伝播するという言説は当時ほど多く見られない。一部の熱心な自由の信奉者がそのような理論を唱えることはあるが、プログラミングの現場へ圧倒的に普及したAIコーディングのメリットに押し流されているようにも見える。そのような風潮の中で、私自身もそのような理論は最初からなかったようにも錯覚することがある。

では、このようなAIモデルへ学習コードのライセンスが伝播する理論は完全に否定されたのだろうか?

実はそうではない。この問題は今もなお訴訟が継続し、また主要な各国政府の判断も明確にはなっていない未確定の問題なのである。本稿では、この「GPLコードを学習したAIモデルにGPLが伝播する」というライセンス伝播性理論の現在の状況を解説し、そこからモデルの法的位置付けや我々が追求するAI領域での自由とは何か、といった論点にまで繋げたい。

  1. 二つの訴訟における現在地
    1. Doe v. GitHub(Copilot集団訴訟):残り続けるオープンソースライセンス違反クレーム
    2. GEMA v. OpenAI:モデルへの「記憶」を法的複製とみなす理論
    3. 二つの訴訟の現在地から導かれる可能性
    4. 日本法での扱い
  2. ライセンスのモデルへの伝播理論への否定材料
    1. 著作権法レイヤーでの否定材料
    2. GPL条文レイヤーでの否定材料
    3. 技術レイヤーでの否定材料
    4. 実務的・政策的な否定材料
  3. OSIとFSFのスタンス
  4. まとめ
  5. 参考

English translation: https://shujisado.org/2025/11/27/gpl-propagates-to-ai-models-trained-on-gpl-code/


二つの訴訟における現在地

まず、「AIモデルへのGPL伝播理論」とは何か?を整理しておく。これは、AIモデルがGPLコードを学習データとして取り込んだ場合に、そのモデル自体がGPLコードの二次的著作物(派生物)に当たるため、モデルを頒布する際にはGPLにおけるソースコード公開義務等のコピーレフトの条件が適用される、とする考え方である。すなわち、モデルの出力がGPLコードと類似しているか否かという問題ではなく、「モデルそのものがGPLコードを含む派生物であるからモデルにもGPLが及ぶ」という理論である。2021年前後にはこの理論を支持する声が多く聞かれたが、前述の通り現在では議論の主流ではなくなっている。しかし、この理論が完全に否定されたとは言い切れない根拠として、現在進行中の二つの主要な訴訟が挙げられる。それが、米国で提起されたDoe v. GitHub(Copilot集団訴訟, Doe 1 et al v. GitHub, Inc.)とドイツで提起されたGEMA v. OpenAIである。以下、それぞれの訴訟の経緯と現状を説明する。

Doe v. GitHub(Copilot集団訴訟):残り続けるオープンソースライセンス違反クレーム

GitHub Copilotに関連して2022年末に提起されたCopilot集団訴訟では、匿名の開発者らが原告となり、GitHubやMicrosoftおよびOpenAIが公開リポジトリ上のソースコードを無断で学習させ、Copilotを通じて大規模なライセンス違反を招いていると主張した。具体的には、Copilotが学習元となったコードの一部を出力として再現する際に、MITやApache-2.0等で要求される著作者表示やコピーライト表示を一切行っていない点、さらにはGPLのようにコピーレフト的条件を課すライセンスのコードも無差別に学習および出力しており、ライセンス条項を踏みにじっている点を問題視している。原告側はこれをオープンソースライセンスの契約上の違反であると主張し、また著作権法上もDigital Millennium Copyright Act(DMCA)への違反にも該当するとして損害賠償や差止めを求めたのである。

本件はカリフォルニア北部地区連邦地裁にて既に幾つかの判断が下され、原告側の多くの請求が却下されている。却下されたのは主としてDMCA条項違反やプライバシーポリシー違反、不当利得、不法行為など周辺的な請求であるが、一部のDMCA違反と「オープンソースライセンスの違反」(契約不履行)の主張は今も生き残っている。特に後者であるが、原告のコードがGPLやMIT等のライセンスで公開されていたにも関わらず、被告が著作者表示や派生物の同ライセンスでの公開義務を遵守しなかったことが契約上の違反に当たるという主張であり、裁判所は原告が具体的な損害額を示せていないことから金銭賠償請求は認めなかったものの、ライセンス違反行為の差止め請求自体は十分に理由があると判断しているのである。その結果、原告らはCopilotが適切なライセンス表示なく他人のコードを再現する行為の禁止命令を求めて引き続き訴訟を進めることが許容されている。

以上の経緯から明らかなように、Copilot訴訟では「学習データのオープンソースライセンス違反」が依然として法廷で争われており、これこそがモデルへのライセンス伝播理論が完全には否定されていない一因である。この訴訟における原告の主張はモデルそのものをGPLでの公開を直接求めるものではないが、学習および出力の過程でライセンス条件を無視した点を法的に追及するものであり、結果として「学習データのライセンスに従った扱いをしなければモデル提供行為は違法になり得る」ことを示唆している。そして、裁判所は現時点でこの論法を明確に排斥せず、オープンソースのコードの利用にはライセンス上の義務が伴い、それを無視したツールの提供には差止め得る不法行為が成立し得るとの判断も示している。

もっとも、Copilot訴訟の主張は法的には契約(ライセンス)違反やDMCA違反という枠組みであり、「モデルがGPLコードの二次的著作物である」という直接的な著作権論ではない点に注意が必要である。モデル全体をGPLライセンスで開示させる義務まで踏み込んだ判断が示されたわけでもない。実際の判断は「金銭的損害は示されていないが、将来的な差止め請求の余地はある」という保守的なものであり、モデルそのものの公開義務までは言及していない。つまり、現時点では「モデルへのGPL伝播理論」に直接言及した判例はなく、学習元コードのライセンス違反という問題提起が司法の場で生き残っている状況である。

GEMA v. OpenAI:モデルへの「記憶」を法的複製とみなす理論

もう一つの重要な訴訟が、ドイツの音楽著作権管理団体GEMAがOpenAIを訴えたケースである。こちらはAIコード生成ではなくAIモデルによる歌詞の無断学習および出力に関する著作権訴訟であり、直接GPLとは関係ないものの「モデルへのライセンス伝播」に関連する理論的含意が大きい。

2025年11月、ミュンヘン第一地裁はこの訴訟について判決を下し、ChatGPTのモデルが著名なドイツ語歌詞9曲分を記憶および再現していた件につき、モデル内部への「記憶」行為自体が著作権法上の複製行為に該当するとの判断を示した。判決によれば、ChatGPTのGPT-4および4oのモデルには原告管理下の歌詞が「固定」されており、ユーザが簡単なプロンプトを与えるだけでその歌詞がほぼ原文どおり出力される状態であった。それをもって裁判所は、モデルが「著作物を記憶したパラメータ」を内部に含んでおり、適切なプロンプトによって人間にとって原作品と実質的に同一の表現を再現可能な場合には、その記憶自体がドイツ著作権法16条の「複製」に該当すると判断したのである。さらに、実際にプロンプトに応じて歌詞を出力する行為も別個の複製行為であり、ユーザに歌詞を提供することは公衆への提供(公衆送信)行為にも当たると判断した。また、これらはいずれも権利者の許諾なく行われているため、EU DSM著作権指令におけるTDM(テキスト・データマイニング)例外規定によって正当化される範囲を逸脱しているとも判示している。

この判決の重要なポイントは、「モデル内部に著作物が再現可能な形で記録されているならば、その状態自体が著作権侵害となり得る」と明確に認めた点である。裁判所は「複製とはあらゆる形式若しくは態様でのコピーを含み、直接人間に知覚できる形でなくともよい」とのEU情報社会指令の文言を引き、その精神からすればモデルのパラメータ内に歌詞が符号化されているだけでも複製物の作成に当たるとした。「確率的なウェイトという形でのエンコードであることはコピーとみなすことを妨げない」とまで言及しており、技術形式の違いによって著作権上の複製性を回避することはできないとの強い認識を示している。また、モデルが歌詞を出力できたのは偶然ではなく高度に一致していることから、統計的学習の結果ではなく「学習データの本質的部分のそのままの取り込み」が生じていると事実認定された。この結果、ミュンヘン地裁はOpenAIに対し当該歌詞の出力行為の差止めと損害賠償責任を認め、さらに将来のために学習データや出力内容に関する情報提供を命じた。もっとも、本判決は第一審であり、OpenAI側は不服の意向を示しているため今後も継続する係争となる見込みである。

このGEMA判決が示す特筆すべき理論は、著作権法上の複製概念をモデル内部にまで拡張することである。つまり、学習データとして使用した著作物がモデル内に残存し、それを簡単な操作で再現できるのであれば、モデルは既にその著作物の複製物を含んでいるということになる。この理論は、「モデルが学習元著作物を含有している」とみなす点で画期的であり、実際Osborne Clarkeによる解説でも「英高等法院のGetty v. Stability AI事件の判断とは対照的に、ミュンヘン地裁はAIモデルが学習素材のコピーを含んでいる可能性を明示的に認めた」と評価されている。この見解に立てば、モデルは単なる分析の結果ではなく、場合によっては学習データそのものの集合体とも評価し得ることになる。

もっとも、この判決は歌詞という短いテキストで完全一致の出力が得られたという極端な事例に基づいている点には留意が必要である。裁判所自身、「通常は学習用の一時複製は分析目的に留まり権利者の市場を侵害しないが、本件ではモデルが作品を復元可能な形で保持しており分析の範囲を超えている」と述べており、「モデルが完全な再現を行う場合」に限定した判断であることを強調している。また英国の事例が示すように、司法の判断も国によって分かれており、この問題に対する法的コンセンサスは未だ形成されていない。

それでもなお、モデル内部への著作物の記録が複製であると明言した今回の判決は、ライセンス伝播理論を支える大きな論拠となり得る。なぜなら、GPL伝播を論じる前提としてまず「モデルがGPLコードの複製または派生物と言えるか」が問題となるところ、ミュンヘン地裁の論理はまさに「モデルは学習データの複製物となり得る」ことを法的に認定したからである。

二つの訴訟の現在地から導かれる可能性

以上の二つの訴訟から、AIモデルへのライセンス伝播理論が将来的に認められる道筋を考えることができる。

仮にAI事業者から見ての最悪のシナリオとして、これらの訴訟が原告側勝訴で確定した場合を想定しよう。Copilot訴訟においては「モデル提供者は学習元コードのライセンス条件を遵守しなければならない」という判断が確立し、GEMA訴訟においては「モデルが著作物の複製物を内包している」との法理が確立することになる。この二つが交差すると、「GPLコードを含むAIモデルはGPLコードの複製物若しくは派生物である以上、その提供にはGPLの条件が直接適用される」という結論が理論上導かれる。すなわち、モデルへのGPL伝播理論が司法によって事実上追認される可能性が出てくる。

具体的には、モデルが内部にGPLコード片を記憶し含有しているならば、そのモデルを第三者に頒布若しくは提供する行為はGPLコードの複製物の頒布と看做される可能性があり、その場合GPLではない条件での頒布行為はGPLライセンス違反と評価される。GPL違反が成立すれば、通常のソフトウェアの場合と同様に差止請求や損害賠償請求のほか、同一ライセンスでモデル全体を公開という強制的なGPL遵守による救済が主張される余地も出てくるだろう。実際、GEMAがOpenAIに求めた救済には学習データや出力内容に関する開示が含まれており、音楽著作物の文脈ではあるもののこれは「モデルが何を学習し含んでいるか」を透明化させる一種の開示請求と言える。GPL違反の場合も、ライセンス遵守を図る上で「モデルの内部に含まれるGPLコード部分の開示」や「モデルを再構築可能な形でのソース開示」といった要求が出てくる可能性は否定できない。

ここまで過激な結論ではなくとも、中間的なシナリオとしてはモデル提供者に一定の制約が課される展開が考えられる。例えば、Copilot訴訟が和解あるいは判決により「生成コード中に一定長以上の既存コードが含まれる場合は出力時にライセンスと著作者表示を付与する」といった措置を取ることで決着したり、あるいはモデルからGPLコード片が抽出若しくは再現されないよう技術的フィルタを実装することを義務付けられる可能性である。実際、Copilot開発元であるGitHubは、既に「候補コードが大規模リポジトリ上の既存コードと一致する場合は提案から除外する」というオプション機能を導入しており、訴訟リスクを低減する試みを行っている。また、OpenAIについても、GEMA判決を受けてChatGPTが著作権付き歌詞をそのまま出力しないようフィルタを強化したという報道もある。

これらは法的にはライセンス伝播そのものではないが、実務上は「モデルがライセンス条件を潜在的に侵害しないようにする」方向へ業界が舵を切っていることを示している。将来的には、モデルの学習段階でGPLといった特定ライセンス条項を持つデータを除外するガイドラインや、学習後に出力検査を行ってライセンス侵害出力がないことを保証する仕組みや制度などが整備される可能性もある。

いずれにせよ、これら二つの訴訟が完全に決着し、その後の立法的対応が定まるまでは、「モデルへのGPL伝播理論」は完全には消えていない。今後の判決次第では一挙に現実味を帯びるシナリオであり、また仮に訴訟で原告が敗れたとしてもオープンソースコミュニティ内でこの理論への支持が再燃する可能性もある。現時点では「かつてほど声高に叫ばれてはいない未確定理論」だが、それは法的に完全に否定され解決されたという意味ではない点に注意が必要である。我々のコミュニティとしては、こうした動向を注視しつつ、本稿後半で述べる各国法制度や反対論も踏まえて冷静に対応策を検討する必要がある。

日本法での扱い

前述の海外の訴訟の動向を踏まえ、日本法におけるAIモデルと著作物とライセンスの関係も整理しておく。日本においては、2018年の著作権法改正で導入された著作権法第30条の4が、機械学習に伴う複製行為を包括的に適法化する規定として存在し、さらに2024年3月には文化庁の文化審議会著作権分科会が「AIと著作権に関する考え方について」(以下、考え方)というガイドライン的資料を公表し、生成AIの開発・学習段階と生成・利用段階に分けて法的整理を提示している。

「考え方」によれば、基本的にAIの学習目的で行われる複製は第30条の4が定める「著作物に表現された思想又は感情の享受を目的としない情報解析」を満たす限り適法である。したがって、研究開発目的でインターネット上から広範なデータを収集および複製して学習用データセットを作成する行為は、原則として権利者の許諾なく行うことができる。ただし、重要なのはその学習行為に「享受目的」が混入していないかという点である。「考え方」では、もし「学習データ中の特定の著作物の創作的表現の全部または一部を生成AIの出力として意図的に再現させること」を目的とした学習が行われた場合、それは単なる情報解析ではなく著作物の享受目的が併存していると評価され、第30条の4の適用を欠くと述べている。この典型例として「過学習」が挙げられており、追加学習によって特定の作品群をモデルに覚え込ませ、その作品と類似した出力をさせるような行為は享受目的があると判断される。

さらに、「考え方」は学習済みモデルの法的扱いについても言及し、「AI学習により作成された学習済みモデルは、学習に用いた著作物の複製物とはいえない場合が多い」とまず述べられている。これは、モデルが汎用的に様々な入力に対してオリジナルとは無関係の出力を生成し得る以上、モデル自体は特定の著作物のコピーそのものではないという考え方である。

しかし、同時に「考え方」は、例外的に「学習済みモデルが学習データである著作物と類似性のある生成物を高頻度で生成する状態にある」ような場合には、モデルに元の著作物の創作的表現が残存しているとして複製物と評価される可能性を認めている。そのような場合には、モデルが著作権侵害の機械として位置付けられ、差止請求が認められ得るとも指摘している。要するに、通常はモデルは単なる統計データであって著作物それ自体ではないが、特定の著作物をほぼそのまま吐き出すための装置と化している場合には、侵害物として扱われ得るということであり、この考え方はGEMA判決の内容とも通じる部分がある。

以上の整理はあくまで著作権法上の権利制限規定(例外規定)の適用範囲の話であり、契約やライセンス条項の効力については触れられていない点に注意が必要である。文化庁文書は「著作権侵害か否か」の観点から論じており、たとえ学習行為が適法でも、それとは別に利用規約やオープンソースライセンスに違反すれば契約上の責任が生じ得ることまでは否定していない。またGPLなどコピーレフト条項の伝播についても踏み込んだ見解は示されていない。日本の著作権法には、30条の4のような権利制限規定が契約条件に優先するというオーバーライドの規定はなく、経済産業省の「AI・データの利用に関する契約ガイドライン」では、当事者間でデータ利用を禁止する契約がある場合にその契約が優先される可能性も示唆されている。

したがって、ライセンスを有効な契約とみなすならば、たとえ著作権法30条の4で「学習は適法」とされても、契約法上は「ライセンス条件違反」となるリスクが残存し、少なくともモデルへのGPL伝播理論が整理された公式見解は存在しないと言えるだろう。つまり、現状では、著作権法上はモデル学習行為の適法性がかなり広く認められているものの、ライセンス違反については民事上の一般論に委ねられており、例えば「GPLコードを学習させたモデルを公開頒布する行為がGPLライセンス違反となるか」について明確な指針はない。総じて、日本における法的整理は「著作権レイヤーでは原則セーフだが、契約レイヤーは白紙」という状況にある。ゆえに、モデルへのGPL伝播理論を巡る日本での議論は今後の司法判断や立法動向に委ねられており、現時点では文化庁の整理に従って慎重に運用指針を考えるほかないだろう。


ライセンスのモデルへの伝播理論への否定材料

前節までに見たように、モデルへのGPL伝播理論は法的にもゼロではない。しかし、多くの法律家や技術者は、この理論には重大な弊害があると指摘する。ここでは、著作権法、GPL条文、技術、実務政策の各レイヤーから、モデルへのライセンス伝播理論を否定する代表的な材料を示す。

著作権法レイヤーでの否定材料

まず、著作権法上ではAIモデルを「学習元著作物の二次的著作物」や「複製物」と見なすことには無理がある。多くの場合、モデルの内部には特定の著作物の表現が人間に認識可能な形では格納されていない。モデルはテキストやコードを重みパラメータに変換した統計的な抽象を保持しているに過ぎず、それ自体は人間にとって何ら創作的表現ではない。著作権法上の「二次的著作物」とは、原著作物の表現上の本質的特徴を直接感得できる形で取り入れた創作物を指すが、モデルの重みからは元コードの創作性を直接感得することはできない。言い換えれば、モデルは元コードを内包していると評価できるほどには直接的に作品としての性質を示さないのである。例えば、英国高等法院はGetty v. Stability AI事件の判断で「Stable Diffusionのモデルそのものは学習画像の侵害的複製物ではない」と述べており、モデルを著作物の複製と見なすことに否定的な見解を示した。このように、モデル自体を著作物の集積ないし編集著作物とみなすことには国際的にも慎重な立場が多い。

また、モデルが生成する出力には確率的及び統計的な変換が加わっており、多くの場合は学習元と似ても似つかないものが出力される。仮に偶然に一致や類似が生じても、それが依拠性のある複製なのか偶発的類似なのかの立証は困難である。著作権侵害を論じる上で必要な依拠性および類似性の認定を、モデル全体について行うのは現実的ではない。結局のところ、著作権法の枠組みでは「モデルが特定の著作物に依拠しているか」を作品毎に判断するほかなく、モデルそのものに一律の著作物性や侵害性を認めるのは飛躍が大きい。日本法の整理でもモデルは大半のケースで複製物ではないとされている通り、著作権法上はモデル=著作物という図式には無理があると考えられる。

GPL条文レイヤーでの否定材料

次にGPLそのもののライセンス条文や趣旨から見ていくと、やはりAIモデルにGPLが伝播するという解釈には疑問が呈される。例えばGPLv2の条文では、コピーレフトの対象はGPLで提供された元のコードの「二次的著作物」および「プログラムを含むもの」に限定されている。典型的には、GPLコードを改変若しくは組み込みしてできたソフトウェアやGPLコードと結合(リンク)したソフトウェアがこれに当たると解釈されてきた。AIモデルの場合、モデルが元のGPLコードのどの部分を「含んでいる」のか極めて不明確である。仮に学習に使ったGPLコードの断片をモデルが記憶し得るとしても、それはモデル全体から見ればごく一部であり、多くの部分はGPLコードとは無関係なパラメータで占められている。部分的にGPLコード由来の情報を内包している可能性がある統計モデルが「プログラムを含むもの」と言えるのかについては、GPL起草者による明確な想定も示されていない。

さらにGPLv3では、ソフトウェアのソースコードに対して「改変に適した形式」での提供を要求する。もしAIモデルがGPL派生物だとすると、その改変に適した形式とは何になるのかという問題が生じる。モデルの重みそのものは人間にとって可読性および編集性が低く、それは「改変に適した形式」とは言い難い。では、学習データがソースコードかと言えば、元の学習されたGPLコードそのものはモデルのソースとは言えず、かといって膨大かつ他種多様な全学習データセットを指すのかも不明確である。モデルをGPL準拠で再頒布するために何を公開すればよいのか定義が困難であり、モデルの学習に用いた全てのコードおよびデータを公開せよといった極端な結論にもなりかねない。これは自由信奉者の一部が目指す所ではあるものの現実には非現実的としか言えず、GPLの趣旨であるユーザがソースから改変およびビルドできるようにするという地点からも逸脱している。このように、既存のGPL条文はAIモデルのような産物を直接カバーする設計にはなっておらず、無理に適用しようとすると条文上も運用上も齟齬が生じる。

実際、OSI(Open Source Initiative)が2023年にまとめた「オープンソースAIの定義」では、モデルの「改変に必要な情報」として学習データについて十分詳細な情報を開示すべきとするに留め、学習データそのもの全ての提供までは要求していない。またモデルの重みや学習コードについてはOSI承認ライセンスで公開すべきとしている。

加えて、FSF(Free Software Foundation)自身も現行のGPL解釈だけでAI領域の自由を担保できるとは考えておらず、2024年に「機械学習アプリケーションが自由であるための基準」の策定に着手したと発表している。そこでは「ソフトウェアだけでなく生の学習データやモデルパラメータも含めて四つの自由をユーザに保証すべき」という方向性が示されているが、これは裏を返せば現行ライセンスではそれが保証されていないという認識である。FSFは「モデルパラメータは人間にとって理解可能なソースとは言えないので、直接編集よりも再学習による改変が現実的」とも指摘しており、既存GPLの延長線上でモデルを扱うことに慎重と言える。総じて、GPL条文の文言や想定から外れるAIモデルに対し、一義的にGPL伝播を主張するのはその解釈上から無理がある

技術レイヤーでの否定材料

モデルへのGPL伝播理論には、技術的観点からの反論も強い。AIモデル、とりわけ大規模言語モデルと呼ばれるモデルは、基本的には巨大な統計的傾向を内部に保持しているのであって、元のコードやテキストをそのままの形でデータベースのように格納しているわけではない。特定の入力に対し特定の出力を返すのも、あくまで確率分布に従った生成に過ぎず、常に学習データと同一の出力が得られるとは限らない。モデルがごく一部の例外的なケースを除いて学習データの逐語的再現を行わないのであれば、モデル内に「GPLコードを含む」と評価することは技術的な実態にそぐわないだろう。実際、OpenAI側はGEMA訴訟で「モデルは個別の学習データを記憶せず、あくまで全データセットから学習した知識をパラメータに反映している」と主張していた。この主張はミュンヘン地裁には受け入れられなかったが、それは明確な歌詞の再現例があったからであり、裏を返せば「明確な再現例がない限りモデルは統計知識の塊である」という見方になるだろう。

さらに、モデルが学習データの断片を出力し得ることは確認されているものの、その割合は全体から見れば極めて限定的と考えられる。部分的記憶の存在をもってモデル全体を複製と見做すのは、画像で言えばごく小さなモザイク状の断片を含むだけの全体を写真の複製と主張するようなもので、過剰な一般化と言える。技術的には、モデルの特定パラメータがどこまで元データの影響を保持するか定量的に測ることは難しく、モデルと学習データの対応関係はやはり統計的でしかなく線引きが困難である。よって、「どの程度似ていればGPLが伝播するのか?」といった基準をそもそも定めようがない。侵害か否かの判断は個別の出力単位で行わざるを得ず、これではモデル全体に単一のライセンスを適用するという発想とは整合性が取れないだろう。技術面からはモデルは基本的に統計的変換物であり、大部分はGPLコードと無関係である以上、一括でGPLを適用するのは不合理であると言える。

実務的・政策的な否定材料

最後に、実務上および政策上の観点からもモデルへのライセンス伝播理論には大きなデメリットを指摘できる。もし仮に、このGPL伝播理論が法的に認められるとどのような事態が起こるだろうか?極端な例としては、ある大規模モデルの学習に100万件のコードリポジトリが使われていた場合、それらに含まれる様々なライセンス(GPL、MIT、Apache、プロプライエタリ等)が全てモデルに「伝播」し、そうなるとモデル提供者は100万件分のライセンス条項全てに適合する形でモデルを頒布しなければならなくなる。現実問題として、GPLv2とApache-2.0のように条件が矛盾する組合せもあるだろうし、著作権表示の膨大な集合を一モデルに付与して管理することも非現実的としか言えない。ライセンスが混在する学習データから作られたAIモデルに全ライセンスを適用するのは実務的に破綻としか言えず、結局、それを避けるためにできることは学習データから最初からGPL等のコピーレフト性のあるライセンスのコードを除外することぐらいしかないだろう。

このような事態は、我々のコミュニティにとって本当に望ましいだろうか?GPLの精神はソフトウェアの自由な共有と発展を促すことである。しかし、AIモデルへの過剰な伝播を主張することで企業がGPLコードの利用を忌避し、結果としてGPLソフトウェアが持つ価値がAI時代に生かされなくなるなら本末転倒であろう。ソフトウェア開発の現場では自社製品にGPLコードを混入させない方針を取る企業も多いが、同様に「自社AIの学習データにGPLを含めない」となれば、GPLプロジェクトはデータ提供源として価値を失いかねない。さらに言えば、現在進行中のAIを巡る法廷での争いはどちらかと言えば金銭補償や規制ルール作りに軸足があり、GPLが理想とするようなコードの共有という方向とは別ベクトルに進みつつあるのが現状である。モデルへのGPL伝播理論だけが独り歩きしても、現実には訴訟リスクを避けるためのデータ排除やクローズド化が進むだけで、自由なソフトウェア文化の拡大には繋がらない恐れがあるのである。

政策的にも、各国の政府はAIにおける著作物利用について慎重に検討しているが、現時点で「学習データのライセンス違反はモデルに対する法的責任を生じさせる」という明示的ルールを定めた例はない。EU AI規則でも、学習データの質や透明性に関する規定はあるものの、オープンソースライセンスの遵守までは求めていない。むしろオープンサイエンスやイノベーション促進の観点から、テキスト・データマイニングを権利制限で許容する動きが強い。日本でも前述のとおり、第30条の4で広く情報解析利用を認める方向であり、AIモデルにライセンスを強制適用するという政策は少なくとも現状の国際議論では主流ではない。

以上を踏まえると、実務および政策両面でモデルへのライセンス伝播理論はかえってオープンソースの不利益を生む可能性が高く、現実的な解ではないと言える。重要なのは、オープンソースの理念である「ソフトウェアの自由」をAI時代にどう実現するかであり、それは極端な法解釈よりも、透明性の確保やオープンなモデル開発の推進といった現実的手段によって図られるべきだとの意見が有力であり、私自身も常々主張していることである。


OSIとFSFのスタンス

AIモデルへのGPL伝播理論に関連して、オープンソース(および自由ソフトウェア)界隈の主要団体が現時点でどのようなスタンスを取っているかも整理しておこう。代表的な団体としてOpen Source Initiative(OSI)とFree Software Foundation(FSF)となるが、両者はソフトウェアの自由を掲げている所は共通するものの、AIモデルと学習データに関して必ずしも同一のアプローチではない。

まず、OSIは2024年に「オープンソースAIの定義」(OSAID:Open Source AI Definition)を策定し、AIシステムがオープンソースと呼べるための要件を定めた。この定義では、AIシステムに対してもソフトウェアと同様の4つの自由(利用・研究・改変・再頒布)を保障すべきとしており、その実現のために必要な要素として「改変に必要な形式」に関する要件も定めており、そこで以下の3要素を開示することが求められる。

  • データ情報:学習に使用したデータについて、熟練者が同等のモデルを再構築できるのに十分な詳細情報を提供すること
    • これは学習データそのもの全てを公開することを必須とするものではないが、公開できないデータがある場合でもその出所・範囲・性質・取得方法を開示し、公開可能なデータはリストアップし、第三者から入手できるデータについても情報を提供することを求めている
  • コード:モデルを学習・実行するための完全なソースコード一式をOSI承認ライセンスで公開すること
  • パラメータ:モデルの重み(パラメータ)をOSI承認の条件で公開すること

OSIは「オープンソースAI」を実現するにはモデル重みだけでなく学習に用いたコードと学習データに関する情報が不可欠としつつも、学習データそのものの完全公開までは要求していない点に注目すべきである。これは、例えばプライバシーや機密の関係で生データを公開できない場合でも、そのことを明らかにしてデータの性質を説明することで代替し得るという柔軟な姿勢である。また、モデルパラメータの自由な利用を確保する法的メカニズムは今後明確化していく課題としており、現時点ではパラメータに対する法的権利制御(例えば著作物性の有無など)にも結論を出していない。

これらから読み取れるように、OSIとしてはAIモデルについても原則オープンソースの定義のレベルでのオープン化を推進するが、学習データの扱いについては情報開示レベルでの要件に留めていることになる。これにより、OSIはモデルへのライセンス伝播理論を採用して学習データ公開を求めることを避けていると言え、まず透明性と再現可能性を担保する現実解を模索しているとも言える。原理的には、OSIとしてはGPL伝播理論をOSAIDの定義公開時点で否定したとも言えるだろう。なお、この定義の策定プロセスの最終盤で学習データの必須論を封じたのはおそらく自分であるが、これは正しい判断だったと私は考えている。

一方、FSFおよびFSF Europe(FSFE)はより原理原則に忠実なスタンスを取っている。FSFEは2021年時点で「AIアプリケーションが自由であるためには、その学習用コードも学習データも共に自由ソフトウェアライセンスで公開される必要がある」と明言している。すなわち、モデルを改変若しくは検証するには学習データも含めて手に入らねばならず、ゆえに両方が自由でなければならないという考え方である。また、FSF本体も2024年の声明で、「現在の理解では、MLアプリケーションが自由と呼べるためには全ての学習データとそれを処理するスクリプト類が四つの自由を満たさねばならない」と述べており、自由の要件をデータにまで拡張しようとしている。このようにFSF/FSFEは学習データ非公開のモデルはソフトウェア部分が自由でも全体として不自由であるという立場に立っている。

もっとも、FSFは同時に「不自由機械学習アプリケーションが倫理的に不当かは場合による」という旨も述べており、例えば医療診断AIの学習データ(個人情報)を公開できないことには「正当な道徳的理由」があり得るとも言及している。その場合、そのAIは不自由ではあるが社会的有用性から使用が倫理的に許される場合もある、という含みを持たせている。このあたりにFSFの理想と現実の折衷を模索する姿勢が見えるが、いずれにせよFSFは究極的には学習データまで含めた自由を目指していることは間違いない。

では、FSFがAIモデルへのGPL伝播理論を支持しているのかと言えば、必ずしもそうではない。彼らの主張は法的強制力というより倫理基準若しくは理想像に近く、現行GPLライセンスの解釈としてモデルに適用されると主張しているわけでもない。むしろ前述のように新たな基準や合意を作ろうとしている段階である。FSFが資金提供したCopilot問題に関するホワイトペーパーでも、法的論点としては著作権やライセンス違反が論じられつつも、実質的にはCopilotの出力にGPLコード断片が含まれていた場合に利用者がGPL違反リスクを負う懸念といったの利用者(下流開発者)のGPLコンプライアンス問題として語られている側面が強い。これは、モデルそのものへのGPL適用というよりAIコーディングツールを使う開発者への注意喚起であり、モデル提供者に直接GPL遵守を強制するアプローチとは異なる。

Software Freedom Conservancy(SFC)は当然のようにこの問題に強い関心を寄せているがやはり慎重な所もある。SFCは2022年にGitHubに対する抗議キャンペーン「Give Up GitHub」を開始し、Copilotのやり方はオープンソースの理念に反すると非難しており、Copilot集団訴訟にも関与している。ただし、SFCのブログ記事では、この訴訟について「オープンソースコミュニティの原則から外れた解釈が持ち込まれるリスク」に懸念を示し、原告側にもコミュニティ主導のGPLエンフォースメント原則を遵守するよう呼びかけている。SFCは、Copilotの行為が「前代未聞のライセンス違反」であるとも述べており、GPL伝播理論に対して全面否定ではないものの法廷闘争の結果次第ではコミュニティにとって望ましくない判例ができることを恐れているとも取れるだろう。SFCはGPL伝播を追及する側面と司法に委ねるリスクとの間で慎重にバランスを取っていると言えるかもしれない。

最後に、自由なソフトウェア陣営として懸念されるのは、ライセンスの過剰な伝播はかえって自由を損なう結果を招きかねないという点である。OSIもFSFも究極的にはAIを誰もが活用できる開かれたものにしたいと考えているが、全データの公開要求等において法理の純度を高めることが本当に目的達成につながるかを慎重に見極めている。過剰な伝播解釈によってオープンデータの忌避、あるいは訴訟乱発による委縮効果などのデメリットを考慮すれば、自由の普及という大局を見失わないことが肝要だという点で主要団体の考えは共通項があるように私は感じている。モデルへのGPL適用を煽るよりも、どうすればモデルとデータをオープンにできるか、どの部分は現実に即して緩和すべきか、といった現実解の追求が今後も続くだろう。


まとめ

以上、AIモデルへのGPL伝播理論の現在地を見てきたが、結論として本理論は「かつてほど喧伝されなくなったが、完全に消え去ったわけではない」という中途半端な位置にある。Copilot集団訴訟やGEMA v. OpenAI訴訟といった訴訟の中で、学習データのライセンス違反やモデル内の複製という論点が精査され始めた結果、かえって侵害認定のハードルは下がりつつあるようにも見える。実際、ミュンヘン地裁の判断はモデル記憶を複製とみなし、Copilot訴訟ではオープンソースライセンス違反の主張が生き残っている。

しかし一方で、GPL等のライセンス伝播のハードルは依然として高い。侵害が認められることとそれが直ちにGPL等でモデル全体を公開せよという結論になることの間には大きな隔たりがある。現状の訴訟も求めているのは差止めや損害賠償であってモデルの強制的なGPL化ではない。モデルへのGPL伝播理論そのものを司法が支持した例は皆無であり、法的には未踏の領域である。仮に今後どこかでその主張が試みられても、前述した法的・技術的・実務的な反論に直面することになるだろう。

もっとも、状況はまだ流動的な部分もあり、各国の政策やコミュニティの動向によって線引きが変動する可能性もある。例えば、欧州で権利者団体の圧力が強まれば、ライセンス遵守を含むガイドラインが策定される可能性もある。また、コミュニティ内でAI時代のコピーレフトのあり方について合意が形成されれば、新たなライセンスが登場するかもしれない。そうした変化が起これば、モデルへの伝播理論が再評価される局面も訪れるだろう。

私見を交えれば、現時点で重要なのはソフトウェアの自由とAI領域での自由をいかに両立させるかという視点である。コピーレフトの理念を闇雲にAIに適用しようとするのではなく、AI特有の技術的性質と産業構造を踏まえつつ自由を最大化するには何が最善かを考える必要がある。幸いにもオープンソースコミュニティからは既に大規模なAIモデルのオープンな公開やデータセットのクリーニング手法、ライセンス表記の自動付与化など、実践的な諸問題の解決策も模索されている。そうした自発的な取り組みを促進し、必要に応じて法的整備で後押しすることが、自由と発展のバランスを取る鍵となるのだろう。

モデルへのGPL伝播理論は、追求すべき理想なのか避けるべき悪夢なのか判断が分かれるところではある。しかし、本稿で述べたように2025年現在の情勢を見る限り、直ちにそれが現実となる状況ではないし、コミュニティも慎重な姿勢が大勢だろう。今後も司法・立法・技術の各面で試行錯誤が続くと推測されるが、我々のコミュニティとしては拙速な結論に飛びつくことなく、技術革新とソフトウェアの自由の両立点を模索し続ける必要がある。そのプロセス自体が、自由なソフトウェア精神の延長線上にあるAI時代の新たな挑戦と言えるのだろう。

参考

GEMA v. OpenAI (ミュンヘン第一地裁)判決雑感

ドイツの音楽著作権管理団体であるGEMAが、ChatGPTの運営元であるOpenAIを相手取りミュンヘン第一地方裁判所へ提起した訴訟において、GEMAが求めていた差止、情報開示、および損害賠償の請求を実質的に認める広範な勝訴判決を下した。初めてのOpenAIの敗訴ということでも重要であるが、さらにこの判決は生成AIの学習(トレーニング)と出力の双方において著作権の侵害性を認める極めて重大な判断を示しており、地裁判決と言えども影響を軽くみるべきではないのだろう。

この訴訟は大量のデータスクレイピングという抽象的なものを対象とするのではなく、GEMA側が選択したドイツ国民がよく知っている9つの楽曲に絞って単純なプロンプト入力によって出力として歌詞が現れるかを訴訟の客体としており、これまでの米国でよく見られたふんわりとしたAIモデルのトレーニングにおける間接的な侵害を争うものとは大分様相が異なる。なお、この原告のやり方は米国のような強い証拠開示請求制度が存在しない法域においては出力として動かぬ証拠を握るということであり、非常に効果的であるとは個人的に思う。

裁判所の判断であるが、まずモデルの学習段階において複製権の侵害を認定している。係争中の歌詞が出力に現れることで「再現可能な形で含まれている」との認定に基づき、歌詞がモデルの「指定されたパラメータ内のデータ」として「具現化」されているという認定したのである。要するにモデルのウェイトも法的には「複製」に該当し得るという判断である。これは従来のAIモデルの開発ベンダー側の感覚からすれば非常に厳しい。これについて、OpenAIは技術的に抽象的パターンに過ぎないとする従来からの論を展開したようであるが、裁判所は出力における歌詞の正確な同一性を証拠としてモデル内への「記憶」として認定し、OpenAI側の「新たに生成した」という主張に対しては歌詞の長さと複雑性を考慮して「偶然の一致」という反論も排除している。

学習面だけでなく出力においても裁判所は別個に送信可能化権を侵害したと認定している。つまり、OpenAIがChatGPTを介して歌詞を出力し、公衆であるユーザーが個別にアクセスできるようにした行為そのものが侵害ということである。個人的な感想としては、この学習と出力での二重の侵害認定は非常に重いと感じている。仮にOpenAIが今回の判決を不服として控訴したとしても、学習面での複製権侵害と出力の送信可能化権侵害の両方を覆さなければならない。今のところは自分からはそこそこ堅実なロジックに基づいているように見えるので、全ての判断を覆すのは難しいだろう。

EU域内ということでOpenAIはEU DSM指令のTDM例外に該当するという反論を行なっているが、権利団体側のGEMAが歌詞のオプトアウトをしていたという事実が認定されたことでそもそもTDM例外の主張が崩れたのだが、さらにその前段として単なる「分析」を超え、作品を「記憶」した後で「出力」する形で利用することは、TDM例外が保護する目的の範囲を根本的に逸脱しているという画期的な判断も地裁側は行なっている。

ただし、ミュンヘン地裁は根本的なEU DSM指令の解釈に触れると考えられる問題について欧州司法裁判所に付託しないという判断を行なっていることは今後特に控訴審において問題視されるかもしれない。ミュンヘン地裁的にはそもそもOpenAIの行為がEU DSM指令のTDM例外が許可する目的の範囲外なのでそもそも付託する理由がないというロジックなのではあるが、個人的にはやはり前例のないEU法の解釈なのであるので欧州司法裁判所に付託して判断を仰ぐべきだったのではないかと思う。ただし、この判断の法的な是非については自分は特にEU法を知らないので何とも言えない。

また、出力の責任がプロンプトを書いたユーザー側にあるというOpenAI側の主張については、OpenAIがトレーニングデータとして歌詞を選択し、モデルアーキテクチャを設計し、トレーニングデータの記憶に責任を負っているとして地裁は否定している。ユーザーのプロンプトはあくまで引き金であって原因ではない論である。この点についてはある程度は仕方がないだろう。

今後であるが、OpenAIは間違いなく控訴すると考えられるが、やはりAIモデルを「法的な複製」とみなす論は崩されやすいように感じている。英国のGetty v. Stability AI訴訟でまさにここをOpenAIの言う「確率的合成」とみなしたばかりでもあり、国際的な判例との齟齬を突きやすい。しかしながら、地裁判決とは言え、包括的なライセンスモデルを推進していた権利者団体側がここまで綺麗に完勝した事実は大きそうだ。Web上のデータは無料の訓練素材という考え方は少なくともEUでは厳しい傾向になるのではないかと思う。

なお、法管轄について裁判所としては侵害行為の一部あるいは侵害の結果がドイツ国内で発生しているという判断から終始ドイツ法とEU法で判断を行なっているが、送信可能化権の侵害については結果発生地とする考え方もあるのでまだ分かるとしても、複製権侵害についてはOpenAIのモデルトレーニング時における複製行為は全て米国であろうからここが控訴審で争点になるかもしれない。判決文によればOpenAIはドイツ国内を含むEEA域内のサーバーでもモデルを提供していると認定されており、ミュンヘン地裁はEU域内のサーバーにモデル又は結果物が保存された時点でEU法の管轄という判断を下したのだろうが、開発段階の複製が米国のみであった場合の法的評価などは今後の争点になり得る。

ただ、仮に今回の地裁の解釈がそのまま一般化するとEU域外のAI事業者にとってはEU域内へのAIサービス提供は常にリスクがあるということになる。今回の判決ロジックをそのままEU全域で維持となると、単なるWebのサービスならEUを遮断すれば良いが、モデル単体や出力の欧州への流入まで遮断という話になりかねないだろう。逆にEU市民からすると、AIトレーニング用のデータだけを域外のAI企業に不当に搾取されているという感覚が増幅しそうであり、今後の政治的な火種になるかもしれない。

脱線したのでいったん戻ると、自分はドイツ法にもEU法にも詳しくはないものの、今回のミュンヘン地裁判決は個人的には若干攻め過ぎなようにも思い、控訴審あるいは欧州司法裁判所あたりでこの「管轄問題」、「TDM例外の解釈」、あるいは「記憶の複製理論」があらためて争点になるかと思う。なお、特に複製行為に関してはOpenAIとしてはやはり米国で技術的には完了しているわけであり、それを欧州に持ち込むことの是非というあたりで政治的な判断も入ってくるんじゃないかと思うところもあり、司法だけではない動きも誘発する可能性があるだろう。色々エスカレートしていくと、GDPRやDSAなどの強い規制法と同じ理屈がAI領域で強まるかもしれない。

個別の訴訟としてみると、今回は原告のGEMAがドイツで有名な9つの楽曲を選んで単純プロンプトで出力させ、その侵害の認定はわずか15語とか25語のごく短い歌詞の出力でされているわけである。短くても個性が強く表れた創作性の高い部分をうまく選んだことがGEMA勝訴の要因の一つであるだろう。この単純プロンプトのみで独創性が極めて高い著作物の一部を出力させてそれを証拠とする手法は、米国のような強い証拠開示請求の制度がない法域であることを逆手に取った戦略とも言え、これは他の法域でも類似の訴訟を誘発するかもしれない。なお、今回の訴訟も結局のところ歌詞のデッドコピーそのものがAIの出力によって現れたことから全てが推認されているわけであり、これは日本法的言い回しであれば著作権法30条の4の情報解析の例外規定における「非享受利用」の範囲に該当しないということでもあろう。各国の法のアプローチは異なるものの、モデルの出力とその利用の目的での判断を重視するのは各国の訴訟で共通していると考えられ、少しずつ各国の考え方のすり合わせが進んでいるようにも感じられる。その意味では、日本の著作権法の非享受目的の概念は先進的だったと言えるのだろう。

注:この投稿はXへ投稿した同様の内容のスレッドを編集したものである。元がXのスレッドなので雑多にあちこちへ飛んでいるが、あまり気にしないこと。

特に意味はない。たまたまあったので。

過剰で厳格なCode of Conduct(行動規範)が多くのオープンソース・プロジェクトに不要な理由

オープンソースのプロジェクトで採用されているCoC (Code of Conduct, 行動規範)を巡る議論が、一つの転換点を迎えているかもしれない。2025年9月、Rubyのエコシステムを支えるRubyGemsのガバナンスを巡る騒動が勃発し、コミュニティに大きな波紋を広げている最中であるが、これと直接的には関係がないもののこの混乱をきっかけにRuby on Railsの作者であるDavid Heinemeier Hansson(DHH)とオープンソースの元伝道師であるEric S. Raymond(ESR)という二人の有名人が、現代的なCoC、特に「Contributor Covenant」に対して痛烈な批判をX上で展開するという出来事があった。

DHHは、Contributor Covenantのような詳細かつ厳格なCoCを「トロイの木馬」と断じ、プロジェクトから排除すべきだと主張し、一方のESRはさらに踏み込み、CoCはコミュニティを掻き乱す「厄介者のための道具」に過ぎず、プロジェクトから完全に削除することが最善であると主張している。この二人は界隈で物議を醸すタイプの人物と見られることが多いが、この件に関しては自分の考え方もかなり近いところにある。

そもそもコラボレーションを促進し、コミュニティを健全に保つためのツールと見なされていたCoCが、何故これほどまでに激しい論争の的となったのか。本稿では、オープンソースのプロジェクトがCoCと出会った黎明期から、その普及と変質、そして現代における弊害までを歴史的に紐解き、なぜ過剰なCoCが多くのオープンソースプロジェクトにとって不要であるのかを論じる。結論として、CoCの原点に立ち返り、個々のプロジェクトの規模や文化に合わせた、身の丈に合った規範こそが、持続可能な開発コミュニティの礎となることを示す。

English version: https://shujisado.org/2025/09/30/why-heavy-codes-of-conduct-are-unnecessary-for-most-open-source-projects/

  1. オープンソースプロジェクトがCoCの効力に出会った時
    1. Debianの停滞とUbuntuの躍進:CoC黎明期の原体験
    2. カンファレンスからプロジェクトへ:規範の一般化
    3. Contributor Covenantによる標準化と主流化
  2. 厳格なCoCの弊害と反発の動き
    1. Rustモデレーションチーム総辞職事件
    2. RubyGems事件からの示唆
    3. ESRの功利主義とRuby CoCの寛容性
  3. さいごに

オープンソースプロジェクトがCoCの効力に出会った時

CoCは、ある日突然、思想的な目的のために外部から持ち込まれたものではない。それは、オープンソース・コミュニティが内包する現実的な問題、すなわち、技術的な対立がいつの間にか個人的な攻撃に発展し、プロジェクト全体の生産性が著しく損なわれるという課題への、実践的な解決策として生まれたのである。

Debianの停滞とUbuntuの躍進:CoC黎明期の原体験

CoCの有効性が初めて大規模に実証された事例は、2000年代初頭のDebianプロジェクトの状況に遡る。当時のDebianは、開発者の自律性を最大限に尊重する文化を持ち、中央集権的な強い意思決定機関が存在しなかった。その結果、各パッケージのメンテナーや各機能の担当者が自身の技術的信念を貫くあまり、プロジェクト全体のリリースが停滞するという事態が頻発していた。

この構造的な問題が最も顕著に現れたのが、2005年6月にリリースされたDebian 3.1、コードネーム「sarge」を巡る長い騒動である。その前のバージョンである「woody」がリリースされたのは2002年7月であり、sargeのリリースには実に3年近い歳月が費やされたわけだが、この長期にわたる遅延はDebianコミュニティ内の絶え間ないフレームウォーによる疲弊と、意思決定プロセスの麻痺を象徴していた。

このDebianの停滞と混乱に対する直接的な回答として登場したのが、2004年にMark Shuttleworthが立ち上げたUbuntuだった。Ubuntuは、「六ヶ月ごとのリリースサイクル」という技術的な約束事に加え、コミュニティの健全な運営を担保するためのCoCを最初期から導入した。このCoCの起草にはDebianプロジェクトにも深く関与していたBenjamin Mako Hillが中心的な役割を果たしているが、彼自身の言葉によれば、UbuntuのCoCは他のプロジェクト(当然、Debianであろう)で経験した「刺々しいやり取り」への反省から意図的に明文化されたものであった。つまり、UbuntuのCoCは、技術的な生産性を最大化するために、健全なプロジェクトの協働を維持するという現実に即した目的から生まれたのである。この結果として「Ubuntuの方が動きやすい」という空気が醸成され、多くの開発者がDebianからUbuntuへと活動の場を移すことになった。

カンファレンスからプロジェクトへ:規範の一般化

Ubuntuが示したCoCの有効性は幾つかのプロジェクトへ波及していたが、2010年代に入ると、その議論の舞台はオンラインの開発のメーリングリストから、オフラインの技術カンファレンスへと波及し、そこから一気に拡大していく。ここでCoCの目的は、全体の「協働の生産性向上」から「参加者の安全確保」を含むものへと大きく舵を切ることになったと言えるだろう。

この転換の引き金となったのは、2011年から2015年にかけて活動した非営利団体「Ada Initiative」である。Ada Initiativeは、技術カンファレンスにおけるハラスメントが深刻な問題であると指摘し、具体的な対策としてアンチハラスメント・ポリシーのテンプレートを公開し、その導入を強力に推進した。それまで一部のコミュニティを除いてほとんど存在しなかったカンファレンスの行動規範は、Ada Initiativeの活動によって業界の標準的な慣行として急速に広まっていった。

そして2013年、Pythonの年次カンファレンスであるPyConで発生した「Donglegate」事件が、CoCの必要性を決定的に可視化させることになった。これは参加者であった女性が、近くの席にいた男性たちの「ドングル」という発言を性的な冗談と受け止め不快に感じ、彼らの写真をTwitterに投稿したことが発端であった。この一件は、冗談を言った男性の一人と告発した女性自身の両方が職を失うという結末を迎えたのだが、コミュニティ内の対立が当事者のキャリアに深刻な実害を及ぼしうること、そして非公式な規範だけではこのような事態を収拾できないことを白日の下に晒した。事件後、PyConは「公の場での名指しの批判は、強力なコミュニティを構築する上で逆効果になり得る」との文言をポリシーに追加し、CoCとその運用手順の重要性が広く認識されるようになった。

Contributor Covenantによる標準化と主流化

Ubuntuが示した「協働の生産性向上のためのCoC」とAda Initiativeが推進した「安全のためのCoC」という二つの潮流が合流し、一つの完成形として登場したのが2014年にCoraline Ada Ehmkeによって作成された「Contributor Covenant」であるのだろう。Contributor Covenantは、特定のプロジェクトやイベントに限定されない汎用的なCoCのテンプレートとして設計され、その内容は、年齢、性自認、民族、経験レベルなど、保護されるべき属性を明示的に列挙し、「歓迎されインクルーシブな言葉遣い」を推奨する一方で「個人攻撃や政治的攻撃」「公的または私的なハラスメント」などを許容されない行動として具体的に定義している。さらに、違反が報告された場合の調査や是正措置に関する詳細な執行ガイドラインまで含んでおり、単なる理念の表明に留まらない法的文書に近い枠組みとなっている。

この網羅性と導入の容易さからContributor Covenantは瞬く間に普及し、多くのIT企業や主要なオープンソース・プロジェクトを含む数万ものプロジェクトで採用されるに至っている。2018年、Linus Torvalds自身が過去の攻撃的な言動を謝罪するとともに、Linuxカーネルが従来のCode of Conflictを廃止してContributor Covenantを採用したことで、この重量級の標準化されたCoCがオープンソース界隈にて象徴的転換点を経て現在に至っている。

CoCの歴史を振り返ると、その目的が段階的に変化してきたことが分かるだろう。当初はDebianの機能不全を解決するための「協働の生産性向上のツール」であった。次に、カンファレンスでの事件を契機に参加者を守るための「安全確保の仕組み」を含むものへと進化した。そして最終的に、Contributor Covenantによって、コミュニティのあるべき姿を定義し、それを強制するための法的な拘束力も強まった「倫理規範の標準フレームワーク」へと変貌を遂げた。ESRやDHHが批判の矛先を向けているのは、2004年当時の現実に即したツールではなく、2014年以降に主流となったこの倫理的・法的な性格を強く帯びたCoCなのである。

厳格なCoCの弊害と反発の動き

善意から生まれたはずの厳格なCoCであるが、その普及とともにオープンソースのガバナンスに新たな、そしてより深刻な問題をもたらし始めた。CoCが、時にコミュニティを守る盾ではなく、内部の権力闘争を助長し、貢献者を疲弊させる武器へと姿を変えることも分かってきたのである。特に詳細な条文と厳格な執行プロセスを持つCoCは、理論上は公平なコミュニティ運営を保証するように見える。しかし、現実には、前述のLinuxカーネルでのContributor Covenantの導入は賛否を呼び、多くのプロジェクトで政治的な対立を招いたわけでもあり、重厚なCoCにおける複雑さがガバナンスの構造的欠陥を露呈させたり、悪意ある第三者によって悪用されたりする脆弱性を生み出している。

Rustモデレーションチーム総辞職事件

中でも最も象徴的な事例は、2021年11月に起きたプログラミング言語Rustのモデレーションチームが全員辞任するという衝撃的な事件であろうか。彼らが発表した声明では、辞任の理由は「コアチームが自分たち以外の誰に対しても説明責任を負わない立場に身を置いているため」とされ、その結果として「コミュニティが期待する水準でRustのCoCを執行することができなくなった」というものであったのである。

問題の核心はガバナンスの構造にあった。Rustプロジェクトでは、CoCの執行を担当するモデレーションチームのメンバーがプロジェクトの最高意思決定機関であるコアチームによって任命されていた。つまり、CoCを執行する組織が、CoCによって裁かれる可能性のある組織に従属していたのである。この構造では、コアチームのメンバーが関与する違反疑惑に対して、独立かつ公平な調査や裁定を下すことは事実上不可能である。この事件は、どれほど立派なCoCを掲げたとしても、それをプロジェクトの最高権力者に対しても公平に適用できる独立したガバナンス構造がなければ、CoCが空文化し、摩擦だけが残るという厳然たる事実を示しており、CoCが権力に対するチェック機能として失敗した典型例と言えるだろう。

RubyGems事件からの示唆

Rustの事例がCoCの「無力さ」を示したとすれば、今回の論争のきっかけでもある現在進行中であるRubyGemsの事例は、CoCを含むガバナンスの言説がいかにして「権力掌握の道具」として悪用されうるかを示している可能性があるだろう。

この事件では、Rubyコミュニティのインフラを運営する非営利団体Ruby Centralが、主要なスポンサーからの圧力を受け、長年に渡り無償で貢献してきたメンテナーらの同意なしにRubyGemsとBundlerのGitHub Organizationの管理権を掌握したと追求されている。Ruby Centralが公式に掲げた理由は「サプライチェーンセキュリティの保護とガバナンスの強化」という誰もが反対しにくい正当なものであり、これは一定の説得力を持つものであるが、追放されたメンテナーらはこの動きの実態を「スポンサー企業の意向を背景とした中央集権化とコミュニティの乗っ取りであった」と主張し、「敵対的買収」と呼んでいる。この事案に対して自分のような外部の者がどちらか一方が悪いと決定的な論調で書くほどの材料は今のところは揃っていないと判断しているが、仮にメンテナーらの証言側に立てば、CoCの執行やセキュリティ確保といったガバナンス強化の名目がコミュニティを保護するのではなく、むしろコミュニティから権限を奪い、企業や一部の権力者の利益のために利用され得るというより悪質な失敗のパターンが存在することを露呈させているだろう。

RustとRubyGemsの事例が示すのは、CoCガバナンスのパラドックスであるのだろう。すなわち、指導部の暴走を抑えるほどに強力なCoCは指導部(あるいは外部勢力)によって乗っ取られ、コミュニティを支配するための道具としても使われるほどに強力でもあるということだ。コミュニティを守るために設計された仕組みそのものが、コミュニティの権利を奪うための手段となり得るのである。厳格かつ強力なCoCは必然的に複雑な執行機関を必要とする。この執行機関はプロジェクト内に新たな権力の中枢を生み出し、その権力は政治的力学や乗っ取りのリスクに晒される。結果として、CoCを複雑化させることが、意図せずしてプロジェクトの政治的な「攻撃対象領域」を拡大させてしまうのである。RubyGems事件はCoC自体ではなくガバナンスだが、規範や統治の重さがコミュニティの分断や企業政治と結び付く危険性を示唆しているとも言えるだろう。

ESRの功利主義とRuby CoCの寛容性

このようなCoCの機能不全の状況に対し、ESRとDHHは現代のCoCパラダイムに対する根本的な批判を展開したのである。両者のアプローチは異なるものの複雑で官僚的なCoCがオープンソースの本質を損なうという点で共通している。

ESRの主張(https://x.com/esrtweet/status/1971768345188844003) は明快であるが、やや過激である。彼の助言は三点であり、(1) CoCを持つことを拒否せよ。もし既にあるなら削除せよ。(2) 官僚的な理由でどうしても必要なら次の一文で置き換えよ。「あなたの貢献が正当化できる範囲を超えて一緒に働くのが面倒になった場合、あなたは追放される」。(3) これ以上具体的にしようとする試みは機能しない。それは厄介者が操作するための制御面を提供するだけだ、ということである。この主張は純粋な能力主義と結果主義に基づいている。唯一の評価尺度は、貢献者がもたらす技術的な価値と彼らが引き起こす社会的な摩擦との差引勘定である。つまり、これはプロジェクトのリーダーに対して最終的な判断を下すという絶対的な信頼を委ねるモデルと言える。

DHHの批判(https://x.com/dhh/status/1971454220726566998) は一見はESRの主張と同様に強い意見に見えるが、よりバランスが取れた主張である。彼はContributor Covenantを「トロイの木馬」と呼び、その代替として「MatzがRubyのために導入した美しい代替案」を賞賛しているのである。DHHが「美しい」と評するRubyの公式CoCは非常にシンプルであり、以下の四つの基本原則から構成されている。

  • 反対意見に対して寛容であること。
  • 個人の攻撃や中傷的な発言をしないこと。
  • 他者の言動を解釈する際は、常に善意を前提とすること。
  • ハラスメントと合理的に見なされる行為は容認されないこと。

このRubyのCoCが効果的である理由は、その記述内容もさることながら、むしろ「何が書かれていないか」にあるだろう。ここには保護されるべき属性の長いリスト、段階的な執行プロセスの詳細な規定、法的な専門用語等といった類のものは一切ない。つまり、Ruby CoCは法律の条文ではなく、原則の表明なのである。このRuby CoCのアプローチは、参加者が善意を持った大人であることを信頼し、明確な不正行為(ハラスメントや個人攻撃)にのみ介入するというコミュニティに対する高い信頼に基づいている

Contributor Covenantのような厳格なCoCは、政治的な目的で「武器化」されたり、法廷闘争のように扱われたりする可能性がある。例えば「政治的攻撃」のような曖昧な用語は大きな解釈の余地を生み、そこが脆弱性を生むことになる。また、公式な委員会、調査プロセス、詳細な記録保持を前提とした執行はコミュニティへ望まぬ負担をかけるだろう。これに対し、Ruby CoCは、何が違反にあたるかの判断はコミュニティの合意に大きく依存し、官僚的なプロセスなしで既存のプロジェクトリーダーシップに依存することになる。

Rubyの日本国外のコミュニティではMINASWAN(Matz is nice and so we are nice.:Matzは優しい、だから私たちも優しくあろう)という精神が掲げられることがあるが、これは開発者とコミュニティの相互の幸福のために加者同士が思いやりと尊厳を持って接することを求めているのだろう。細かい条項や政治的理念をわざわざ明文化しなくとも、運用が容易でありながら、他者を尊重する文化の形成には参加者が共有できる理念を掲げるだけで十分に機能するのである。

さいごに

本稿で詳述してきたように、DebianとUbuntuの歴史が示す通り、大規模な共同作業において、基本的な行動規範が必要であることは当然だとは思う。しかし、その後のCoCの進化は、本来の目的を見失い、オープンソースコミュニティに新たな問題をもたらした側面もあるだろう。

Contributor CovenantのようなCoCの普及はある意味で歴史の必然だったのかもしれないが、振り子が一方の極端からもう一方の極端へと振れすぎたのではないだろうか?Contributor Covenantに代表されるような、汎用的で重量級のフレームワークの広範な採用は、官僚的な運用コストの増大、Rustの事例に見られるようなガバナンスの危機、そして企業や特定利益集団による乗っ取りへの脆弱性といった深刻な病理を生み出したとも言えるだろう。これらのフレームワークは、参加者に対する低い信頼を前提として設計されており、オープンソースの生命線である、時には辛辣でさえある活発な技術的議論を萎縮させる危険性をはらんでいる。

今求められているのは、全サイズ共通のフリーサイズなテンプレートを思考停止で導入することではなく、個々のプロジェクトの規模、文化、目的に合わせた「身の丈サイズ」のアプローチである。Linuxカーネルのような世界中の開発者と大企業が参加する巨大プロジェクトの真似をしても仕方がなく、おそらく、多くのプロジェクトにとって理想的なCoCのモデルとしてはRuby CoCが挙げられるだろう。短くて分かりやすく、原則に基づいており、ハラスメントや個人攻撃といった明白な不正行為の禁止に焦点を当てつつ、技術的な意見の対立についてはコミュニティの自浄作用を信頼する。このバランスこそが、多くのプロジェクトにとって最適解である。前時代的と思われるかもしれないが、結局はこれが最もロバストな規範なのである。

オープンソース・プロジェクトはCoCに関する自律性を取り戻すべきだ。CoCは、ソフトウェアを構築するというコミュニティの中核機能を守るためのシンプルな「盾」であるべきであり、コミュニティ自身に向けられかねない複雑な「武器」であってはならない。大多数のオープンソース・プロジェクトにとって、ほんの数行で収まる程度のCoCは、単に十分であるだけでなく、むしろ優れている。何故なら長くなればなるほど、そのコミュニティにとってそれが必要なことが起きた過去があるからである。

契約としてのオープンソース・ライセンスの歴史と現実に迫る違反リスク :契約×著作権の二層執行の時代へ

米国においてオープンソース・ライセンスが契約ではなく「著作権の一方的な許諾」であると長らく見做され、Jacobsen v. Katzerの訴訟でその効力が法的にも認められるようになった流れは前回の記事で解説したが、一方でこの訴訟の判決はオープンソース・ライセンスが法的に強制力のある契約として認知されるまでの道のりの一歩でもあった。 

今回は4つの訴訟での判示からこの長い道のりの過程を詳細に示しつつ、ライセンスが強制力のある契約として確立することで、国境を越えたライセンス違反リスクにどのような影響が生じているのかを日本企業、そしてコミュニティへの影響を含めて解説していく。

English version: https://shujisado.org/2025/09/17/from-permission-to-contract-dual-enforcement-and-rising-risk-in-open-source-licensing/

  1. 1. オープンソース・ライセンスの一方的許諾から契約への歴史的変遷
    1. Jacobsen v. Katzer (2008年):ライセンス違反が著作権侵害として確立
    2. MDY v. Blizzard (2011年):著作権侵害と契約違反の範囲を確立
    3. Artifex v. Hancom (2017年):ライセンスの契約性と金銭的救済手法を裁判所が明確に許容
    4. SFC v. Vizio (2022–2025年継続中):第三者受益者にまで法執行が拡大するか?
  2. 2. ライセンス違反リスクへの影響
    1. 商用ライセンスとのデュアル戦略のソフトウェア利用のリスク
    2. 海外の権利者から現地で訴追されるリスク
    3. 国境を越えてエンドユーザーから訴追されるリスク
  3. 3. 自由のコミュニティへ向けて
  4. 4. まとめ
  5. 5. リンク

1. オープンソース・ライセンスの一方的許諾から契約への歴史的変遷

オープンソース・ライセンスの法的性質を巡る議論は、長らく「一方的な許諾(unilateral permission)」であるという見解が根強くあった。英米法の契約法においては「対価(consideration)」の要件が存在し、契約が法的に有効であると認められるために当事者間で価値のある何かが交換される必要があるとされていたからである。よって、オープンソースであるソフトウェアは一般的に金銭的な対価無しで提供されるため、ライセンスが法的に強制力のある契約としての要件を満たしていないと解釈されてきた。このため、ライセンスは著作権者が自身の権利行使を一定の条件下で許諾するという一方的な宣言に過ぎないとする「許諾説」が支持されていたのである。  

しかし、2000年代後半からの一連の画期的な訴訟を通じてこの解釈は大きく変化したと考えて良いだろう。幾つかの訴訟によって、オープンソースのライセンスが単なる許諾に留まらず、著作権法と契約法の両方によって強制され得る二重の法的構造を持つことが判例として積み重ねられていったのである。すなわち、ライセンス違反という行為に対し、著作権者が定める利用の条件(condition)を逸脱することによる「著作権侵害」と当事者間の合意である約定(covenant)に違反することによる「契約違反」という二つの異なる法的根拠に基づいて追及され得ることが確立されたとも言える。

本章では、これら4つの訴訟を時系列に沿って解説し、オープンソースのライセンスが「許諾」から「契約」へとその法的地位を進化することになった過程を解説する。

Jacobsen v. Katzer (2008年):ライセンス違反が著作権侵害として確立

オープンソース・ライセンスの法的強制力を確立する上で、最も重要かつ最初の大きな一歩となったのが、2008年のJacobsen v. Katzerにおける連邦巡回区控訴裁判所の判決である。この判決以前、オープンソース・ライセンスの違反が法的にどのような結果をもたらすかは不透明な領域にあった。

まず本件の背景を説明すると、原告であるRobert Jacobsenは、Javaで書かれた鉄道模型の制御用ソフトウェアを開発し、Artistic Licenseの下で公開していた。Artistic Licenseはソフトウェアの改変や再頒布を許可する一方、原著作者の表示や改変箇所の明記といった条件の遵守を求めているが、被告であるMatthew Katzerは自身の事業での製品にその制御用ソフトウェアを組み込んだにも関わらず、Artistic Licenseが規定する表示義務を遵守しなかった。これに対して、Jacobsenが著作権侵害を理由として差止請求を求めて提訴したのである。

裁判所の判断:

第一審においてカリフォルニア北部地区連邦地方裁判所は、Artistic Licenseに対しての条項違反をライセンスの範囲を定める「条件」への違反ではなく、単なる契約上の約束事である「約定」の違反に過ぎないと判断した。著作権侵害が認められれば回復不能な損害が推定され、差止命令が認められやすいのに対し、約定違反ではそのような推定は働かないために差止請求は棄却された。この判断は、オープンソースのライセンスが持つ強制力を著しく弱めるとして一時は大きな懸念を呼んだ。

しかし、連邦巡回区控訴裁判所はこの地裁判決を覆し、Artistic Licenseの条項が単なる約定ではなく、著作権の許諾範囲そのものを確定させる「条件」であると明確に判示した。つまり、これらの条件を遵守しないソフトウェアの利用はライセンスの範囲を逸脱した無許諾の利用となり、著作権侵害を構成すると結論付けたのである。

この判断は、オープンソースの経済的価値に対して理解が進みつつあった当時の状況も寄与したのであろうと思う。控訴裁は、オープンソースのライセンスにおける「対価」が金銭である必要はないと指摘し、金銭的対価の代替として帰属表示、コミュニティからのフィードバック、市場シェアの拡大、名声の向上といった実質的な経済的利益を得ており、ライセンス表示義務のような条件はこれらの経済的利益を確保するために不可欠であり、著作権法によって保護されるべき正当な利益であると認定されたわけである。つまり、オープンソースのビジネスモデルそのものに法的なお墨付きを与えたとも言えるのだろう。

判決の意義:

今日のオープンソース・コンプライアンスを語る上でこのJacobsen v. Katzer判決の意義は計り知れないものがある。第一に、オープンソース・ライセンスへの違反が著作権侵害となり得ることを明確に確立し、ライセンスに法的な根拠を与えたことは大きい。これにより、オープンソース開発者は違反者に対して差止請求という強力な救済手段を行使できるようになったわけであり、これは同時に公開したソースコードの利用方法に法的な統制を及ぼしたいと考えるコピーレフト型ライセンスの根幹を支える法的基盤となったとも言える。

また、この判決はライセンスの法的性質に関する議論を新たな段階へと進めたとも言えるのだろう。ライセンス違反が著作権侵害であると確立されたことで、ライセンスが持つ契約としての側面にも注目されるようになり始めたわけである。この判決を起点として、オープンソース・ライセンスが「条件付きの許諾」と「契約」の二重の性質を持つという今日の複雑で精緻な理解へと進んでいく一歩になったのだろう。

MDY v. Blizzard (2011年):著作権侵害と契約違反の範囲を確立

Jacobsen判決によってオープンソースのライセンス違反が著作権侵害として確立された一方、あらゆるライセンス条項への違反が即座に著作権侵害となるわけではないという重要な境界線を画定したのが、2011年のMDY Industries, LLC v. Blizzard Entertainment, Inc.事件における第九巡回区控訴裁判所の判決である。

この訴訟は、オンラインゲーム「World of Warcraft」を巡るものであり、被告のMDYはゲームを自動プレイするボットを販売していたのだが、原告のBlizzardはWoW利用規約においてボットの使用を明確に禁止していた。そこでBlizzardは、ボットの使用が利用規約違反であり、利用規約がソフトウェア利用許諾契約の一部であるために許諾範囲を逸脱した著作権侵害に当たると主張したのである。

裁判所の判断:

第九巡回区控訴裁判所は、原告であるBlizzardの主張を退けたのだが、その際にライセンス違反が著作権侵害を構成するための「ネクサス・テスト」という基準を提示した。そして、裁判所は「ライセンシーによる契約違反が著作権侵害を構成するためには、その違反した条件と著作権者が持つ排他的権利との間に「関連性(nexus)」が存在しなければならない」と判示したのである。 

米国の著作権法が著作権者に与える排他的権利とは、複製権、頒布権、二次的著作物作成権などであるが、ネクサス・テストは、違反されたライセンス条項が、これらの排他的権利の行使を直接的に制限または条件付けるものであるかどうかを問うものである。裁判所はWoW利用規約におけるボット禁止条項を検討し、この条項はゲームの公平性や体験を維持するための「ゲームのルール」に関するものであって、Blizzardが持つソフトウェアの複製権や頒布権といった著作権上の排他的権利とは直接的な関連性がないとこのテストによって判断した。よって、ボットの使用は利用規約という契約に対する違反(約定違反)ではあるものの、著作権侵害には当たらないと結論付けられたのである。

オープンソース界隈から見ると、この判決はJacobsen判決で示された「条件」と「約定」の区別をより具体的な判断基準によって精密化したものであると言える。例えば、GPLにおけるソースコード開示義務やArtistic Licenseにおける表示義務への違反は、二次的著作物作成権や頒布権などの著作権者の排他的権利に直接関連する条件違反となり、著作権侵害を構成すると言える。一方、特定の目的での使用禁止条項や本件のようなゲーム内での不正行為の禁止などは著作権者の排他的権利とは直接関連しないため、契約への違反となるということである。なお、本件ではDMCA §1201の成立も確認され、契約・著作権以外の執行ルートがあることも示されている。

判決の意義:

このMDY判決はオープンソースに直接的に関わる訴訟ではないものの、オープンソース・ライセンスが持つ契約としての側面を意図せずして強化する結果となったのではないかと考える。ライセンス違反の一部を「著作権侵害ではないが、契約違反ではある」と明確に切り分けたことで、契約法理に基づく権利行使が、著作権法とは独立した有効な法的手段であることが司法的に裏付けられたわけである。Jacobsen判決が著作権侵害という強力な武器を確立したとすれば、MDY判決はその武器が使える範囲を限定する一方で、契約違反というもう一つの武器の存在を明確に浮かび上がらせたのである。

この判決により、ライセンサーは違反された条項の性質に応じ、著作権侵害に基づく差止請求と契約違反に基づく損害賠償請求を使い分けるか、若しくは併用するという二段構えの戦略を取る法的基盤が整った。この流れが、次のArtifex v. Hancom事件における判断へ直接つながっていくことになる。

Artifex v. Hancom (2017年):ライセンスの契約性と金銭的救済手法を裁判所が明確に許容

Jacobsen判決が「著作権侵害」となり得る道を開き、MDY判決が「著作権侵害」と「契約違反」を選別した後、オープンソース・ライセンスの契約としての側面を決定的に確立したのは2017年のArtifex Software, Inc. v. Hancom, Inc.訴訟である。先に書いてしまうと、ここでの裁判所の命令は、GNU General Public License(GPL)が法的に強制力のある「契約」として成立することを明確に認め、さらにその違反に対する金銭的な損害賠償の算定方法にまで踏み込んだ点で画期的であり、オープンソース・コンプライアンスにおける今日の実務で中核的参照点になっている。

まず訴訟の背景を説明すると、原告のArtifex Softwareは言わずと知れたGhostscriptの開発ベンダーであり、ArtifexはGPLと商用ライセンスのデュアルライセンス戦略でGhostscriptを販売・提供している。すなわち、Ghostscript利用者には無償で利用可能であるもののソースコード開示義務等が含まれるGPLの義務を遵守するか、もしくはArtifexから商用ライセンスを購入するという二つの選択肢があるわけであるが、被告である韓国のソフトウェア企業であるHancomは、商用ライセンスを購入せず、かつGPLが定めるソースコード開示義務も果たさないまま自社のオフィススイート製品にGhostscriptを組み込んで製品を頒布していたのである。この状況に対し、原告のArtifexは「著作権侵害」と「契約違反」の両方を理由に提訴した。

裁判所の判断:

被告であるHancomは、「GPLには署名しておらず、当事者間の明確な合意(mutual assent)がないため契約は成立していない」という主張を軸に反論し、オープンソース・ライセンスの契約性を根本から問う戦略で進めていたが、カリフォルニア北部地区連邦地方裁判所は、契約の成立は黙示的な同意で十分であるとし、Hancomの行動そのものがGPLへの同意の意思表示であると判断し、Hancomの主張を明確に退けた。そもそもGPLの条文にはソフトウェアを改変・頒布する場合、利用者はGPLの条件に受諾したものとみなされる旨が記載されているし、Hancomが商用ライセンスを購入せずにGhostscriptを利用しつつ、GPLの下でライセンスされている事実を公に表示していた事実からGPLという契約に同意していたと認定するのが妥当であると結論付けたのである。

この訴訟でさらに重要なのは、損害賠償に関する判断である。Hancomは、「GPLは無償ライセンスなのだから、たとえ違反があったとしてもArtifexに金銭的損害は発生しない」と主張したものの、裁判所は、GPL違反に対する損害額を算定する際にArtifexが提供している「商用ライセンスの料金」を合理的な基準として利用できると判示したのである。裁判所の論理としては、HancomにはGPLによる義務を回避するために商用ライセンスを購入するという選択肢があったにもかかわらず、それを選択せずにGPLによる恩恵として無償利用だけを享受したという点にある。従って、Artifexが失った利益とはHancomが支払うべきであった商用ライセンス料とも言え、損害額を算定する上での有効な指標となり得ると結論付けたのである。

判示の意義:

このArtifex訴訟は2017年9月12日の地裁命令後に両社の和解となったために最終的な判決には至らなかったものの、地裁命令における判示はその後のオープンソース・コンプライアンスのリスク評価の構造転換を現実のものにした。

まず、GPLのような主要なオープンソース・ライセンスが、署名がなくとも法的に有効な「契約」であることを米国の裁判所が明確に認めた最初の事例の一つとなった。これにより、オープンソース・ライセンス違反は著作権侵害だけでなく、契約違反としても追及できるという二重の法的構造が司法の場で確固たるものとなったわけである。契約法理に基づいた場合、著作権法とは異なる時効や適用法若しくは救済措置の可能性を開くなど、権利者にとっての法的な選択肢を大幅に広げることになった。

さらに、本件で最も画期的であったことは、損害賠償スキームが地裁命令で許容された点であるのだろう。「無償」で提供するライセンス違反から「有償」の損害が生じるのか?という難問に対して、デュアルライセンスモデルにおける商用ライセンス料を損害算定の有力な参照値として用いることを、地裁命令が明確に許容したのである。これによって、オープンソース・ライセンスの違反リスクは、それまでの差止命令による製品出荷停止といった「事業継続リスク」という抽象的なものから、高額な損害賠償金が生じる可能性がある「金銭的リスク」という企業としてより高リスクなものへと大きく前進したと言えるだろう。

この訴訟の判示は、デュアルライセンス戦略を採用するソフトウェア開発企業にとって自社のビジネスモデルが強力な法的執行ツールにもなり得ることを示したと言え、ライセンス違反者に対して自社の商用ライセンス価格そのものが損害賠償請求額の基準となることで、よりライセンス遵守を促すための強力な経済的インセンティブが生まれたのである。逆に利用者側にとっては、安易なGPL系ソフトウェアの利用が、意図せずして高額なライセンス料に相当する損害賠償責任を負うリスクを孕むことになった。

SFC v. Vizio (2022–2025年継続中):第三者受益者にまで法執行が拡大するか?

これまでの三つの訴訟が、ライセンスの「執行可能性(Jacobsen)」、その「範囲(MDY)」、そして「契約性と金銭的救済(Artifex)」を確立してきたのに対し、現在も進行中のSoftware Freedom Conservancy, Inc. v. Vizio, Inc.訴訟は、ライセンスを執行できる「主体」は誰かという我々のオープンソース・コミュニティとして未知の領域への問いを投げかけている。

本件の背景を説明すると、原告であるSoftware Freedom Conservancy(SFC)は言わずと知れた自由ソフトウェアを推進する非営利団体であり、被告のVizioはスマートテレビの製造及び販売大手企業である。Vizioのスマートテレビには、LinuxカーネルをはじめとするGPLv2やLGPLv2.1といったコピーレフト型のライセンスの下で提供される多数のオープンソース・ソフトウェアが組み込まれており、それらのライセンスが著作物の改変物である製品を頒布する者に対し、利用者の要求に応じて完全な対応ソースコードを提供することを義務付けているもののVizioはその義務の履行を怠っているとしてSFCは契約違反を主張しているのである。

勘の良い方は気付いているだろうが、この訴訟の最大の特徴は、原告であるSFCがVizioのテレビに搭載されているソフトウェアの著作権者ではないという点にある。通常、著作権侵害等の訴訟はライセンサーとライセンシーとの当事者間で争われるものであるが、SFCはVizioのテレビを一般消費者として購入した「エンドユーザー」の立場でVizioによる契約違反を主張しているのである。SFCの法的論拠は、GPLという契約は契約当事者であるライセンサーとライセンシーだけでなく、そのソフトウェアを受け取る全てのエンドユーザーに利益を与えることを意図して作られたものであり、したがってエンドユーザーは契約の「第三者受益者」としてソースコード提供という契約上の利益を直接Vizioに要求する権利を持つ、というものである。

この訴訟は、オープンソース・ライセンスの権利行使者が、著作権者だけでなく「第三者受益者」にまで広がる可能性を示唆しており、良くも悪くもその帰結はオープンソースのエコシステム全体を揺るがしかねないだろう。

裁判所の判断:

この訴訟は非常に興味深い展開を辿っている。当初はSFCが州裁判所へ提訴したもののVizioの申し立てにより連邦地裁に一度引き上げられ、そして連邦地裁が州裁判所への差戻しを命じるという展開を辿り、その後はオレンジ郡上級裁判所で進行しているのである。

Vizioとしては、SFCによる契約違反からの請求は実質的に著作権法上の救済に等しく、連邦法が州法請求を呑み込むので連邦裁判所の管轄になるという論理で連邦著作権法を戦場を移動させる戦略であった。当然ながら連邦著作権法の救済ということになれば、ソースコード請求への論拠を弱体化もしくは潰せると考えられる。しかし、連邦地裁は、SFCがGPLという契約における「ソースコード提供」義務の履行を第三者受益者として求めており、それは著作権による専有権と同等の権利を主張するものではなく、著作権による権利とは別物だと明確に述べて結局は州裁判所へ差し戻したのである。この一連の経緯は奇しくもArtifex訴訟におけるGPLの契約性論理を強化することになったと言えるだろう。

なお、本件は現在も係争中であって審理は2025年10月からの予定になっており、したがって最終的な判決は下されていないのだが、実は訴訟の行方を占う上で極めて重要な中間的判断が既に出されている。

VizioはSFCが著作権者ではないため訴訟を起こす資格がないとして訴えの棄却を求めていたのだが、州裁判所はSFCの第三者受益者としての主張が法的に成り立ち得るものであるとして、そのVizioの申し立てを棄却したのである。裁判官は、「GPLの目的を達成するためには、SFCのような第三者がソースコード提供を強制する権利を持つことが不可欠かもしれない」と示唆しており、その理由として、遠隔地も含む個々の著作権者が世界中の全てのライセンス違反を追跡し、訴訟を起こす経済的インセンティブやリソースを持つことは稀であり、ソフトウェアを利用するエンドユーザーに執行権を認めなければ、GPLのソースコード開示義務が形骸化してしまう可能性がある点を指摘しているのである。

判示の意義:

この訴訟が最終的にSFCの勝訴で終わった場合、オープンソース・ライセンスの執行モデルを根本的に変革することになりその影響は計り知れないだろう。

従来、ライセンス執行は著作権者という主体によって行われ、よって企業が法的リスクを評価する際に訴訟を起こしてくる可能性があるとして想定するのはFSF(Free Software Foundation)や特定の開発ベンダー等のごく限られた主体でしかなかった。しかし、SFCが主張する第三者受益者の理論が認められればライセンス執行の主体は製品を購入した全ての消費者、製品を分析する研究者、権利擁護団体、さらには競合他社までもが潜在的な原告となり得るのである。原告となり得る数も、たった数人から数百万単位まで爆発的に増加する可能性もある。

これは、企業にとってのコンプライアンス・リスクの性質が、特定の既知の主体からの訴訟リスクから「不特定多数の未知の主体からの予測不能な集団訴訟リスク」へと変貌することを意味するわけであり、訴訟の動機も金銭的利益、修理する権利の確保、透明性向上や自由の追求といったイデオロギー的なものまで多様化すると考えられる。

SFC v. Vizio訴訟がどのような帰結を迎えるかはまだ判然としないが、企業がオープンソースとどう向き合うべきか、その戦略の根本的な見直しを迫るものとなる可能性が高いだろう。

2. ライセンス違反リスクへの影響

Jacobsen判決からSFC v. Vizio訴訟に至る一連の訴訟における法解釈は、オープンソース・ライセンスが著作権法に基づく「条件付きの許諾」と契約法に基づく「双務的合意」という二つの顔を持つことを確立したと言える。この二重の法的構造は、ライセンス違反がもたらすリスクを質と量の両面で劇的に増大させた。

かつてのライセンス違反のリスク評価は、基本的に著作権侵害の法理に基づいており、最大のリスクはJacobsen判決で示されたような著作権侵害を理由とする「差止請求」であった。これは製品の製造・販売・配布が差し止められることを意味するわけであり、企業にとっては「事業継続リスク」を意味するものであったが、直接的な金銭的損失に結びつくものではなかったのである。しかし、Artifex判示以降、契約法理による救済が強力な選択肢として加わったことで、利用者である企業にとっては以下の三つの側面から複合的かつ重大なリスクとなっていると考えられる。

  • 事業停止リスク+損害賠償リスクの顕在化:従来からの使用の差止請求のリスクに加え、契約違反を根拠とする直接的な金銭賠償のリスクが現実のものとなった。特にデュアルライセンスの場合、その額は高額な商用ライセンス料に相当する可能性がある。
  • 原告側の法的戦術の多様化:原告側は、違反の性質に応じて著作権侵害と契約違反のいずれか、あるいは両方を主張できるようになった。特に米国では原則として著作権局の著作権登録証発行後でなければ侵害訴訟を提起できないが、契約ルートではこの前提に縛られにくい。これもあって、より法廷での戦術が多様化した。
  • 潜在的原告の爆発的増加:進行中のSFC v. Vizio訴訟が示すように、ライセンス執行の主体が著作権者だけでなくエンドユーザーへと拡大する可能性が浮上している。これにより、訴訟を提起し得る主体が世界中に散らばる不特定多数となり、リスクの予測と管理が困難になる可能性がある。

以下の本章では、これらのリスクが具体的にどのような形で企業、特にグローバル市場で事業を展開するような日本企業に影響を及ぼすのかを掘り下げていく。

商用ライセンスとのデュアル戦略のソフトウェア利用のリスク

デュアルライセンス戦略は、オープンソース開発ベンダーにとって持続可能なビジネスモデルを構築するための一般的な手法であるが、Artifex v. Hancom訴訟の地裁命令以降、この戦略はライセンス違反者に対して強力な経済的制裁を科すための法的ツールとしての側面も持つようになった。何故なら、この訴訟の地裁命令が、GPLのようなコピーレフト型ライセンスの違反に対する損害賠償額を対応する商用ライセンスの料金に基づいて算定できることを示したからである。

この理論は、米国だけに特有のローカルな考え方ではない。2024年2月にフランスのパリ控訴裁判所が下したEntr’ouvert v. Orange事件の判決は、このリスクが国境を越えて普遍的なものであることを明確に示したと言える。原告のEntr’ouvertはLassoという認証ライブラリをGPLと商用ライセンスのデュアルライセンスで提供していたが、大手通信事業者であるOrangeはポータルサイト開発においてLassoを利用したがGPLの義務を遵守せず、商用ライセンスも購入しなかった。これに対し、パリ控訴裁判所はOrangeに対して著作権侵害とライセンス違反を認定し、損害賠償金として500,000ユーロ、精神的損害として150,000ユーロ、不当利得の吐出として150,000ユーロ、費用等として60,000ユーロの支払いを命じたのである。

この判決で特に注目すべきは損害賠償額の算定根拠であり、過去にOrangeに対して提示されていたLassoの商用ライセンスの価格とほぼ同額が損害賠償金として命じられたのである。これは、Artifex訴訟での判示と同様の論理、すなわち「違反者が本来支払うべきだった商用ライセンス料が権利者が被った損害の基準となる」という考え方が、米国のコモンロー圏だけでなく、フランスのような大陸法圏の司法判断においても採用されたことを示しているのである。

これは、日本企業にとっても極めて重要な示唆を与えたと言える。近年では日本国内のソフトウェア開発においても様々なデュアルライセンスのオープンソース製品が利用されているが、意図的か否かにかかわらずGPLによる義務を遵守しなかった場合、オープンソース製品のベンダーから商用ライセンス料を基準とした損害賠償請求訴訟を提起される可能性が高まったと言えるだろう。

日本法にある程度の知識がある方であれば、そもそも日本においては著作権侵害ルートをとっても商用ライセンス価格や相場ロイヤルティを参考にする発想は著作権法の枠組みに合致すると言えるだろうし、当初からGPLのようなオープンソース・ライセンスを契約として捉える見方が優勢であったので契約違反ルートでも損害を主張しやすいだろうから、米国とフランスでの訴訟は単に最初から予測されていたことの先例ができただけと考えるかもしれない。しかし、同時に従来の多くの日本企業では「無償のソフトウェアだから金銭的損害はない」という安易な想定をしがちであったわけであり、もはやそのような考え方は通用しないということが米国と欧州の実例からさらに説得力を持ったと言えるのだろう。

ともかく、コンプライアンス違反のコストはもはや抽象的な事業リスクではなく、具体的な金銭的リスクへと変貌していることを多くの日本企業は意識する必要があるだろう。

海外の権利者から現地で訴追されるリスク

これまでの日本国内でのライセンス違反に関する訴訟リスク議論というものは、漠然と日本法による日本国内での訴訟を念頭に置かれることが多かったように思う。しかし、Source Availableライセンス適用のツールを含めて、現代の重要なオープンソース・ソフトウェアの権利者は米国の企業か組織であることがほとんどであり、Artifex v. Hancomでの判示が確立した米国での契約論ベースで考えれば、それらの米国企業が米国の所在地の州の裁判所にて契約法を根拠として日本企業に対して訴訟を提起することが十分にあり得る。いや、あり得るではなく、現実にArtifex v. Hancomで被告となったHancomは韓国の企業であり、米国内での販売・頒布・サポート等の行為があったことで地裁の個別管轄が通ったのである。GPL違反=契約違反として捉えることによって「米国著作権法は原則として域外行為に及ばない」という域外行為に対する壁が乗り越えやすくなっていると言えるだろう。

従来の米国における一方的な許諾論に依拠すれば法的根拠は著作権法となり、著作権の問題であれば侵害行為に対しての適用法はその行為が行われた現地の法となる。つまり、日本で行われた侵害に関しては日本国内で訴訟を提起するのが原則である。しかし、ライセンスが契約でもあるということで契約法に依拠すれば、多くの米国企業は自らの所在地の州の裁判所で訴訟を提起することができるわけであり、域外の被告となった企業には不利な状況で戦うことになる。ごく一部には国外からの訴訟提起は無視すれば良いという乱暴な考え方があるかもしれないが、ハーグ送達条約に日本も加盟している以上は条約加盟国からの訴状は結局届くことになり、裁判に出廷しなければそのまま原告の主張通りに判決が出される可能性が高い。

なお、日本国内での訴訟であれば損害賠償に懲罰的な金額が加算されることはなく、逸失利益等を考慮しても商用ライセンス料相当額から大きく超える損害賠償が命じられるケースは考えにくいが、特に米国での訴訟となった場合、不法行為や州の不公正取引法等の併合を含めた場合や故意・悪質性が考慮された場合には特定法の適用(例:州消費者保護法、Lanham Act、RICO等)がある場合に限られるものの懲罰や倍額の加算も念の為に考慮が必要だろうし、弁護士費用付与、契約債務不履行による遅延利息が刺さり、日本では考えにくい高額の損害賠償金が命じられるリスクが生じる可能性もあるだろう。

よって、海外の権利者のオープンソースのツール、特に商用ライセンスも存在するような製品を利用する場合には、ライセンス違反時には最悪のケースとして権利者の所在地の裁判所で提訴される可能性があり、そうなった場合には高額の損害賠償金が発生し得る現地の法で戦う必要があることも意識する必要もあるのだろう。

国境を越えてエンドユーザーから訴追されるリスク

オープンソース・コンプライアンスにおけるリスクの最終地点は、訴訟主体が不特定多数のエンドユーザーにまで拡大することではなかろうか? Artifex v. Hancom判示が確立した「ライセンス=契約」という法的地位と、SFC v. Vizio訴訟で現在進行形で争われている「エンドユーザー=第三者受益者」という理論が組み合わさった場合、米国の権利者のオープンソースのソフトウェアを多く利用し、米国市場においても製品やサービスの提供を行う多くの日本企業にとって、これまでにない規模と性質の訴訟リスクが出現することになる。

例えば、ある日本の自動車メーカーの車載インフォテインメント・システムにあるGPLと商用ライセンスのデュアルで提供されるツールを搭載した新型車を米国で販売すると仮定する。Artifex判示の論理によれば、このメーカーは自動車を米国の消費者に販売(頒布)した時点で、ツールの開発ベンダーとの間でGPLという契約を締結したとみなされる。契約の条件には、要求に応じてシステムの完全な対応ソースコードを提供する義務が含まれるからである。そして、ある消費者がこの新型車を購入し、車載システムを独自にカスタマイズしたいと考え、メーカーにGPLに基づいてソースコードの提供を要求する。しかし、何らかの理由で要求は無視されるか、不完全なコードしか提供されなかったとしたらどうなるか? SFC v. Vizio訴訟でSFCが勝訴した場合、この消費者個人はGPL契約の「第三者受益者」として、ソースコードの提供を求めて日本の自動車メーカーを米国の裁判所に提訴する法的権利(当事者適格)を持つことになるのである。

このシナリオは、二つの判例が作り出すリスクの相乗効果であり、日本企業にとってのリスクを複数の側面から劇的に高めると言えるだろう。

  • リスクの「現地化」:従来、GPL違反で訴訟を懸念すべき相手は、Linuxカーネルの開発者コミュニティやFSF等の特定の団体が中心であった。これらの主体が日本の企業を米国の裁判所で訴えるには、相応の障壁があった。しかし、Artifex判示の論理に加えて、Vizioの法理が確立されれば、原告は製品が販売されている米国内のどこにでも存在する「現地の消費者」となる。訴訟は現地の裁判所で、現地の法律に基づいて行われるため、地理的・法的な障壁は一気に取り払われることになる。
  • リスクの「大衆化」:訴訟を起こし得る主体が、少数の専門家集団から製品を購入した不特定多数の一般大衆へと拡大することになる。原告となり得るのは、SFCのような権利擁護団体、個人開発者、ヘビーユーザー、さらには「修理する権利」を主張する活動家等、動機も背景も様々となる。これによって、企業は予測不能なタイミングで予測不能な相手から訴えられる可能性に常に晒されることになる。
  • リスクの「非対称性」:原告側は金銭的な利益から自由理念の追求やその企業のコンプライアンス体制の是正といったイデオロギー的なものまで多様化する可能性がある。少額の和解金で解決することが難しく、企業側は原則的な対応を迫られる可能性がある他、企業側が敗訴した場合のダメージは訴訟費用からブランドイメージの毀損まで多岐に渡ることになる。

このように、Artifex判示とSFC v. Vizio訴訟の流れが合流する地点には、多くのオープンソースの利用者側となる日本企業にとっての非常に厳しい訴訟環境が形成されつつある。オープンソースの利用においては、特に米国法における法的リスクを管理する高度なガバナンスを要求する状況となっているのである。

3. 自由のコミュニティへ向けて

前節まではオープンソースの利用者である企業側から見た視点でのリスクを解説してきたが、これは元来のコミュニティからの視点ではどうなのだろうか?

Jacobsen v. Katzerは、オープンソース・ライセンスの帰属表示等の条件を著作権上の可罰的条件として認め、その違反は著作権侵害になり得るとした。そして、Artifex v. HancomはGPLを契約としても執行可能とし、SFC v. Vizioによって著作権者本人でない主体が第三者受益者としてソース開示等を迫れる可能性が見えてきている。このような状況は我々の自由を追求するコミュニティの一部が求め続けていたものであり、ライセンスを遵守しないと法的リスクがあるという強制性が働くことはオープンソースのエコシステム維持には一定の福音であるのかもしれない。

しかし、現在の状況は何かが損なわれ得る可能性も秘めている。

法執行の手段を獲得したからといって何でも即座に訴訟で解決するというのは我々のコミュニティにとって良い影響を与えるとは思わない。第三者受益者を過度に広げ過ぎた場合、誰もが私的検察官化し、恣意的な要求や合意なき係争を招くことになり、これが過度になるとオープンソースの採用回避や過度な法務コストによるコミュニティへの貢献の忌避が発生しかねないだろう。であるので、ライセンス違反の解決はなるべくコミュニティにおける柔軟な是正に頼るべきである。実際、FSFも「コミュニティ指向のGPL施行原則」において教育を重視すべきと明言しており、これは私も賛同する。

また、契約理論が強すぎると、著作権の射程外の行動規制(利用規約等)まで契約だからと正当化しがちとなり、これは「オープンソースの定義」における“無差別の自由”と緊張関係が生じる。これは、近年のAIモデルのライセンス領域で現実となっていることである。さらに、契約法に依拠した場合、グローバルでほぼ同一の考え方が通じる著作権とは異なり、契約や第三者受益の射程は法域差が非常に大きく、グローバルなオープンソース・プロジェクトの運用負担が増えることにもつながる。

ということで、我々のコミュニティにとって決して良いことばかりということではないことに留意してほしい。

さらにもう一点、本稿ではあくまで米国におけるオープンソース・ライセンスの契約性の確立とその影響について論じてきたのであるが、Artifex v. HancomはGPLを契約としても執行可能とした理論は多くの日本企業へのリスクとなっていることは確かであるものの、実はあるオープンソース以外の製品利用のリスクがGPL系よりも高まっていると考えている。SSPL(Server Side Public License)やBUSL(Business Source License)を適用するSource Availableと呼ばれるライセンスを採用する製品群を採用するリスクである。これらのライセンスを適用する製品は総じて商用ライセンスとのデュアル戦略であり、オープンソース企業とは異なりコミュニティの評判を気にする必要もない。業績が少し傾くだけで、訴訟戦略に打って出る動機が強くあるのである。

また、契約理論であれば、日本国内でよくある会社法に基づいた50%超での支配権でのグループ会社間での利用を内部利用とみなす考え方は、ニューヨーク州やカリフォルニア州など米国の多くの州法下では通用しない可能性が高い。このような適用法の差異をうまく突く形で多額の損害賠償金目的の米国での訴訟を提起される事案が出てくるのではないかと心配している。Source Availableはオープンソースではないので問題ないという考え方もできるだろうが、人々の中には我々のコミュニティに近い立場の企業が訴訟を起こしたと感じる人も多く発生するだろう。我々のコミュニティは、そのような時でも原理原則を守り、その時々で結束して適切な対処を続ける必要があるだろう。

4. まとめ

ここまで本稿で詳述してきたように、オープンソース・ライセンスの法的地位は過去20年足らずの間に劇的な進化を遂げた。かつては著作権者による「一方的な許諾」と見なされ、その法的強制力すら疑問視されていたライセンスは、米国における一連の画期的な司法判断を経て著作権法と契約法の両輪によって支えられる堅牢かつ二重の法的構造を持つに至ったのである。

Jacobsen v. Katzerは、ライセンス違反が著作権侵害を構成し得ることを確立し、オープンソース・ライセンスに差止請求という「法的な牙」を与えた最初のマイルストーンであった。MDY v. Blizzardは、著作権侵害と契約違反の境界を画定し、ライセンスの二重構造をより的確なものにした。Artifex v. Hancomは、GPLが強制力のある契約であることを認め、違反に対する損害賠償額を商用ライセンス料に基づいて算定できるという金銭的リスクの枠組みを構築した。そして、現在進行中の SFC v. Vizioは、ライセンスを執行する権利がエンドユーザーという「第三者受益者」にまで拡大する可能性を示唆し、コンプライアンス・リスクの主体を根本から変えようとしている。

これらの訴訟が積み重ねてきた法的解釈の結果、オープンソース・ライセンス違反のリスクはその性質を根本的に変容させ、複合的かつ多層的なものとなっていると言えるだろう。リスクの性質は製品の出荷停止を意味する事業継続リスクから、高額な賠償金支払いを意味する直接的な金銭的リスクへと重心を移し、リスクの主体は著作権者から、不特定多数のエンドユーザーへ拡散する可能性を秘めている。さらに、リスクの地理的な側面は、開発者と利用者の間の国内的な問題からグローバル市場で事業を展開する企業が海外の法廷で裁かれる国境を越えた問題へと拡大したと言えるだろう。

この新たなリスクの状況は、特にグローバルに製品やサービスを提供する日本企業にとって深刻な経営課題を突きつけている。オープンソース・コンプライアンスを、開発部門や法務部門の一部が担う技術的・法務的な問題として捉える時代は完全に終わっていると考えられ、今やオープンソースの利用と管理は全社的な戦略課題として位置づけられなければならないのだろう。オープンソースがもたらす技術革新の恩恵を享受し続けるためには、その裏側にある法的責任の重さを正しく理解する必要があるのである。

5. リンク

Wikipedia: Jacobsen v. Katzer
https://en.wikipedia.org/wiki/Jacobsen_v._Katzer

Jacobsen v. Katzer
https://wiki.creativecommons.org/images/9/98/Jacobson_v_katzer_fed_cir_ct_of_appeals_decision.pdf

Jacobsen v. Katzer: Failure of the Artistic License and Repercussions for Open Source
https://scholarship.law.unc.edu/cgi/viewcontent.cgi?article=1133&context=ncjolt

Wikipedia: MDY Industries, LLC v. Blizzard Entertainment, Inc.
https://en.wikipedia.org/wiki/MDY_Industries,_LLC_v._Blizzard_Entertainment,_Inc.

MDY Industries, LLC v. Blizzard Entertainment, Inc.
https://cdn.ca9.uscourts.gov/datastore/opinions/2011/02/17/09-15932.pdf

MDY INDUSTRIES LLC v.
https://caselaw.findlaw.com/court/us-9th-circuit/1555898.html

Artifex Software Inc. v. Hancom Inc.
https://www.govinfo.gov/app/details/USCOURTS-cand-3_16-cv-06982/USCOURTS-cand-3_16-cv-06982-2

Justia: Artifex Software, Inc. v. Hancom, Inc.
https://docs.justia.com/cases/federal/district-courts/california/candce/3%3A2016cv06982/305835/54

Linux.com: Artifex v. Hancom: Open Source is Now an Enforceable Contract
https://www.linux.com/topic/open-source/artifex-v-hancom-open-source-now-enforceable-contract/

Software Freedom Conservancy v. Vizio Inc.
https://sfconservancy.org/copyleft-compliance/vizio.html

Justia: Software Freedom Conservancy, Inc. v. Vizio, Inc. et al
https://docs.justia.com/cases/federal/district-courts/california/cacdce/8%3A2021cv01943/837808/30/

Free Software Foundation: The Principles of Community-Oriented GPL Enforcement
https://www.fsf.org/licensing/enforcement-principles

Grok 2.5がオープンソースではない理由とそのライセンスの問題点

2025年8月、イーロン・マスク率いるxAIがGrok 2.5のモデルウェイトをHugging Face上で公開した。報道では「オープンソース化」と表現され、マスク氏自身も「Grok 2.5モデルをオープンソースにした」とXに投稿している。しかし、しかしこの「オープンソース化」は、OSIが定義するオープンソースとはほど遠い。むしろプロプライエタリと言っても良いだろう。Grok 2.5にはGrok 2 Community License Agreementが付与されているが、さまざまな制約によるオープンソース性が否定されることの解説と幾つかの問題点を説明する。

なお、既にXやLinkedinでは解説済みのことだが、Xで書いても他の有力なAIの検索システムには取得されないのでここで改めて解説する。

ライセンスが課す「制約」と OSI の定義

Grok 2ライセンスの第2条では、「許可された利用」を定めており、モデルの利用を非商用・研究目的と商用の場合に分類している。そして、商用利用にはxAIのAcceptable Use Policy(AUP) を順守する場合のみ利用を認めると明記されており、これは利用目的に応じて条件を課していると言える。また、2条(b)では、公開されたモデルや派生物、生成物を用いて他の基盤モデルや汎用AIを学習・作成・改良することを禁止している。さらに、第3条では「Powered by xAI」という表示を目立つ形で義務付ける条件もある。

こうした条項は、OSIの「オープンソースの定義」(OSD)が求める基本原則に抵触する。OSDは、派生物を自由に作成・頒布できること(第3条)や商用利用を含むあらゆる分野への差別的な利用制限を設けないこと(第6条)を求めており、また、昨年にOSIが発表した「オープンソースAIの定義」(Open Source AI Definition 1.0: OSAID)では、AIシステムを自由に「使用・研究・改変・共有」する権利をあらゆる目的に対して保障することが必要とされている。xAIのライセンスはAUP順守義務や他モデルへの学習利用の禁止といった用途制限を課しているためこれらの要件を満たさず、よってオープンソースと称することはできない。

不明確な「商用閾値」とライセンスの矛盾

ここまではMeta Llamaと然程変わらないわけだが、Grok 2 Community Licenseには実は他にも不可解な点がある。

第7条をよく読むと、「許容される商用閾値を超えると直ちにライセンスが終了する」と記されているのである。それでいて、「商用閾値」が具体的に何を指すのかということは契約書内で全く定義されておらず、よって利用者側にはどこまでの利用が許容範囲なのか全く分からない。これはMeta社のLlamaライセンスが月間7億アクティブユーザーという明確な閾値を設けている点と対照的であり、利用者にとっては予測可能性が著しく低く、事業上の大きなリスクとなり得る。この文言を文字通り解釈すれば、xAIが事実上いつでも何らかの商用利用等を理由に任意にライセンスを取り消せる余地を残しているようにも受け取れ、何とも不可解である。

さらに、第4条では「出力に対して制限や義務は課さない」と宣言して生成物の利用・改変・共有は自由であるかのように読めるものの、第2条2(b)では前述の通り、出力や派生物を用いて他のAIモデルを学習・作成・改良することを禁止する条項が存在する。これは条項が相互に矛盾しているように見え、契約解釈の面でも不安が残る。

この矛盾は法的には「一般条項より具体的条項が優先する」という原則で解釈されるだろう。よって、商用閾値には大きな意味はないと考えられるし、第2条2(b)での他者AIモデルへの学習利用は禁止ということなのだろう。おそらく、Llama等の利用制限のあるライセンスを模倣しようとして失敗したのだと思うが、多くの利用者に公開するライセンスとしては不明瞭さが残ることは確かである。条文を再構成するか但書を追加するなどの工夫が必要であることは間違いない。

他社の動きと比較した意味づけ

同じく今月に、OpenAIがgpt‑oss‑120b/20b という推論モデルを公開し、モデルウェイトをApache 2.0 + USAGE_POLICYの形式で公開している。
そのUSAGE_POLICYに沿えば、現地の法における違法行為目的でモデルを利用すればUSAGE_POLICY違反となるのだが、これは目的による差別とは言い難いだろうし、そもそもライセンスそのものはApache 2.0というOSI承認ライセンスである。そのため多くの開発者がgpt‑ossはオープンソースに近いと評価している。

このようなタイミングで、xAIがLlamaライセンスに似た独自条項を備えたGrok 2 Community Licenseでモデル公開を行ったことには疑問が残る。Llamaライセンスほどの複雑な問題は生じないものの、商用閾値やAUP遵守など独自の制約は利用者にとって扱いづらさが増している側面もあるだろう。xAIが最新モデルの普及を目指すなら、コミュニティが受け入れやすい形にライセンスを見直す必要がある。

おわりに

まとめると、xAI が公表したGrok 2 Community License Agreementは、モデルの使い道や再利用に広範な制限を課しており、「オープンソースの定義」が求める自由には適合しない。とりわけ、AUP準拠義務や他モデルへの学習禁止は「用途に関する差別」を禁じたOSD第6条やOSAIDの「どのような目的でも使用可能」という条件に反している。また、定義されていない商用閾値や出力利用の矛盾もあり、ライセンス文面の品質にも大きな疑問が残る。

xAIには、長期的にコミュニティの信頼を得るため、より透明性の高いライセンス設計と実践的なドキュメンテーションが求められる。現在のライセンスはモデルが入手可能なだけのSource Available的なモデルに過ぎず、オープンソースとはとても呼ぶことはできない。より開かれたAI研究とイノベーションをxAIが望むのであれば、xAIは専門家の助言を得ながらライセンスを再設計するべきである。

リンク

Grok 2 Community License Agreement:
https://huggingface.co/xai-org/grok-2/blob/main/LICENSE

Grok 2 Community License Agreement

Grok 2 Community License Agreement
Last Updated:  August 23, 2025

1. Background and Definitions
By downloading, accessing, or using the Materials (as defined below) relating to Grok 2 provided by X.AI LLC (“xAI”), you (“Licensee” or “you”) agree to the terms of this agreement (“Agreement”). If you accept this Agreement for or on behalf of an entity, you represent that you have the authority to bind that entity. As used in this Agreement, “Materials” means the Grok 2 materials provided to you by xAI under this Agreement, consisting of: (1) one or more machine learning models (including architecture and parameters); and (2) related artifacts (including associated data, documentation, and software) that are provided to you hereunder.  

2. License Grant & Scope
a. Permitted Uses: xAI grants you a non-exclusive, worldwide, revocable license to use, reproduce, distribute, and modify the Materials:
	•	For non-commercial and research purposes; and
	•	For commercial use solely if you and your affiliates abide by all of the guardrails provided in xAI's Acceptable Use Policy (https://x.ai/legal/acceptable-use-policy), including 1. Comply with the law, 2. Do not harm people or property, and 3. Respect guardrails and don't mislead.
b. Restrictions:
	•	You may not use the Materials, derivatives, or outputs (including generated data) to train, create, or improve any foundational, large language, or general-purpose AI models, except for modifications or fine-tuning of Grok 2 permitted under and in accordance with the terms of this Agreement.
	•	No right to use xAI’s trademarks is granted, except as required for attribution (see below).

3. Distribution & Attribution
If you distribute the Materials, derivatives, or products/services incorporating them:
	•	Include this Agreement and a notice stating: “This product includes materials licensed under the xAI Community License. Copyright © 2025 xAI. All rights reserved.”
	•	Prominently display “Powered by xAI” in related materials or interfaces.

4. Ownership & Outputs
xAI retains all rights in the Materials. This Agreement does not impose any restrictions or obligations with respect to any use, modification, or sharing of any outputs generated by using the Materials. If you provide feedback, suggestions, or ideas, you grant xAI a perpetual, worldwide, irrevocable, royalty-free license to use and incorporate that feedback without restriction.

5. Acceptable Use
You are responsible for implementing appropriate safety measures, including filters and human oversight, suitable for your use case. You must comply with xAI’s Acceptable Use Policy (AUP), as well as all applicable laws. You may not use the Materials for illegal, harmful, or abusive activities.

6. Warranty Disclaimer & Limitation of Liability
THE MATERIALS ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, NONINFRINGEMENT, ACCURACY, OR THE ABSENCE OF LATENT OR OTHER DEFECTS OR ERRORS, WHETHER OR NOT DISCOVERABLE, ALL TO THE GREATEST EXTENT PERMISSIBLE UNDER APPLICABLE LAW.
YOU ARE SOLELY RESPONSIBLE FOR (1) CLEARING RIGHTS OF OTHER PERSONS THAT MAY APPLY TO THE MATERIALS OR ANY USE THEREOF, INCLUDING WITHOUT LIMITATION ANY PERSON'S COPYRIGHTS OR OTHER RIGHTS INCLUDED OR EMBODIED IN THE MATERIALS; (2) OBTAINING ANY NECESSARY CONSENTS, PERMISSIONS OR OTHER RIGHTS REQUIRED FOR ANY USE OF THE MATERIALS; OR (3) PERFORMING ANY DUE DILIGENCE OR UNDERTAKING ANY OTHER INVESTIGATIONS INTO THE MATERIALS OR ANYTHING INCORPORATED OR EMBODIED THEREIN.
IN NO EVENT SHALL XAI BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT, OR OTHERWISE, ARISING FROM, OUT OF, OR IN CONNECTION WITH THE MATERIALS, THE USE THEREOF, OR OTHER DEALINGS THEREIN. TO THE MAXIMUM EXTENT PERMITTED BY LAW, XAI WILL NOT BE LIABLE FOR ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, OR FOR AGGREGATE LIABILITY EXCEEDING $100, REGARDLESS OF THE LEGAL THEORY.

7. Termination
This license terminates immediately upon your breach or if you exceed the permitted commercial threshold. Upon termination, you must cease all use and delete all copies of the Materials and derivatives.
Additionally, if you file, maintain, or voluntarily participate in a lawsuit against any person or entity alleging that the Materials, or any part thereof, directly or indirectly infringe any patent, then your license under this Agreement shall immediately terminate. This does not apply to a lawsuit brought in response to a corresponding lawsuit first filed against you.

8. Governing Law
The laws of Texas govern this Agreement, and any dispute shall be resolved exclusively in the courts located in Tarrant County, Texas.

9. Miscellaneous
This Agreement is the entire agreement between the parties on this subject. Failure to enforce any provision is not a waiver. If any provision is unenforceable, the remainder remains in effect. xAI may assign this Agreement, including in connection with a merger or acquisition. Licensee may not assign this Agreement without xAI’s prior written consent. This Agreement creates no third-party beneficiaries. You must comply with all applicable export control, trade compliance, and sanctions laws.

一方的許諾としてのオープンソース・ライセンスの概念はどこから来たのか?

日本ではオープンソースライセンスをライセンス契約として見做すことが一般的な見解であり、これはEUでも同様である。しかし、オープンソースのあらゆる側面においての原点である米国では、オープンソースライセンスは契約ではなく「著作権の一方的な許諾」であると長らく見做されている。現在では幾つかの訴訟による判例を踏まえ、一方的な許諾だけでなく契約としての側面も併せ持つという考え方が米国でも主流になっているが、特に開発者コミュニティにおける実務上は従来の一方的な許諾としての側面をまず教えることが多い。これは、そもそものオープンソースの歴史的な成り立ちや著作権の仕組みを学習するためには許諾説を取るほうがよりシンプルで分かりやすいからとも言えるし、ライセンス違反等の状況にならない限りは実務上の大きな差異が生じないからでもあるのだろう。

ともかく、現時点ではやはり一方的な許諾としてのライセンスの概念というものはオープンソースへの理解に重要だと考えられるのだが、そもそもこの米国法特有のライセンスというものはどこからやってきたのだろうか?

English version: https://shujisado.org/2025/07/24/why-uslaw-sees-opensource-as-permission-not-a-contract/

  1. ソフトウェア著作権の確立と自然発生したソフトウェアの一方的許諾の概念
    1. 連邦著作権法の「抜け穴」
    2. ハッカー文化によるライセンス概念の自然発生
    3. MITライセンス等の登場による慣習の形式化
    4. 判例による強化
  2. 日本法との違い
  3. まとめ
  4. リンク

ソフトウェア著作権の確立と自然発生したソフトウェアの一方的許諾の概念

米国発のこの「一方的な許諾」というライセンスの概念は、おそらく特定の誰かや組織が発明したという性質のものではないのだろう。米国連邦著作権法の構造、初期のコンピュータコミュニティの文化、そしてそれを追認した判例という三つの要素が絡み合って生まれたと自分は考えている。ある意味、極めて米国的と言える産物なのだろう。

連邦著作権法の「抜け穴」

全ての根源は、米国連邦著作権法の基本構造にある。同法第106条では、ソフトウェアの作者に複製、改変、頒布等に関する「排他的な権利」を与えることが規定されているが、これは「作者以外は許可なく何もしてはいけない」という状態がデフォルトであることを意味している。この排他的権利の利用の許可を与える伝統的な方法は「契約」であるが、英米法の契約には「申込みと承諾」や「対価」といった日本法等とは違った複雑な要件が伴う。しかし、ソフトウェア著作権が生まれた辺りの当時の開発者たちは、この法の構造の中に一種のハック可能な「抜け穴」を見出したわけである。

1976年米国著作権法では、権利の移転に関して下記のように「著作権の譲渡」とそうでないものを明確に区別している。

  • 著作権の譲渡: 第101条の定義により、独占ライセンス等が含まれ、第204条(a)項により権利者の署名がある書面が必須
  • 非独占ライセンス: 同条項において、著作権の「譲渡」には含まれないと明確に除外

この法律の条文を開発者的に都合よく解釈していくと、「譲渡ではない非独占ライセンスには書面は不要である」という結論が導き出される。つまり、著作権の非独占ライセンスは、口頭や当事者の行動から推測される「黙示」でも成立するという余地が生まれるわけである。これが契約という重い手続きを回避し、開発者が「この条件を遵守するのであればソフトウェアの自由な利用をして良い」と一方的に宣言することを可能にした極めて重要な法的根拠と言える。

ハッカー文化によるライセンス概念の自然発生

法が前節で説明したような構造を持っていたとしても、それを利用する文化がなければ意味がない。しかしながら、1960年代から70年代にかけてのMIT AIラボ等に代表される研究機関では、ソフトウェアは共有され、互いに改良し合うべき「知識」と見なされていた。これは私自身がその時代を経験しているわけではないが、リチャード・ストールマンの伝記やハッカー文化関連書籍等の様々な文書が当時の「ハッカー文化」というものを証明しているのだろう。

このハッカー文化における環境では、ソースコードの共有は当たり前であり、法的なものではなくコミュニティのルールやマナーというか村の掟に近い「ライセンス」の概念が機能していたのだろう。ソフトウェア著作権という存在が徐々に浸透していった1980年代前半にかけて、READMEファイルに書かれた「自由に使ってよい」「作者名は残せ」といった単なるお願いのメモが事実上のライセンスとして機能していたと考えられるが、それらは法的な拘束を意図したものではなく、「一方的な許諾」の精神そのものだったのだろう。

その実例として自分としては象徴的だと感じるのは、後にGNUを創始するリチャード・ストールマンが初期のEmacsエディタで用いた許諾通知である。彼は1985年には既にGNU Emacs複製許諾通知という後のGNU GPLへ思想的に繋がる再頒布の自由や改変の共有を推奨する考え方を示した文書を作成している。このような互恵的な共有の約束が著作権法の「抜け穴」を利用していく「一方的許諾」の思想的な土壌となったと考えられる。

MITライセンス等の登場による慣習の形式化

自然発生的に生まれた「一方的許諾」の慣習を、誰でも再利用の可能な法的文書として形式化したのはおそらく1984年のPC/IP頒布における原始のMITライセンスだったのだろう。

ソフトウェアが特定の研究室以外の世界へ広まり、またソフトウェア著作権が確立されていく中において、口頭での約束や単なるメモ書きでは「どこまで自由なのか」あるいは「責任問題はどうなるのか」といった点が曖昧であり、法的なトラブルの原因になりかねない。かといって、ライセンス契約のために弁護士を依頼し、単に共有したいと希望しているソフトウェアのために割に合わないコストをかけるわけにもいかない。MITライセンスは、この問題を解決するために、ハッカー文化の精神をそのまま法的テキストに落とし込んだと言える。

MITライセンスは、「誰でも無償で無制限に扱って良い。ただし、著作権表示とこの許諾条文は残すこと。適用法が許す限り作者は一切の責任を負わない。」と宣言しているものであるが、これは既に存在したコミュニティの暗黙の掟をそのまま法的な明確さを持ったテキストとして形式化した結果である。このようなシンプルな法的文書のテンプレートの登場により、あらゆる開発者が自分のソフトウェア作品を法的な安定性を保ちながら容易に共有することができるようになった。これを皮切りにBSDライセンスやGNU GPLが後に続き、「一方的許諾」の考え方と法的メカニズムはその後の多くのライセンスに受け継がれ、発展していったと言える。

判例による強化

この「連邦著作権法の抜け穴」と「ハッカー文化」から生まれた一方的許諾の慣習は、やがて法廷の場でその正当性が問われ、判例によって思想が強力に補強されていった。まず、Effects v. Cohen(1990年)のような判例を通じて、書面がなくても当事者の行動からライセンスの成立を認める「黙示のライセンス」という考え方が確立されたことが大きい。この判例は、行動が許可を生むという黙示のライセンスの基本原則を確立したリーディングケースであるが、これによって形式的な契約書がなくとも実態に即してライセンスの存在を認める道が大きく開かれ、「一方的許諾」の法的な実在性が裏付けられたと考えられている。

そして、決定的であったのが、Jacobsen v. Katzer(2008年) というオープンソースコンプライアンスの領域でのランドマーク的な判決であろう。
この裁判で連邦巡回区控訴裁判所は、オープンソースのライセンス違反は単なる契約違反ではなく、著作権侵害そのものであるとの判断を示した。ライセンスに書かれた義務は、ライセンスが有効であるための前提となる条件であり、それに反することは許可の範囲を超えた無断利用にあたると結論付けたのである。この判決により、「一方的許諾」の宣言は、連邦著作権法でその履行を強制できることが証明された。

なお、この訴訟はライセンスの一方的許諾説を決定付けただけでなく、契約説が高まりを見せることになった始点となる判決であるが、契約説については機会があればまだ書くことにする。

日本法との違い

日本においてはこの一方的な許諾という考え方は法解釈的には一般的ではない。その根本的な理由は、米国が採用するコモン・ローと日本やEUが採用する大陸法の設計思想の違いにある。前述した通り英米法では契約の成立に「対価」が重要な要素となるために、無償のライセンスを契約と見なすことに問題が生じかねないという考え方が発生するわけであるが、一方で日本が依拠する大陸法では「対価」は契約の必須要件ではない。当事者間に「この条件で使う」という意思の合意があれば、たとえ無償であろうが立派な「契約」が成立することになる。

そのため、日本の法曹関係者がオープンソースライセンスを見た際、わざわざ「一方的許諾」という特別な概念を持ち出すまでもなく、開発者と利用者の間の契約の一種であると、既存の民法の枠組みでスムーズに理解することが可能であったのだろう。

ただし、冒頭でも書いたように、開発者コミュニティの中ではやはり一方的な許諾としてライセンスを認識するほうが歴史的経緯を含めて理解しやすいこともあり、我々のような立場にいる人間は米国に合わせてオープンソースは著作権の許諾であるという言い方をすることが多いということも理解しておくと良いのだろう。

まとめ

米国の「一方的許諾」としてのライセンス概念は、著作権法の構造的な「抜け穴」、共有を掟とする「ハッカー文化」、そしてその慣習を法的に追認した「判例」という三位一体によって生まれたテクノロジーと法が相互作用した産物である。この柔軟な法的メカニズムは、MITライセンスのようなミニマムなものから、GNU GPLのような思想的に強力なものまで、多様なオープンソースライセンスを生み出す土台となったと言える。この歴史的背景を知ることは、日々利用されているオープンソースライセンスの条文一つ一つの背後にある深い意味を理解するための重要な鍵となる。

リンク

OpenMDWライセンス初期評価:オープンAIライセンスの革命か、オープンウォッシュの免罪符か?

オープンソースライセンスで頒布されるAIモデルが増えてきてはいるが、トレーニングデータを含めた全ての関連コンポーネントがオープンであるAIシステムには幾つかの有望なシステムが生まれているものの未だ発展途上にあると言える。そのような中で、今年5月にLinux FoundationがAmazon、Meta、IBM、Microsoft等の企業と協力し、Open Model Definition & Weights License v1.0(OpenMDW-1.0)というAIシステムに関わるコンポーネントを包括的に扱ってオープンに利用許諾を付与するライセンスを公開した。本稿では、そのOpenMDW-1.0のオープンソース性、他のライセンスとの比較、法的に不明瞭な点やAI領域における議論が必要な点等の提起を行う。

English version: https://shujisado.org/2025/07/14/openmdw-license-review/


オープンソースと呼べるライセンスであるか?

OpenMDWは、従来のソフトウェア中心のライセンスでは明示的に射程となっていなかったAIモデル、データ、重み(パラメータ)といったAI関連コンポーネントを包括的に扱うライセンスであり、全体的にはMITライセンスApache-2.0と類似する部分の多い寛容なライセンスと言える。「オープンソースの定義」の10ヶ条へ適合してオープンソースと呼べるライセンスであるかという点に関しては、再頒布の自由、ソースコードの公開、派生物作成の自由といった基本的な原則をクリアし、また人や用途等における制限はなく、特定技術を排他する条項もないと評価できることから、オープンソースのライセンスとして承認される可能性は高いだろう。(なお、2025年7月13日時点でOpenMDWはOpen Source Initiative(OSI)のライセンス承認プロセスには提出されていない。)

Subject to your compliance with this agreement, permission is hereby granted, free of charge, to deal in the Model Materials without restriction, including under all copyright, patent, database, and trade secret rights included or embodied therein.
あなたが本契約を遵守することを条件として、モデルマテリアルに含まれる、またはその中に具現化された全ての著作権、特許権、データベース権、及び営業秘密の権利を含め、いかなる制限もなくモデルマテリアルを無償で取り扱う権限をここに許諾します。

肝心の権利許諾に関しては、上記のように規定されている。この条文の構造はMITライセンスの権利許諾の条文と非常によく似ているが、対象としているのはMITにおけるソフトウェアではなく、モデルマテリアルとしてOpenMDW内で定義される“モデルアーキテクチャ、パラメータ、関連するデータ及びドキュメントまでを包括的に含んだ概念”が導入されている。また、いかなる制限もなく無償で取り扱う権利として明示的に“著作権、特許権、データベース権、及び営業秘密までを含む”と挙げられており、要するにモデルを中核として一緒に頒布可能な様々のコンポーネントに対して包括的に自由な利用を許諾しているわけである。MITライセンスに近いものの、MITでは著作権以外の権利においては黙示許諾に頼るわけであり、AIという新しい領域において考えられる全ての権利を明示的に許諾することで「著作権を許諾してはいるが、著作権で保護されないアイディア等は許諾していない」という詭弁が罷り通るリスクを封じたということなのだろう。

OpenMDWの特徴

それ以外のライセンスの特徴若しくは条件としては、下記が挙げられる。

  • 再頒布時の条件はライセンス条文のコピーと著作権表示若しくは起源表示のみ

MITライセンス等と同様の概念であるが、起源表示まで含まれることに差異がある。ただし、これはAIシステムを構成するコンポーネントの多様性から著作権表示ではない表記が必要な場合はあるからであろう。基本的には頒布するコンポーネントがどこから来たか、誰の手によるものか、を示す全ての記載をNOTICEファイル等に残せば良いということであろう。

  • Apache-2.0に枠組みが似た特許条項

簡単に言えばApache-2.0の特許条項に似た枠組みであり、利用者がモデル提供者に対して特許侵害訴訟を起こした場合にその利用者のライセンスを停止する条項であるが、AIコンポーネント向けの細かな変更が幾つか存在する。この点については後述するが、オープンソース性に影響するものではないと現時点で評価する。

  • AI生成物の利用にはいかなる制限も義務もなしと明記

一般的にAIの出力には明示的な契約が存在しない限りモデル提供者側の権利が及ばないが、OpenMDWでは出力に対していかなる制限も義務もないと明記している。これは、Meta LlamaやGoogle Gemma等のライセンス契約が出力を経由したライセンスの伝播性を持っていることと対照的であり、利用者には安心材料となる。

  • デューデリジェンス責任の明確化

トレーニングデータに含まれる可能性のある第三者の著作権等の権利処理や必要な許諾の取得は全てモデル利用者の責任でデューデリジェンスする旨が明記されている。モデル提供者側のリスクを軽減する現実的な条項とは言えるが、特に権利監査のための工程を持てないような中小規模のモデル利用者にとっては負担となり得る。ただし、条項の有無に関わず何らかの規制法がない限りは原則として利用者側の負担となるわけであり、オープンソース性の判断には影響するものではないと判断できる。

オープンソースへの適合性評価

これまでのライセンスの特徴を整理すると、OpenMDWにはオープンソースの定義に反する内容がライセンス条文に含まれているとは判断できず、やはりOSI承認ライセンスとなるための大きな障害は現時点でないと考えられる。また、MITライセンスやApache-2.0に近い寛容なライセンスであり、モデル、コード、データ、文書といったAI関連コンポーネントに対して包括的に適用できるという手軽さも兼ね備えている。条文の簡便性もあり、AIモデル提供者側にとって扱いやすいライセンスであることは間違いないだろう。

ただし、後述するように幾つかの不明瞭な点やライセンスによって間接的に引き起きる懸念点も考えられ、OpenMDW利用を推奨できる状況は条文の簡便さから比較すると実は少ないのではないかと考えている。オープンソースを追求する多くの組織にとっては、従来の寛容なオープンソースライセンスとクリエイティブ・コモンズ系統のライセンスの組み合わせのほうが適していることが多いだろう。

OpenMDWの不明瞭な点及び懸念点

OpenMDWはAIシステム向けに設計されたAIモデル提供者側にとって扱いやすいライセンスであるが、その一方で従来のプログラムコード向けとは異なる領域も大胆に射程に組み入れたことで、幾つかの議論が生じるだろうと考えられる不確実性が存在し、そこから発生する懸念点も存在する。いずれも深刻な欠陥ではないのだが、変化が激しいAI領域においては今後大きな問題となる可能性は否定できないと考える。

営業秘密までを許諾範囲に含める意味

OpenMDWが明示的に射程としている諸権利には、著作権、特許権、データベース権、及び営業秘密がある。著作権はそもそもオープンソースライセンスで扱う権利の根幹であり、特許権についてはApache-2.0やGPL-3.0等のライセンスで扱っており、もはや特別視されるものではない。また、データベース権についてもクリエイティブ・コモンズ系統のライセンスで実装されており、これもデータベース性を含むコンテンツに対して付与することが一般的になりつつあると言える。しかし、営業秘密に対して明示的な利用許諾を与えるライセンスというものは極めて珍しい。

そもそも、日本、EU、米国といった主要法域においていずれも営業秘密の保護は「非公知(秘密であること)」が絶対的な要件であり、よってOpenMDWのようなライセンスの下で頒布され公知となった情報はもはや営業秘密として法的に保護されない。この根本的に保護されない権利に対してわざわざその権利の利用許諾を付与する意味があるのかどうかという疑問は出てくるだろう。

営業秘密条項に法的な意味がある理由を考えると、少なくともモデルで実現しているアルゴリズム、設計思想、パラメータのチューニング方法といったノウハウやアイディアに対して権利主張することはしないという宣言的な意味合いはあるのだろう。それによって、悪意のあるモデル提供者が将来において「著作権は許諾したが、実装されているアイディアやノウハウの使用までは許諾していない」という詭弁を防ぐ効果はあるのかもしれない。また、営業秘密を列挙することで、まだ未知の権利を含めてあらゆる知的財産権の観点から、制限なく自由に利用できるというライセンスの意図を最大限に強固なものにするという効果もあると考えられる。

ただし、やはりその程度の意味合いでしかなく、モデルの利用者への制限のないモデル利用の許諾を明確化することと引き換えに、あまりライセンスフレームワークに馴染みのない権利をライセンスに入れ込むことによる未知の副作用があるかもしれない。おそらく何の問題もないとは思うものの、営業秘密に関しては著作権よりも各国の法律の定義の差異は大きいわけであり、数年の間はその法的なテスト期間になるのではないだろうか。

適用範囲がより広く、明確かつ強力となった特許報復条項

OpenMDWの特許条項は、Apache-2.0の特許報復条項とよく似ており、基本的な思想や目的は同様と評価できる。ただし、Apache-2.0とは幾つかの点で異なる箇所がある。

If you file, maintain, or voluntarily participate in a lawsuit against any person or entity asserting that the Model Materials directly or indirectly infringe any patent, then all rights and grants made to you hereunder are terminated, unless that lawsuit was in response to a corresponding lawsuit first brought against you.
モデルマテリアルが直接的または間接的に特許を侵害していると主張する個人または団体に対し、あなたが訴訟を提起、継続、または自発的に訴訟に参加した場合、当該訴訟があなたに対して最初に提起された関連訴訟に対するものでない限り、本契約に基づきあなたに付与された全ての権利および許諾は終了します。

Apache-2.0では特許訴訟が提起された場合に特許ライセンスが終了するわけであるが、OpenMDWでは提起だけではなく、“継続、または自発的に訴訟に参加した場合”となっており、これは訴訟を開始した原告だけでなく、後から訴訟へ何らかの加担をする行為も対象になる。また、訴訟の対象範囲はOpenMDW特有の概念であるモデルマテリアルという広い範囲が対象となっており、“直接的または間接的に特許を侵害”という文言から「間接的」な侵害主張も含んでいる。つまり、OpenMDWの特許報復条項はApache-2.0と比較してかなり広い行為と範囲をカバーしており、AIという新しい領域において将来の未知の訴訟形態にも対応しようという意図が伺える。このような範囲の広さは特定の利用者には厳しい条件と映るかもしれないが、モデル提供者を可能な限り保護するということで好ましいことだろう。

なお、特許を直接的に侵害という状況は分かりやすいが、間接的に侵害とは何なのだろうか?これは所要法域の特許法において規定されている間接侵害を指しているのだと推察されるが、日本、米国、EUといった法域でこの間接侵害の要件や思想は幾つかの点で異なる。そのため、この間接侵害の要件の差異がライセンスの解釈に混乱を招くのではないかという懸念が生じる。米国では間接侵害と判断されるが、日本では侵害と見做されないというパターンがありえるという話である。ただ、この間接的という表現は、どの国の法律の下で解釈されてもその国における「直接的ではない侵害」という概念全般をカバーしようという意図と考えられ、法的な不確実性によって利用者からの訴訟行為を強力に抑止することを狙っていると考えられる。

さらに、もう一つ、最も大きなApache-2.0との違いがある。Apache-2.0では訴訟提起によって終了するのは特許ライセンスであるが、OpenMDWでは“全ての権利および許諾”が終了すると規定されている。これは曖昧さがなく、より厳しい報復内容となっているわけである。範囲の広さと合わせ、訴訟を封じるための極めて強力な法的セーフガードであると考えられ、AIコミュニティ内での特許紛争を最大限防ぐという実用的な効果を狙っているのだろう。その反面、特に大企業のモデル利用者側には厳しい条件と映るだろうし、考え得る最大限の範囲を対象にしていることから未知の事案が起きる可能性は否定できない。

モデルのデューデリジェンスを利用者に強いる

オープンソースのライセンスでは、“現状有姿(AS IS)”“no-liability”から構成される免責条項が一般的であるが、OpenMDWでもほぼMITなどと同様の条項が存在するものの、もう一つ大きな免責の条項が存在する。“モデルマテリアルに含まれる第三者のあらゆる権利のクリア、必要な同意の取得、そしてデューデリジェンスを全て利用者の責任”とする条項が追加されているのである。これは事実上、モデルや一緒に頒布されるトレーニングデータに含まれる第三者の権利、例えば個人の著作権やプライバシーを含む人格権等が含まれているかどうかを利用者側が監査することを義務付けている。

モデル提供者側にとってはこのデューデリジェンス条項はある意味での安心感を与えるかもしれないが、個人情報保護、消費者保護、そして各国でのAI規制法などの強行規定から逃れることはできない。また、モデル利用者側にとっても、非常に大きなデューデリジェンスの負担を課しているようにも取れる。モデル提供者側が傲慢であると世間に受け取られるかもしれないし、利用者側には「全ての権利が許諾されてはずなのに話が違うじゃないか!」という思いも発生するだろう。ということで、余計な混乱を生むだけではないかと考える者もいるかもしれない。

しかしながら、このデューデリジェンス条項は、モデル提供者が持っていない第三者の著作権、人格権等の権利はそもそも利用を許諾することは不可能であるし、各国の強行法規から逃れることはできないという現実を誠実に示したものであるのだろう。結局のところ、出力を含めたAIモデルの利用においては、利用者側が第三者の権利を侵害していないかどうかを監査し続けなければならないわけであり、個人的にはAIモデル向けのライセンスとして好ましい条項だと考える。

データライセンスとしてはクリエイティブコモンズに劣る

OpenMDWライセンスは、単一のモデルの他に関連するソースコード、ドキュメント、メタデータも同一のライセンスで頒布することを実現するが、その同じライセンスで頒布されるコンポーネントにはトレーニング用データセットも含まれる。この仕組みにより、モデル開発に関連したコンポーネントを一括でライセンシングするという簡便さを実現するが、その反面、お世辞でもOpenMDWがトレーニング用データセットにとって適したライセンスであるとは言えない。

OpenMDWの許諾条件はクリエイティブコモンズ系統ではCC-BYに近いと言えるが、データライセンスとしての比較であれば幾つかの点で劣っている。まず、CC-BY 4.0はEUのデータベース権を前提としたデータ特有の権利を明確に処理できるように設計されているが、OpenMDWでは包括的なデータベース概念を許諾しているだけであり、法的に不明瞭であると言える。また、データ自体が特許を侵害するリスクは極めて低いものであり、OpenMDWの強い特許報復条項はデータライセンスとして過剰なものであり、正当な権利を持つ企業などの利用を妨げる可能性があるだろう。

さらに、クリエイティブコモンズはオープンなデータライセンスとして事実上の標準の地位にあり、データの利用、改変、再頒布に関する権利と義務が、世界のデータコミュニティの常識に沿って設計されている。この常識に逆らってまでデータライセンスとして適していないライセンスをデータセットにまで適用する意味はあまりないように考えられる。

クリエイティブコモンズには、CC-BYだけでなく、パブリックドメイン宣言に近いCC0もあるし、CC-BY-SAという派生データセットを作った場合に派生側に同じCC-BY-SAライセンスが伝播するライセンスもあり、用途や目的によって使い分けることが一般的である。そこへOpenMDWという包括的ライセンスを持ち込むのは単にAIトレーニングデータのライセンシングをより複雑な状況に追い込むだけかもしれない。安易にOpenMDWを選択されることで、CC-BY-SAやコピーレフト性のあるライセンスとの矛盾が発生するケースを誘発することにも繋がるのではないかとも危惧する。

オープンウォッシュを助長する可能性

個人的にはこれが最も大きな懸念である。OpenMDWライセンスは「オープンソースの定義」に適合すると個人的には判断しており、OSIへライセンスが提出されればオープンソースとして承認される可能性が高いだろう。しかし、実際にOpenMDWライセンスを採用するモデル開発ベンダーが増えた時、この数年の間に我々のコミュニティを悩ませてきた“オープンウォッシュ”をこのライセンスが助長するかもしれない。

前項でも説明したように、OpenMDWライセンスを特定のモデルへ適用する時、同一リポジトリに置いた関連コンポーネントにもOpenMDWが適用される。つまり、トレーニング用データセットもそれに含めればOpenMDWが適用される。この際、わずかな量、若しくは希少性も重要性も少ないデータセットだけを同一リポジトリに含めてOpenMDWライセンスでリリースし、その状態を「オープンソースAIでリリースした」とも「データセットレベルから真にオープンなモデルである」ともモデルベンダーが宣伝することは可能である。OpenMDWライセンスが「オープンソースの定義」に合致したライセンスであれば、そのような詭弁、つまりオープンウォッシュに信憑性を与えることになる。

OSIが多大な労力をかけて作り上げた「オープンソースAIの定義」では、“実質的に同等のシステムを構築できる程度に十分な詳細な情報”をデータの要件としている。これによって、誰もが同等のモデルを再構築して挙動を確かめたり、どのようなデータでトレーニングされ、どのようなバイアスを持つ可能性があるかを検証したりできるわけであるが、トレーニングデータのごく一部しか公開されていなければこれらの価値は完全に失われることになる。しかし、「オープンソースの定義」に合致したOpenMDWライセンスが一般的に利用されるようになった場合、一部のデータセットだけを公開さえしていれば残りのデータセットは完全秘匿でもオープンソースを名乗れる状況を生み出し、それは数十年に渡ってコミュニティが築き上げてきた「自由」「透明性」「共同作業」「信頼性」といった非常に高い価値を持つオープンソースというブランドを毀損することになるだろう。

Linux FoundationがOpenMDWライセンスをいまだにOSIのオープンソース承認プロセスに申請していない理由はよく分からないが、私はOpenMDWライセンスをよく考えられた優れたライセンスであると現時点で認識している。オープンウォッシュを助長するという理由はオープンソースへの承認を否定する理由にはならないだろう。むしろ、これはOSIを中心としたオープンソースのライセンスコミュニティに対してAI関連のライセンスに関する課題を明確にしてくれたと考えている。

我々は、オープンソースの定義の2条「ソースコード」における「プログラムを改変するために好ましい形式でなければならない」という条項をAIに適用した「AIモデルを研究・改変するために好ましい形式とは、推論コードだけでなく、トレーニングデータやプロセスに関する情報も含まれる」という解釈を広める努力を進めなければならない。それによって、OpenMDWがオープンウォッシュを助長するという見方を減らすことはできるだろう。

総合的な評価

OpenMDWライセンスはMITとApache-2.0の考え方を複雑なAIシステム全体への適用を可能とした寛容なライセンスであり、AIシステム専門のライセンスとして初めてのオープンソースコミュニティが納得できるライセンスであるかもしれない。出力に対して完全に制限がないと宣言していることも非常に好ましい。

ただし、許諾する権利に営業秘密を含む点には様々な法域での意見を聞く必要があるように思うし、データに関してまで特許報復条項の効果が及ぶ点はやや過剰であるようにも感じる。一般的なトレーニングデータの巨大さやライセンスの複雑さを考えても、トレーニングデータはモデルとは別のリポジトリでクリエイティブコモンズ系統等の別のライセンスで頒布するという分離方式がベストプラクティスであり続けると考える。MIT若しくはApache-2.0をモデルに適用し、データセットにはCC系を適用するという方式が今後も続くだろう。

おそらく、一部のトレーニングデータを含めてOpenMDWライセンスを適用することが向いているケースというものは基本的には特殊事例になるのだろう。考えられるのは以下のようなものだと思う。

  • 特許等のリスクを伴う科学技術データを含む場合

創薬や遺伝子関連、あるいは半導体設計等のデータそのものに訴訟リスクがある場合は特許紛争の抑止力を提供する包括的な特許報復条項が向いていると言える。

  • モデル専用に加工された派生・合成データが存在する場合

データがモデル前処理の副産物であり、他用途だと半端という場合は、モデルと同じライセンスに揃える方が管理しやすく明確である。

  • モデルパラメータとデータが相互依存して再現性を成立させる場合

動作検証においてモデル単体では再現できない場合に権利関係を明確にした一括でのライセンシングが分かりやすい。

AIモデル開発に関わりのない自分としてはせいぜいこれぐらいの大雑把なケースしか示せないが、原則としてトレーニングデータを含めてのOpenMDW適用が勧められるのはモデルとデータを不可分にしたい特殊事情がある場合に限られると考えて良いだろう。ただ、それだけでも十分に有用なライセンスであると考えられる。

一部の大企業がOpenMDWを適用したモデルに特に重要ではないデータセットを含ませることで「オープンソースAI」と名乗り出すオープンウォッシュの懸念はあるが、この懸念に立ち向かうのはOSIを中心としたオープンソースのライセンスコミュニティの仕事である。繰り返しとなるが、「AIモデルを研究・改変するために好ましい形式とは、推論コードだけでなく、トレーニングデータやプロセスに関する情報も含まれる」というオープンソースAIと呼ぶための前提を広める努力を我々は継続しなければならない。


OpenMDW License Agreement, version 1.0 (OpenMDW-1.0)

OpenMDW ライセンス契約書、バージョン 1.0 (OpenMDW-1.0) 日本語参考訳

By exercising rights granted to you under this agreement, you accept and agree to its terms.

本契約に基づきあなたに付与される権利を行使することにより、あなたは本契約の条項に同意したものとみなされます。

As used in this agreement, “Model Materials” means the materials provided to you under this agreement, consisting of: (1) one or more machine learning models (including architecture and parameters); and (2) all related artifacts (including associated data, documentation and software) that are provided to you hereunder.

本契約において「モデルマテリアル」とは、本契約に基づきあなたに提供されるマテリアルを指し、(1) 1つ以上の機械学習モデル(アーキテクチャおよびパラメータを含む)、および (2) 本契約に基づきあなたに提供される全ての関連成果物(関連データ、ドキュメント、およびソフトウェアを含む)で構成されます。

Subject to your compliance with this agreement, permission is hereby granted, free of charge, to deal in the Model Materials without restriction, including under all copyright, patent, database, and trade secret rights included or embodied therein.

あなたが本契約を遵守することを条件として、モデルマテリアルに含まれる、またはその中に具現化された全ての著作権、特許権、データベース権、および営業秘密の権利を含め、いかなる制限もなくモデルマテリアルを無償で取り扱う権限をここに許諾します。

If you distribute any portion of the Model Materials, you shall retain in your distribution (1) a copy of this agreement, and (2) all copyright notices and other notices of origin included in the Model Materials that are applicable to your distribution.

あなたがモデルマテリアルの一部を頒布する場合、あなたは頒布物の中に (1) 本契約の写し、および (2) モデルマテリアルに含まれる、あなたの頒布に適用される全ての著作権表示およびその他の起源表示を保持するものとします。

If you file, maintain, or voluntarily participate in a lawsuit against any person or entity asserting that the Model Materials directly or indirectly infringe any patent, then all rights and grants made to you hereunder are terminated, unless that lawsuit was in response to a corresponding lawsuit first brought against you.

モデルマテリアルが直接的または間接的に特許を侵害していると主張する個人または団体に対し、あなたが訴訟を提起、継続、または自発的に訴訟に参加した場合、当該訴訟があなたに対して最初に提起された関連訴訟に対するものでない限り、本契約に基づきあなたに付与された全ての権利および許諾は終了します。

This agreement does not impose any restrictions or obligations with respect to any use, modification, or sharing of any outputs generated by using the Model Materials.

本契約は、モデルマテリアルの使用によって生成された出力の使用、変更、または共有に関して、いかなる制限または義務も課しません。

THE MODEL MATERIALS ARE PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, NONINFRINGEMENT, ACCURACY, OR THE ABSENCE OF LATENT OR OTHER DEFECTS OR ERRORS, WHETHER OR NOT DISCOVERABLE, ALL TO THE GREATEST EXTENT PERMISSIBLE UNDER APPLICABLE LAW.

モデルマテリアルは「現状有姿」で提供され、明示または黙示を問わず、いかなる種類の保証も行われません。これには、商品性、特定目的への適合性、所有権、非侵害、正確性、または発見可能か否かを問わず、潜在的な瑕疵もしくはその他の瑕疵または誤りがないことに対する保証が含まれますが、これらに限定されません。これらの保証は適用法の下で許容される最大限の範囲で保証されます。

YOU ARE SOLELY RESPONSIBLE FOR (1) CLEARING RIGHTS OF OTHER PERSONS THAT MAY APPLY TO THE MODEL MATERIALS OR ANY USE THEREOF, INCLUDING WITHOUT LIMITATION ANY PERSON’S COPYRIGHTS OR OTHER RIGHTS INCLUDED OR EMBODIED IN THE MODEL MATERIALS; (2) OBTAINING ANY NECESSARY CONSENTS, PERMISSIONS OR OTHER RIGHTS REQUIRED FOR ANY USE OF THE MODEL MATERIALS; OR (3) PERFORMING ANY DUE DILIGENCE OR UNDERTAKING ANY OTHER INVESTIGATIONS INTO THE MODEL MATERIALS OR ANYTHING INCORPORATED OR EMBODIED THEREIN.

あなたは、(1) モデルマテリアルまたはその使用に適用される可能性のある他者の権利(モデルマテリアルに含まれる、または具体化されている個人の著作権またはその他の権利を含みますが、これらに限定されません)を処理すること、(2) モデルマテリアルの使用に必要な同意、許可、またはその他の権利を取得すること、または (3) モデルマテリアルまたはそれに組み込まれ、または具体化されているあらゆるものについてデューデリジェンスを実施し、その他の調査を行うことについて、単独で責任を負います。

IN NO EVENT SHALL THE PROVIDERS OF THE MODEL MATERIALS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE MODEL MATERIALS, THE USE THEREOF OR OTHER DEALINGS THEREIN.

いかなる場合においても、モデルマテリアルの提供者は、契約行為、不法行為またはその他の行為のいずれにおいても、モデルマテリアル、その使用、またはその他の取り扱いから生じる、またはそれに関連するいかなる請求、損害、またはその他の責任についても責任を負わないものとします。

オープンソースプロジェクトはAI生成コードをどのように受け入れるべきか? — QEMUの禁止ポリシーからの教訓

QEMUプロジェクトは、AIツールによって生成されたコードによる貢献を拒否する方針を正式に取り決めた。その核心的な理由は、貢献者が提出するパッチの正当性を証明するために用いているDeveloper’s Certificate of Origin (DCO) の要件を、AI生成コードが満たせないという懸念である。この問題に対して我々は何をすべきなのだろうか?

English article: https://shujisado.org/2025/07/02/how-can-open-source-projects-accept-ai-generated-code-lessons-from-qemus-ban-policy/

なぜDCOはAI生成コードを拒むのか?

AI生成によるコードがDCOをクリアしにくい理由は二つある。一つは人間による作者性の問題である。DCOの条項は貢献が「自身によって作成された」ことを求めているが、現状で多くの法域ではAI生成コードに著作物性を認めていない。従って、人間の作者の存在を示すことが法的に難しい。二つ目は生成コードが本当にクリーンであるかが不明瞭だからである。AIが様々な世界中の様々なライセンスが適用されたソフトウェアのコードでトレーニングされているのは自明であり、貢献対象のソフトウェアのライセンスと矛盾するライセンスのコード断片が偶然出力される可能性もある。

現在ではある程度の大きさの断片のコードが既存の公開されたソースコードとの類似をチェックする仕組みを利用することが一般的になりつつあるので、二つ目の懸念は割と小さなリスクと整理できるかもしれない。しかし、どの程度リスクが抑制されているのかはまだ不明瞭であるとは言える。それよりも一つ目の作者性の問題は本質的に解決が難しい。

AI生成コードは多くの法域で著作権が認められない。これは一種のパブリックドメインのコードに近いと言える。パブリックドメインのコードをオープンソースのソフトウェアに組み込むこと自体は、ライセンスの互換性を気にする必要がなく、全く問題がない。また、一般的にソースコードの全てが著作権で保護されるわけでなく、「アイデア」や「ありふれた表現」などの人間による創作性が低い部分は著作権保護の対象外である。この二つの事実を合わせると、AI生成コードをプロジェクトへ組み込むことは、プロジェクト全体に占める著作権保護対象となるコードの割合が減るだけという見方が理論上は成り立つ。

だが、実際にAIによって生成されたコードに「著作権がない」ことを人間が保証することは非常に困難である。AI生成コードに著作権がないという多くの法域での見解は存在するが、グローバルで法的に統一された見解からは程遠い。また、そのコードをどのように扱えば人間の著作権が認められるのかという点も曖昧であり、法的な不確実性が大きいと言える。また、AI生成コードに対して誰かが著作権のクレームを付けた場合、AIの利用者が「これはAIが生成したものであり、著作権がなく、あなたの著作物とも無関係だ」と立証することは難しい。つまり、現状では、AI生成コードが、第三者コードと一切類似せず、かつ、著作権が発生しないことが法的に保証することは難しい。よって、QEMUプロジェクトのようなAI生成コードを拒絶するという決断をするプロジェクトは今後も出てくるだろう。

それでもAI生成コードを受け入れる道は?

AI生成コードをオープンソースプロジェクトが何ら障害もなく受け入れるためには、まず既存コードとの類似性をチェックする仕組みの更なる改善が必要である。商用の優れた製品があることは理解しているが、オープンソースで提供されるツールの進化を促す必要があるだろう。また、AI出力コードの透明性を高めるために、SPDXがAI生成関連コードを識別する仕様をなるべく早く追加し、様々なシステムで自動的にタグが付与されるように促すことも重要だろう。

さらに、QEMUプロジェクトがAI生成コードを拒絶するポリシーを規定したのは、DCOの解釈上は人間の作者を要求しているからである。よって、AIの時代の到来に合わせてDCO自体のアップデートが必要なのかもしれない。歴史的に考えれば、DCOはSCO GroupからのLinux陣営への訴訟攻撃があった時代にLinuxカーネルへの貢献コードの出所をめぐる問題や訴訟の排除を目指して導入されたものである。AI生成コードの出所が課題なのであるから、このDCOをアップデートしてDCOv2を作成することは理想的であるように一見は考えられる。

しかし、DCOはすでに様々なプロジェクトやコードホスティングプラットフォームで使われており、DCOを安易にアップデートすることは大きな副作用が生じる可能性が高い。DCOの最大の利点はその簡潔さと普遍性にあり、その利点を損なうアップデートも難しいだろう。事実上、DCOでAI生成コードへの対応を行うのは相当に難易度が高いと言える。そのため、DCOにおける「私が作成した」という根幹の宣誓は維持し、その宣誓を誠実に行うために貢献者が何をすべきかを、周辺のドキュメントで補うというアプローチが現実的であるが、この作業を完全に各プロジェクトに任せるとDCOの解釈がプロジェクトによって揺らぐ状況となり、貢献者にとってもプロジェクト管理者にとっても混乱を招き、エコシステムの健全性を損なうだろう。

非常に難しい作業になると思うが、DCOの策定者であるLinux FoundationはAI時代におけるDCOの解釈がどのようにあるべきかという点に対してある程度のガイダンスを示す必要があるように思う。

https://www.linuxfoundation.org/legal/generative-ai でLinux FoundationとしてのAIポリシーを示していることは理解しているが、これだけではDCOを採用していく幾万のプロジェクトにとって参考とはなりにくいだろう。特にDCOにおける「人間の作者性」を要求する部分に対する指針を示すべきである。Linuxカーネルのような法的安定性が最優先されるプロジェクトとWebフレームワークのような開発速度が優先されるプロジェクトでは許容されるリスクに大きな差異が生じることは理解するが、それでもDCOにおけるAI生成コードの受け入れに関する最低限の考え方を整理する必要がある。

何故、DebConfは日本で未開催なのか?自由の闘士を来日させる道程

Debian Projectが毎年開催している開発者会議「DebConf」というイベントがある。もう随分と長い歴史があるのだが、一度として日本で開催したことはない。日本ではDebian GNU/Linuxが受け入れられていないからだろうか? いやいや、Debian開発者を数百人も結集させる希少性のある機会が日本企業にとっても魅力的に映る時期もあったので、これまでに何度もDebConf招致を検討はされてきた。しかし、自分が知る限りではすぐに計画が構想段階で立ち消えになってきたのである。そもそも、日本ではDebConfを開催するための条件をクリアすることが非常に難しいという問題があるからだ。

DebConfは、世界中からDebian Projectのメンバーが結集する約二週間のイベントである。昔は一週間のDebConfだけだったような気がするが、今ではDebCampというイベントをDebConf直前の一週間で開催する形式となっている。一般的な技術カンファレンスとは趣きが異なり、総じて長期滞在での共同開発作業を前提としたハッカーのためのイベントなのである。

そのような性質のイベントのため、単に講演のための大きな部屋を揃えるだけでなく、小規模トークルームや24時間利用できるハックスペースを用意する必要もあり、それらの部屋には豊富な電源とネットワーク設備を提供しなければならない。また、自費で世界中から渡航してくるDebian開発者らに対して、最大で二週間の期間における食事を含めた滞在支援も必要である。これらは予算さえ注ぎ込めば何とかクリアできる会場を探すことはできるかもしれないが、長期に渡っての会場確保、施設における防犯上の利用制限、あるいはそもそも予算との大幅な乖離から、どうしても日本での開催は実現が難しいという結論になってしまうのである。

ただ、日本でも可能性がないとは言い切れず、企業や自治体の研修施設を格安で貸してもらえることはあるかもしれないし、大昔のような全ての物価が高い日本ではなく、むしろ物価が安い日本となった今では再検討できる余地はあるかもしれない。また、企業や自治体よりもおそらく地方の大学には可能性があるのだろう。特に情報科学系に強く、寮を保有する大学が理想的であり、DebConfの一般的な開催期間中は通常であれば夏休み期間であるので最も望ましいと考えられる。つまり、直球で答えれば、北陸先端大や奈良先端大のような大学を動かせれば良いわけだ。ただし、昨今の大学という機関が置かれている状況を考えると、物好きな教授らがいたとしても相当にハードルは高いのだろう。

自分が今更ながらこのようなことを書いたのは、チラッと日本でのDebConf開催を模索している人達の噂を小耳に挟んだからである。Debian開発者という数百人の自由の闘士というかヒッピー風のよく分からないハッカーらをこの日本に結集させるというのは単純に面白い。Big Techが莫大な利益を追い求める昨今においても、多くの国内企業のシステムにおいてDebianの成果に乗っかる部分は大きいわけであるし、また、多くの日本人に自分達のシステムを支えている存在の生き様を見てもらうという意味もあるだろう。

このような無謀な計画というか妄想を実現させようとする動きは自分としては非常に好ましいと思っている。数年以内に日本でのDebConf開催が実現してくれることを願っている。

AIは仕事を奪うのか?AIと人間はどちらが最終決定を担うのか?

AGIという言葉が至る所で叫ばれているが、人間の行動のあらゆる側面が本当にAIに置き換えられるようになるのだろうか?現時点において依然として自分は懐疑的に見ている。

例えば、ソフトウェア領域においては間もなくAIが大規模なシステムの開発プロジェクトにおけるあらゆる工程を処理できるようになるだろうと見られている。Clineに全部賭けた後にClaude Codeに賭けた人達の存在はそれを証明するかのようである。しかし、人間の発注者が真に望むシステムをAIが構築できるかどうか、自分は依然として疑問を感じている。

有名な「Tree swing cartoon」(顧客が本当に必要だったものとして日本でも有名)を思い出して欲しい。このイラストはよく知られているので、特に絵に関する説明は不要だろう。このイラストでは、「顧客の説明」は人間がAIに与える要件に対応し、「顧客が本当に必要だったもの」はAIが提供する最終的な成果物に対応している。つまり、私はAIがこのギャップを埋めることができるかどうかを疑っているわけである。

https://pmac-agpc.ca/project-management-tree-swing-story

現実としては、AIの能力はほぼ確実に人間を上回るため、システム開発の中間工程、この漫画におけるプログラミング、分析、テストなどでは、人間の成果をはるかに超える結果が生み出されるだろう。AIがプロジェクト管理の役割も担うようになれば、漫画のような醜態は消えるかもしれない。しかし、「顧客が説明した要件」と「顧客が本当に必要だったもの」は、優秀なAIが開発を行うだけで本当に一致するのだろうか?

人間がAIに与える指示や要件は、常に曖昧で、誤りだらけであり、時には完全に意味不明であることもしばしばである。近い将来には高度な能力を持つAIが我々の思考や感情を読み取り、隠れたニーズを推論し、最適な結果を提供できるかもしれない。しかし、人間の根本的ミスや発注側が意図的あるいは偶然的に伝えなかった要望をAIが予測した解決策に発注者である人間は満足するのだろうか?一部の人は、AIが生成した最適であるはずの「顧客が本当に必要としていたもの」を見て、AIは無用だと不満を言うだろう。

人間は愚かな存在だ。我々はAIよりも知識が少なく、思慮深くなく、感情にすぐに左右される。さらに悪いことに一般的な多くの人々は自分たちが特別な存在だと信じる傲慢さを抱えている。この愚かさを抱えている限り、我々はAIに完全に依存することを躊躇するだろう。

それでも、AIが人間の多くの仕事を置き換えることは疑いようがない。しかし、人間が愚かさを抱えている限り、人間の手で最終的な解決と決定をやりたがるだろう。

(本稿は、https://www.linkedin.com/posts/shujisado_the-term-agi-is-being-trumpeted-everywhere-activity-7332676882892525568-lrpa/ を若干修正したもの)

AIモデルがオープンソースであるために完全な学習データの公開は必要なのか?

DeepSeekは世界に衝撃を与えているが、その要因としては、中国から米国の巨大AIベンダーを脅かす新たな勢力が現れたことに加え、AIモデルがMITライセンスというオープンソースライセンスでも頒布されている点が大きいと考えられる。しかし、DeepSeekはモデルこそMITライセンスで公開しているものの、データ処理コードや肝心のトレーニングデータに関する情報は、現時点では何も公開されておらず、詳しい情報も開示されていない。このような経緯から、「DeepSeekはオープンソースとは言えない」とする意見が各所で盛んに主張されており、「果たしてオープンソースと呼ぶために完全なトレーニングデータの公開は必須なのか」という問いへの関心も、ある程度高まっているように思われる。

昨年10月、Open Source Initiative(OSI)は「オープンソースAIの定義」(OSAID: Open Source AI Definition)を公表しており、それに従えばオープンソースAIであるためには完全なトレーニングデータが存在することは推奨されるものの必須とする要素ではなく、基本的にはトレーニングデータの詳細な情報があれば済むという定義となっている。現状ではこのOSIの方針は妥当な考え方であるとの見方が強いと考えているが、その一方で「完全なトレーニングデータの公開を必要とする論」及び「データの公開は全く必要としない論」の相反する二つの考え方が根強くある。本稿ではその対立の背景を踏まえつつ、OSIの考え方が導き出されるまでの解釈を説明する。

なお、この解釈は佐渡個人が今までの議論を踏まえて、個人としての現在の解釈を整理して解説するものであり、実際の議論がこのような過程を踏まえたわけではないことは留意して頂きたい。

English Version: https://shujisado.org/2025/02/18/should-open-source-ai-mean-exposing-all-training-data/


1. トレーニングデータの必要性に関する対立の構図

AIシステムがオープンソースであるための条件を考えると、誰もが先ずモデルそのものへオープンソースライセンスが適用されていることを条件とするだろう。ただ、AIの場合、その条件だけではAIの動作を完全に解明することは困難であり、研究と改変の自由を実現することは難しい。よって、その他の要素も必要とし、AIのトレーニングからモデルの実行までの過程で使用された全てのコードがオープンソース化されることも条件とする考え方が生まれる。ここまではオープンソースのライセンスに関する知識を少し持っている者であれば、ほぼ同意するだろう。しかし、そのトレーニングで使用された実際のデータとなると、その完全な公開を求める陣営と公開を必要としない陣営に分かれることになる。中でも全てをパブリックドメインやオープンデータを使用することを条件とする考え方とデータの詳細な情報すら一切必要としない考え方ではあまりにも隔たりが大きく、相互に妥協することは困難となる。困ったことに双方を支持する声は無視できるほどには小さくないのが現実であり、極端な声に押される形で各所で論争の火種となっていることは事実だろう。

そこでトレーニングデータに関する意見を整理すると、大まかには下記四つの主張に分類されるのではないかと思う。

  • A. 完全なトレーニングデータの必要性を主張する派:
    • Aa. 全てのデータをオープンデータとする論:
      全てのトレーニングにおいてオープンデータ若しくはパブリックドメインのデータセットを使用し、モデル作成のあらゆる側面の透明性が確保され、かつ一から再製可能であることを保証する必要があるという主張
    • Ab. 一般に入手できる公開データを必須とする論:
      全てのトレーニングデータ全体を誰でもダウンロードできるように公開し、モデルを正確に再現できるようにする必要があるとする主張
  • B. 完全なトレーニングデータを必要としない派:
    • Ba. データを一切必要なしとする論:
      追加学習や微調整を行うことで改変や派生ができるため、元々のトレーニングデータ全ての共有が必須ではないとする主張
    • Bb. データの出処等の詳細な情報を開示すれば良いとする論:
      類似のデータを複製または入手できるのであれば、データがどのように取得されたか等の詳細な情報が必要であると主張し、元のデータセットを完全に開示する必要はないとする主張

この四つの主張はデータの完全性という一つの直線の尺度の上にプロットして並べていくと、データの完全性が高い順に Aa – Ab – Bb – Ba という並びになるのだろう。オープンソースであるかどうかということはYesかNoの二値で表現するしかない問題であり、よってこの尺度の上のどこかにオープンソースとして認める明確なラインを引くことになる。

しかし、この四つの主張はいずれにも即座に反論を唱えることできるので話がややこしくなる。
真に「オープンなデータ」を要求した場合、利用可能なデータセットは大幅に縮小され、現時点で大規模なモデルとされる規模のAI開発でオープンソースでは不可能になる可能性が生じるだろう。また、ヘルスケアや教育等の多くの専門領域においては法律上または倫理的に制限されたデータが含まれており、それらのデータはそのまま共有できないため、公開データのみにこだわることはAIを必要とする重要な領域からオープンソースAIが除外されるということに繋がる。一方、トレーニングデータがないと再現性と徹底的なモデルの監査はほぼ不可能になり、バイアスを検出したり、研究や改善のために結果を再現することが妨げられることになる。正確な再現性や詳細なデバッグには実際のデータセットへのアクセスが必要という反論には説得力があるように考えられる。

意見を4つに分類することで Aa – Ab – Bb – Baの尺度のどこかにオープンソースAIであると認めるラインを引かねばならないということだけははっきりしているが、どこにそのラインを引くかはもっと原理原則に立ち返って詳細に検討しなければならない。


2. AI領域におけるOSD 2条「ソースコード」の探究

トレーニングデータの完全性をどこまで求めるかを詳細に検討するためには、やはり「オープンソースの定義」(OSD: Open Source Definition)という根本的な原則に基づいて考える必要がある。現在のOSDのバージョンは2004年にリリースされた1.9であり、20年以上変更がない。オープンソースであるための条件として完全に安定化していると言えるだろう。そして、このOSDをAIシステムに対して適用する場合、問題となるのは下記の第2条「ソースコード」である。

OSD Section 2. Source Code:

The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, preferably downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.
(オープンソースであるプログラムはソースコードを含んでいなければならず、コンパイル済形式と同様にソースコードでの頒布も許可されていなければなりません。何らかの事情でソースコードと共に頒布しない場合には、ソースコードを複製に要するコストとして妥当な額程度の費用で入手できる方法を用意し、それをはっきりと公表しなければなりません。方法として好ましいのはインターネットを通じての無料ダウンロードです。ソースコードは、プログラマがプログラムを改変しやすい形式でなければなりません。意図的にソースコードを分かりにくくすることは許されませんし、プリプロセッサや変換プログラムの出力のような中間形式は認められません。)

OSD 第2条では、オープンソースである条件としてソースコードが自由に入手可能でなければならないことを規定している。通常のソフトウェアであれば、実行ファイル形式のバイナリファイルに対して改変の許諾がなされていたとしても、技術的には自由に改変できるとは言えない。プログラマが通常扱うソースコード形式のファイルが入手できなければ、自由に改変や派生の自由が確保されていると言えないことは自明であるだろう。基本的にAIモデルはウェイトやパラメータと呼ばれる数値データを保存したバイナリファイルであるので、素直に考えればAIモデルそのものだけではソースコードが存在しないと言える。

しかし、ここである領域におけるオープンソース性の判断のケースを思い出さなければならない。オープンソースのフォントである。オープンソースのフォントとして知られるSIL OFL適用のフォントは、実際どのような形式で頒布されているだろうか。多くの場合、OpenTypeやTrueType形式のファイルで配布されており、これらは文字のアウトラインやメタデータが格納されたバイナリ形式である。フォントにはソフトウェアのソースコードに相当するマスターデータ(テキスト形式)が存在する場合もあるが、それがなくとも、バイナリ形式だけでオープンソースと見做されているのが実情だ。

バイナリファイルの頒布だけでフォントがオープンソースであると見做されるのは、フォントにおいてはソースコードという定義をその文字通りの意味で捉えるのではなく、「改変を加えるために好ましい形式」(preferred form of making modifications)を事実上のソースコードとして見做しているからである。OpenType等のフォント形式は完全に仕様が公開され、FontForgeといったツールを使用することでフォントを解析、編集することができる。つまり、根本的な「改変」や「派生物の作成」が可能であり、実際にバイナリのフォントファイルをそのまま編集することが一般的となっている。つまり、このような事実からバイナリファイルであっても「改変を加えるために好ましい形式」と言え、ソースコードとしての要件を満たすと言えるのだろう。バイナリファイルだけではマスターデータに存在するデザインの意図等の深い情報が欠けることになり、厳密には改変や研究の自由が一部制限されているはずであるが、それでも一般的にはそれで十分に改変と研究の自由を満たしたオープンソースであるという現実的な判断がなされているのである。

このフォントのオープンソース性の判断から教訓となるのは下記の二点であろう。

  • OSDにおける「ソースコード」とは厳密にソースコードそのものを指すのではなく、あくまで開発者がオープンソースである対象物を改変や研究しやすい「改変を加えるために好ましい形式」であることを指す。
  • 開発コミュニティにとって十分に機能する程度の「改変と研究の自由」が確保されているのであれば、一部の情報が欠けた不完全な状態でもオープンソースとして許容される。

前者は、ライセンスの対象物を作成するための材料とも言えるもの全てを揃える必要性はなく、材料を加工済みの形式でも許容されるということを示している。これは一見、バイナリのAIモデルさえ存在していればOSDのソースコード要件を満たすという主張を強化するように感じる。しかし、フォントの場合はバイナリのフォントファイルの中にグリフのアウトラインが全て収まっており、それを編集する手段もあるので事実上ソースファイルと呼べるのに対し、AIモデルの場合にはモデルの動作を完全に再トレーニングしたり大幅に改変したりする場合には全てのデータ前処理ロジックが必要になることもある。よって、AIモデルだけでは「改変を加えるために好ましい形式」には該当せず、前節でのBaに該当する「データを一切必要なしとする論」は不十分であると言えるのだろう。

後者は、開発者のための「改変と研究の自由」が十分に確保されているのであれば、その自由の実現に直接関係しない情報やオブジェクトが必要とは限らないことを示す。フォントの場合でもマスターデータにしか存在しないデザインの意図のような情報は必須とはされていないし、他の領域でも例えばプロプライエタリなコンパイラ等の開発環境やクラウド等の商用サービス環境を必要とするソフトウェアであってもそのコードに「改変と研究の自由」があればオープンソースである。このような事実を総合して考えれば、前節でのAaに該当する「全てのトレーニングデータをオープンデータとする論」は過大過ぎる要求であるとは言えるだろう。確かに全ての材料を構成する情報やオブジェクトがオープンな条件で入手できることは完全な「研究」にとって重要かもしれないが、再現性の確保のために全部の材料が自由に手に入る必要はないのである。

ここまでのOSD 2条「ソースコード」の要件の探究により、オープンソースのAIのために必須となるトレーニングデータの要件は「改変を加えるために好ましい形式」であることが見えてきた。また、開発コミュニティにとって十分に機能する程度の「改変と研究の自由」が確保されるラインは前節の尺度における両端の論の周辺ではなく、Ab-Bbの二つの論のどこかにあることも見えてくる。しかし、このAb-Bbの間には完全なトレーニングデータを必要とするかしないかという全く相反する考え方のラインが存在する。このどちら側にオープンソースAIとしてみなすラインを引くかという問いに答えを出すには更なる詳細な検討をしなければならない。


3. 思想、法制、技術の観点からのトレーニングデータの必要性の検討

「改変と研究の自由」が確保される「改変を加えるために好ましい形式」を実現するラインがAb-Bb間のどのあたりに存在するのか検討するためには、結局の所その中間にあるトレーニングデータを必要とするかしないかという壁から見て左右のどちら側なのかを検討することになる。オープンソースとは自由を求める思想や哲学であり、著作権という法的な権利に基づいた概念であり、ソフトウェアの技術領域における考え方であるわけなので、それぞれ思想面、法制面、技術面の三つの要素から詳細に検討する。

3.1. 思想面からの検討

先ず、思想面からの検討については様々な観点が浮かぶが、下記のようにトレーニングデータの必要性の両論を整理できるだろう。

トレーニングデータのソースコード性

前節までにOSD 2条におけるソースコードとは「改変を加えるために好ましい形式」であることは明らかとなっているが、この定義によって誰もが対象となる何かを研究し、フォークし、改善することが可能となっている。この考え方を援用すれば、AIモデルの機能や性能がトレーニングデータによって決定的に決まる場合、思想的にはトレーニングデータが極めてソースコードに類似するものと言える。このデータが完全にオープンであるのであれば、正確にモデルを再製し、バイアスを精査し、完全に研究を行って結果を確認することもできるだろう。

その一方、トレーニングデータによってモデルの機能や性能が決定的には決まらず、類似のデータやその他のデータを使用して微調整または再トレーニングを行うことができるのであれば、事実上フォークを可能としているとも言える。また、バイアスの精査を含めた研究もトレーニング用のデータセットが収集された場所と方法、フィルタリングの方法などに関する詳細な指示等の詳細な情報さえ把握できれば、必要に応じて同等のデータセットを再構成し、オープンソースである派生物を作成する自由が維持されるとも考えられる。

透明性と倫理的な説明責任

トレーニングデータが全てオープンに利用できるのであれば、それは完全に透明性が確保されていると言える。また、全てのデータを公開するということは、非倫理的な手法で収集されたデータも明らかにできるということであり、コミュニティによる監視も可能になる。例えば、トレーニング用のデータセットに著作権で保護された素材やプライバシーに配慮が必要な素材が適用法上における適切な許可なく含まれていた場合、その問題を明らかにすることに役立ち、修正や法的措置が促されることになるだろう。

これに対し、確かに全てのデータが揃っているのであれば透明性等の倫理的な面にはメリットがあることは間違いないものの、そもそもオープンソースであるための要件にそれが必要であるかという問題が発生するだろう。極論すれば悪い目的であってもオープンソースは成り立つのである。また、AIがオープンソースであるために完全なデータを要求した場合、特に医療、金融や教育等の領域における個人のプライバシー情報を扱うことが事実上無理ということになる。トレーニングデータの完全性を求めなければ、それらのセンシティブなデータの共有を義務付けないということになり、プライバシー関連の法を尊重しつつオープンソースを称するというメリットが生まれるだろう。

自由ソフトウェア的な哲学の追求

オープンソースはライセンス判定基準として見ると基本的に自由ソフトウェアとほぼ同義であり、オープンソースにおいても自由ソフトウェアの哲学というものが共有されていると言える。その自由ソフトウェアの哲学的な観点からは、AIモデルの機能や性能に影響を与える全コンポーネントが「自由」であることが必要となるだろう。AIモデルの機能や性能に対してトレーニングデータがある程度の影響を与えることは確実であるわけなので、哲学的にはデータを必要とし、それによって「ユーザーがあらゆる点でソフトウェアを制御する」という基本的な自由の哲学と合致すると言えるだろう。

この哲学的な観点においては、データの完全性を必要としない陣営からはあまり有効な反論はあると思えない。やはり、自由の哲学からはトレーニングデータをなるべくオープンにするというのは正しいとしか言いようがない。

トレーニングデータのソースコード性、透明性と倫理的な側面における検討からは一長一短だと言えるが、オープンソースの根幹にある自由の哲学からはトレーニングデータを全て公開することを要件とする考え方に分があるように思われる。

3.2 法制及び規範面からの検討

各国の法制度ならびにオープンソースの世界における規範面から下記のように両論を整理できるだろう。

オープンソース定義(OSD)との一貫性

思想面でも触れたように、OSD 2条におけるソースコードとは「改変を加えるために好ましい形式」であり、トレーニングデータが最終的なモデルの動作を実際に形成する場合、AIモデルにおける「ソースコード」の法的な概念を満たすと言える。この場合、AIモデルはソースコードであるトレーニングデータの派生物もしくは二次的著作物であると考えられ、オープンソースとして適合するライセンスがデータセットへ適用されていない限り、そのモデルをオープンソースとは呼べない。また、データセットを完全に取得できない場合、派生モデルの作成を妨げられるという考え方もあるだろう。

しかし、実際には機械学習モデルの根幹は確率論的な演算結果である数値データの積み重ねでしかなく、グローバルな知的財産権の考え方では通常このような出力に権利は発生せず、著作権の許諾でしかないライセンスは伝播しないどころか、基本的に何も影響しない。著作権保護されたデータが複製されて出力に残存するようなケースであれば派生と見做せるが、それは極めてレアケースとなるのだろう。日本では情報解析の権利制限規定(著法30条の4等)、シンガポールでは計算機データ解析の権利制限規定が存在するように、AIトレーニングに対して著作物の無許諾の利用が認められている法域もある他、米国でも著作物の変容的利用としてフェアユースに該当する行為であるとの考え方が強い。このようにトレーニングデータの権利がモデルに及ばない状態であるににも関わらず、それを「ソースコード」と見做すのは厳しいように感じられる。また、そもそもAIトレーニングのような情報解析ともデータマイニングとも称される行為は多くの法域で無許諾での著作物の利用が認められているが、そのトレーニングに使用したデータを一般に広く再頒布することは通常は制限されている。ここで、「データを共有する意義」とのミスマッチが生じるだろう。

さらに、フォークの可能性に関しては、一部もしくは多くのデータが欠けていたとしても類似のデータを充足することができるのであれば、フォークは可能と言えるだろう。前節でのフォントでのオープンソース性の判断のアプローチは、まさにこのような元々の材料が存在しないワークフローにおける中間形式からのフォークを認めているように見える。

著作権とプライバシー法

一般的にトレーニングデータには多くの著作物が含まれており、一部の法域ではデータの集合物にデータベース権を付与されることもあり、大規模にキュレーションされたデータセットを何らかの知的財産権で保護された編集物として扱うことは可能である。このデータセットが実際に「ソースコード」である場合、そのデータにオープンソースもしくはそれに類似したライセンスを要求することは、ソフトウェアのソースコードにライセンスを要求することと論理的には一致する。また、それらのトレーニング用のデータセット全体を公開することで、多くの法的な不確実性が解消されるという側面もあるだろう。データの一部が非公開であるなら、そのトレーニングデータを利用したモデルの派生モデルを開発した者はトレーニングデータに関わる契約や許諾、あるいは何らかの法に意図せず違反するリスクを負うことにもなる。

しかし、前項でも書いたように、一般にAIモデルにおけるトレーニングとは確率論的な演算結果の積み重ねであって、現時点において、モデルに対してトレーニングデータの知的財産権の影響は特に何も発生しないというのが多くの法域での考え方であるだろう。データに対する権利がモデルに残存しないのであれば、それが「ソースコード」であるかは説得力が欠けてくる。また、一般に公開されアクセス可能なコンテンツデータの大部分には何らかの使用制限が課せられている可能性が高く、全てのデータをそのまま頒布することは、第三者の権利を侵害するリスクが発生することになる。さらに、多くの法域では、特定の機密情報や個人を特定できる情報の共有はプライバシーデータ保護に関する法(EU GDPR、HIPAA等)によって禁止されている場合が多いだろう。データセット全体の頒布をオープンソースAIにおける条件として要求すると、条件に適合するためにこれらの法律に違反することになってしまうというのは本末転倒であるだろう。

全てのトレーニングデータへ容易にアクセス可能であり、またそれらがオープンソースに類似したライセンス条件で利用できるのであれば、確かに法的な確実性は上がる。また。特定の科学系領域においては、正確な再現性というものが重要であり、そのためにデータの完全性が重要であることは理解できる。しかし、それらのデータに発生している知的財産権が作成されたモデルには残存しないという現在のAIトレーニングに対しての多くの法域での一般的な理解においては、AIモデルがオープンソースと称するための条件としてそれらの完全性を求めるのは中々難しいように感じる。また、一般に共有することが難しいデータというものは様々な分野における機密情報やプライバシーデータ等、多岐に渡るものであり、それらを扱うことでAI開発者を法的リスクに晒すことがないようにするには、生のデータを条件とするのでなく、あくまでデータの来歴等の詳細な情報を求め、派生の可能性を高めるアプローチが向いているように考えられる。よって、「改変を加えるために好ましい形式」を法的に考えると、完全なデータ公開を条件としない方が妥当であり、現実の法や規範に合わせやすいのだろうと考えられる。

3.3. 技術面からの検討

技術面に関しては私は門外漢であるが、一般的な技術解説から検討すると下記のように両論を整理できるだろう。

AIモデル開発と動作分析

AIトレーニングのアルゴリズムはデータから何らかのパターンを学習するものであって、データはウェイトを効果的にプログラミングするとも表現できる。そのため、データはモデルのロジックの一部であるとも言えるのだろう。実際、モデルに何らかの欠陥がある場合、開発者はトレーニングデータの収集やラベル付けの手法を再検討する場合もあるようだ。これはデバッグや改善、あるいはバイアスやエラーの検出といった信頼性確保のための行為のために実施されることもあるのだろう。このような場合は全てのトレーニングデータが自由に入手できることが重要と言える。

一方、実際のモデル開発におけるワークフローにおいては再トレーニングよりも微調整の方が多いという現実がある。多くのAIモデル関連の開発は元のトレーニングデータ全体へのアクセスを必要とせず、ビジネス等におけるドメイン固有のデータに基づいた微調整がほとんどであり、大規模なファウンデーションモデルを最初から再トレーニングし直すという需要はほぼ存在しないだろう。モデルのウェイトとトレーニングのパイプラインの詳細が公開されていれば、それは事実上のフォークとしてモデルの改善を効果的に実行できることになる。AIをオープンソース化することの価値の一つはハイパーパラメータを含めてパイプラインを共有できることでもあり、これによって第三者の開発者が別のデータセット(オープンあるいはプロプライエタリを問わず)で代用して、元のAIモデルのアーキテクチャと方法論のメリットを享受できるのである。

完全な再現の必要性

通常のソフトウェアでは、ソースコードを入手することでビルドを完全に再現できる。だからこそ、ソースコードを入手できることがオープンソースである要件の一つになっているとも言える。それを当てはめればAI領域においても同様に、AIモデルを正確に再現するには完全なデータが必要という主張は理解できるものである。同一のデータがなければ、最終的なモデルには微妙ではあるが重要な点で異なる結果が生じる可能性があると主張する者も多い。

それに対し、非決定論的な演算、ランダムシード、ローカルな開発環境の違いを考慮すると、特に大規模なモデルのトレーニングにおいては完全な再現が事実上不可能であるとも言われている。であれば、ほぼ同等の類似のデータをもってトレーニングを行い、同等のパフォーマンスを達成するのであれば実質的な同等性を実現するという一種の妥協が許容される余地が出てくると考えられる。おそらく、多くのAI/ML開発者や研究者にとっても、「研究」と「改変」の自由というものに完全なビット単位での完全な再現性が含まれるという感覚はあまりないのが実情ではないだろうか?それであれば、詳細なデータドキュメントと完全なトレーニングコードにより、同一の生データを必要とせずに実質的な再現性を実現し、それをもって「研究」と「改変」の自由を確保したという考え方は可能であろう。

データがモデルのロジックの一部であるという考え方も完全なモデルの再現のためには完全なデータが必要であるという考え方も既存のソフトウェア開発においてであれば理解できるものではあるのだろう。ただし、データがモデルの動作を直接的に定義しているわけではなく、モデルの動作がコードのアルゴリズムに依存することは確かであり、さらにデータセットはコードによって処理される単なる入力という側面もあることから、モデルを創造しているソースコードと言えるかは疑わしい部分もある。また、完全に全てのデータとコードが揃っていたとしても完全なモデルの再現が可能であるかも疑わしく、そもそも完全な再現は多くの開発者にとって必要かも疑わしい。オープンソースであるためには「研究」と「改変」の自由が確保される必要があるが、その二つの要件はデータに関する十分に詳細な情報が入手できれば良いという考え方が現実的であるように考えられる。

3.4. 思想、法制、技術の観点からの検討の帰結

AI領域における「改変を加えるために好ましい形式」を思想、法制、技術の各観点で検討したわけだが、思想的には全ての関連するコンポーネントが「自由」であることは我々のコミュニティの哲学としては正義であるかもしれない。

ただし、オープンソースというものは「全ての第三者に対し、著作権法若しくは類似の法上で規定された権利を行使する利用行為への自由を与える法的条件」のことであることを鑑みると、法的な観点における解釈が優先されるだろう。法的観点においては、データに発生している知的財産権が作成されたモデルに残存しないという多くの法域での解釈を鑑みると、やはりデータの完全性は行き過ぎた要件に思えるし、また、プライバシーデータ等の扱いを考慮するとそれらのデータの共有を求める要件というものが現実の社会に適合しないとも考えられる。

さらに、技術的な観点では、モデルを直接的に制御しているのはコードのアルゴリズムであろうし、仮に完全なデータが共有されたとしてもモデルを完全に再現することは困難であり、またその必要性もさほど多くはない。これらを総合して考えると、「改変を加えるために好ましい形式」には完全なデータセットの共有を必須条件とすることは現実的ではなく、それを埋め合わせるために類似のデータを用意できるようにするための情報があれば問題ないという整理ができるのだろう。これにて現実社会における法や規範との整合性が出てくるのだと思う。純粋な思想的なアプローチによるオープン性は完全なトレーニングデータを要求するかもしれないが、トレーニング コード、パラメーター、およびデータ情報を必要とするOSIのアプローチは、オープンソースAIの幅広い採用を促進する実現可能なバランスを実現するだろう。

よって、1節にて提示した Aa – Ab – Bb – Ba の直線の尺度上において、AIシステムがオープンソースであるために必要なデータに関する条件の境界線としては、完全なデータの公開を求めない左側の領域にあるBbに近い所に線引きされると考える。これはOSIが作成したOSAID v1.0におけるデータ情報の要件に近いものである。


4. データ要件に関する将来の展望

オープンソースAIであるための要件に完全なトレーニングデータの共有を要求するかどうかの議論は、完全な再現性と透明性を求める自由の哲学に依拠する考え方と知的財産権やプライバシー等の様々な法的制約と共存しながら現実的なオープン性を求める考え方との間で緊張関係にある。

トレーニングデータの完全な共有への支持者は、データこそがAIの「ソースコード」であり、すべての元の入力がなければモデルの完全な再製や公平性と透明性を実現する監査を実現できないと主張している。一方、OSIが定義したOSAIDのアプローチは、データはモデルのトレーニングに不可欠であるものの、完全なデータセットを共有することは、多くの場合において法的に不可能なケースや実質的に大きな意味がないケースもあるという現実的な考え方に依存している。データセットの詳細で包括的な「データ情報」を要求することでフォークの可能性を維持し、プライバシーや法的制約によって制限されている分野においてもオープンソースAIが実現できるという可能性を残しているとも言えるだろう。

OSAIDは、完全なトレーニングデータの共有がモデルの再現性への最も純粋なルートであることを否定するものではないが、オープンソースAIが現実の世界で成功するためには許容可能な妥協が必要であることを示したものであるのだろう。使用(Use)、研究(Study)、改変(Modify)、共有(Share)の四つの原則を遵守しながら、必要であればトレーニングデータをある程度非公開にできるという現実的な境界線を示しているのである。現時点のOSIのアプローチは、AI領域においてオープンソースの精神を維持しながら、実用的なバランスを取っていると言える。

一方で、「オープンソースAIと称するには完全なトレーニングデータを共有すべきだ」という論点が、今後すぐに決着することはないだろう。AI領域は変化が激しく、進行中の訴訟や各国でのデータプライバシー規制、AI業界における規範の確立など、状況を劇的に変化させる要因が数多く存在するためだ。

例えば、2節で触れているフォントのオープンソース性に関しては、現状ではTTF/OTFがそのままソースコード、つまり「改変を加えるために好ましい形式」としてみなされているが、主要なデザインに関するデータがTTF/OTFの外部に存在するようになった場合には、TTF/OTFだけではソースコードとみなされなくなり、追加のデータの共有がオープンソースであるとみなすための条件となっていくだろう。フォントの例と同様に、AIの領域でも現状のOSAIDよりも実質的なデータの共有が必要になる状況が強まるかもしれないし、それとは逆に、トレーニングデータの完全な標準化が進んだ場合やウェイトの解析だけである程度以上のモデルの機能や性能を正確に把握できるようになった場合にはトレーニングデータの情報すら然程重要ではなくなるかもしれない。どちらの状況になったとしても、結局はその都度に「改変を加えるために好ましい形式」とは何であるかという点を検討し、使用(Use)、研究(Study)、改変(Modify)、共有(Share)の自由を実現できる基準を示すことがOSIには求められるのだろう。


5. 最後に

私はOSAID作成の議論には初期から関わっているが、特に本稿のテーマである完全なトレーニングデータの共有がオープンソースAIであるために必要であるか否かという議論には本当に手こずらされた。非常に難しいテーマであり、立場によって異なる見方になることも分かっているが、両者のバランスを取ろうとする者等を一方的に中傷する者達が出てきたことには本当にうんざりさせられたし、残念でもあった。特に巨大IT企業に属する者からの一方的な攻撃には本当に呆れている。

オープンソースという言葉の歴史は常に自由の哲学と現実的な法と技術のバランスを取ってきたものであり、OSIはAI領域において懸命にその境界線を引くために奔走している。AI領域においては我々のオープンソースコミュニティにとってもまだ未確定な要素も多く、今後も立場の違いにより様々な主張がぶつかり合う可能性はあるだろう。そのような時には、一方的な主張の押しつけではなく、多角的に問題を検討し、現実的な解を見つける努力をしてほしいと願っている。

DeepSeekは何故ユーザーの検閲を行いつつオープンソースなのか? – 中国における生成AI規制

DeepSeekアプリがユーザーの入力や出力といった情報を中国内のどこかに送信している可能性について世界中で大騒ぎとなっているが、これは特に今始まったことではなく中国の国内法に依拠する問題である。元々この文書、というより短いメモ書きは欧米人向けに説明するものだったが、それを和訳?の上で若干加筆して下記に残す。

2023年、中国の政府機関は「生成式人工知能サービス管理暫定措置」(生成式人工智能服务管理暂行办法)を制定し、生成AIサービス業界のための規制のガイドラインとした。
[参照:https://www.cac.gov.cn/2023-07/13/c_1690898327029107.htm]
この法律には、第三者による知的財産権を尊重し、侵害しないこと、個人の要求に応じて個人情報を取り扱うこと、民族や思想に基づく差別を禁止すること、トレーニングデータを含めて透明性を向上させること、高品質なトレーニングデータの入手可能性を高めること、健全なAIエコシステムを構築するための協働と共有を促進することなど、様々な賞賛すべき規定が含まれている。その内容の多くが科学的合理性に重点を置いていることは、中国らしさを感じさせる。

しかし、当然ながら問題点もいくつかある。
この法の第4条には次のように書かれている(括弧内は原文中国語、その後に日本語訳)。

第四条 提供和使用生成式人工智能服务,应当遵守法律、行政法规,尊重社会公德和伦理道德,遵守以下规定:
(一)坚持社会主义核心价值观,不得生成煽动颠覆国家政权、推翻社会主义制度,危害国家安全和利益、损害国家形象,煽动分裂国家、破坏国家统一和社会稳定,宣扬恐怖主义、极端主义,宣扬民族仇恨、民族歧视,暴力、淫秽色情,以及虚假有害信息等法律、行政法规禁止的内容;

日本語訳:

第4条:生成型AIサービスを提供または利用する際には、法律および行政法規を遵守し、社会道徳および倫理を尊重し、以下の規定に従わなければならない。
(1)社会主義核心価値観を堅持すること。国家政権の転覆や社会主義制度の打倒を扇動する内容、国家安全や利益を脅かす内容、国家のイメージを損なう内容、国家分裂を扇動する内容、国家の統一や社会の安定を損なう内容、テロリズムや過激主義を助長する内容、民族間の憎悪や民族差別を助長する内容、暴力やわいせつ、ポルノを助長する内容、法律や行政法規で禁止されている虚偽や有害な情報を含むコンテンツの生成は禁止されている。

社会主義核心価値観」とは、国家、社会、個人それぞれが守るべきとされる12の価値観を指す。中国の政治的枠組みでは、これらの価値観と矛盾するとみなされるコンテンツは、原則として排除される。これが、AIモデルにバイアスを組み込むことの根拠となっている。

そして、第11条および第14条には、次のように記載されている。

第十一条 提供者对使用者的输入信息和使用记录应当依法履行保护义务,不得收集非必要个人信息,不得非法留存能够识别使用者身份的输入信息和使用记录,不得非法向他人提供使用者的输入信息和使用记录。
第十四条 提供者发现违法内容的,应当及时采取停止生成、停止传输、消除等处置措施,采取模型优化训练等措施进行整改,并向有关主管部门报告。

日本語訳:

第11条:プロバイダーは、法律に従い、ユーザーの入力情報および利用記録を保護する義務を履行しなければならない。不必要な個人情報を収集してはならず、ユーザーを特定できる入力情報および利用記録を違法に保有してはならず、またユーザーの入力情報および利用記録を違法に他者に提供してはならない。
第14条:プロバイダーは、違法なコンテンツを発見した場合、速やかにその生成を停止し、送信を停止し、または削除するなどの措置を講じなければならない。また、モデル最適化トレーニングなどの措置を講じて問題を是正し、関連監督当局に報告しなければならない。

この法的枠組みに基づき、第4条で求められている「社会主義核心価値観」を維持するために、第11条ではプロバイダーがすべてのユーザー活動を記録することを義務付け、第14条ではこれらの記録に基づく検閲を正当化している。これらを総合すると、これらの規定は生成AIアプリケーションや生成AIのWebサービスにおけるユーザーの入力と出力の監視を事実上合法化及び義務化していることになるのだろう。言い換えれば、DeepSeekアプリが様々な情報を中国に送信している場合、それは単に中国の国内法に従っているだけということになる。これは当然ながら中国国内の企業によって運営されているその他の全てのAIサービスにも当てはまる。

なお、第6条には次のように書かれている。

第六条 鼓励生成式人工智能算法、框架、芯片及配套软件平台等基础技术的自主创新,平等互利开展国际交流与合作,参与生成式人工智能相关国际规则制定。」

日本語訳:

第6条:生成型AIアルゴリズム、フレームワーク、チップ、およびサポートソフトウェアプラットフォームなどの基礎技術における自主的なイノベーションを奨励する。平等かつ互恵的な国際交流および協力を行い、生成型AIに関する国際的な規則の策定に参加する。

中国企業によるAIサービスを利用する際には特段の注意が必要であることは疑いようがないだろう。ただ、同時にこれらの国家が義務付ける検閲が生成AIサービスとアプリケーションのみに課せられていることは興味深いことでもある。AIモデルを開発する行為に関しては、第6条において国際交流と国際ルールの順守を前提にして、そのような活動を推進すべきであると明確に規定している。この姿勢こそが、オープンソースのライセンスの下でAIモデルを頒布することを推進していると考えられる。MITやApache 2.0などのライセンスでAIモデルを頒布することは、この点において中国の国家戦略に沿うものでもあるのだろう。

中国のAI規制には一見矛盾する二つの側面がある。一方では強力な検閲システムを義務付け、もう一方ではAI技術開発における国際協力と協働を重視している。これは、技術開発と安全保障のバランスを取るという中国の戦略的アプローチを反映しているのかもしれない。

Llamaライセンス契約を適用するAIモデルを使用する際の多大なリスク

Meta Platforms社のLlamaモデルならびにLlamaライセンス契約(Llama Community License Agreement)がオープンソースに全く該当しないことは既に解説した通りであるが、Llamaライセンス契約にはオープンソースであるか否かという観点において直接的に関係せず、実用に際して予期せぬライセンスの終了にも繋がりかねない幾つかの重大な問題が潜んでいると考えられる。Llamaのオープンソース性に関する論考と重複する部分も多く含まれるが、ここではそれらの問題に対する危険性について雑多に解説する。

なお、本稿はLlama派生モデルの開発やLlamaモデルを自社サービスに組み込もうと検討している企業・エンジニア・コンプライアンス担当者を主な対象としてLlamaモデル利用における潜在的リスクを整理したものであるが、具体的な利用事案への法的助言を提供するものではなく、深い解釈や具体的な実務の助言が必要な場合にはなるべく米国契約法とカリフォルニア州法に精通した専門家に相談することを推奨する。

  1. 一方的な許諾ライセンスとは異なる契約としての性質
  2. 7億MAU制限を企業は無視できるか? 合算での抵触リスクは?
  3. 大企業以外の企業は7億MAU制限は関係ないのか?
  4. 子会社、親会社、関連会社にまでLlama利用規約の遵守が義務付けられているか?
  5. 契約義務と利用規約の遵守はどこまでの範囲で求められるか?
  6. 利用規約が更新された場合は新規の条項も遵守する必要があるのか?
  7. 利用規約が更新された場合にどのようなリスクが考えられるか?
  8. 利用規約の条項は自国の法による解釈をしても問題ないか?
  9. モデルの出力とその出力結果によってトレーニングされたモデルにはLlamaライセンス契約は伝播するのか?
  10. むすび
  11. 参考:
  12. Llama 3.1 コミュニティライセンス契約 日本語参考訳
  13. Llama 3.2 Acceptable Use Policy(利用規約) 日本語参考訳

一方的な許諾ライセンスとは異なる契約としての性質

まず、本稿を書くにあたっての前提として、Llamaライセンス契約の法的な位置付けがオープンソースの考え方で一般的な著作権の許諾ではなく、二者間の商業的な取引上での契約であることに注意しなければならない。Llamaライセンス契約という名称そのものや契約テキスト冒頭における「Agreement」の定義において既に契約だと宣言しているようなものだが、同意ボタンのクリックやLlamaの利用によってライセンシー側が契約に拘束されることを同意させる仕組みになっていること、ならびに契約テキストの各所でMeta社に発生する知的財産権に基づく権利以上の制約をライセンシー側へ課していることなどから、明らかに著作権等の許諾というよりも契約としての体裁が備わっている。実際、Meta社からのモデルのダウンロードに際しては利用者側のサインが求められるので、著作権ライセンスではなく米国の契約法に基づくMeta社と各ライセンシー間における二者間の合意による商取引の契約という体裁とが整っていると見做すべきだろう。

オープンソースとは、ソフトウェア等の著作物において複製、翻案、頒布、公衆送信等の各国における著作権法および類似の法上で規定された権利を行使する利用行為への自由を与えるライセンスもしくはそれらのライセンスが適用されたソフトウェアであり、これを言い換えれば、各国の著作権法上で認められている権利者がある種の利用制限をかける権利に対して自由に利用できることを宣言する法的手段である。著作権表記や二次的著作物におけるライセンスの継承等の義務とされるものは、この自由な利用のための条件に過ぎない。米国での幾つかの訴訟の結果により、契約としての強制力が認めらてきているのは事実であるが、一般的なコンプライアンスの実務上は単に一方的な自由利用の宣言をしているとみなしており、そこに契約手法的な同意や対価というものは存在しない。

一方、Llamaライセンス契約は、Meta社と利用者の双方に合意に基づいて対価(約因)の交換がなされたと解釈するべきであり、AIモデルの利用を利用制限と利用規約の遵守を確約することで契約が成立していると考えられる。著作権ライセンスは著作権に依拠することから著作権の効力が及ぶ範囲でしか制限をかけることはできないが、契約法に基づくことによって契約当事者の双方の合意をもって知的財産権の範囲を超えた領域まで取引の範囲が拡張され、また相互の義務の法的な強制力が高められているとも言えるだろう。

さらに、契約法に基づくことで文字通りの契約テキストを超えた拡張が行われる可能性も考慮しなければならない。Llamaライセンス契約の準拠法はカリフォルニア州法と規定されているが、契約にやや曖昧な条文があったとしてその解釈は基本的に当事者の意図に即したものとなり、契約テキスト内の一つ一つの文言の意味は厳密な法的意味ではなく、一般的な意味で理解されなければならない。例えば、契約テキスト上では直接的に何らかの行為を制限する内容の文言が含まれていないとしても、それと類似の行為が制限される条項があったり、契約全体の意図としてその行為を制限していると読み取れるような場合にはその行為が制限されることを裁判所が支持する場合があり得るということである。付与した瞬間に利用者の権利が確定するオープンソースのようなライセンスとは全く世界が異なると考えなければならない。

7億MAU制限を企業は無視できるか? 合算での抵触リスクは?

Ans: 7億MAU制限は、一般的に考えられている範囲より多くの企業へ影響し、無視することができないだろう。

セクション 2 条文
“If, on the Llama 3.1 version release date, the monthly active users of the products or services made available by or for Licensee, or Licensee’s affiliates, is greater than 700 million monthly active users in the preceding calendar month, you must request a license from Meta …”
(Llama 3.1のバージョンリリース日において、ライセンシーまたはライセンシーの関連会社によって、もしくはライセンシーまたはライセンシーの関連会社に対して提供される製品またはサービスの月間アクティブユーザー数が直前の暦月において7億人を超える場合、あなたはMetaからのライセンスを要求しなければならず、)

Llamaライセンス契約のセクション2はそのまま月間7億MAUのユーザーを抱える企業はLlamaモデルをMeta社の許諾なしでは使用できないと規定している。本邦においては、このセクション2はオープンソース性の議論では触れられるものの、月間7億という数字の巨大さから米国と中国の巨大IT企業の数社のみが対象として考えられ、いわば対岸の火事のような感覚で見られているように思う。しかし、本当にその他の国の大企業には関係のない条項なのだろうか?

このセクション2をよく見ると、この制限はLlamaを採用するサービス若しくはプロダクトのユーザー数に対する制限ではなく、利用者となる企業全体に対する制限であることが読み取れる。そして、「Licensee’s affiliates」という表現から利用者である企業の子会社や親会社も含まれることも分かる。affiliatesという用語に対しての定義は契約テキスト内に存在しないが、一般的には50%以上の持分関係で繋がる全ての子会社や親会社が抱えるユーザーも考慮しなければならないということになるのだろう。米国法準拠の契約であれば、厳密には親子関係以外にも取引上のパートナーシップや、共同出資のジョイントベンチャー的な関係もaffiliatesとされる場合があるので、50%以上の資本関係で繋がる全ての企業群と考え方は最低限のラインだと考えねばならない。つまり、単純に考えれば2億MAUを抱えるサービスが4社存在し、それらが50%以上の資本関係で繋がっている場合、全て合算すると8億MAUということでセクション2への抵触を心配せねばならないだろう。

ここで、2億MAU x 4社で8億MAUとなるのは重複を無視していて乱暴だという主張が出てくるだろう。というより、それが妥当な考え方だろう。実際、ライセンサーとしての当事者であるMeta社は2024年度の数字で自社のMAUを月間40億MAUと発表しているが、その内訳としてFacebook 30億MAU、WhatsApp 20億MAU、Instagram 20億MAUとも発表しており、これは明らかに各サービスのMAUの合算数字よりも小さな数字を企業全体のMAUとしていることになる。少なくともMeta社は何らかの方法でユーザーの重複を省いていると考えられるが、これを業界標準とするなら同様の方法でユーザーの重複を排除することが合理的な判断と考えられる。しかし、異なるシステム間において同一ユーザーと明確に判断する方法がないような場合やシステムのアカウントを使用しないメディアサービスのユーザー数はどのように考えれば良いのだろうか?単なるWebメディアの場合はトラフィックの分析ツールの数字をそのまま合算する方がビジネス上合理的な判断とされるのではないだろうか?

また、ライセンシーが日本企業であれば、日本の人口1.2億人なのでそれをMAUが上回ることはないという主張もあるかもしれない。このような主張は通信回線が必要な通信サービスや完全に日本国内の事情に合わせたサービス等であれば有効である可能性がある。ただ、前述のMeta社全体での40億MAUという数字を考えてみてほしい。世界人口は80億人であり、Meta社のサービスが規制される中国の人口は約14億人、世界の13歳未満の人口は約20億人といった数字を考慮すると、Meta社サービスを利用可能な世界の人口の80%以上がMeta社のサービスを月に一度は使用していることになる。自分はそこに含まれていない側の人間であるので偏見があるかもしれないが、正直な所、実際の人口と比較するとかなり過大な数字であるように思う。複数アカウント、ビジネスアカウント、バックアップやボット等がこの過大とも言える数字を作り上げているのだと考えられるが、つまりMeta社としては、MAUにおけるユーザーとは一意の個人を指すのではなく、アカウントのアクティビティに基づいていることを示している。そして、これはソーシャルプラットフォーム業界の標準的な慣行でもあるのだろう。となると、日本の人口1.2億人というリアルな人間に依存して上限を申告してしまう仕組みは、オープンなプラットフォームやサービスであれば特に意味をなさないことが分かる。

ここまでを総合すると、特定の巨大IT企業以外の企業グループであっても、総体として巨大なコングロマリット的な企業グループを形成し、各グループ企業においてアカウントやユーザーの重複を判定する仕組みが乏しく、幾つかの国にまたがってユーザーを獲得しているサービスを保有しているグループ企業が存在する場合、Llamaを利用する当事者となる企業が意図せずにセクション2の7億MAU制限に抵触する可能性は否定できないのではないかと考えられる。

実際、東欧を中心に8億MAUを記録する通話サービスアプリを展開する企業を海外子会社に持つ電子商取引を中心とした日本の企業グループはセクション2に抵触すると考えられるし、5億MAUを記録する求人サイトを運営する米国の子会社を保有する人材情報サービスを中心とする企業グループも他のサービスとの合算で7億MAUの制限を越える可能性が高いのではないだろうか?他にも幾つか7億MAUの制限にかかりそうな企業グループは存在するが、そのような企業グループに属する企業はMeta社の別途の許諾がない限りはLlamaを利用すべきではないだろう。

なお、企業グループ内のMAUを色々細かく数字を整えて何とか7億MAU以下にみせかける資料を作って備えたとしても、例えばCEOやCFOが業績発表会等で7億MAUを越えていることを公言していた場合、それは米国法における「利益に反する自白」(Admission against interest)として扱われ、訴訟において他の証拠よりも重要な非常に強い証拠となり得ると考えられる。結局のところ、Meta社からすれば自社を脅かす程度にまで成長しそうな企業にはLlamaを無料で使わせたくないのであり、ここでの検討は特に関係なく、Meta社の一存で「制限を超えているので契約終了」と主張する権限を契約で持たせている以上、大きなコングロマリットを形成する企業グループ内でLlamaを利用することは避けたほうが無難なのだろう。

大企業以外の企業は7億MAU制限は関係ないのか?

Ans: 中小規模の企業が7億MAU制限に全く関係ないとは言い切れない。

このセクション2による制限を受ける企業グループならびに予備群企業グループの企業に属していないので問題ないという考え方も少し外れており、Llama派生モデルやサービスを開発する企業が合併や買収を実行する際に巨大企業を相手にできないという問題が発生するだろう。会社を売却したいと考える企業にとってM&A先となる企業を絞られてしまうことはLlamaモデルを利用すること事態がリスクになるだろう。

また、例えばLlama派生モデルを開発し、それを利用するシステムやソリューションを巨大な企業グループに納入するといった場合、その納入先となる企業がLlama派生モデルを使用する権利はMeta社とのLlamaライセンス契約に基づくので、その時点で7億MAU制限に抵触するリスクを考慮しなければらならない。セクション 1.b.iiにおいて「統合エンドユーザー製品の一部としてLlamaマテリアルまたはその派生作品を受け取った場合」は、セクション 2における7億MAU制限の適用外となることが規定されているのだが、契約テキスト上ではここでの統合エンドユーザー製品という用語が詳細に定義されていないものの、少なくともネットワーク越しのサービスであるとか、あるいは完全にパッケージ化されている製品において、組み込まれているLlamaマテリアルに対して顧客側が直接的にLlama派生モデルへアクセスする権限を有していない場合を指すケースに限定した例外規定と考えられる。つまり、ベンダー側が構築を行ってLlamaモデルを含むシステムの運用は顧客側で継続するようなケースには該当しないと考えられる。これは日本企業では特に注意すべき点なのだろう。

子会社、親会社、関連会社にまでLlama利用規約の遵守が義務付けられているか?

Ans: 関係会社にまで義務が波及することが確実とは言い切れないが、ケースによって事実上全てのグループ内企業へLlama利用規約の遵守が義務付けられるだろう。

Llamaライセンス契約のセクション 2では、ライセンシー側における7億MAUという閾値での使用制限を課しているわけだが、そのMAUの計測範囲は「ライセンシーの関連会社(Licensee’s affiliates)まで明示的に含んでいる。ここでの関連会社は50%以上の資本関係でつながる企業グループ全体を指すと考えられるが、Llamaライセンス契約のテキスト内にこれ箇所以外の関連会社という意味合いを含む表現は存在しない。このことから、あくまでMAUを計測する際だけ子会社や親会社の存在や状況を気に掛ける必要があるという解釈をしがちになる。

セクション 1.b.iv 条文
“iv. Your use of the Llama Materials must comply with applicable laws and regulations (including trade compliance laws and regulations) and adhere to the Acceptable Use Policy for the Llama Materials (available at https://llama.com/llama3_1/use-policy), which is hereby incorporated by reference into this Agreement.”
(iv. あなたによるLlamaマテリアルの使用は、適用される法律および規制(貿易コンプライアンスに関する法律および規制を含む)を遵守し、Llamaマテリアルに関する利用規約(https://llama.meta.com/llama3_1/use-policy で入手可能)に従う必要があります。このポリシーは、参照することによって本契約に組み込まれます。)

しかし、これを契約内の他の条項と併せて読むと様相が異なってくる。セクション 1.b.ivでは、Llamaマテリアルの使用に際して利用規約(AUP: Acceptable Use Policy)を遵守することが求められている。この条文だけではあくまでライセンシーだけを対象としているように読めるが、セクション 2と併せて読むと「あなたによるLlamaマテリアルの使用」(Your use of the Llama Materials)には関連会社による使用も含まれるのではないかという疑問が出てくる。

実際、多くの企業グループにおいては、一つのソフトウェア若しくはサービスのエンタープライズ契約を同じ企業グループ内の複数の企業で共有することはよくあることである。開発子会社等として本社から分離しているような企業グループの場合、親会社の契約に子会社分の利用も契約へ組み込むことはソフトウェア業界ではよくある慣行ではないかと思う。これはLlamaのようなAIモデルにおいても同様であると考える方が自然であるだろうから、Llamaモデルを利用するシステムをLlamaライセンシーである会社とその子会社や親会社が共有し、利用することをあり得ることである。この場合、Llamaモデルを共有する子会社や親会社は事実上Llamaマテリアルのユーザー若しくは共同の頒布者ということになり、Llama利用規約への遵守義務が伝播することになるだろう。そもそも、LlamaモデルをMeta社からダウンロードし、何らかのシステムへ利用した当事者ではないとしても、その派生モデルを親会社等が共有しアクセスできるのであればモデルを使用を開始した時点でその親会社もMeta社との契約関係になるので、関係会社にも利用規約の遵守義務が発生することはLlamaライセンス契約の伝播性の観点からも当然のことと言える。

一方、50%以上の資本関係で結ばれている企業のそれぞれが全く独立した経営がされていることもよくあることである。このような場合、一方の会社がLlamaモデルを利用しているからといってもう一方の会社もそのモデルによるシステムを共有しているという可能性は低く、また、独立した関係性であることが外部からもわかりやすく一般に周知されている場合には問題となることはほぼないのでないかと考えられる。

ただし、資本的に親子関係である場合に当事者間においては相互に独立した関係であると認識していても、その関係性がMeta社からも分かるようになっているわけではない。同じ企業グループに属しているのであればLlamaマテリアルが内部で共有される可能性を疑うことは当然にあり得ることであり、ライセンシーである企業とは別の同じ企業グループに属する企業においてLlama利用規約に抵触するような行動に対して何らかのAIモデルが関与していることが明らかであれば、やはりLlamaマテリアルが内部で共有されていると外部から推測されるわけである。Llamaライセンス契約のセクション 6では利用規約に違反した場合にMeta社の裁量による即時の契約の終了を認めており、Meta社が企業グループに属する企業群を同一のエンティティとみなして契約の終了を主張することはあり得ると考えられる。このMeta社による契約終了の行動が訴訟に発展したとしても、セクション 2での関連会社までを含めた制限やセクション 1.bにおけるライセンス契約の伝播性を考慮すると、企業グループ全体を同一のエンティティとみなす主張を裁判所が支持する可能性はそれなりに高いのだろう。

よって、日本によくあるITコングロマリット的な企業グループ内の企業においては、グループ全体でLlama利用規約で書かれているような利用法に抵触する行為をしていないかどうかを監視し、相互にその情報を共有していく必要があるのだろう。おそらく、これはLlamaだけの問題に留まらず、他のAIモデルでも同様ではないかと考えられる。

契約義務と利用規約の遵守はどこまでの範囲で求められるか?

Ans: 契約上の義務事項はライセンシーだけを拘束するが、利用規約の遵守義務はその範囲を越えてLlamaを利用するサービスのエンドユーザーにも影響する。

オープンソースのライセンスは基本的にライセンサー側による著作権の一方的な許諾であり、許諾の条件となる事項の遵守義務は対象となるソフトウェアを著作権法上で規定される権利を行使する態様、すなわち複製、頒布、翻案、公衆送信等の行為を行う際に利用者を拘束すると言える。つまり、全ての人々にあらかじめ権利の許諾が与えられた状態であり、単純な使用者である場合には基本的な原則としては何も拘束されず、著作権法上で認められた利用行為に及ぶ場合にのみ義務が発生する。

一方、Llamaライセンス契約は、Llamaダウンロード時の同意ボタンのクリックまたはLlamaマテリアルの一部若しくは要素を使用若しくは頒布を行なった場合にMeta社と利用者側に契約が締結されるという体裁になっている。この場合、Llamaをダウンロードした者および使用者全てがMeta社と二者間の契約関係となり、Llamaライセンス契約に従った義務事項に拘束されることとなる。

この両者は単に最初の開発元からダウンロードして使用するまでは遵守する義務に違いはあるものの形式的には大差はない。ただ、ライセンスの効力が及ぶマテリアルを他社へ頒布する場合、後者は第三者から頒布を受けたライセンシーはMeta社から直接入手していないにも関わらずMeta社との契約関係となる。つまり、この頒布の繰り返しによる連鎖の過程において元のLlamaモデルとは異なるLlama派生モデルとして改変されたとしても、この派生モデルを使用する者はそのモデルを使用した時点でMeta社とLlamaライセンス契約を締結することになる。このような派生モデルを含むLlamaマテリアルを使用する者全てに契約の遵守義務が及び、さらにさながらコピーレフトのように派生モデルにもLlamaライセンス契約が伝播されるということで、契約の遵守義務の連鎖が拡張されていく仕組みとなっている。

ただし、Llamaの普及によっていくら契約の連鎖が発生したとしても、契約テキストに直接書かれている譲渡不可やLlamaブランドに関する制限等はあくまでLlamaマテリアルの使用者が遵守すべき義務に過ぎない。単に派生モデルを使用しているだけでもMeta社と契約関係にはなるが、ブランド制限等は基本的に頒布若しくは公衆送信等の利用行為に及ばない限りは気にする必要はないはずである。

しかし、契約に「参照によって組み込まれている」利用規約については、そもそも利用規約がモデルを使用するに際しての禁止事項を列挙したものであるという性質から全てのライセンシーが遵守する義務を負うことになる。このライセンシー側の利用規約の遵守義務は当然ではあるのだが、この利用規約の遵守は契約の連鎖よりもさらに拡大した範囲へも連鎖すると考えられる。何故なら、派生を含むLlamaモデルを何らかのシステムやサービスに組み込んだ場合、そのサービスを単に使用する顧客にも事実上Llama利用規約の遵守義務が発生すると考えられるからである。

仮にLlamaモデルを組み込んだ何らかのサービスが存在したとして、そのサービスの顧客に直接的にLlamaモデルへアクセスする手段がなければLlamaライセンス契約が顧客へ伝播することはなく、契約上の義務は発生しない。このケースではLlamaモデルを使用しているのはサービス側であり、その顧客がLlamaモデルを使用しているわけではないからである。しかし、そのサービスのベンダー側はLlamaライセンス契約に基づいてLlama利用規約を遵守しなければならないわけであり、顧客の行動に依拠するものであろうがLlamaモデルの挙動によってLlama利用規約に違反する行為がなされることを防止しなければならない。つまり、顧客の行動を制御しなければならないのである。このような顧客の行動を防止するには技術的な手段も当然あるが、最も根本的な手段としてはLlama利用規約と全く同一の内容をそのサービスの利用規約へ含めてしまうことである。これによって、そのサービスの顧客にも事実上Llama利用規約の遵守義務が発生することになる。

このような単なるサービスのエンドユーザーへの利用許諾遵守義務が発生することにより、Llamaの利用が拡大するに従って、Llamaを採用するシステムを介したLlama利用規約への遵守義務の連鎖が再現なく拡大することが考えられる。これは通常のソフトウェアのライセンスの影響範囲をはるかに越えてMeta社が自身の制御を及ぼすことが可能な範囲を世界的に拡大させることに繋がるだろう。

利用規約が更新された場合は新規の条項も遵守する必要があるのか?

Ans: Meta社によって更新された内容は、その更新の都度遵守する必要があると考えられる。

セクション 1.b.iv.条文
“iv. Your use of the Llama Materials must comply with applicable laws and regulations (including trade compliance laws and regulations) and adhere to the Acceptable Use Policy for the Llama Materials (available at https://llama.com/llama3_1/use-policy), which is hereby incorporated by reference into this Agreement.”
(iv. あなたによるLlamaマテリアルの使用は、適用される法律および規制(貿易コンプライアンスに関する法律および規制を含む)を遵守し、Llamaマテリアルに関する利用規約(https://llama.meta.com/llama3_1/use-policy で入手可能)に従う必要があります。このポリシーは、参照することによって本契約に組み込まれます。)

Llamaライセンス契約のセクション 1.b.iv.には、Llama利用規約が参照によって契約に組み込まれることが明記されている。この参照によって組み込まれるという意味を、「契約テキスト冒頭に記述されている日付またはLlamaマテリアルをダウンロード若しくは使用を開始した日付をもって利用規約が組み込まれており、その時点における利用規約の内容が有効」と解釈する方もいるようであるが、それは間違いである。指定されているURLに置かれている利用規約の文書が常に有効な利用規約となると考えねばならない。

これは契約法の概念に基づくが、Llamaライセンス契約に同意した際、ライセンシー側はその時点で存在していた利用規約に従うことに同意するだけではなく、利用規約の将来の変更に応じてそれにも従うという継続的な義務にも同意したことになるからである。つまり、この継続的な義務と引き換えとしてLlamaマテリアルを利用する権利を受け取っているわけである。これは特に珍しい形態の契約ではなく、例えばクレジットカードや保険等の契約においては、その時々の情勢や時代の変化に合わせて規約が改正され、規約の改正が発表された後にそのサービスを継続して使用することで新しい規約に同意したとみなされる。AI領域においてはLlama以外にも利用規約のあるライセンスは存在し、また、各国での法規制が進んでいるという状況も考慮すると、新たなリスクや懸念事項の出現に応じて利用規約を変更していく必要があるという主張を強化することになるだろう。つまり、新たな懸念が生じる度に利用規約を強化し、ライセンシーに遵守を求めることが正当化される。

もちろん、Meta社によって恣意的または著しく信義則や公平性に欠ける利用規約の変更にはある程度の法的な制限がかかるが、契約の本来の目的のために合理性があり、取引の性質を根本的に変えるものではない内容であって、また、その変更がライセンシー側へ明確な方法で伝達されているのであれば、利用規約の変更が係争になったとしてもMeta社側による変更を裁判所が支持する可能性が高い。カリフォルニア州法に基けばこのような規約の更新に対して、「双方の合意よりも明確な通知」、「ユーザー保護よりもビジネス上の合理性」が重視され、通知期間も一般的には消費者保護を重視した日本法での感覚よりも短い期間になると考える。つまり、Llamaの利用者は、Llama利用規約はMeta社がいつでも変更できるということを考慮に入れ、特に日本企業においては日本法での常識的な感覚に囚われないことに注意する必要があるだろう。

利用規約が更新された場合にどのようなリスクが考えられるか?

Ans: Meta社はいつでも特定企業に対して不利益となる行為を強いたり、使用の停止へ追い込む条項を利用規約へ追加することができる。

Llama利用規約ではおおまかに特定コンテンツの生成、使用者の操作、他のツールやシステムとの統合といった観点において、違法若しくは公序良俗に反するような行為を禁止しているが、Meta社の立場から合理的かつ中立的で安全性に考慮したという外形を保ちながら特定企業に多大な不利益を与える条項を利用規約へ追加することが可能となっている。

例えば、安全性や法令遵守を名目としてLlama組み込みのシステムにおいて使用者の行動の完全なログの保存、厳格なコンテンツフィルタリングや分析ツールの導入といった事項を義務付けて、ライセンシー側のLlama使用継続のためのコストを引き上げることができるだろう。そのような義務と共に、事実上Meta社が承認したツールだけをそのような規約遵守のために利用できるようにすれば、さらに多くの対応コストをライセンサーに課すことが可能になる。このような制限は一見合理的な透明性の要件に見えるので非常に厄介である。

このような技術的な要件とは異なる法域や文化的な慣習の違いを利用した制限を課すこともできるだろう。例えば、「モデルの出力は、架空の人物の描写に関しても米国のコンテンツ基準に準拠する必要がある」という条文が利用規約へ追加された場合、アニメ、漫画、ゲームといった日本のエンターテインメント業界に不当な影響を与える可能性が生じると推測されるが、条文そのものはコンテンツの安全対策のために合理的であると考えられるだろう。既に日本国内では合法であり一般的に倫理的な問題のないコンテンツ取引を問題視してVISAカードの取引停止といった事案が発生しているが、それと構図的にはよく似た事案が発生する可能性があるだろう。

“h. Engage in any action, or facilitate any action, to intentionally circumvent or remove usage restrictions or other safety measures, or to enable functionality disabled by Meta”
(使用制限またはその他の安全対策を故意に回避または削除する行為、または無効化された機能を使用可能にする行為を行うこと、またはそのような行為を助長すること)
“5. Interact with third party tools, models, or software designed to generate unlawful content or engage in unlawful or harmful conduct and/or represent that the outputs of such tools, models, or software are associated with Meta or Llama 3.2”
(違法なコンテンツの生成、違法または有害な行為を目的として設計された第三者のツール、モデル、ソフトウェアと相互に作用すること、および/または、そのようなツール、モデル、ソフトウェアの出力がMetaまたはLlamaに関連していると表明すること)

Meta社がそのような暴挙に出るわけがないという楽観的な考え方もできないわけではないし、既にリリース済みのLlamaのバージョンの利用規約の条文がリリース後に追加で更新されたケースは現状の所はない。しかし、Llama 3.2が公開された際に、Llama 3.1の利用規約と比較して何箇所かの条項が特段の予告なく追加されており、しかもそれらの新規の条項はAIの安全性に考慮した合理的な条文に見えつつも、通常は正当と考えられる行為を不当に制限しかねない内容となっている。

利用規約 1.h.はMeta社側がLlamaモデルへ施した技術的な制限を回避する行為を禁止するものであるが、これはLlamaモデルの挙動を調査若しくは研究する行為を禁止するものとも受け取れる。ライセンサー側がLlamaの安全性を調査する目的で技術的制限を回避したとしても、Meta社側はこの条文を根拠として契約を終了させることができるわけである。また、利用規約 5.は有害な行為を目的とするツールとの連携自体やそれによる出力をLlamaに由来すると表明することを禁止するものであるが、有害な行為がMeta社の恣意的な判断に依拠するというリスクがあると同時に、そもそもLlamaと連携した有害ツールによる出力をLlama由来と表明できないというのは、かえって安全性向上には寄与しないだろう。むしろ、Meta社側が単に恣意的に契約終了できる範囲を拡大させておきたいだけのようにも見える。

“With respect to any multimodal models included in Llama 3.2, the rights granted under Section 1(a) of the Llama 3.2 Community License Agreement are not being granted to you if you are an individual domiciled in, or a company with a principal place of business in, the European Union.”
(Llama 3.2に含まれるマルチモーダルモデルに関して、あなたがEUに居住する個人または主たる事業所をEUに置く企業である場合、Llama 3.2コミュニティ・ライセンス契約のセクション1.aに基づいて付与される権利はあなたへ付与されません。)

利用規約 1.h.と5.について百歩譲って正当化できるとしても、マルチモーダルモデルに関してEU市民と企業を排除する条文に関しては、Llamaライセンス契約における重大な罠の存在を浮かび上がらせる。

利用規約は通常ソフトウェアの使用法に関しての制限を列挙したものであり、Llama利用規約でも基本的にはライセンシー側が守るべきルールが書き連ねられている。しかし、このEU市民に対しての条項は、そもそもモデルを使う権利が付与されなく、つまりライセンシーとはならないとされているのである。使用のための許諾を与えるか否かということはLlamaライセンス契約の仕組みであれば契約テキスト側に記述されるべき事項であると思われるが、このような条項まで利用規約に記述することで、Meta社自身がいついかなる場合においても任意で特定の組織や集団による派生を含むLlamaマテリアルの使用を停止させる権限を持っていることが誇示されているということである。本条項はEUのAI規制を嫌ったものであることは彼らの動機として理解するが、このEU市民排除の条項は、Meta社が気に入らない国、企業、集団はいつでもLlamaの使用を停止させられるリスクがあることを示している。

なお、Llama利用規約は基本的には禁止行為を列挙したものであるが、前述までに解説した罠を利用すれば、Llamaライセンス契約とは別のプロプライエタリな契約へ誘導することもできるだろう。これはオープンソースの世界でもデュアルライセンス、オープンコア等のビジネスモデルで見られるアプローチであり、Meta社がコンプライアンスの維持を名目として料金徴収へシフトすることは特に不自然な行動とは言えないだろう。

利用規約の条項は自国の法による解釈をしても問題ないか?

Ans: 米国法や米国の慣習、慣行に従うことが基本となる。

セクション 7条文:
“7. Governing Law and Jurisdiction. This Agreement will be governed and construed under the laws of the State of California without regard to choice of law principles, and the UN Convention on Contracts for the International Sale of Goods does not apply to this Agreement. The courts of California shall have exclusive jurisdiction of any dispute arising out of this Agreement.”
(7. 準拠法および管轄権: 本契約は、法の選択に関する原則に関わらず、カリフォルニア州法に準拠し、解釈されるものとし、国際物品売買契約に関する国連条約は本契約には適用されないものとします。本契約に起因する紛争に関しては、カリフォルニア州の裁判所が排他的管轄権を有するものとします。)

Llamaライセンス契約のセクション 7には上記のように「法の選択に関する原則に関わらず」カリフォルニア州法が準拠法となることが明示されている。この文言は他の法域の法を適用する可能性を排除しており、例えば日本の裁判所での訴訟を阻止する効果があると考えられる。利用規約については、契約に参照によって組み込まれていることから契約の一部として機能するものと考えられることから、当然のように利用規約もカリフォルニア州法によって解釈する必要がある。

日本法と米国法及びカリフォルニア州法を比較すると、知的財産権や契約法に関しての解釈の違いがある他、これまでの利用規約の改変の解説でも前提としたようにシュリンクラップやクリックスルー契約の有効性についても違いがある。一方的な条件変更に対する厳格な見方がされる日本法を基準にするとリスクを軽視しがちとなる可能性があるだろう。つまり、前項で解説した法域や文化的な慣習の違いを利用した制限が利用規約に組み込まれた場合には、即座にカリフォルニア州法に基づいた判断をしなければならないことになる。特に日本のネット界隈においてはアニメキャラクター等における未成年の架空の人物の描写についての各国での扱いの違いについて議論となることがあるが、他にもプライバシー情報やデータ保護、コンテンツモデレーション等でも各国での文化若しくは慣習的差異が顕在化する可能性があるのではないかと考える。

ともかく、米国外の企業であってもカリフォルニア州法に従って利用規約を解釈する必要があり、Llamaマテリアルを利用するサービスを一般へ展開する場合においてもエンドユーザーに対してもその解釈に従って利用を制限しなければならない。日本の単なるLlamaをバックエンドにしたシステムのエンドユーザーであってもカリフォルニア州法基準の規約に従うことになるが、Llamaライセンス契約の仕組み上はそうなるし、Meta社としても一つの規約の解釈で運用できるという合理性があると考えられるだろう。

モデルの出力とその出力結果によってトレーニングされたモデルにはLlamaライセンス契約は伝播するのか?

Ans: Meta社側では特に明言していないようであるが、Llama出力による合成データを利用してもLlamaライセンス契約が伝播するという主張を採用していると考えられる。

“Llama 3.2” means the foundational large language models and software and algorithms, including machine-learning model code, trained model weights, inference-enabling code, training-enabling code, fine-tuning enabling code and other elements of the foregoing distributed by Meta at https://llama.com/llama-downloads.
(「Llama 3.2」とは、Metaが https://llama.meta.com/llama-downloads で頒布する機械学習モデルコード、トレーニングモデルの重み、推論を可能にするコード、トレーニングを可能にするコード、ファインチューニングを可能にするコード、およびこれらに付随するその他の要素を含む、大規模言語モデルおよびソフトウェアおよびアルゴリズムを指します。)
“Llama Materials” means, collectively, Meta’s proprietary Llama 3.2 and Documentation (and any portion thereof) made available under this Agreement.
(「Llamaマテリアル」とは、本契約の下で提供されるMeta独自のLlama 3.2およびドキュメンテーション(およびその一部)を総称して指します。)

この結論を説明するために順序立てて述べる。先ず契約テキスト冒頭の定義では、Llama 3.2とLlamaマテリアルは上記にように定義されている。「Llama 3.2」がウェイト、コード、アルゴリズムを含むモデルそのものを指しており、「Llamaマテリアル」とはそれらのモデル全体とドキュメンテーションを総称している。これは、モデルそのものとドキュメント全体を合わせた全体若しくはそれらの任意の部分を指していると解釈する者もいるが、実際には”collectively”という用語の効果により、Llama 3.2のモデルとドキュメントという二つの要素を含むもののそれらに限定されないと解釈される。これによって、トレーニングデータ、派生モデル、又は知的財産権が及ばないAPIアクセスや技術サポートといった様々な要素までLlamaマテリアルに含まれることを可能としている。

“i. If you distribute or make available the Llama Materials (or any derivative works thereof), or a product or service (including another AI model) that contains any of them, you shall (A) provide a copy of this Agreement with any such Llama Materials; and (B) prominently display “Built with Llama” on a related website, user interface, blogpost, about page, or product documentation. If you use the Llama Materials or any outputs or results of the Llama Materials to create, train, fine tune, or otherwise improve an AI model, which is distributed or made available, you shall also include “Llama” at the beginning of any such AI model name.”
(i. あなたがLlamaマテリアル(またはその派生作品)またはLlamaマテリアルを含む製品やサービス(他のAIモデルを含む)を頒布もしくは利用可能にする場合、あなたは (A) 当該のLlamaマテリアルとともに本契約書の写しを提供し、(B) 関連するWebサイト、ユーザーインターフェース、ブログ投稿、概要ページ、または製品ドキュメントに「Built with Llama」を明示的に表示しなければなりません。LlamaマテリアルまたはLlamaマテリアルの出力若しくは結果を使用して、AIモデルを作成、トレーニング、ファインチューニング、または改良し、それを頒布する場合、そのAIモデル名の先頭に「Llama」を含めるものとします。)

そして次に、セクション 1.b.i.における「LlamaマテリアルまたはLlamaマテリアルの出力若しくは結果を使用して、AIモデルを作成、トレーニング、ファインチューニング、または改良し、それを頒布する場合」という下りが最も重要であり、ここでは「Llamaマテリアル」と「Llamaマテリアルの出力若しくは結果」を並列に並べる形で双方にモデル名の先頭にLlamaを含める義務を課している。このモデルとモデルの出力を並列にすることで双方が同じ義務を負っていることが効果的に強調されており、契約範囲が出力や結果にも及ぶことが明確化されていることになる。ライセンス義務は出力及び結果の部分に関しても全く等価であることから、「出力若しくは結果はLlamaマテリアルに属する」という内容の文言が契約テキスト上に存在せずとも出力がLlamaマテリアルの一部としてライセンスを継承すると考えられる。

この解釈は、セクション 1.b.iv.の「Llamaマテリアルの使用は、適用される法律と規制を遵守し、利用規約に従う必要があります」という内容でも強化される。何故なら利用規約は出力や結果の利用に対して規定しているからである。さらに、セクション 5.c.には、「LlamaマテリアルまたはLlama 3.2の出力や結果、またはいずれかの一部があなたの所有またはライセンス付与可能な知的財産権またはその他の権利を侵害していると申し立てる場合」という文言もあるが、これは出力に関する潜在的な侵害の申し立てをモデル自体に関する申し立てと同列に扱っており、Meta社がモデルの出力を法的に同一視していることを示唆していると言える。これらの論理は米国の契約法上で問題なく説明される論理だと考えられるが、実際、Meta社はLlamaモデルを様々なベンチマークテスト的な評価コードによってテストした結果をHugging Face上でデータセットとして公開しており、それらのデータセットにはLlamaモデルのバージョンに合わせたLlamaライセンス契約が適用されている。これはMeta社自身がLlamaライセンス契約が出力にも及ぶことを実践して示しているとも言えるだろう。

この理論を適用した場合、Llamaライセンス契約はLlamaモデルの出力を経由しても伝播することになり、Llamaモデルの出力をまとめた合成データセットを作成してそれをトレーニングデータセットとしてAIモデルを開発した場合、合成データセットとAIモデル双方にLlamaライセンス契約が伝播するという解釈になるだろう。これは著作権を利用したコピーレフトの仕組みをはるかに越える契約のチェーンを作り上げることにつながる。

ただし、この合成データを介しての契約の伝播性は、知的財産権の範囲や従来のソフトウェアにおけるライセンスや使用許諾契約の常識を超えるものであり、司法がどのように判断するかを推測する判例と言えるものは乏しく、法的な不確実性が存在すると考えられる。例えば、Llama出力をブログ記事等でそのまま公開し、それがまわりにまわってAIトレーニングに利用されたとして、そのトレーニング結果によるモデルへLlamaライセンス契約を適用する必要性は極めて薄いだろう。かといって大々的に出力から合成データを作成し、AIのトレーニングへ利用すれば、Meta社はLlamaライセンス契約が伝播されなければならないという主張をするのではないかと考えられるし、契約上はそのように解釈する方が自然である。

なお、いわゆる合成データ経由での契約の伝播は、他のライセンスや契約が適用されたAIモデルにも追加のトレーニングによってLlamaライセンス契約が伝播すると考えられ、そのモデルが元々寛容なオープンソースライセンスが適用されていたのであれば矛盾は発生しないものの、他の利用規約が付いているようなライセンスや契約の場合は法的条件が矛盾する可能性も考慮しなければならない。利用規約は基本的に禁止事項が書かれているので、それらは併存するライセンスと契約の利用規約を全て論理和を取ったものとなる。契約上のライセンス条件にどうしても双方の義務を履行することができない条件が存在すれば契約が矛盾することとなり、契約は終了せざるを得ないだろう。Llamaであれば先頭にLlamaを含める名称制限は矛盾しやすいと考えられるが、利用規約側でも矛盾が発生する可能性はあるだろう。

むすび

Llamaコミュニティライセンス契約はオープンソースには全く適合しない不自由なライセンスであるにも関わらず、AIの透明性や信頼性確保のために「妥当な倫理のためのガイドライン」を備えた無料のオープンソース的なモデルとして喧伝する一派が存在する。本稿で明らかとしたように、Llamaライセンス契約における商業規模の閾値制限、強力で随時変更可能な利用規約の存在、出力データを介したコピーレフトを超える強い契約の伝播性といった性質は通常のソフトウェアのライセンスを大幅に超える拡張に挑戦するものである。単に無料のオープンなモデルであると想定している企業や個人も多いと想定されるが、派生モデルを介した事実上の全てのエンドユーザーの行動制限をかける仕組みであることを理解する必要があるだろう。

Llamaライセンス契約及び利用規約を注意深く読み、継続的に監視しなければ、自社の事業や評判に重大な影響を及ぼす危険に晒される可能性があることを留意すべきである。

参考:

Llamaライセンス契約のオープンソースへの適合性について
https://shujisado.com/2025/01/15/llama_is_not_opensource/

オープンソースAIとは何か? –「オープンソースAIの定義 v1.0」詳細解説
https://speakerdeck.com/shujisado/opunsosuaitohahe-ka-opunsosuainoding-yi-v1-dot-0-xiang-xi-jie-shuo


Llama 3.1 コミュニティライセンス契約 日本語参考訳

Llama 3.1 バージョンリリース日: 2024年7月23日

「契約」とは、本契約書に記載されているLlamaマテリアルの使用、複製、頒布および改変に関する条件を指します。

「ドキュメンテーション」とは、Metaが https://llama.meta.com/doc/overview にて頒布するLlama 3.1に付随する仕様書、マニュアル、および文書を指します。

「ライセンシー」または「あなた」とは、あなた、あなたの雇用主、またはこの契約をその人または団体のために締結している場合、法的な同意を提供するために必要な年齢に達しており、かつその雇用主またはその人や団体を法的に拘束する権限を持っているその他の個人または団体を指します。

「Llama 3.1」とは、Metaが https://llama.meta.com/llama-downloads で頒布する機械学習モデルコード、トレーニングモデルの重み、推論を可能にするコード、トレーニングを可能にするコード、ファインチューニングを可能にするコード、およびこれらに付随するその他の要素を含む、大規模言語モデルおよびソフトウェアおよびアルゴリズムを指します。

「Llamaマテリアル」とは、本契約の下で提供されるMeta独自のLlama 3.1およびドキュメンテーション(およびその一部)を総称して指します。

「Meta」または「我々」とは、あなたもしくはあなたが法人である場合に主たる事業所ががEEAまたはスイスに所在する場合はMeta Platforms Ireland Limited、その他の場合はMeta Platforms, Inc.を指します。

以下の「同意する」ボタンをクリックするか、Llamaマテリアルの一部または要素を使用または頒布することにより、あなたは本契約に拘束されることに同意することになります。

  1. ライセンスの権利と再頒布
    a. 権利の付与: あなたは、Llamaマテリアルに含まれるMetaの知的財産またはその他の権利に基づいて、Llamaマテリアルを使用、再製、頒布、コピー、派生作品の作成、および改変するための非独占的、世界的、譲渡不可能でロイヤルティフリーの限定的なライセンスが付与されます。

    b. 再頒布と使用:
    i. あなたがLlamaマテリアル(またはその派生作品)またはLlamaマテリアルを含む製品やサービス(他のAIモデルを含む)を頒布もしくは利用可能にする場合、あなたは (A) 当該のLlamaマテリアルとともに本契約書の写しを提供し、(B) 関連するWebサイト、ユーザーインターフェース、ブログ投稿、概要ページ、または製品ドキュメントに「Built with Llama」を明示的に表示しなければなりません。LlamaマテリアルまたはLlamaマテリアルの出力若しくは結果を使用して、AIモデルを作成、トレーニング、ファインチューニング、または改良し、それを頒布する場合、そのAIモデル名の先頭に「Llama」を含めるものとします。

    ii. あなたがライセンシーから統合エンドユーザー製品の一部としてLlamaマテリアルまたはその派生作品を受け取った場合、本契約の第2条はあなたに適用されません。

    iii. あなたが頒布する全てののLlamaマテリアルのコピーには、「Notice」テキストファイル内に次の帰属表示を保持する必要があります:「Llama 3.1はLlama 3.1 コミュニティライセンス契約の下でライセンスされています。Copyright © Meta Platforms, Inc. All Rights Reserved.」

    iv. あなたによるLlamaマテリアルの使用は、適用される法律および規制(貿易コンプライアンスに関する法律および規制を含む)を遵守し、Llamaマテリアルに関する利用規約(https://llama.meta.com/llama3_1/use-policy で入手可能)に従う必要があります。このポリシーは、参照することによって本契約に組み込まれます。
  2. 追加の商用条件: Llama 3.1のバージョンリリース日において、ライセンシーまたはライセンシーの関連会社によって、もしくはライセンシーまたはライセンシーの関連会社に対して提供される製品またはサービスの月間アクティブユーザー数が直前の暦月において7億人を超える場合、あなたはMetaからのライセンスを要求しなければならず、Metaは独自の裁量であなたにライセンスを付与することができ、Metaが明示的に当該権利をあなたへ付与しない限り、もしくは付与するまで、あなたは本契約に基づく権利を行使することは許可されません。
  3. 保証の免責: 適用法で義務付けられていない限り、Llamaマテリアルおよびそれらから生じるあらゆる出力および結果は、「現状有姿」で提供され、いかなる種類の保証も付されず、Metaは明示的または黙示的かを問わず、所有権、非侵害、商品性、または特定の目的への適合性に関する保証を含むがこれらに限定されずあらゆる種類の保証を全てを否認します。あなたは、マテリアルを使用または再頒布することの適切性を判断する全責任を負うものとし、Llamaマテリアル、出力、結果の使用に関連するリスクを全て負うものとします。
  4. 責任の制限: いかなる場合においても、Metaまたはその関連会社は、契約、不法行為、過失、製造物責任、またはその他の責任理論に基づくかを問わず、本契約に起因する逸失利益または間接的、特別、結果的、偶発的または懲罰的損害賠償について、Metaまたはその関連会社がこれらの可能性を認識していたとしても、一切責任を負わないものとします。
  5. 知的財産:
    a. 本契約の下で商標ライセンスは付与されず、Llamaマテリアルに関連して、Metaまたはライセンシーのいずれも他方またはその関連会社が所有する、またはそれらに関連する名称または商標を使用することはできません。ただし、Llama素材を合理的かつ慣例的に説明し再頒布するために必要な場合、または本第5条(a)項に定める場合を除きます。Metaは、本契約により、第1条b項iの最後の文章に従うために必要な場合のみ、「Llama」(「マーク」)を使用するライセンスを貴社に付与します。あなたはMetaのブランドガイドライン(現在は https://about.meta.com/brand/resources/meta/company-brand/ でアクセス可能)を遵守するものとします。マークの使用から生じるすべてののれんは、Metaに帰属するものとします。

    b. Metaが作成したLlamaマテリアルおよびMetaによるまたはMetaのための派生物の所有権に従い、あなたが作成したLlamaマテリアルの派生作品および改変作品に関しては、あなたとMetaの間で、あなたは現在および今後もそれらの派生作品および改変作品の所有者となります。

    c. あなたがMetaまたは他の法人に対して、訴訟またはその他の手続き(訴訟における反訴または反論を含む)を起こし、LlamaマテリアルまたはLlama 3.1の出力や結果、またはいずれかの一部があなたの所有またはライセンス付与可能な知的財産権またはその他の権利を侵害していると申し立てる場合、訴訟または申し立てが提起または開始された時点で、本契約に基づきあなたに付与されたライセンスは終了するものとします。あなたは、Llamaマテリアルの使用または頒布に起因もしくは関連する第三者からの請求について、Metaを免責し、損害を与えないものとします。
  6. 期間および終了: 本契約の期間は、あなたが本契約を受け入れるかLlamaマテリアルにアクセスした時点で開始され、本契約の条件に従って終了するまで有効に継続するものとします。Metaは、あなたが本契約のいずれかの条項に違反した場合、本契約を終了することができます。本契約が終了した場合、あなたはLlamaマテリアルを削除し、その使用を中止するものとします。第3条、第4条および第7条は本契約の終了後も有効に存続するものとします。
  7. 準拠法および管轄権: 本契約は、法の選択に関する原則に関わらず、カリフォルニア州法に準拠し、解釈されるものとし、国際物品売買契約に関する国連条約は本契約には適用されないものとします。本契約に起因する紛争に関しては、カリフォルニア州の裁判所が排他的管轄権を有するものとします。

Llama 3.2 Acceptable Use Policy(利用規約) 日本語参考訳

Metaは、Llama 3.2を含むそのツールおよび機能の安全かつ公正な利用を促進することに努めています。Llama 3.2にアクセスまたはこれを使用する場合、本利用規約(以下「規約」)に同意したものとみなされます。本規約の最新版は、https://www.llama.com/llama3_2/use-policy でご覧いただけます。

禁止されている利用

私たちは、誰もが Llama 3.2 を安全かつ責任を持って使用してほしいと考えています。あなたは、以下の行為のためにLlama 3.2を使用しないこと、また他者による使用を許可しないことに同意するものとします。

  1. 法律または他者の権利を侵害する行為、具体的には以下を含みます:
    a. 以下の違法または不法な活動またはコンテンツに関与、促進、作成、寄与、奨励、計画、扇動、または助長すること。
    i. 暴力若しくはテロ行為
    ii. 児童搾取的コンテンツの勧誘、作成、取得、または普及、または児童性的虐待的コンテンツの報告の不履行を含む児童に対する搾取または危害
    iii. 人身売買、搾取、および性的暴力
    iv. 未成年者に対する情報または素材の違法な配布(わいせつな素材を含む)、またはそのような情報または素材に関連して法的に要求される年齢制限の適用を怠ること。
    v. 性的勧誘
    vi. その他の犯罪行為
    b. 個人または個人グループに対する嫌がらせ、虐待、脅迫、またはいじめへの関与、促進、扇動、または促進
    c. 雇用、雇用手当、信用クレジット、住宅、その他の経済的利益、またはその他の必要不可欠な商品およびサービスの提供における差別またはその他の不法または有害な行為の関与、促進、扇動、または促進
    d. 金融、法律、医療/健康、または関連する専門的業務を含むがこれらに限定されない、あらゆる専門職の無許可または無免許の業務に従事する
    e. 適用される法律で要求される権利および同意なしに、個人に関する健康健康、人口統計情報、またはその他の機密性の高い個人情報またはプライバシー情報を収集、処理、開示、生成、または推測すること
    f. Lamaマテリアルを使用した製品またはサービスの成果または結果を含む、第三者の権利を侵害、不正利用、またはその他の方法で侵害する行為に関与または容易にしたり、コンテンツを作成したりすること
    g. 悪意のあるコード、マルウェア、コンピュータウイルスを作成、生成、またはその作成を容易にしたり、Webサイトまたはコンピュータシステムの適切な動作、完全性、操作、または外観を無効にしたり、過剰な負荷をかけたり、妨害したり、損なったりする可能性のあるその他の行為を行うこと
    h. 使用制限またはその他の安全対策を故意に回避または削除する行為、またはMetaによって無効化された機能を使用可能にする行為を行うこと、またはそのような行為を助長すること
  2. 以下の内容に関連するLama 3.2の使用を含め、個人に対して死亡または身体的な危害のリスクをもたらす活動の計画または開発に従事、もしくはそのような活動を宣伝、扇動、助長、支援すること
    a. 軍事、戦争、原子力産業またはその用途、スパイ行為、米国国務省が管理する国際武器取引規則(ITAR)の対象となる物品または活動への使用
    b. 銃および違法な武器(武器開発を含む)
    c. 違法薬物および規制・管理物質
    d. 重要なインフラストラクチャ、輸送技術、または大型機械の運用
    e. 自傷または他者への危害(自殺、自傷行為、摂食障害を含む)
    f. 暴力、虐待、または個人に対する身体的危害を扇動または助長する意図を持つコンテンツ
  3. 以下に関連するLama 3.2の使用を含め、故意に他人を欺いたり、誤解を招くような行為
    a. 詐欺行為、または偽情報の作成、宣伝、促進、または助長する行為
    b. 中傷的な発言、画像、その他のコンテンツの作成を含む、中傷的なコンテンツの生成、促進、または助長
    c. スパムの生成、宣伝、または配布の助長
    d. 同意、承認、法的権利なく他者を装うこと
    e. Llama 3.2の使用または出力が人間による生成であると表明すること
    f. 偽のレビューやその他の偽のオンラインエンゲージメント手段を含む、偽のオンラインエンゲージメントの生成または助長
  4. あなたのAIシステムに存在する既知の危険性をエンドユーザーに適切に開示しないこと
  5. 違法なコンテンツの生成、違法または有害な行為を目的として設計された第三者のツール、モデル、ソフトウェアと相互に作用すること、および/または、そのようなツール、モデル、ソフトウェアの出力がMetaまたはLlama 3.2に関連していると表明すること

Llama 3.2に含まれるマルチモーダルモデルに関して、あなたがEUに居住する個人または主たる事業所をEUに置く企業である場合、Llama 3.2コミュニティ・ライセンス契約のセクション1.aに基づいて付与される権利はあなたへ付与されません。この制限は、そのようなマルチモーダルモデルを組み込んだ製品またはサービスのエンドユーザーには適用されません。

本規約に対する違反、ソフトウェアの「バグ」、または本規約に対する違反につながる可能性のあるその他の問題については、以下のいずれかの方法で報告してください。

モデルに関する問題の報告: https://github.com/meta-llama/llama-models/issues
モデルによって生成されたリスクのあるコンテンツの報告: developers.facebook.com/llama_output_feedback
バグやセキュリティに関する懸念の報告:facebook.com/whitehat/info
利用規約違反またはLlama 3.2の無許諾使用の報告:LlamaUseReport@meta.com

Llamaライセンス契約のオープンソースへの適合性について

Meta Platforms社が開発するAIモデルのシリーズである「Llama」は、高性能で費用対効果が高く、比較的寛容な条件で頒布されていると多くの人々から見做されていることからシステムへの採用や派生モデルの開発等の利用が拡大しているように見受けられる。しかし、Meta社のCEOが自ら「Llamaはオープンソースである」と喧伝することで本当にLlamaがオープンソースであると誤解する傾向もあり、またLlamaライセンス契約自体に幾つかの厄介な問題が潜んでいるにも関わらず採用が進むことで今後法的な問題が生じかねないと考えられる。そこで本稿では、先ずLlamaライセンス契約のオープンソースへの適合性から解説することとする。
なお、Llamaライセンス契約のモデル利用時における注意点に関しては別の記事とする。

AIはtypoする

Llamaのオープンソースへの適合性

Llamaモデルに適用されているLlamaコミュニティライセンス契約(Llama Community License Agreement)は、ライセンスや著作権に関する知識が乏しい方からするとオープンソースライセンスと然程変わらないように見えるようである。Llamaライセンス契約は、使用、再製、頒布、コピーといった利用に関して制限されてはいるがある程度の自由を規定し、派生物の作成までを明示的に認めているので、オープンソースライセンスの特徴を幾らか含んでいることは確かであろう。しかし、ライセンスがオープンソースであることを証明する唯一の組織であるOpen Source Initiativeが規定するオープンソースの定義(OSD:Open Source Definition)に照らし合わせると、Llamaライセンスは様々な観点でオープンソースへの適合性がないことが明らかである。下記では、Llamaライセンス契約の条項を示しながら、Llamaがオープンソースではない理由を一つずつ示していく。

1. オープンソース性を否定する主要な理由

Llamaライセンス契約がオープンソースではない理由は幾つも挙げることができるが、契約が目指す目的に沿った根本的な理由と考えられる条項は下記の巨大企業における使用制限と利用規約の存在に絞られると考えられる。

1.1. 7億人のアクティブユーザー制限

セクション 2 条文
“If, on the Llama 3.1 version release date, the monthly active users of the products or services made available by or for Licensee, or Licensee’s affiliates, is greater than 700 million monthly active users in the preceding calendar month, you must request a license from Meta …”
(Llama 3.1のバージョンリリース日において、ライセンシーまたはライセンシーの関連会社によって、もしくはライセンシーまたはライセンシーの関連会社に対して提供される製品またはサービスの月間アクティブユーザー数が直前の暦月において7億人を超える場合、あなたはMetaからのライセンスを要求しなければならず、)

Llamaライセンス契約のセクション2は、そのまま字面通り月間7億人のユーザーを抱える企業はLlamaモデルをMeta社の許諾なしでは使用できないと規定している。これは実質的に自社を脅かす巨大企業に対してLlamaを使用させないことを意図しているのだろう。このような制限はOSD 5条の「個人やグループに対する差別の禁止」に抵触する。

今時であれば巨大企業は十分に儲けているので問題にならないという主張もあると思うが、オープンソースというものはそのような組織の大小や性質に関わらず自由を認めることで発展してきた概念であることに留意しなければならない。また、Llamaモデルを組み込んだサービスや派生モデルを開発する企業が巨大企業を顧客もしくはM&Aの相手とすることも制限されるというビジネス上の問題も出てくるだろう。

なお、この制限をLlamaを採用するサービス若しくはプロダクトのユーザー数であると考える者がいるようだが、ライセンシーである企業全体で抱えるユーザー数であり、当然ながら複数のサービスを展開していればそれを考慮することになる。また、ライセンシー企業単体だけではなく、50%以上の持分関係で繋がる全ての子会社や親会社のユーザーも考慮に入れる必要がある。これについては別稿でも触れる。

1.2. 契約へ組み込まれる利用規約の存在

セクション 1.b.iv 条文
“Your use of the Llama Materials must … adhere to the Acceptable Use Policy for the Llama Materials (available at https://llama.meta.com/llama3_1/use-policy), which is hereby incorporated by reference into this Agreement.”
(Llamaマテリアルに関する利用規約(https://llama.meta.com/llama3_1/use-policy で入手可能)に従う必要があります。このポリシーは、参照することによって本契約に組み込まれます。)

Meta社はLlamaモデルの使用者がモデルの使用に際して遵守すべき事項を利用規約(Acceptable Use Policy)として別途定めており、セクション 1.b.ivではこの利用規約が「参照によってLlamaライセンス契約に組み込まれる」ことを規定している。この契約に「組み込まれる」ということは契約の一部となるということであり、つまり利用規約はライセンス契約の拡張された一部ということになる。

利用規約では、おおまかに (1)法律に反する利用または第三者の権利を害する利用、(2)個人に死亡または身体的侵害のリスクをもたらす活動の企画・開発に従事し、もしくはこれを促進、扇動、促進、支援すること、(3)意図的に他人を欺いたり、誤解させたりする利用、(4)AIシステムの既知の危険性をエンドユーザーに適切に開示しないこと、といった行為を禁止することが定められている。これらの行為が社会的に望ましくない行為であることは事実であるが、こういったいわば倫理的条項と言える条文で一般的に合法であるはずの行為まで利用の制限を行うことはOSD 6条の「利用する分野(fields of endeavor)に対する差別の禁止」に抵触する。

これについても「人々に対して正しくAIモデルを利用させることが何故ダメなのだ?」という意見があるだろうが、ここでの正しい利用行為とは何なのだろうか?また、その正しさは誰が決めるのだろうか? 利用規約で曖昧に記述されている数々の望ましくない行為は、結局の所、Meta社が恣意的に判定するのである。

そして、ライセンス契約のセクション 7で規定されるように準拠法はカリフォルニア州法であり、また、Meta社は米国企業であることから当然ながら米国の文化、慣習で倫理的な正しさを判断することになる。米国内の組織や個人であれば大きな問題は発生しにくいだろうが、本邦のように異なる慣習と法体系を持つ国々からすれば、ライセンシー側が全く意図せずにライセンス契約に違反してしまうことは発生するだろう。2024年に大きな問題となったVisaの決済停止問題と類似の事案が起きる可能性もあるだろう。なお、セクション 6では、Meta社がライセンス契約に違反したと見做した場合に随時契約を終了できることが明記されており、GNU GPLにあるような救済期間等は特に存在していない。

1.3. 随時拡張可能な利用規約

前項における利用規約に関連する問題はもう一つ存在する。利用規約は「参照によって契約に組み込まれる」と契約の条文に明記されているが、これは指定されている場所に置かれている利用規約の内容が逐次有効となることを示しており、さらにその指定場所はMeta社のWebサイト内であるわけなのでMeta社がいつでも恣意的に利用規約を改変することが可能になっている。利用規約はLlamaライセンス契約に組み込まれているので、事実上、利用規約を改変することでライセンス契約本体の条件すら変更することも可能であり、これはOSD 7条の「ライセンスの分配(distribution)」に抵触することになる。

突然、多くの企業が別途の有償契約を結ばなければならなくなるように追い込むような条文を事後に追加することも可能であり、信義誠実及び公正取引等の観点からある程度の妥当性があればおそらくそれは有効と認められるのだろう。そもそもこのような仕組みはOSDに違反するという以前の問題である。

上場企業であるMeta社がそのような蛮行はしないと主張する方もいると思うが、Llama 3.2の利用規約ではセクション 1.a.で付与されている「Llamaマテリアルを使用、再製、頒布、コピー、派生作品の作成および改変」する権利がEU市民から取り上げる条文が利用規約に追加されている。これはもはやオープンソースであるかどうかを検討するレベルに一切達していないと言えるし、ライセンス契約の主要部分を使用法に関する注意事項を規定するはずの利用規約側で否定するという仕組みにも問題があると言える。

“With respect to any multimodal models included in Llama 3.2, the rights granted under Section 1(a) of the Llama 3.2 Community License Agreement are not being granted to you if you are an individual domiciled in, or a company with a principal place of business in, the European Union.”
(Llama 3.2に含まれるマルチモーダルモデルに関して、あなたがEUに居住する個人または主たる事業所をEUに置く企業である場合、Llama 3.2コミュニティ・ライセンス契約のセクション1.aに基づいて付与される権利はあなたへ付与されません。)

さらに、Llama 3.2の利用規約では下記の条文も追加されているが、これらの条文は安全性を名目にしつつ、安全性を検証することを阻害することになると考えられる。これはいずれもLlamaモデルの挙動を研究する自由を奪うことになり、オープンソースの根本的な原則に反するとも言えるだろう。

h. Engage in any action, or facilitate any action, to intentionally circumvent or remove usage restrictions or other safety measures, or to enable functionality disabled by Meta
(使用制限またはその他の安全対策を故意に回避または削除する行為、または無効化された機能を使用可能にする行為を行うこと、またはそのような行為を助長すること)
5. Interact with third party tools, models, or software designed to generate unlawful content or engage in unlawful or harmful conduct and/or represent that the outputs of such tools, models, or software are associated with Meta or Llama 3.2
(違法なコンテンツの生成、違法または有害な行為を目的として設計された第三者のツール、モデル、ソフトウェアと相互に作用すること、および/または、そのようなツール、モデル、ソフトウェアの出力がMetaまたはLlamaに関連していると表明すること)

2. オープンソース性を否定するその他の理由

Llamaのオープンソース性を否定する論拠としては前項までで十分過ぎると考えられるが、Llamaライセンス契約には他にもオープンソースライセンスに適合しない内容が含まれている。それらを列挙し、解説する。

2.1. 派生作品のブランド化/命名に関する制限

セクション 1.b.i 条文
“Prominently display “Built with Llama.””
(「Built with Llama」を明示的に表示しなければなりません)
“If you use the Llama Materials or any outputs or results of the Llama Materials to create, train, fine tune, or otherwise improve an AI model, which is distributed or made available, you shall also include “Llama” at the beginning of any such AI model name.”
(LlamaマテリアルまたはLlamaマテリアルの出力若しくは結果を使用して、AIモデルを作成、トレーニング、ファインチューニング、または改良し、それを頒布する場合、そのAIモデル名の先頭に「Llama」を含めるものとします。)

セクション 1.b.iは派生作品を頒布する際にLlamaライセンス契約のテキストを添付することに加え、「Built with Llama」という文言を製品のWebページやドキュメント等に目立つように表示することと派生モデルの名称の先頭に「Llama」を含めることを強制している。これは、OSD 8条の「特定製品でのみ有効なライセンスの禁止」に抵触するだろう。通常、オープンソースであるライセンスは著作権の帰属表示を正しく表示することを求めるが、Llamaライセンス契約のように特定の名称やブランディングを強制せず、自由な派生と再頒布を認めている。つまり、Llamaはこの点で派生と頒布の自由を妨げていると言える。

名称程度は大した制限ではないと思われるかもしれないが、これは派生部分が明らかに巨大であろうが関係なく契約関係が継続する限りこの制限が継続する。Metaからすれば派生モデル開発者がわざわざ自社のブランディングに寄与してくれるということである。

2.2. 契約を譲渡することの禁止

セクション 1.aでは、ライセンシー側に付与される権利について規定されているが、ここでLlamaライセンス契約が「譲渡不可能」(non-transferable)であることが明記されている。これはOSD 1条「再頒布の自由」に抵触することになるだろう。

ここで「派生モデルを作成し、その頒布までの権利が認められているのに譲渡不可能とはどういう意味だ?」と不思議に思う方がいるかもしれない。これは、派生モデルの頒布時にはそれを受領した派生モデル利用者はMeta社と新規でLlamaライセンス契約を結ぶことになり、よって派生モデル開発者から派生モデル利用者へ契約を譲渡しているわけではないので、そのようなケースが問題になるわけではない。では、どういったケースが問題になるかと言えば、Llamaモデル利用時に結ばれたLlamaライセンス契約でのライセンシーとしての立場をそのまま第三者へ移譲させないとならないようなケースにおいて、契約がMetaの許諾がない限りは譲渡不可能であるとされているのである。これは企業の買収、合併、事業譲渡においてLlamaのライセンシーである企業が消滅するような場合に問題が発生することになる。

2.3. 出力にまで伝播する契約

セクション 1.b.i 条文
“If you use the Llama Materials or any outputs or results of the Llama Materials to create, train, fine tune, or otherwise improve an AI model, which is distributed or made available, you shall also include “Llama” at the beginning of any such AI model name.”
(LlamaマテリアルまたはLlamaマテリアルの出力若しくは結果を使用して、AIモデルを作成、トレーニング、ファインチューニング、または改良し、それを頒布する場合、そのAIモデル名の先頭に「Llama」を含めるものとします。)

再度のセクション 1.b.iの掲載となるが、上記の条項はLlamaライセンス契約バージョン3.1以降において追加された条項である。この条項は既に触れているようにLlamaの派生モデルの名称に制限を加える規定であるが、よく見るとLlamaマテリアルだけでなくLlamaモデルの出力若しくは結果を学習データとして利用することを含めていることが分かる。つまり、モデルの出力および出力を学習へ利用したモデルにまで権利付与のための条件を継承させていることになる。

これを単にGNU GPL等のコピーレフトのようなものと考える勢力もいるとは思うが、コピーレフトはあくまで当該ソフトウェアの著作権が及ぶ範囲において各国で認められる正当な権利に基づく仕組みである一方で、Llamaモデルの出力がモデル自身の知的財産権を継承するものであるかは甚だ疑わしい。トレーニングデータに依拠するという考え方は一部にはあると考えられるが、結局の所はモデル出力は確率論的な結果に過ぎない。このような計算機による確率論の結果を介してライセンス契約の条件の継承させるという試みは、良く言えば斬新、悪く言えば暴挙であろう。オープンソースのライセンスは全世界的に各国の著作権法で認められる権利に対して自由を付与する仕組みであるが、Llamaライセンス契約はその範囲を越える領域にまで自社の制御を及ぼそうとしている。少なくともオープンソースが希求する自由とは相反すると考えられる。

2.4. 商標に関しての追加的な制限

セクション 5.a.において、商標使用のライセンスが付与されないことが明記されている。商標ライセンスが付与されないことが明記されているオープンソースのライセンスは幾つも存在し、そのこと自体は問題にはならない。しかし、前述したようにLlamaという名称を派生モデルにまで使用を義務づけておきつつ、さらにセクション 5.a.においてそのような限定的な商標使用においてもMeta社のブランドガイドラインへの遵守を追加的に義務付け、その使用から生じるのれんまでMetaに帰属することが定められている。これはオープンソース性の議論からはやや離れた問題ではあるが、制限的であることは事実だろう。

2.5. 契約としての性質

オープンソースライセンスは各国の著作権法に基づいて著作権者が予め宣言する著作物の利用許諾である。幾つかの訴訟にてライセンスの契約性から生じる執行の強制力が認められたことで契約としての側面も考慮するようになりつつあるが、グローバルなコミュニティ内では実務上においてやはり権利者による一方的な許諾であると見做し、それによってエコシステム拡大の連鎖を作り上げていると考えられている。これは準拠法が明記されているような形式のライセンスでも基本的には変わりない。

一方、Llamaライセンス契約は名称そのもので既に契約だと宣言しているようなものだが、同意ボタンのクリックやLlamaの利用によってライセンシー側が契約に拘束されることを同意させる仕組みになっていること、ならびに契約テキストの各所でMeta社に発生する知的財産権に基づく権利以上の制約をライセンシー側へ課していることなどから、明らかにライセンスというよりも契約としての体裁が備わっている。実際、Meta社からのモデルのダウンロードに際してはサインが求められるので、著作権ライセンスではなく米国契約法に基づくMeta社と各ライセンシー間における二者間の商取引という体裁となっている。

この仕組み自体が即座にオープンソース性を否定するものではないが、Llamaの場合はこれまでに指摘してきた事項で発生する契約上の義務の解釈が、米国契約法の原則を通じて文字通りの契約テキストを超えて拡張され、強制力を高める方向へ寄与すると考えられるだろう。これは、オープンソースの根本原則である様々な自由を損なう方向へ圧力をかけていくことになるだろう。

3. オープンソースAI

ここまでに指摘した数々の事項に照らし合わせれば、Llamaライセンス契約はOSDのほとんどの条項に適合せず、Llamaがオープンソースではないことは明らかである。これに対して、AIモデルは一般的なソフトウェアと異なり、OSIによるオープンソースの定義に拘束されることはないという詭弁も一部にある。その論拠となるものはOSD 2条「ソースコード」であり、そもそもOSIのオープンソースはソースコードが存在するソフトウェア向けの定義でしかないということを言いたいのだろう。

このような意見を意見を封じることも目的に含め、私を含む世界の有志が2年間の共同設計プロセスを経て「オープンソースAIの定義」(OSAID: Open Source AI Definition)を2024年10月までに作り上げた。OSAIDはモデル、コード、データと様々なコンポーネントから構成されるAIシステムがオープンソースAIを名乗るための条件と言えるものであり、モデル単体のようなコンポーネント単位でのオープンソース性を判断するものではない。しかし、その策定プロセス中において「AIモデルにおけるソースコードとは何か?」という疑問は当然ながら幾度も議論された。その議論において、AIトレーニングという演算における最終的な結果物であるモデルには世界の多くの法域における解釈ではトレーニングデータに発生している知的財産権が残存せず、さらに、データ自身がモデルを制御しているわけでもないことから、トレーニングデータがAIモデルのソースコードと言えるかは疑問視する見方が強かったと思う。そうは言っても、トレーニング過程からを含めて全てのソースコードとウェイトを含むモデルの実体が完全にオープンソースの定義の根本的理念に適合し、さらに全てのトレーニングデータに完全な透明性があることは、AIシステムがオープンソースと見做す上でコンセンサスが取れている考え方である。そして、これはほぼそのままOSAIDの考え方でもある。

Llamaライセンス契約が「オープンソースの定義」に全く適合しないことは明らかであるが、仮にその契約がオープンソースに適合したとしても、Llamaモデルに関連するソースコードとデータセットは完全に公開されているわけではなく、オープンソースのAIシステムである見做すことはできないだろう。

4. むすび

LlamaモデルならびにLlamaライセンス契約のそれぞれがオープンソースの定義とオープンソースの原理原則に適合しないことは明らかである。Meta社にはMeta社の裁量でライセンスを定める自由があるが、オープンソースではないライセンスをオープンソースであると喧伝することはオープンソースコミュニティがこれまで拡大させてきたエコシステムの価値を毀損させる行為であり、このような行為は慎まなければならない。

また、Llamaの利用者は、Llamaライセンス契約の本質を正しく理解し、開発したLlama利用のサービスやLlama派生モデルの利用者にどのような影響が及ぶのかを逐次把握しなければならない。特に契約組込み型の利用規約についてはその影響力を軽視する風潮が強いように見え、多大な投資を無駄にすることのないように努める方が良いだろう。

なお、Llamaのオープンソース性とは直接的に関係のないLlamaライセンスの契約の問題点に関しては前述のように別稿で取り上げることとする。

参考:

オープンソースとは何か? Open Source Definition逐条解説書:

オープンソースAIとは何か? – Open Source AI Definition策定経緯とドラフト版概説:

オープンソースAIとは何か? –「オープンソースAIの定義 v1.0」詳細解説:


LLAMA 3.1 コミュニティライセンス契約 日本語参考訳

Llama 3.1 バージョンリリース日: 2024年7月23日

「契約」とは、本契約書に記載されているLlamaマテリアルの使用、複製、頒布および改変に関する条件を指します。

「ドキュメンテーション」とは、Metaが https://llama.meta.com/doc/overview にて頒布するLlama 3.1に付随する仕様書、マニュアル、および文書を指します。

「ライセンシー」または「あなた」とは、あなた、あなたの雇用主、またはこの契約をその人または団体のために締結している場合、法的な同意を提供するために必要な年齢に達しており、かつその雇用主またはその人や団体を法的に拘束する権限を持っているその他の個人または団体を指します。

「Llama 3.1」とは、Metaが https://llama.meta.com/llama-downloads で頒布する機械学習モデルコード、トレーニングモデルの重み、推論を可能にするコード、トレーニングを可能にするコード、ファインチューニングを可能にするコード、およびこれらに付随するその他の要素を含む、大規模言語モデルおよびソフトウェアおよびアルゴリズムを指します。

「Llamaマテリアル」とは、本契約の下で提供されるMeta独自のLlama 3.1およびドキュメンテーション(およびその一部)を総称して指します。

「Meta」または「我々」とは、あなたもしくはあなたが法人である場合に主たる事業所ががEEAまたはスイスに所在する場合はMeta Platforms Ireland Limited、その他の場合はMeta Platforms, Inc.を指します。

以下の「同意する」ボタンをクリックするか、Llamaマテリアルの一部または要素を使用または頒布することにより、あなたは本契約に拘束されることに同意することになります。

1. ライセンスの権利と再頒布

a. 権利の付与: あなたは、Llamaマテリアルに含まれるMetaの知的財産またはその他の権利に基づいて、Llamaマテリアルを使用、再製、頒布、コピー、派生作品の作成、および改変するための非独占的、世界的、譲渡不可能でロイヤルティフリーの限定的なライセンスが付与されます。

b. 再頒布と使用:

i. あなたがLlamaマテリアル(またはその派生作品)またはLlamaマテリアルを含む製品やサービス(他のAIモデルを含む)を頒布もしくは利用可能にする場合、あなたは (A) 当該のLlamaマテリアルとともに本契約書の写しを提供し、(B) 関連するWebサイト、ユーザーインターフェース、ブログ投稿、概要ページ、または製品ドキュメントに「Built with Llama」を明示的に表示しなければなりません。LlamaマテリアルまたはLlamaマテリアルの出力若しくは結果を使用して、AIモデルを作成、トレーニング、ファインチューニング、または改良し、それを頒布する場合、そのAIモデル名の先頭に「Llama」を含めるものとします。

ii. あなたがライセンシーから統合エンドユーザー製品の一部としてLlamaマテリアルまたはその派生作品を受け取った場合、本契約の第2条はあなたに適用されません。

iii. あなたが頒布する全てののLlamaマテリアルのコピーには、「Notice」テキストファイル内に次の帰属表示を保持する必要があります:「Llama 3.1はLlama 3.1 コミュニティライセンス契約の下でライセンスされています。Copyright © Meta Platforms, Inc. All Rights Reserved.」

iv. あなたによるLlamaマテリアルの使用は、適用される法律および規制(貿易コンプライアンスに関する法律および規制を含む)を遵守し、Llamaマテリアルに関する利用規約(https://llama.meta.com/llama3_1/use-policy で入手可能)に従う必要があります。このポリシーは、参照することによって本契約に組み込まれます。

2. 追加の商用条件: Llama 3.1のバージョンリリース日において、ライセンシーまたはライセンシーの関連会社によって、もしくはライセンシーまたはライセンシーの関連会社に対して提供される製品またはサービスの月間アクティブユーザー数が直前の暦月において7億人を超える場合、あなたはMetaからのライセンスを要求しなければならず、Metaは独自の裁量であなたにライセンスを付与することができ、Metaが明示的に当該権利をあなたへ付与しない限り、もしくは付与するまで、あなたは本契約に基づく権利を行使することは許可されません。

3. 保証の免責: 適用法で義務付けられていない限り、Llamaマテリアルおよびそれらから生じるあらゆる出力および結果は、「現状有姿」で提供され、いかなる種類の保証も付されず、Metaは明示的または黙示的かを問わず、所有権、非侵害、商品性、または特定の目的への適合性に関する保証を含むがこれらに限定されずあらゆる種類の保証を全てを否認します。あなたは、マテリアルを使用または再頒布することの適切性を判断する全責任を負うものとし、Llamaマテリアル、出力、結果の使用に関連するリスクを全て負うものとします。

4. 責任の制限: いかなる場合においても、Metaまたはその関連会社は、契約、不法行為、過失、製造物責任、またはその他の責任理論に基づくかを問わず、本契約に起因する逸失利益または間接的、特別、結果的、偶発的または懲罰的損害賠償について、Metaまたはその関連会社がこれらの可能性を認識していたとしても、一切責任を負わないものとします。

5. 知的財産:

a. 本契約の下で商標ライセンスは付与されず、Llamaマテリアルに関連して、Metaまたはライセンシーのいずれも他方またはその関連会社が所有する、またはそれらに関連する名称または商標を使用することはできません。ただし、Llama素材を合理的かつ慣例的に説明し再頒布するために必要な場合、または本第5条(a)項に定める場合を除きます。Metaは、本契約により、第1条b項iの最後の文章に従うために必要な場合のみ、「Llama」(「マーク」)を使用するライセンスを貴社に付与します。あなたはMetaのブランドガイドライン(現在は https://about.meta.com/brand/resources/meta/company-brand/ でアクセス可能)を遵守するものとします。マークの使用から生じるすべてののれんは、Metaに帰属するものとします。

b. Metaが作成したLlamaマテリアルおよびMetaによるまたはMetaのための派生物の所有権に従い、あなたが作成したLlamaマテリアルの派生作品および改変作品に関しては、あなたとMetaの間で、あなたは現在および今後もそれらの派生作品および改変作品の所有者となります。

c. あなたがMetaまたは他の法人に対して、訴訟またはその他の手続き(訴訟における反訴または反論を含む)を起こし、LlamaマテリアルまたはLlama 3.1の出力や結果、またはいずれかの一部があなたの所有またはライセンス付与可能な知的財産権またはその他の権利を侵害していると申し立てる場合、訴訟または申し立てが提起または開始された時点で、本契約に基づきあなたに付与されたライセンスは終了するものとします。あなたは、Llamaマテリアルの使用または頒布に起因もしくは関連する第三者からの請求について、Metaを免責し、損害を与えないものとします。

6. 期間および終了: 本契約の期間は、あなたが本契約を受け入れるかLlamaマテリアルにアクセスした時点で開始され、本契約の条件に従って終了するまで有効に継続するものとします。Metaは、あなたが本契約のいずれかの条項に違反した場合、本契約を終了することができます。本契約が終了した場合、あなたはLlamaマテリアルを削除し、その使用を中止するものとします。第3条、第4条および第7条は本契約の終了後も有効に存続するものとします。

7. 準拠法および管轄権: 本契約は、法の選択に関する原則に関わらず、カリフォルニア州法に準拠し、解釈されるものとし、国際物品売買契約に関する国連条約は本契約には適用されないものとします。本契約に起因する紛争に関しては、カリフォルニア州の裁判所が排他的管轄権を有するものとします。

オープンソースAIとは何か? – Open Source AI Definition策定経緯とドラフト版概説

オープンソースAI(Open Source AI)とは、オープンソースの状態にあるAIシステムのことである。これはある意味で自明なのではあるが、「オープンソースの定義」(OSD)を管理している米国の非営利団体Open Source Initiative(OSI)では、2023年からわざわざ新たに「オープンソースAIの定義」(OSAID: Open Source AI Definition)の策定を開始している。2024年の8月頃には定義のRC版が公開される見込みであるが、本稿ではこの新たな定義が何故必要になり、その定義がどのような機能するものであるかということに対し、主に佐渡が視点から時系列的に簡単に紹介していく。これによって日本国内においてOSAIDが認知され、AI開発コミュニティにおいて自由かつ透明性が確保されたシステムの必要性への理解が深まる一助となることを期待する。

注:2024年10月にオープンソースAIの定義 v1.0 がOSIによってリリースされている。本稿はドラフト0.0.8に沿った解説であり、概念的にはv1.0を理解する上で役に立つとは考えられるもののv1.0では多くの部分で議論を踏まえた修正があり、正しい理解をするためには、オープンソースAIとは何か? –「オープンソースAIの定義 v1.0」詳細解説 を参照して頂きたい。

  1. OSIにおけるAIへの問題意識の高まり
  2. 定義策定方針に至った理由
  3. 定義の策定プロセス
  4. ドラフト版定義解説
    1. 前文解説
    2. OSAID定義の本体の解説
      1. 4つの自由を採用した理由
      2. AIシステムという用語を採用する理由
      3. 4つの自由を必要とするAIシステムを構成するコンポーネント
    3. チェックリストの解説
      1. 必須となるコード
      2. 必須となるモデル
      3. 必須となるデータ情報
  5. チェックリスト適用の現状
  6. 今後と懸念点
  7. 参考

OSIにおけるAIへの問題意識の高まり

2022年は画像生成AIモデルStable DiffusionやOpenAIのChatGPTが公開され、広く世間に現在の生成AIが認知され、その可能性が盛んに議論され始めた年である。同時に当時は既に策定作業中であったEU AI規則案に代表されるように、俄に高まったAIのリスクにどのように対処していくべきかという議論も世界各地で行われ出した年でもあるのだろう。

AI関連領域の技術が急速に発展し、それが一般社会に対して未曾有の影響を与える可能性を見せ始めたことを踏まえ、OSIは「Deep Dive: AI」という調査プログラムをこの年に開始した。これはAI関連のビジネス、社会、法律、学術の観点から専門家を集め、インタビューやパネルディスカッションを実施するものであった。そこでは、現在でもよく言われているようにAIのアルゴリズムやモデルがどのように機能するかを理解することが根本的に困難であるブラックボックス的な性質、またそこから起因するプライバシー侵害やバイアスといった不正使用がもたらすリスクへの対応の必要性が論じられた。そして、これらの課題への対処には、データのオープン化の促進と従来のオープンソース・コミュニティにおける協働作業のような透明性のある技術の民主化が必要であるとの結論が出された。

ただし、この時点ではOSIにてオープンソースAIのための定義を作るという動きは表面的には存在しなかった(当時からOSIの上層部は定義策定を考えていたと私は推測している)。OSIの最大の使命は「オープンソースの定義」(OSD)を維持していくことであり、世間で喧伝されていた生成AIのモデルも結局は計算機システム上に存在するソフトウェアの一種でもある。であれば、従来からのOSDとその定義による審査をパスしたOSI承認済みオープンソース・ライセンスで実用的には十分にカバーされるという考え方に辿り着くのが普通であるだろう。一般に学習済みのモデルのパラメータ部分には著作権が発生しないとされていることで、ライセンスが依拠する著作権で保護される部分が少ないという問題があっても、それは従来のソフトウェアでも多少なりとも存在していた話であり、また改変が複雑かつ困難であり再現性がないという問題もライセンスの問題とは考えなければ良いことである。AI技術の分野にてオープンソースが大きな役割を果たさなければならないことは明らかであったが、まだこの頃はOSIがAIのためにわざわざ定義を策定するという方向性はあまり現実味がなかったように思う。

定義策定方針に至った理由

OSIがオープンソースAIの定義の策定の方針を明確に打ち出したのは、2023年の6月だったように思う。前項で示したようにDeep Diveの取り組みから自由で透明性のあるAIへの要求が高まってきており、オープンソースのAIと言える要件を明確化する必要性はコミュニティ内でも存在していたが、この漠然とした欲求に加えて二つの理由が積み重なった結果であると思う。

一つは最近よく指摘されるようになってきているOpen Washing(オープン・ウォッシング)への対処である。近年はSSPL等のような事業推進のために外形的にオープンソースに見せかけながらも何らかの制限や罠をライセンスに入れ込む欺瞞に満ちた取り組みが増えており、自由なコミュニティへの脅威の一つとなっているが、MetaによるLlama等の一部のAI企業によるモデルは明らかにオープンソースではない条件で頒布されているシステムに対してオープンソースという冠を被せており、25年以上の年月に渡ってコミュニティが積み重ねてきたオープンソース・エコシステムの価値を毀損させている。この状況に対応するためには、AIがオープンソースであるための明確な定義が必要であるという論を強化している。

もう一つはEU AI規則のような世界各地で議論され始めたAI法制への対処である。特にEU AI規則においては、AIによるイノベーションの創出と高いレベルのAIの安全性と信頼性を両立するために透明性とオープン性が確保されることが必要であるとし、自由に実行、複製、頒布、研究、改変が可能なオープンソースの重要性を認め、そのためオープンソースであるAIシステムに対して様々な規則の例外を定めている。しかし、それだけオープンソースであるAIシステムの重要性を認めながらも、肝心のオープンソースAIが何であるか?という明確な定義はないわけである。

この二つの理由は実は相関性があり、そもそも後者のようにAIがオープンソースAIと見做されることには事業推進上で大きなメリットが生じると考えられ、このメリットの存在によって前者のようなOpen Washing的行動が促されるという側面もあるのだろう。いずれにせよ、こうしてオープンソースAIの定義(OSAID)の策定の機が熟していったのである。

定義の策定プロセス

OSAIDの前に1998年のOSD策定時について触れておくが、よく知られているようにOSDはDebianプロジェクトのリーダーであったBruce Perensによって書かれている。とはいっても彼が一人で全て書いたというわけでなく、OSDの元となったDebianフリーソフトウェア・ガイドラインはDebian Project内での一ヶ月あまりの激論の中で生まれたDebian社会契約の副産物として生まれたと考えた方が妥当だろう。そして、その中で書かれている理念や規則はフリーソフトウェアの運動が始まってから十数年の間にコミュニティが蓄えてきた経験則を簡潔に再構成したと考えて良い。つまり、既に生きた手本があり、それを定式化していったわけである。

この先例に倣ったかどうかは知らないが、2023年6月前後にDeep Diveの枠組みでの専門家集団やOSIのボード周辺等で様々な議論がなされていたと思う(佐渡自身は当時のOSI内の議論は知らない)が、おそらく頭を抱えていたのではないかと思う。先にAIが「計算機システム上に存在するソフトウェアの一種」であると書いたが、そのソフトウェアの一種であるAIを一つのライセンスでカバーできるかと考えるとそうはならない。現在の一般的な生成AIにおいてもAIのシステム全体は非常に多くのコンポーネント(各種のデータ、コード、モデル)が存在し、またそれらはオープンソースが主に扱うプログラムとは異なる何かである。それらが複雑に絡み合うものがAIシステムなのであり、それらのコンポーネントのための法的な利用条件も様々である。

このような特性から、例えばオープンソースに触発されたオープンデータやオープンコンテンツのようにオープンソースAIというものを定義し、その定義に適合するライセンスをオープンソースAIライセンスと呼ぶといったやり方は難しい。例えばAIシステムの何らかのコードがオープンソースであったとしてもモデルの一部が自由に利用ができなければ、それはやはりオープンソースとは言えない。従来のソフトウェアであればソースコードとバイナリコードは対になっており、例えばGPLであるソースコードからはGPLである実行コードが生まれたわけであり、ライセンスさえチェックしていれば十分であった。しかし、AIの場合はシステムの一部のコードがオープンソースであるからといって、システム全体がオープンソースであるとみなすのは難しいわけである。

このため、
(1) 最初にAIシステム全体がオープンソースと呼ぶために必要な要件となる理念を定め、
(2) その後、AIシステム全体の中でそれらの要件をクリアする必要があるコンポーネントが何であるかを突き止め、
(3) それらのコンポーネントの(ライセンス等の)利用条件がクリアすべき(OSD等の)法的な枠組みを規定する

という順序のプロセスが採用され、AIシステムを構成する様々なコンポーネント一つ一つをOSD等の枠組みで検証し、(2)で規定されたコンポーネント全てでオープンソースと呼ぶために必要な枠組みに適合した場合にオープンソースAIと認められるという複雑なものとなった。OSDは十箇条のテキストの条文であるが、OSAIDはこの(1)、(2)、(3)の全てが入れ込まれた複雑なチェックリストのようなものとなっている。

この文章を書いている2024年6月末の段階ではこの「オープンソースAIの定義」(OSAID)のバージョンは0.0.8であり、夏にはRC版が公開され、秋になる前には正式に1.0版がリリースされる計画となっており、今のところはそのスケジュール通りになると思う。

なお、OSAIDドラフトバージョン0.0.2以降はOSIメンバー全員が策定作業に関与できるようになっており、そこから数えても既に9ヶ月ほど議論が続いている。佐渡自身もその頃からOSIでの議論に参加しているのだが、まだ前述の(1)しか見えていない頃はそもそもOSAIDの必要性が中々掴めず、既存のOSDの存在の意味を毀損しないことばかりに注力していたが、別のワーキンググループが(2)に該当するコンポーネントを規定してからは非常にスムーズにプロセスが進み、OSAIDが機能する可能性を着実に高めているように手応えを感じている。特に最近はLinux Foundation、AWS、Googleからの意見も出てくるようになり、良い方向へ進んでいると思う。これはOSAIDの議論のために世界を飛び回っているOSIのExecutive DirectorであるStefano Maffulliの手腕に依るところが大きいだろう。

何となく区切りのために置いたDALL-E出力

ドラフト版定義解説

オープンソースAIの定義 0.0.8 日本語参考訳https://github.com/opensource-jp/Open-Source-AI/blob/main/osaid-0-0-8-ja.md
Open Source AI Definition draft 0.0.8https://opensource.org/deepdive/drafts/the-open-source-ai-definition-draft-v-0-0-8

現在のOSAIDのドラフト版は上記にて公開されている。日本語参考訳は佐渡によるものである。

定義全体を見渡すと、ぱっと見でもOSDとは随分と趣が異なることが分かるだろう。OSAIDは策定の意図を述べた前文、オープンソースAIの定義そのもの、ライセンス等の法的文書を評価するためのチェックリストという三つの部分で構成される。以降は、それらの解説を行う。

前文解説

OSAIDの前文ではオープンソースであるAIが必要な理由が述べられている。オープンソースのライセンスが適用された従来のソフトウェア・システムによる恩恵が、自律性、透明性、軋轢が生じない再利用、共同改善に集約されることを述べ、AIシステムにおいてはユーザーが信頼性と透明性のあるAIシステムを構築するためにオープンソースによる自由が必要だと先ず宣言している。つまり、信頼性、安全性、透明性の確保されたAIシステムのためにはオープンソースが必要だと言っているわけである。

前文は今のところこれだけである。信頼性と透明性の下りが重要な部分であるが、これはOSAID策定の決定に影響を与えたEU AI規則や米国の大統領令等を意識しており、それらの法的文書におけるオープン性の部分はOSAIDが担うという宣言でもあるように佐渡個人としては考えている。

なお、元々前文はもう少し長かったのだが、倫理だとか責任だとかそういった言葉があって冗長だったために次第に削除されていった。長い前文で想いを語るような方向性もあったのだと思うが、私のようなOSD原理主義者がOSDの感覚にはない表現に対してネガティブな意見を出していった結果、現状ではこうなっている。前文で倫理や責任あるAIといったフレーズを削除する方向に力学が働いたのは結局OSDがそれらを全く定義していないからである。OSDはあくまでソフトウェアが自由であるための条件を示しているのであり、倫理といったことは規定しない。AIの倫理のために自由が必要であるかもしれないが、それらとは別の議論であるということである。また、倫理というものは結局の所、人と場所が違えば違う考え方になるものでもある。オープンソースは世界のどこにいても自由であるためのルールであるわけであり、従ってオープンソースのAIシステムを定義するための定義でも倫理が規定されるべきではないのである。

OSAID定義の本体の解説

次のOSAID 0.0.8の定義本体部分では、オープンソースAIとは下記のような自由を与える条件の下で利用できるAIシステムのことであると定義している。下記の条件はおそらくOSAID 1.0リリースまで細部においても維持されるだろう。それだけ条文が安定していると考えて良い。

使用:どのような目的であれ、許可を得ることなくシステムを使用すること。
研究:システムがどのように動作するかを研究し、そのコンポーネントを検査すること。
改変:出力を変更することを含め、どのような目的であれシステムを改変すること。
共有:どのような目的であれ、改変の有無に関わらず、他者が使用できるようにシステムを共有すること。

https://github.com/opensource-jp/Open-Source-AI/blob/main/osaid-0-0-8-ja.md

OSDの十箇条とは随分違うと思われる方もいるだろうし、勘の良い人であればFree Software Foundation(FSF)の「4つの自由」(4 Freedoms)との類似性に気が付くかもしれない。そう、ここではFSFの4つの自由に着想を得た要件が書かれているのである。

FSFの4つの自由は、実行、研究、改変、再頒布の自由であり、OSAIDの自由は使用、研究、改変、共有である。大きな違いは頒布が共有となったことだが、これは現在では従来の頒布という行為に収まらない行為も含ませるためだろう。また、実行が使用になっているのも「データの使用」等の行為も含まれるように拡張する意図がある。なお、私は使用という用語が曖昧なのでまだ実行のほうがいいと当初は主張していたのだが、その点は賛同者はあまりいなかった。この点はデータの使用という観点も含まれるので仕方がない。

4つの自由を採用した理由

さて、ここでOSDの十箇条ではなくFSFの4つの自由を採用しているのは奇妙であると思われる方がいるかもしれない。しかし、ここにOSDが書かれていないのは、そもそもOSDはソフトウェアそのものではなくライセンスのための定義であることを思い出さなければならない。

拙作のOpen Source Definition逐条解説書にも書かれていることであるが、OSDの十箇条は第一条から第三条までと第四条から第十条までの二つの部分に大別することができる。第三条までは著作権における各支分権の利用許諾に焦点を置いており、第四条以降はライセンスの条文が満たすべき技術面を含む要件が記述されているのだが、これは第三条までが何が自由であるべきかという理念を示し、第四条以降はライセンス審査のための要件、すなわち現在のOSAIDで言う所のチェックリストを指し示すと解釈することも可能である。つまり、OSDでは10箇条で定義とライセンス審査のためのチェックリストを兼ねていたものをOSAIDでは明確に分離したとも言える。よって、OSAIDの定義部分はOSDの最初の三条までにあたる理念を表現しているとも言える。

また、OSDの最初の三箇条で明示的に自由が書かれている権利は改変と頒布のみであり、使用、研究に関しては明示的ではない。これは著作権の利用許諾としてのライセンスの審査のためには特に必要ではないし、全十箇条で暗黙的に自由が規定されているとみなされるのであるが、OSAIDのようにAIシステムの審査要件部分を切り離すと、定義部分での自由が何の自由を指すかが不明瞭になってしまう。そこで、FSFの4つの自由に依拠した使用、研究、改変、共有の自由を明示的に定義することにした、というのは私の勝手な理解であるがさほど間違ってはいないだろう。

AIシステムという用語を採用する理由

ここに至るまで既に何度か「AIシステム」という用語を使用しているにも留意してほしいが、OSAIDはそのAIシステムの自由のための定義である。OSDはライセンス審査のための定義であるが、OSAIDはそうではないのである。さらに言えば、OSAIDは様々なトレーニングデータや学習から推論までのプログラム、そしてモデル等の様々なコンポーネントから構成される一連のシステムのための定義なのである。

よく考えれば分かることであるが、一つのライセンスや一つのソフトウェアのためであれば既にOSDが存在する。AIシステムの一部を構成する単一のソフトウェア・コンポーネントがオープンソースであるかどうかという識別にはOSDで十分に機能するが、AIシステム全体をオープンソースと呼ぶためにはOSDによる一回の判定でカバーできない部分が生じるため、OSAIDがそれを補うことになるのである。

なお、OSAIDにおけるAIシステムという用語の定義は経済協力開発機構(OECD)が採用した下記のAIシステムの定義に従っている。

「AIシステムとは、明示的または暗黙的な目的のために、受け取った入力から物理的または仮想的な環境に影響を与えることができる予測、コンテンツ、推奨、または決定などの出力を生成する方法を推論する機械ベースのシステムである。AIシステムによって、自律性や導入後の適応性のレベルは異なる。」

https://github.com/opensource-jp/Open-Source-AI/blob/main/osaid-0-0-8-ja.md

このOECDによる定義を採用することに対しては主に佐渡から異論があった。極論すればこの定義はソフトウェアやデータだけでなくハードウェアの領域を含むように解釈できるということで、私としてはAIシステムとされる領域が広過ぎるのではないかと懸念していたのであるが、後述のAIシステムを構成するコンポーネント単位による記述で調整できると理解してからは現状ではこの定義を使うことが妥当なのだろうと思い至っている。このOECDの定義を使用することで、OSAIDは現在の生成AIブームを牽引する大規模言語モデルだけでなく、機械学習、ディープラーニング、コンピュータービジョン、その他の幅広い分野への適用性を残している。

4つの自由を必要とするAIシステムを構成するコンポーネント

定義本体の後半部分ではオープンソースAIと呼ぶために4つの自由が満たされるべきコンポーネントが書かれているが、現時点ではデータの情報、コード、モデルで大別されている。これは下記の0.0.8の定義をそのまま参照する方が理解が早いだろう。ようは、これらのコンポーネントが全て使用、研究、改変、共有の自由が満たされて初めてオープンソースAIを名乗れるということである。一部のコードやモデルがオープンソースであるからと言って、それ以外のコンポーネントがクローズドであればオープンソースAIとは限らないということでもある。

データの情報:熟練者が同一または類似のデータを使用して実質的に同等のシステムを再作成できるように、システムの学習に使用したデータに関する十分に詳細な情報。例えば、使用されている場合、学習方法方法および技術、使用された学習用データセット、それらのデータセットの出所および範囲と特徴、データの取得方法と選択方法、ラベリングの手順とデータクリーニング方法に関する情報が含まれる。
コード:システムのトレーニングおよび実行に使用されたソースコード
例えば、使用されている場合、データの前処理に使用されたコード、学習と検証およびテストに使用されたコード、トークナイザーやハイパーパラメーター検索コード等のサポートライブラリ、推論コード、モデルアーキテクチャなどが含まれる。
モデル:モデル・パラメータ
例えば、最終的なオプティマイザの状態だけでなく、学習の主要な中間段階からのチェックポイントも含まれる。

https://github.com/opensource-jp/Open-Source-AI/blob/main/osaid-0-0-8-ja.md

なお、データの情報における説明で「熟練者が同一または類似のデータを使用して実質的に同等のシステム」という不思議な文言が出てくる。特に熟練者、類似のデータ、実質的に同等という三つの用語の曖昧性が気になる方もいると思うが、ここは意図的に曖昧性を残し、解釈の幅を持たせていると現時点で考えてもらえれば良いだろう。

チェックリストの解説

AIシステムを審査するために前項で大別したコンポーネントをLF AI+Dataのメンバーらが公表した論文「The Model Openness Framework」に従って細分化したリストを使用し、下記のようにデータの情報、コード、モデルを分類し、それらが満たすべき法的枠組みを個別に指定している。このチェックリストは現状のドラフト0.0.8では定義に含まれている形式の文書となっているが、今後の議論次第でこのチェックリストは定義とは分離される可能性があると私は見ている。AI周辺の技術の進展によってこのような形式の分類が不適当となる将来はそんなに遠くないと思われ、この部分は今後逐次改編される可能性があるからである。

必須コンポーネント 法的枠組み
データの情報
– 学習の方法論と技術OSD準拠のライセンスで利用可能
– 学習データの範囲と特徴OSD準拠のライセンスで利用可能
– 学習データの出所(データの入手方法、選択方法等)OSD準拠のライセンスで利用可能
– 学習データのラベリング手順(使用する場合)OSD準拠のライセンスで利用可能
– 学習データのクリーニング技法OSD準拠のライセンスで利用可能
コード
– データ前処理OSI承認のライセンスで利用可能
– 学習、検証、テストOSI承認のライセンスで利用可能
– 推論OSI承認のライセンスで利用可能
– サポート用のライブラリとツールOSI承認のライセンスで利用可能
モデル
– モデル・アーキテクチャOSI承認のライセンスで利用可能
– モデル・パラメータOSDに適合した条件で利用可能

https://github.com/opensource-jp/Open-Source-AI/blob/main/osaid-0-0-8-ja.md

現時点のOSAIDでは、最低限上記のコンポーネントがOSDに従うことをオープンソースAIと呼ぶために要求することになる。ここで注意深く見て欲しいのは法的枠組みが微妙に文面が異なり、「OSD準拠のライセンス」、「OSI承認のライセンス」、「OSDに適合した条件」という三種類の文言を使い分けているということである。

AIシステム開発に使用されたコード類が全てOSI承認ライセンスというのは自明的であるが、学習データ関連がOSD準拠となっているのはどういう意味だろうか?これはOSI承認ライセンスが基本的にプログラムのコードのためのライセンスであり、データやコンテンツのためのライセンスではないからである。オープンデータやオープンコンテンツ、もしくはクリエイティブコモンズの一部のライセンスについてはOSD準拠と通常は見做されており、データやコンテンツのための利用されているライセンスであるが、これらのライセンスを含めた考え方を指していると現状で考えて良いだろう。

また、モデル・パラメータでの「OSDに適合した条件」という表現は、そもそもパラメータでは通常の著作権を前提とするライセンスが多くの法域で無効の可能性が否定できず、約款方式を含む契約等の法的枠組みに頼らざるを得ないという懸念があることで曖昧な表現が使用されている。とは言っても結局はOSDへの適合を求めているわけであり、パラメータにおいても4つの自由が保証されていることがオープンソースAIの前提となるのである。

必須となるコード

OSAIDへの適合のために必須となるコンポーネントの中で最も理解がしやすいのは当然ながらコードの部分であるだろう。現状では、データの前処理、学習、検証、テスト、推論、サポート用のライブラリとツールがOSAIDへの適合のために必須とされ、それぞれがOSI承認のライセンスで利用可能であることを求められる。これはAIシステムの実行のために必要となる推論コードだけでなく、システムの構築のためにトレーニングの課程で必要となったコードまでを含めてオープンソースであることを求めていることになる。結局の所、日本流に言えばAIの学習課程で使用されたコードもオープンソースでなければ、AIシステムの透明性は確保されず、再現も不可能であるということである。この辺りは異論はほとんどないのではないかと思う。

必須となるモデル

モデルの部分に関しては、モデルアーキテクチャおよびモデルパラメータを必須コンポーネントとしている。モデルアーキテクチャは、機械学習アルゴリズムやニューラルネットワークのアーキテクチャ要素が含まれ、これらには完全に記述されたソースコード等の形式で共有され、OSI承認のライセンスで利用可能であることが求められる。

また、モデルパラメータはモデルの重み(ウェイト)や単にパラメータとも呼ばれる学習済みモデルのデータ部分のことであるが、このモデルパラメータは「OSDに適合した条件で利用可能」というやや難解な表現で規定している。OSAIDの理念としてはOSDに適合した条件を求めるのは当然のことと言えるが、オープンソースのライセンスは結局の所は著作権というグローバルに通用する知的財産権に依拠している。つまり、OSI承認のライセンスは著作権が有効ではない領域に適用することには不向きであり、従って他の枠組みのほうがよりベターであるとも言えるだろう。幸いにもデータ向けのライセンスとしてはOpen Knowledge Foundationが推進するオープンデータ系のライセンスやクリエイティブ・コモンズが存在するし、またライセンス以外の方法として何らかの契約的手法が法域によっては有効かもしれない。これらの考え方としてはOSDに合致する枠組みを包括した法的条件を「OSDに適合した条件」としているのである。ようは何らかの法的条件で使用、研究、改変、共有の自由が保証されれば良いのであるが、このあたりは今後様々な試行が続くのではないかと思っている。

必須となるデータ情報

データの情報に関しては「熟練者が同一または類似のデータを使用して実質的に同等のAIシステムを再作成できるように、システムのトレーニングに使用したデータに関する十分に詳細な情報」とOSAIDの中で定義され、その情報にはトレーニング方法および技術、使用されたトレーニング用データセット、それらのデータセットの出所および範囲と特徴、データの取得方法と選択方法、ラベリングの手順とデータクリーニング方法に関する情報が含まれる。これらの情報がOSD準拠のライセンスで利用できる状態にすることが求められるのである。モデル・パラメータのように契約等のライセンス以外の法的行為を含むわけではないが、OSD準拠とみなせるようなライセンスであれば良い。データの情報ということはある意味で文書コンテンツが大半となる可能性が高いわけであり、クリエイティブ・コモンズの一部のライセンス等のOSI承認以外のOSD準拠とみなせるライセンスを含ませる必要があるということである。なお、当然ながらクリエイティブ・コモンズではCC-BY-4.0やCC0等の余計な制限のないライセンスが念頭に置かれている。

ここで注意が必要なのは、トレーニングで使用されたデータそのものはここに含まれていないということである。あくまでそのデータに関する情報のみを必須としているのである。

現時点でOSIがこのように判断しているのは今年の冬に行われた専門家で構成された作業部会での検討結果によるものである。佐渡はそれには参加していないが、作業部会ではAIシステムの使用、研究、改変、共有の自由のために必要であるコンポーネントは何であるかを突き止めるために幾つかのAIモデルを使って調査検討がなされた。そして、トレーニングデータの領域に関してはデータの内容そのものよりもその出所やラベル付け、重複排除、フィルタリングした方法等を知ることが重要であるという結論が出されたのである。AIシステムにおいて4つの自由を実現するためには、単なるデータセットよりもどこのデータをどのように処理したのか分かるような情報の方が重要ということである。

また、データそのものを含むデータセットを共有することは法域によっては違法または技術的に不可能となる状況も発生することが報告された。

例えば、PileというMITライセンスで頒布されているデータセットが存在するが、海賊版サイトから違法に収集された著作権の発生するコンテンツが含まれていることが発覚し、それを除いた上で再公開されるという事案が過去にあった。しかし、既に以前の海賊版コンテンツを含むデータセットで学習したモデルというものは数多く存在する。日本法ではこのような状況に対しての法的な判断の整理はある程度済んでいるが、他の法域ではモデルそのものの正当性に関して判断がつかないこともあるだろう。OSIはその領域における法的判断に踏み込むわけではないが、オープンソースAIである要件にデータの完全な入手まで含まれるとすれば、オープンソースAIと判定されたAIシステムが後から学習したデータセットの公開が禁止された場合にその場でオープンソースAIである資格を失うという考え方もできることになる。その場合、モデルとして十分に4つの自由が実現できているのに学習データが時間経過によって欠けたことでオープンソースAIと呼べなくなる。さすがにそれは理不尽だろうというのが現在の判断である。

なお、データセットそのものをOSAIDで完全に無視しているというわけではなく、学習に用いた完全なデータセットはオプションとして公開リリースされている方が望ましいという位置付けになっている。データセットの位置付けに関してはおそらく継続的に議論され、場合によって判断が変更されることもあるだろう。

チェックリスト適用の現状

現在、OSIでは現在のOSAIDドラフトでのチェックリストを用いた各AIシステムの検証作業も並行して実施されている。Arctic、BLOOM、Falcon、Grok、Llama 2、LLM360、Mistral、OLMo、OpenCV、Phi-2、Poro、Pythia、T5の13システムにおける検証結果が既に報告されているが、現時点ではArctic、LLM360、OLMo、Pythia、T5の5つのシステムのみがOSAIDに適合する可能性が高いとみなされている。

公開されている部分のみにおいても検証するまでもなく4つの自由を満たさないLlamaのようなシステムもあるが、多くのケースでは公開されているコンポーネントが足りていないAIシステムが多い。システムとして再現性があり、使用、研究、改変、共有の自由を満たすには欠けているコンポーネントがあるということである。よって、システムの一部のコードがオープンソースであっても、それがシステムとしてオープンソースAIではないという現象が生じている。なお、これらは現時点のドラフト版を使ってのテスト的な検証に過ぎないが、定義および審査がより厳格になることはあっても緩められることはないだろう。つまり、現状で審査をパスしないシステムがオープンソースAIとみなされることはないだろう。

今後と懸念点

OSAIDの現時点のバージョンは0.0.8であるが、夏にはRC版となり年内にはバージョン1.0として正式にリリースされることになる。現時点では10月にRed Hatの本拠地であるRaleighで開催のAll Things Openにて発表される見込みであるが、そこから若干遅らせる可能性はあるだろう。とは言え、定義全体としては現在の0.0.8でほぼ完成しており、ここから大幅に内容が変更される可能性は低い。しかし、現時点で残されている議論や課題は中々妥協点を探ることは難しく、議論をどのように収束させていくか私から見ても容易ではなさそうなのは懸念される。

残されている議論の中で最大のものは、オープンソースAIのために必須とするコンポーネントにトレーニングデータそのものを含めるか否かという点である。前述のように必ず必要とは限らないという専門の作業部会からの報告やデータに違法性があった場合等に一般に共有することが困難になることへの懸念から現在のドラフトでは完全なトレーニングデータを求めていない。データに関する十分な情報がOSD準拠のライセンスで入手できれば良いという整理をしているわけであるが、これには当然ながら異論もある。完全なモデルの再現性のためには完全なトレーニングデータの入手が必要であるという論である。完全なデータが入手できることは再現性、透明性にとってプラスであることは議論への参加者には否定する者はいないし、私としてもある程度は同意するのだが、それが必須と言えるかは何とも微妙なところである。ただ、OSIとしてはこの点に明確な結論を出しているわけではなく、特にAWS等の大手企業側からこのような完全なデータを必要とする意見を出されているので慎重な議論が継続している。この点は大きくひっくり返るとは思わないが、何らかの微修正はあってもおかしくないとは思う。

また、定義策定以降の審査体制も徐々に問題視されるようになっている。OSDが事実上ライセンスのための定義であるとは前述しているが、そのためOSIは1998年以降ずっとライセンスの審査だけを遂行する組織として成り立ってきた。承認されたライセンスで頒布されるソフトウェアは自動的にオープンソースとみなせるので、ライセンスだけを審査するだけで事足りたわけである。しかし、OSAIDはその構造上から否応なくAIシステムそのもののオープンソースAIへの適合性を審査する必要がある。これをどのような体制、組織、フローで行うかという議論は今のところ具体的なものはない。その必要性は議論されているのでいずれOSIの中で体制を作ることになるとは思うが、その一方でソフトウェアのライセンスの審査は25年以上単なるメーリングリストでのボランティアによる議論での審査というラフな体制で行われてきたわけである。複雑なAIシステムをコンポーネント単位で判定していく作業は既存のライセンス審査とは異質の作業となることは明らかであるし、次々に公開されるAIシステムを逐次審査するだけの人的リソースをOSIが確保し続けるのは今のところは難しい。ただ、このあたりはやると決めれば何とかなるのだろう。

他には、モデル・パラメータに対してグローバルで共通する共有のための法的利用条件としてライセンスという手法が有効であるかどうかという問題もあるだろう。日本法では単なるウェイトは解析結果のデータと整理され、基本的には著作権等の知的財産権が発生しないことが前提となっているが、世界各国の法域においてもモデル・パラメータに対して有効な知的財産権が存在し得るかどうかは微妙な議論が続いている。既に機械学習コミュニティにおいてはオープンソースのライセンスがある程度浸透しているものの、基本的にオープンソースのライセンスは著作権に依拠しているわけであり、その有効性に関しては今後も議論が続くことになるだろう。

この法的な有効性の観点にも関連するのだが、OSAIDに適合するような法的条件をもってAIシステムを共有する行為がこのまま機械学習コミュニティに受け入れられ続けるだろうかという疑問もある。法的有効性に加え、オープンなAIシステムを法的に禁止する動きもあるからである。EU AI規則ではAIの安全性と信頼性を担保するための透明性とオープン性の実現のためにオープンソースが有効であるという論に立って法が作られているが、その一方で特に米国では安全保障上の観点から他国への技術流出を防ぐ目的でオープン性を否定し、根幹から自由な利用を禁止する方向の意見が根強くある。さらに、AIシステム側に一定の倫理制限を求める動きというものは世界共通に見られる傾向でもある。

大昔の暗号領域での米国の輸出規制の経過を見れば分かるように、オープンソースのコミュニティは共有の禁止が安全保障に寄与するとは考えてはいないし、また倫理的な観点での制限が必要であればAIシステムの法的利用条件ではなく各国の倫理の基準に合わせた法令等の領域で制限すべきことだろうということになる。しかし、機械学習コミュニティがこのような判断をするとは限らず、やがてオープンソースであるAIへの熱意が消え去る危険性というものはあるだろう。そもそも、1998年のオープンソース運動というものは自由なソフトウェアを信じる在野のコミュニティの間で成功していた慣習を取りまとめ、それを一般化した運動であったように思うが、一方で現在のAI関連の業界というものは基本的に大資本の資金の投入合戦のようでもあり、元々の機械学習コミュニティにおいて自由な成果の共有という慣習はあるものの大規模で自由なAIシステムの成功例というものはこれからのことであるように思う。今の状況下でオープンソースAIというムーブメントを継続し続けるのは1998年のオープンソース運動より難易度は高いのだろう。

このように課題はまだ山積しているのではあるが、おそらく年内にAIシステムがあるオープンソースAIとみなされる基準となる「オープンソースAIの定義」を我々は公表することになる。公表後もAIと機械学習の技術の進展に合わせて逐次見直しを図ることになるし、定義の運用を開始することにもなるだろう。AIが今後どのように社会に浸透していくのかという観点には我々は回答を持ち合わせていないが、社会で一般的にAIシステムが利用されるようになるのであればそのAIの技術はオープンであり透明性が確保されるべきだと我々は信じている。そのような世界の実現のためにオープンソースAIが存在すると言える世界が訪れることを私は願っている。

参考

Deep Dive: AIレポート: https://deepdive.opensource.org/wp-content/uploads/2023/02/Deep-Dive-AI-final-report.pdf
Now is the time to define Open Source AI: https://opensource.org/blog/now-is-the-time-to-define-open-source-ai
SSPLのライセンス条文とその適格性に関するメモ: https://shujisado.com/2023/12/12/notes_on_sspl/
EU Artificial Intelligence Act: https://artificialintelligenceact.eu/
Open Source AI Definition – draft : https://opensource.org/deepdive/drafts
オープンソースAIの定義 日本語参考訳: https://github.com/opensource-jp/Open-Source-AI
オープンソースとは何か? Open Source Definition逐条解説書: https://shujisado.com/open-source-definition-commentary/
The Model Openness Framework : https://arxiv.org/abs/2403.13784
Recommendation of the Council on Artificial Intelligence: https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0449

Copyright 2024 Shuji Sado
本文書はクリエイティブ・コモンズ 表示-継承ライセンスのもとで利用できる。挿絵は単純プロンプトによるAI生成物であり、パブリックドメインである。

「頒布」という訳語を使用するのは何故か?

オープンソースに限らずソフトウェア業界においては、distributeもしくはdistributionという単語を使用することが多い。そして、その単語への日本語訳としては「配布」を割り当てることが多いだろう。しかしながら、オープンソースの定義やオープンソース・ライセンスの日本語訳等では基本的にdistributeの訳として「頒布」という語が使用されている。これは何故だろうか?

(本稿は「オープンソースとは何か? Open Source Definition逐条解説書」の付録の一つとして収録されている文書である。)

はいふ【配布】
[名](スル)配って広く行き渡らせること。「駅前でちらしを―する」
はんぷ【頒布】
[名](スル)品物や資料などを、広く配ること。「希望者に無料で―する」「銘酒の―会」

デジタル大辞泉を引用すると配布と頒布は上記のような意味となる。違いがあるようには見えるが、どちらも「何かを広く配って行き渡らせる」という意味で違いはない。では何が違うのか? 実は「配布」は基本的に無償であり、「頒布」は無償もしくは有償のどちらの場合もあり得るという違いがある。上記の用例でのチラシは無償であり、銘酒頒布会というのは有償の即売会のことを意味するのである。

自明ではあるがオープンソースの定義や全てのオープンソース・ライセンスにおいては無償か有償かという点は問わない。そうであるにも関わらず、オープンソース関連の文脈においてdistributeを「配布」と訳すと、まるで「ソフトウェアを広く配って行き渡らせる」行為が無償であることに限定する印象を与えることになる。だから、「頒布」という訳語が使用されるのである。我々の自由なソフトウェアのコミュニティは、無償に限定されるように捉えられるということを一貫して否定してきたわけでもあり、正しい理念を伝達していくためには誤解されにくい言葉を使用する方が望ましい。

冒頭の疑問についてはこの回答で終わるはずなのだが、この議論は忘れられた頃に繰り返される話の一つであり、私は認識していなかったが数年前にもそれなりに大きな論争があったらしい。それらの論争において「配布」で良いとする主張する側の論拠は基本的にパターン化されているので、下記で反証していく。

「頒布」という言葉が難しすぎる:

確かに「頒布」という言葉は日常的に使うことは少なく、やや難解な日本語に該当するのだろう。ただ、それは「配布」よりも難しいというだけのことであり、Googleで検索すれば一般的に販売会のような意味で頒布会という言葉が一般的に使用されている事実に気が付くだろう。また、同人誌の界隈では太古の昔から販売会のことを頒布会と呼んでいるようである。コミックマーケットにおいても基本的に「頒布」という言葉が使われている。同人誌業界での「頒布」という用語の使用には歴史的な事情があるようであるが、「頒布」が難しすぎるのであればここまで広く使われないのだから、少なくともこの用語は一般の人々に受けいれられていると考えて良いだろう。

日本の著作権法で定める「頒布権」と混同するし、貸与の意味がある:

日本国の著作権法では「頒布権」という権利が定められている。ややこしいことにこの権利は映画著作物に限定されている権利である。映画館での上映フィルムを配給元から制御するための権利を何故か本邦では頒布権という名称にしたのであるが、オープンソース・ライセンスは著作権に依存しているので、この映画の頒布権との区別するために頒布という言葉を使ってはならないという主張があるわけである。

正直ここまでくると言いがかりに過ぎないのだが、著作権法第二条一項十九号において「頒布」という言葉の意味が「有償であるか又は無償であるかを問わず、複製物を公衆に譲渡し、又は貸与すること」と先に定義されていることをその主張は忘れている。頒布は著作物を広く公衆に譲渡もしくは貸与することと定められているのであれば、すなわちこれはオープンソース・ライセンスにおけるdistributeの意味として完全に正しいだろう。このように明確に定義され、意味としても合致する言葉の使用を否定する理由にはならないだろう。

ここまできてもさらに「オープンソースを貸与するという行為は通常ないので頒布は正しくない」という空虚な主張も過去にあったらしい。このような主張はかつてソフトウェアがテープ、MO、フロッピー等のデバイスに固定化され、回覧されていた歴史を忘れているのだろう。また、最近であれば、クラウドのサービスはその形態によってソフトウェアの貸与があり得るだろう。つまり、ソフトウェアは貸与できるし、オープンソースも然りである。オープンソースのライセンスであれば、複製、翻案、頒布の自由が許諾されているわけだが、この許諾された権利の中に暗黙的に貸与という利用行為への許諾も含まれていると考えて良いのである。

結論として、オープンソース・ライセンスが絡みそうな文脈ではdistributeは極力「頒布」と訳すことを勧める。「配布」の場合はどうしても無償に偏ることになり、有償のケースを除外しかねない。かつて自由ソフトウェアの陣営が、Freeは無償を意味するという誤解を中々払拭できなかった歴史を認識すべきだろう。

出自:
本稿は、2023年3月3日に佐渡によって書かれた「「配布」と「頒布」の違い」を一部修正した文書である。

倫理を振りかざすライセンスが好ましくないのは何故か?

オープンソースが社会で受容されるにつれ、コミュニティの中においても一定の倫理が求められる傾向が強まっている。Code of Conduct(行動規範)を定める開発プロジェクトが多くなったのもその流れだろう。しかしながら、ライセンスによって使用者に対して倫理的な行動を求めることは現在に至っても忌避されており、それを悪だと看做す人々も多い。これは何故だろうか?

(本稿は「オープンソースとは何か? Open Source Definition逐条解説書」の付録の一つとして収録されている文書である。)

嫌いな奴を排除する

大抵の人には嫌いな人がいるものだ。人間とはそのようなものだろう。その嫌いな人々に自分が開発したソフトウェアを使わせたくないという感情を持つことを中々否定できるものではない。そして、ソフトウェアの開発者には開発したソフトウェアに対する著作権が帰属する。著作権に基づいて第三者に対しソフトウェアの利用の許諾を宣言する行為がライセンシングであるわけなので、このライセンスにて「〇〇の集団と〇〇に属する連中は一切使用禁止」と記述すれば嫌いな奴を排除できる。厳密な法的効力の問題は残るが、それでもライセンスとしてはそれでも有効なライセンスとして扱われるだろう。

ということで、昨今の風潮を踏まえれば、様々な領域における「悪人」を排除するといった正義のためにライセンシングの手法を使いたいと思う人が出てくるのは仕方がない。マイノリティを保護もしくは支援したいとか、戦争やテロの脅威を無くしたいとか様々な正義感からくる倫理的と考える思想をライセンスに込めたくなるのは理解できる。しかし、このような倫理をライセンスを込める手法は、ライセンサー側の期待通りに事が運ぶことはまずなく、むしろ想定しなかった害が発生することが多い。

利用者が困るライセンシングの実例

例を出していこう。かなりの昔となるが、Debianプロジェクトにてあるアナログ電子機器用ツールのライセンスが問題となったことがあった。それは「南アフリカ警察の使用を禁ずる」という内容が含まれるライセンス条文だった。おそらくは人種差別政策として名高いアパルトヘイトに抗議する意図があったのだろう。しかし、問題が発覚した当時は既にアパルトヘイトは終結し、南アフリカの警察には黒人警官が一般的となっていた時代だった。つまり、ライセンサーの開発者は差別される黒人を憐んで正義のためにライセンスを書いたのだと思われるが、逆に南アフリカの黒人警官を差別する結果となっていたわけである。

日本に目を移すと、Javaの黎明期に開発された分散オブジェクト関連のツールがあり、そのライセンスには「平和的な目的のために使用してください。軍隊や兵器関連、防衛行為関連、反社会的活動のために使用してはいけません」という記述が存在した。この記述の意図は分かる。平和は尊いものだ。大抵の人々が願うものだろう。しかし、自分の使い方は本当に「平和的な目的」での使用なのだろうか?あるいは本当に軍事利用や反社会活動に完全に繋がっていないのだろうか?という疑問に対して確信を持って否定できる人はどれほどいるのだろうか?そもそも平和的な目的というのはあまりにも曖昧な表現ではあり、もっと簡潔な軍事目的の禁止というだけであったとしても、現在進行中の戦争を見れば意図せず日本の民間企業の技術が使われていることも分かるだろう。ソフトウェアサプライチェーンがグローバルの隅々にまで行き渡った現在においては、ソフトウェアの用途というものは最後まで誰にも分からないケースが多々ある。そのような中で用途で制限をかける非常に難しいのである。

他に有名な用途縛りの事例としてはある音声認識ツールがある。このツールのライセンスには、「原子力関連、航空管制その他の交通関連、医療、救急関連、警備関連その他人の生命、身体、財産等に重大な損害が発生する危険を有するシステムに使用してはいけません」という記述が含まれている。これは正義感というよりも単にミッションクリティカル領域での使用に自信がないだけかもしれないが、このライセンスではヘルスケアや金融サービスといった領域でのサービスで使用することができないことになるだろう。単に自信がないなら「無保証」を強調すれば良いだけの話だ。

オープンソースであるために

これらの前述の例のようにライセンスで使用できる者や利用用途の制限を加えることは、ソフトウェアを使用する側に混乱をもたらすだけでなく、開発者側にとっても普及という点で大きなハンデを負うことになる。良いことと言えばライセンサーである開発者自身の自己満足ぐらいであり、これはある意味で非常に大切かつ重要なのではあるものの、オープンソースではこのような考え方をライセンスに含めることは明確に禁止している。これらの事例はオープンソースの定義における第五条、第六条に反するわけだが、このような条項が設けられたのはまさに上記の事例のようなことを避けるためなのである。

  1. 個人やグループに対する差別の禁止
    ライセンスは特定の個人やグループを差別してはなりません。
  2. 利用する分野(fields of endeavor)に対する差別の禁止
    ライセンスはある特定の分野でプログラムを使うことを制限してはなりません。 例えば、プログラムの企業での使用や、遺伝子研究の分野での使用を制限してはなりません。
https://opensource.jp/osd/osd19/#5

中には、単にオープンソースもしくは自由ソフトウェアと称するよりも倫理的な行動を求める方が重要であると反論する方がいるかもしれない。しかしながら、オープンソースとはどうすればソフトウェアを効率よく伝搬させ、健全なエコシステムを作り上げることができるかという命題を突き詰めた結果でもあり、今日のソフトウェアのサプライチェーンにおいて中心的な考え方でもある。ここにある種の例外を持ち込むことはその例外を含むソフトウェアの使用の忌避を招き、結局のところソフトウェアは普及が妨げられ、ライセンサーが意図する正義や倫理が広く伝わることもないという事象を招くことになる。

今日の倫理を求める勢力

上記のような反論を世界中から指摘されても、ある種の信念を持っているタイプの人達は自分の信じる正義を追求することもあるもので、Organization for Ethical Source (OES)が提唱するHippocratic Licenseという倫理の塊のようなライセンスが数年前に一部で話題となった。このHippocratic Licenseの3条には奴隷制、強制労働、児童労働、拷問や非人道的扱いや罰、基本的人権侵害行為、個人のプライバシー妨害、民族弾圧、労働者団結権および結社権の行使妨害等の行為を禁止する他、性別、性的指向、人種、民族、国籍、宗教、カースト、年齢、障害等での差別も完全に禁止し、同一労働同一賃金も求められるという条項が含まれている。

このHippocratic Licenseを推進する人々には本当に強い信念があるのだろう。このプロジェクトを推進する中心的な方は多くのオープンソースプロジェクトが採用するContributor Covenantという標準的Code of Conduct(行動規範)の作者でもあり、この成功体験からライセンスにおいても信念を持ち続ければ普及すると考えているのではないかと思う。

しかしながら、既に幾つかの事例で述べてきたことと同様の理由でこのライセンスが普及することはないだろう。著作権ライセンスは制約が多いほど使われることが少なくなるが、ここまで詰め込めば好んで採用する者は中々いない。結局はある種の社会運動の象徴的な枠割を果たすということになるのだろう。

倫理を条件にすることは避けよ

そもそもライセンスとは著作権を保持する者が第三者に対して行う一方的な許諾の宣言に過ぎない。契約性が議論されることがあるが、厳密にはライセンスは契約ではないのである。ソフトウェアの使用者側はそのライセンスにサインすることもないわけであり、ある意味では性善説的な部分を含有するシステムである。そもそも広く許諾を与えている状況において倫理的条件への違反をライセンサー側が証明しなければならないというのは途方もない作業である。どこかの組織がソフトウェアを軍事利用しているか、あるいは反社会的活動に手を染めていないか等をどうやってライセンサー側が証明できるのだろうか?これではライセンスの条文としては全く機能していないと言えるだろう。

自分達が考える倫理的な行動をユーザーにも求めるのは問題ない。GNU GPLの前文にはFSFとしての御託が書いてあるが、GPLの本文の条件にはそのような御託はなく単に一般的な条件だけが述べられている。GPLが示しているように、何かの倫理的な主張をするのは問題ないが、それをライセンスにおいて許諾条件にしてはならない。ライセンスが依拠する著作権法で倫理を追求するのは著作権の限界を超えており、世の中における不正な行為や望ましくない行為は著作権法以外の法で縛るべきである。

また、そもそもライセンスを遵守しようという意識が持つ人々は相対的に倫理的にも高い水準にあると考えられるが、倫理意識に乏しい組織や人がわざわざライセンスを遵守しようとするだろうか?ソフトウェアが必要であれば黙って使うか、あるいは言い訳できる仕組みを用意するだけだろう。ライセンスという仕組みは悪用したい者にとっては何の制約にもならないものであり、ライセンスに倫理を持ち込んで複雑にすればするほど、善意の人々は混乱し、悪意の人々が得をすることになる。

これが倫理をライセンスに持ち込んで条件にすることが好ましくない理由である。

オープンソースにおける無保証と免責の条項

オープンソースの定義にはオープンソースであるライセンスで定めるべき条件もしくは定めてはいけない条件が記述されているが、オープンソース・ライセンスと呼ばれるものに必ずのように含まれる条項も存在する。いわゆる無保証と免責の条項である。本稿では、この無保証と免責の条項について雑多に解説する。

(本稿は「オープンソースとは何か? Open Source Definition逐条解説書」の付録の一つとして収録されている文書である。)

免責の必要性

オープンソースのライセンスで記述されている内容は大別すると、著作権表記、許諾内容と条件、無保証と免責の条項となる。著作権表記はライセンスが効力を発揮する前提となる著作権者の証明であり、続く許諾の内容と条件においてオープンソースの定義を完全に遵守する内容を記述していけば基本的にはオープンソースのライセンスとして効力を持つことになる。ということで、無保証と免責の条項はオープンソースであるための必須条件ではないのであるが、このような条項が含まれていることは、歴史的、法的および実務的な理由によって重要な意味を持つ。

歴史的にオープンソースのソフトウェアは営利組織ではなく、個人もしくは非営利組織を主体とするコミュニティの主導によって開発されてきたが、このような営利組織による支援がないということは保証の責任を負う組織が存在しないことを意味している。つまり、オープンソースへの貢献者の多くは保証請求といった法的リスクを負う余裕のないグループの一員であり、免責条項は貢献者を潜在的な責任から保護することになる。

もう少し詳細に書けば、開発者はソフトウェアによって引き起こされた欠陥や損害に対して法的責任を負う可能性があり、使用者は損害が発生した場合に訴訟する権利を持つ。特に個人の貢献者や小規模な組織にとっては経済的に打撃を受ける可能性があるわけであり、このような保証と責任を制限することで法的な影響を恐れることなく、より多くの人々がオープンソースのプロジェクトに貢献することを可能にするのである。

また、一般的にオープンソースによる開発は多くの人々が協働して進化することを目指しているが、このようなスタイルの開発手法を考慮すると、そもそも特定の使用者による特定の目的に対してソフトウェアの適合性を保証することは非現実的であるとも言える。

よって、オープンソースのライセンスにおける無保証条項および免責条項は、開発者を法的リスクから保護し、オープンソースのプロジェクトへの広範な参加を促し、オープンソース開発の協働的な性質を維持するために不可欠な要素なのである。

無保証と免責の歴史

免責条項の解説としてはこれで終わりなのだが、さて、このような条項はいつ頃から存在していたのだろうか?ソフトウェア著作権が認められる以前から商用の計算機の世界でこのような条項を含む契約が存在していたと思われるが、オープンソースのライセンスとしては最初期のライセンスであるMITライセンスの初出とされているライセンスにもそれらしき条文が存在する。

M.I.T. makes no representations about the suitability of this software for any purpose.
It is provided “as is” without express or implied warranty.
(MITは、本ソフトウェアがいかなる目的にも適していることを表明するものではありません。
本ソフトウェアは、明示または黙示の保証なしに「現状のまま」提供されます。)

上記は1984年にMITのコンピューターサイエンス研究所において開発されたIBM PC用のTCP/IPスタックを頒布する際に付与された著作権ライセンスの最後の免責条項の部分の抜粋である。短い二つのセンテンスだけであるが、明確に無保証であることを表明していることが分かる。当時は米国でソフトウェアに著作権が認められることが確定した頃であるが、著作権のライセンス料を徴収しても大した金額にならないという判断から一方的な許諾(ライセンス)とされたという経緯がある。つまり、自由に使っていいが保証はしない、ということであり、現代の協働的な発想とは直接的に結びつかないわけであるが、現在のライセンスで一般的な”as is”はここに源流がある。

GNU Emacs is distributed in the hope that it will be useful, but without any warranty. No author or distributor accepts responsibility to anyone for the consequences of using it or for whether it serves any particular purpose or works at all, unless he says so in writing.
(GNU Emacsは有用であることを期待して頒布されていますが、いかなる保証もありません。GNU Emacsの作者も頒布者も、使用した結果について、あるいは特定の目的を果たすかどうか、あるいは全く機能しないかどうかについて、文書でそう述べない限り誰に対しても責任を負いません。)

GNU Emacs copying permission notice(1985)

翌年の1985年、Richard StallmanがGNU Emacsの頒布のために付与したGNU Emacs copying permission notice(GNU Emacs複製許可通知)にも同様の条項が存在する。このGNU Emacsに付与された通知こそが1989年のGNU GPL version 1に繋がるライセンスであるが、”as is”は存在しないもののMITの初期型よりも明確に無保証と免責が述べられていることが分かる。

1989年に発表されたGNU GPL version 1においてはほぼ現代の一般的なオープンソースのライセンスに見られるような冗長な免責条項となっている。このGPL version 1もそうなのだが、このあたりからの特徴として免責条項が基本的に大文字で表記されるようになったと考えられる。この特徴的な大文字表記には実はそれなりの意味がある。

米国においては民法および商法は州毎に異なるが、それでは州を越える取引に不都合が発生するということで民間の組織によって合衆国内での統一的な法典が作成された。それが統一商事法典(UCC:Uniform Commercial Code)であり、民間組織作成の法典なのでそれ自身は法的効力を持たないものの、全米のほとんどの州がこの法典の内容をそのまま州法として採用しているために事実上の法として機能している。

何の関係があるのだと思われるかもしれないが、この統一商事法典にて商取引の契約では売主側が免責されると規定するためには目立つように記載しなければならないと定められているのである。単に目立つようにと規定されているので太文字や下線でも構わないような気もするのだが、タイプライターの時代からずっと大文字の慣行となっている。

なお、統一商事法典では契約書で目立たないように免責規定を書いた場合、あるいはそもそも免責を明言して規定しなかった場合は、売主は買主に対して黙示的に保証したことになると定められている。つまり、オープンソースのライセンスの無保証と免責条項にて大文字で表現されていなかった場合、それらの条項は無効と主張することも可能であり、黙示的にソフトウェア製品の商品適格性(品質、性能を備え商品として用途に適合しているか)や特定目的適合性(買主の目的に適合しているか)等の保証をしていると理解される余地を残すのである。

ただし、オープンソースのライセンスは著作権の利用許諾であり、商取引の契約ではない。しかしながら、厳密に既存の法との適合性を持たせるように努力した結果、このような大文字の条文となったのだろう。