Shuji Sado

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逐条解説書：

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

オープンソースAIとは何か？ – Open Source AI 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条はあなたに適用されません。

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」詳細解説を参照して頂きたい。

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.8： https://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

「頒布」という訳語を使用するのは何故か？

オープンソースに限らずソフトウェア業界においては、distributeもしくはdistributionという単語を使用することが多い。そして、その単語への日本語訳としては「配布」を割り当てることが多いだろう。しかしながら、オープンソースの定義やオープンソース・ライセンスの日本語訳等では基本的にdistributeの訳として「頒布」という語が使用されている。これは何故だろうか？

(本稿は「オープンソースとは何か？ Open Source Definition逐条解説書」の付録の一つとして収録されている文書である。)

はいふ【配布】
［名］(スル)配って広く行き渡らせること。「駅前でちらしを―する」
はんぷ【頒布】
［名］(スル)品物や資料などを、広く配ること。「希望者に無料で―する」「銘酒の―会」

デジタル大辞泉を引用すると配布と頒布は上記のような意味となる。違いがあるようには見えるが、どちらも「何かを広く配って行き渡らせる」という意味で違いはない。では何が違うのか？実は「配布」は基本的に無償であり、「頒布」は無償もしくは有償のどちらの場合もあり得るという違いがある。上記の用例でのチラシは無償であり、銘酒頒布会というのは有償の即売会のことを意味するのである。

自明ではあるがオープンソースの定義や全てのオープンソース・ライセンスにおいては無償か有償かという点は問わない。そうであるにも関わらず、オープンソース関連の文脈においてdistributeを「配布」と訳すと、まるで「ソフトウェアを広く配って行き渡らせる」行為が無償であることに限定する印象を与えることになる。だから、「頒布」という訳語が使用されるのである。我々の自由なソフトウェアのコミュニティは、無償に限定されるように捉えられるということを一貫して否定してきたわけでもあり、正しい理念を伝達していくためには誤解されにくい言葉を使用する方が望ましい。

冒頭の疑問についてはこの回答で終わるはずなのだが、この議論は忘れられた頃に繰り返される話の一つであり、私は認識していなかったが数年前にもそれなりに大きな論争があったらしい。それらの論争において「配布」で良いとする主張する側の論拠は基本的にパターン化されているので、下記で反証していく。

「頒布」という言葉が難しすぎる：

確かに「頒布」という言葉は日常的に使うことは少なく、やや難解な日本語に該当するのだろう。ただ、それは「配布」よりも難しいというだけのことであり、Googleで検索すれば一般的に販売会のような意味で頒布会という言葉が一般的に使用されている事実に気が付くだろう。また、同人誌の界隈では太古の昔から販売会のことを頒布会と呼んでいるようである。コミックマーケットにおいても基本的に「頒布」という言葉が使われている。同人誌業界での「頒布」という用語の使用には歴史的な事情があるようであるが、「頒布」が難しすぎるのであればここまで広く使われないのだから、少なくともこの用語は一般の人々に受けいれられていると考えて良いだろう。

日本の著作権法で定める「頒布権」と混同するし、貸与の意味がある：

日本国の著作権法では「頒布権」という権利が定められている。ややこしいことにこの権利は映画著作物に限定されている権利である。映画館での上映フィルムを配給元から制御するための権利を何故か本邦では頒布権という名称にしたのであるが、オープンソース・ライセンスは著作権に依存しているので、この映画の頒布権との区別するために頒布という言葉を使ってはならないという主張があるわけである。

正直ここまでくると言いがかりに過ぎないのだが、著作権法第二条一項十九号において「頒布」という言葉の意味が「有償であるか又は無償であるかを問わず、複製物を公衆に譲渡し、又は貸与すること」と先に定義されていることをその主張は忘れている。頒布は著作物を広く公衆に譲渡もしくは貸与することと定められているのであれば、すなわちこれはオープンソース・ライセンスにおけるdistributeの意味として完全に正しいだろう。このように明確に定義され、意味としても合致する言葉の使用を否定する理由にはならないだろう。

ここまできてもさらに「オープンソースを貸与するという行為は通常ないので頒布は正しくない」という空虚な主張も過去にあったらしい。このような主張はかつてソフトウェアがテープ、MO、フロッピー等のデバイスに固定化され、回覧されていた歴史を忘れているのだろう。また、最近であれば、クラウドのサービスはその形態によってソフトウェアの貸与があり得るだろう。つまり、ソフトウェアは貸与できるし、オープンソースも然りである。オープンソースのライセンスであれば、複製、翻案、頒布の自由が許諾されているわけだが、この許諾された権利の中に暗黙的に貸与という利用行為への許諾も含まれていると考えて良いのである。

結論として、オープンソース・ライセンスが絡みそうな文脈ではdistributeは極力「頒布」と訳すことを勧める。「配布」の場合はどうしても無償に偏ることになり、有償のケースを除外しかねない。かつて自由ソフトウェアの陣営が、Freeは無償を意味するという誤解を中々払拭できなかった歴史を認識すべきだろう。

出自：
本稿は、2023年3月3日に佐渡によって書かれた「「配布」と「頒布」の違い」を一部修正した文書である。

倫理を振りかざすライセンスが好ましくないのは何故か？

オープンソースが社会で受容されるにつれ、コミュニティの中においても一定の倫理が求められる傾向が強まっている。Code of Conduct(行動規範)を定める開発プロジェクトが多くなったのもその流れだろう。しかしながら、ライセンスによって使用者に対して倫理的な行動を求めることは現在に至っても忌避されており、それを悪だと看做す人々も多い。これは何故だろうか？

(本稿は「オープンソースとは何か？ Open Source Definition逐条解説書」の付録の一つとして収録されている文書である。)

嫌いな奴を排除する

大抵の人には嫌いな人がいるものだ。人間とはそのようなものだろう。その嫌いな人々に自分が開発したソフトウェアを使わせたくないという感情を持つことを中々否定できるものではない。そして、ソフトウェアの開発者には開発したソフトウェアに対する著作権が帰属する。著作権に基づいて第三者に対しソフトウェアの利用の許諾を宣言する行為がライセンシングであるわけなので、このライセンスにて「〇〇の集団と〇〇に属する連中は一切使用禁止」と記述すれば嫌いな奴を排除できる。厳密な法的効力の問題は残るが、それでもライセンスとしてはそれでも有効なライセンスとして扱われるだろう。

ということで、昨今の風潮を踏まえれば、様々な領域における「悪人」を排除するといった正義のためにライセンシングの手法を使いたいと思う人が出てくるのは仕方がない。マイノリティを保護もしくは支援したいとか、戦争やテロの脅威を無くしたいとか様々な正義感からくる倫理的と考える思想をライセンスに込めたくなるのは理解できる。しかし、このような倫理をライセンスを込める手法は、ライセンサー側の期待通りに事が運ぶことはまずなく、むしろ想定しなかった害が発生することが多い。

利用者が困るライセンシングの実例

例を出していこう。かなりの昔となるが、Debianプロジェクトにてあるアナログ電子機器用ツールのライセンスが問題となったことがあった。それは「南アフリカ警察の使用を禁ずる」という内容が含まれるライセンス条文だった。おそらくは人種差別政策として名高いアパルトヘイトに抗議する意図があったのだろう。しかし、問題が発覚した当時は既にアパルトヘイトは終結し、南アフリカの警察には黒人警官が一般的となっていた時代だった。つまり、ライセンサーの開発者は差別される黒人を憐んで正義のためにライセンスを書いたのだと思われるが、逆に南アフリカの黒人警官を差別する結果となっていたわけである。

日本に目を移すと、Javaの黎明期に開発された分散オブジェクト関連のツールがあり、そのライセンスには「平和的な目的のために使用してください。軍隊や兵器関連、防衛行為関連、反社会的活動のために使用してはいけません」という記述が存在した。この記述の意図は分かる。平和は尊いものだ。大抵の人々が願うものだろう。しかし、自分の使い方は本当に「平和的な目的」での使用なのだろうか？あるいは本当に軍事利用や反社会活動に完全に繋がっていないのだろうか？という疑問に対して確信を持って否定できる人はどれほどいるのだろうか？そもそも平和的な目的というのはあまりにも曖昧な表現ではあり、もっと簡潔な軍事目的の禁止というだけであったとしても、現在進行中の戦争を見れば意図せず日本の民間企業の技術が使われていることも分かるだろう。ソフトウェアサプライチェーンがグローバルの隅々にまで行き渡った現在においては、ソフトウェアの用途というものは最後まで誰にも分からないケースが多々ある。そのような中で用途で制限をかける非常に難しいのである。

他に有名な用途縛りの事例としてはある音声認識ツールがある。このツールのライセンスには、「原子力関連、航空管制その他の交通関連、医療、救急関連、警備関連その他人の生命、身体、財産等に重大な損害が発生する危険を有するシステムに使用してはいけません」という記述が含まれている。これは正義感というよりも単にミッションクリティカル領域での使用に自信がないだけかもしれないが、このライセンスではヘルスケアや金融サービスといった領域でのサービスで使用することができないことになるだろう。単に自信がないなら「無保証」を強調すれば良いだけの話だ。

オープンソースであるために

これらの前述の例のようにライセンスで使用できる者や利用用途の制限を加えることは、ソフトウェアを使用する側に混乱をもたらすだけでなく、開発者側にとっても普及という点で大きなハンデを負うことになる。良いことと言えばライセンサーである開発者自身の自己満足ぐらいであり、これはある意味で非常に大切かつ重要なのではあるものの、オープンソースではこのような考え方をライセンスに含めることは明確に禁止している。これらの事例はオープンソースの定義における第五条、第六条に反するわけだが、このような条項が設けられたのはまさに上記の事例のようなことを避けるためなのである。

個人やグループに対する差別の禁止
ライセンスは特定の個人やグループを差別してはなりません。

利用する分野(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)であり、民間組織作成の法典なのでそれ自身は法的効力を持たないものの、全米のほとんどの州がこの法典の内容をそのまま州法として採用しているために事実上の法として機能している。

何の関係があるのだと思われるかもしれないが、この統一商事法典にて商取引の契約では売主側が免責されると規定するためには目立つように記載しなければならないと定められているのである。単に目立つようにと規定されているので太文字や下線でも構わないような気もするのだが、タイプライターの時代からずっと大文字の慣行となっている。

なお、統一商事法典では契約書で目立たないように免責規定を書いた場合、あるいはそもそも免責を明言して規定しなかった場合は、売主は買主に対して黙示的に保証したことになると定められている。つまり、オープンソースのライセンスの無保証と免責条項にて大文字で表現されていなかった場合、それらの条項は無効と主張することも可能であり、黙示的にソフトウェア製品の商品適格性(品質、性能を備え商品として用途に適合しているか)や特定目的適合性(買主の目的に適合しているか)等の保証をしていると理解される余地を残すのである。

ただし、オープンソースのライセンスは著作権の利用許諾であり、商取引の契約ではない。しかしながら、厳密に既存の法との適合性を持たせるように努力した結果、このような大文字の条文となったのだろう。

何故オープンソースはパブリックドメインを含まないのか？

著作権関連の話題においてパブリックドメイン(Public Domain、公有)という言葉がしばしば出てくる。このパブリックドメインという言葉は特にソフトウェアの業界では根強く誤解されてきた用語であり、現在では少なくなったもののまだ誤用が見られる言葉でもある。

(本稿は「オープンソースとは何か？ Open Source Definition逐条解説書」の付録の一つとして収録されている文書である。)

一言で言えば、パブリックドメインとは「知的創作物において知的財産権が発生していない状態」である。ここでの知的創作物とは人が創作した作品のことであるが、その作品において著作権、商標権、特許権、意匠権等が完全に発生していないことを指している。つまり、全ての知的財産権の帰属を考慮する必要なく、無許諾かつ無制限に作品を利用できることになる。ここでの作品には文学、絵画、映像、音楽そしてプログラム等が含まれる。

作品がパブリックドメインとなるには

知的財産権の枠組みにおいて著作権だけは作品を生み出した段階にて自然に発生し、かつベルヌ条約に加盟する全法域においてその権利が相互に保護されるグローバルな権利として定められている。他の知財権と比較すれば非常にお手軽かつ創作後もしくは著作者の死後70年といった非常に長期に渡る保護がなされることも特徴であるが、期間があるということは当然ながらその権利保護期間が終了すれば著作権は消滅する。これが、パブリックドメインになるということである。

権利保護期間の終了以外にそもそも最初に生み出された段階でパブリックドメインとなっている作品も存在し、日本を含めた多くの法域では政府が発する法令や通達等の文書は著作権等が発生しないことが多い。また、特にプログラムの作品においては無条件に著作権が発生するわけでなく、誰が書いても同一になるといったプログラム創作物としての要件を満たせないような作品は著作権が発生せず、パブリックドメインであると言えるだろう。

さらに、著作権を放棄してパブリックドメインとすることも法域によっては可能であり、日本では著作者人格権(公表権、氏名表示権、同一性保持権等)が留保されると解されるという問題は残るものの、著作権の放棄が宣言されることで事実上のパブリックドメインとして扱うこともできる。このようなケースをパブリックドメインへの献呈と呼ぶこともあり、その宣言の手法としては昨今ではクリエイティブ・コモンズのCC0を採用することが増えている。作品をCC0で宣言した場合、放棄可能な著作権等の権利を放棄し、放棄できない権利に対しては無条件かつ永続的な利用許諾を行い、利用許諾が無効な場合は権利行使をしないということを確約することになる。

オープンソースとの違い

パブリックドメインはオープンソースと混同されることがあるが、オープンソースはその定義から「著作権が発生した上でその権利に基づいて利用者に対して自由な利用を許諾するライセンスもしくは許諾された状態」を指す用語である。つまり、著作権が存在するかしないかという根本的な部分で両者は全く異なる概念なのである。

ただ、どちらも対象となる作品を自由に利用できるという点においては同一である。このため広い意味においてパブリックドメインはオープンソースの範疇に入ると見做されることもある。実際、Free Software Foundation(FSF)は、ソースコードが入手できることが前提であるがパブリックドメインのソフトウェアを自由ソフトウェアとして分類している。パブリックドメインにあるソースコードは全てにおいて自由であり、FSFの根本的理念である自由とは矛盾しないため、その考え方は理解できるものである。

しかしながら、特にオープンソースのコンプライアンスに関わる者等からはパブリックドメインにはやや否定的な捉え方がされることが多い。何故なら、パブリックドメインに著作権が存在しないということであれば、元々の権利者が作品に対しての制御を完全に失っているからである。

著作権がないということは事実上その作品はもはや誰のものでもない。つまり、財産権も人格権も存在せず、クレジットというものも一切必要がなくなるということだ。また、複製、翻案、改変も完全に自由である。作品を管理する人間というものは存在しないし、それによって形式としては剽窃に該当する行為も当然ながら横行するようになる。MITライセンスなどの寛容なオープンソース・ライセンスであったとしても剽窃にはある程度の対抗手段があるわけだが、パブリックドメインの場合にはそもそも最初から権利がない。ソフトウェアのオープンソース化する際には作品を改善するフィードバックというものも期待されることが多いわけだが、それようなエコシステムの発生は基本的に起こりにくくなる。また、剽窃者によって新たに著作権を主張され、不自由なソフトウェアとされることもあるだろう。新たな実装で何らかの問題が発生したとしても、元の権利者にはそれに対処する手段は何もないのである。

これらの理由のため、オープンソースを使用していく上でのコンプライアンス観点ではリスクが増え、そのためパブリックドメインをオープンソースとは明確に区別する意見は根強い。

なお、Open Source Initiative(OSI)ではパブリックドメインであるソフトウェアを実務上はオープンソースの範疇として考えられることを概ね認めていると考えられるが、OSIが行っていることはオープンソースの定義に合致するライセンスの審査であり、パブリックドメインは著作権がないことからライセンスが存在し得ないため、パブリックドメイン化するような法的条件の文書等を審査することもしないし、ソフトウェアをパブリックドメイン化するのではなく承認されたオープンソースのライセンスを付与することを推奨している。

オープンソースと自由ソフトウェアの違い

オープンソースという用語は自由ソフトウェア(Free Software)という用語を置き換えるために作られたのは周知の事実である。それならば、両者の意味する所は全く同じであるはずであるが、歴史的経緯により両者には別々にその言葉の定義が存在する。それぞれの用語を代表する組織であるFree Software Foundation(FSF)とOpen Source Initiative(OSI)は各々の定義の維持に心血を注いでいるが、実際の所、この両者の違いというものは存在するのだろうか？

(本稿は「オープンソースとは何か？ Open Source Definition逐条解説書」の付録の一つとして収録されている文書である。)

四つの基本的な自由

どんな目的に対しても、プログラムを望むままに実行する自由 (第零の自由)。
プログラムがどのように動作しているか研究し、必要に応じて改造する自由 (第一の自由)。ソースコードへのアクセスは、この前提条件となります。
ほかの人を助けられるよう、コピーを再配布する自由 (第二の自由)。
改変した版を他に配布する自由 (第三の自由)。これにより、変更がコミュニティ全体にとって利益となる機会を提供できます。ソースコードへのアクセスは、この前提条件となります。

FSFでは自由ソフトウェアであるための条件として上記の「Four Freedoms」(4つの自由)を定義している。第一から第三までの自由が1999年まで使用された自由ソフトウェアの定義とほぼ同一内容を指す条文であるが、ここでは著作権的な考え方としては複製権、翻案権、二次的著作物作成権、頒布権に関して無制限の許諾を意味すると考えられる。

特殊であるのは「第零の自由」(Freedom 0)である。この条項はオープンソースの定義が誕生後に追加されたのであるが、入手したソフトウェアの実行という著作物の使用行為の自由を定義している。第一から第三までの自由は権利者の著作権による独占権に依拠しているが、第零の自由は著作権としては基本的に自由に使用できる領域に自由を定めているのである。プロプライエタリなソフトウェア業界では実行行為に対しても契約で制限を加えることが長く慣行として根付いているので、この使用行為に自由を定義することは不自然ではないのだが、複製、翻案、頒布といった利用行為に自由が定められているのであれば定義としてはそれで十分であるように一見考えられる。ただ、FSFではこの第零の自由を「どんな人間や組織でも、あらゆるコンピュータシステム上で、どんな種類の仕事と目的のためにでも、開発者や特定の団体と連絡する必要なく、プログラムを使うことができるという自由」と説明しており、非常に幅広い意味を持つ条項として位置付けている。

オープンソースの定義との比較

オープンソースの定義は十箇条で構成されるが、それぞれの条項は下記のように区分することができる。

第一条から第三条 – 著作権における各支分権の利用許諾に焦点：

第一条 (自由な再頒布)：無制限で自由な再頒布を規定
第二条 (ソースコード入手性)：ソースコードへ容易にアクセスできることを規定
第三条 (改変と派生著作物作成)：自由な改変と派生著作物の作成の保証と同一ライセンスでの頒布の許可を規定

第四条以降 – 技術面を含むより広範な原則を明確化：

第四条 (ソースコードの完全性)：元のソースコードの完全性を維持する作者の権利と改変の自由とのバランスを取る
第五条から第十条：個人やグループ、あるいは用途等のおいて差別がなく、技術的に中立で何ら制限もない広範な原則を明確化

これを前述のFSFの四つの自由と比較すると、基本的にオープンソースの定義の第一条から第三条までは四つの自由の論理の組み立て方は異なるものの著作権的なコンテキストでは複製権、翻案権、二次的著作物作成権、頒布権に関して無制限の許諾を意味すると考えて問題ないだろう。すなわち、四つの自由における第一から第三までの自由と同一の内容を規定していると考えて良いと考えられる。なお、第四条に関しては第三条までの内容を補完するものであるが、これも第三までの自由に含まれると考えられる。

そして、オープンソースの定義の第五条から第十条までの内容に関しては、特に実行行為(使用行為)に絞っているわけではないのだが、第五条や第六条での個人や組織あるいは利用目的での差別の禁止に顕著な同一性があるように、ほぼ四つの自由における第零の自由に該当するものと考えて良いだろう。実際の所、自由なライセンスを判別するための審査基準として考えるとオープンソースの定義とFSFの四つの自由は特に差異はなく、結果としては同じような判定になる。

両者の差異

オープンソースの定義と四つの自由には厳密に検証すれば差異がある可能性はあるが、多くのオープンソース関係者は実務上は差異がないと考えている。細かな差異があるとすれば、下記のようなものだろう。

ライセンス判定基準としての違い：

オープンソースの黎明期においてライセンス判定上において自由ソフトウェアと最も大きな差異とみなされていたのはPerlのライセンスであったArtistic License 1.0だと考えられる。OSIはArtistic License 1.0をオープンソースとして設立当初から認めていたが、FSFは「あまりにも曖昧過ぎる。いくつかの文章はそれらに期待される目的には手が込みすぎ、意味は不明瞭」という理由で自由ソフトウェアのライセンスとして認めていない。これはFSFが厳格過ぎるというわけではなく、ごく初期のOSIには厳格なライセンス審査のプロセスが存在せず、オープンソースを全く新しい概念の運動として扱おうとする一部の者の恣意的な判断が介入する余地があったからだと佐渡は考えている。

ごく初期のOSIは少数のオープンソースの偉人らによる極めて小さな組織でしかなかったが、現在のOSIはより開かれた中立的組織に変貌しており、ライセンス承認のプロセスには開発コミュニティだけでなく世界中の法曹関係者もボランティアで関与するようになっている。ライセンスには法的な明確性、一貫性が求められるようになっており、Artistic License 1.0のようなライセンスが提出された場合、問題なく承認されるということはないだろうし、最低でも明確化のための条文修正が求められるのではないかと推測される。

現在のOSIのライセンス承認プロセスにおいてはFSFの自由ソフトウェアの判定と差異が出ることは基本的にはないと考えられるが、逆にOSIによるオープンソースの判定の方が厳密になっている領域もある。特許に関する条項やパブリックドメイン等である。

基本的にオープンソースのライセンスは著作権の許諾であるが、特許条項が存在するライセンスもある。著作権で許諾されている利用が特許権で妨げられるのであれば本末転倒なわけであるので特許権の許諾をついでに行うことは望ましいわけであるが、逆に特許権を許諾しないとライセンスに書かれていた場合にどうなるだろうか？これはCreative CommonsのCC0 1.0のOSIによる審査で問題となった事例であるのだが、CC0では特許権が「許諾されず、その他の影響を受けることもない」とわざわざ書かれているのである。OSIの承認プロセスにおける議論では、このような条項はソフトウェア特許に対するユーザーの防御を弱める可能性があるとの意見が出され、それに同調する意見が一定数存在したことから承認という結論は出せなかった。一方、FSFにおいては特許条項において懸念を示し、ソフトウェアに使用することを推奨してはいないものの自由ソフトウェアのライセンスとして承認している。

パブリックドメインについては、OSIは概ねそれに該当するソフトウェアを実務上はオープンソースの範疇として捉えているように考えられるものの、パブリックドメインとは著作権が存在しないことであるわけなので著作権ライセンスというのが存在することはなく、また法域による解釈の差異があることからパブリックドメイン化することは推奨していない。基本的にはオープンソースと明確に区別していると考えて良いだろう。一方、FSFはパブリックドメインには著作権がないのであるからライセンスは必要とせず、パーミッシブなライセンスと基本的に同じとみなせるという立場を取り、自由ソフトウェアの一部であるとの認識を示している。

哲学の違い：

オープンソースの定義と四つの自由に関して、ライセンス基準としての差異はないもののその解釈の違いによって前述のような差異が発生すると考えられるが、このような解釈差が生まれるのは両者の哲学の違いであるように考えられる。

オープンソースの定義はDebianという主にLinuxディストリビューションを開発するプロジェクトが起源にあるが、様々なライセンスが付与された多くのソフトウェアが漫然と同居するような状況において機能するということが念頭に置かれている。それによって、ソフトウェアの頒布と開発サイクルの法的および実用的側面に主な焦点を当てており、そのことからビジネスフレンドリーな概念としてみなされている。

一方、FSFの四つの自由は、ソフトウェアの自由という哲学的および倫理的側面に重点を置いており、基本的な倫理原則としてユーザーが享受する自由を強調していることから、よりイデオロギーに基づいた概念として見られるのだろう。これはオープンソースの定義の条文があくまで「ライセンスはこのように定義しなければならない」という権利者たる開発者に向けた条文という体裁であるのに対し、四つの自由は頒布を受けたソフトウェアに含まれるべき自由を唱えているという主語の違いからも認識できるだろう。

OSIによるオープンソースの定義とFSFによる四つの自由はどちらも基本的には同じカテゴリのソフトウェアをそれぞれにオープンソースもしくは自由ソフトウェアであると定義していると考えて良い。わずかな解釈の差異や依拠する哲学や倫理に差異はあり、それぞれを支持する勢力はその哲学から支持していることから呼称についても含めて正しく両者の違いは区別されるべきである。ただ、両者はソフトウェアの自由に対処するアプローチは異なるものの、どちらも結局は自由でオープンなソフトウェアを推進しているということは多くの人々が認識すべきことだろう。

定義から見るオープンソースに至るまでの歴史

「オープンソースの定義」はDebianフリーソフトウェア・ガイドライン(DFSG)を流用したことは周知の事実であるが、何故Debianプロジェクトは一般的にはFree Softwareという用語の祖とも管理者ともみなされるFree Software Foundation(FSF)とは別に自由なソフトウェアの定義を定めたのだろうか？この疑問を解き明かすため、用語の定義から見た自由なソフトウェアの歴史についてここで述べる。

(本稿は「オープンソースとは何か？ Open Source Definition逐条解説書」の付録の一つとして収録されている文書である。)

FSFの自由ソフトウェア

いわゆる自由ソフトウェア(Free Software)運動の開始は、1983年9月にRichard StallmanがUSENETニュースグループに「GNU(Gnu’s Not Unix)と呼ばれる完全なUNIX互換システム」の開発開始を宣言するメッセージを投稿したことが起源とされることが多い。ただし、この時のRichard StallmanによるメッセージにはFree Softwareという用語は出てくるものの、その意味の定義は特になく単に文脈に沿って自由な状態にあるソフトウェアを漠然と意味していたように考えられる。当時は米国においてソフトウェアに著作権が認められることが確定して間もない頃であり、機密保持契約やソフトウェア使用許諾契約に署名することへの怒りのほうが目立つ文章であった。この時にはFree Softwareが指す領域を明確に指し示すことについては特に考えが及んでいなかったのだろう。

その後の1985年にGNU Manifesto(GNU宣言)が発表された。これはGNUプロジェクトの目標を説明した文書であり、自由ソフトウェア運動の哲学的な基盤と考えられているが、自由ソフトウェアというよりもGNUが目指す世界の哲学が述べられた文章であり、自由ソフトウェアが何であるかについてはここでもはっきりとはされていなかった。

自由ソフトウェアが何であるか？という問いへの回答になりえるような文章として最古と認識されているものは、GNUプロジェクトの会報であるGNU’s Bulletin 1986年2月号の中での下記の記述である。

The Free Software Foundation is dedicated to eliminating restrictions on copying, redistribution, understanding and modification of software.
(Free Software Foundationは、ソフトウェアの複製、再頒布、研究、改変に関する制限を撤廃することに専心しています。)

The word “free” in our name does not refer to price; it refers to freedom. First, the freedom to copy a program and redistribute it to your neighbors, so that they can use it as well as you. Second, the freedom to change a program, so that you can control it instead of it controlling you; for this, the source code must be made available to you.
(私たちの名前にある “Free”という言葉は値段のことではなく、自由のことです。 第一に、プログラムを複製し、あなたの隣人に再頒布する自由。 第二に、プログラムを改変する自由です。そうすれば、プログラムがあなたを制御する代わりに、あなたがプログラムを制御することができます。)
https://www.gnu.org/bulletins/bull1.txt

GNU’s Bulletinの8ページ目からのFSFという団体を説明する文章の冒頭にてこの記述が出てくるのだが、この時点でソフトウェアに関係する著作権上の権利における自由を意識していることが分かる。そして、その自由である条件として第一として「複製と再頒布の自由」、第二として「改変する自由」を挙げていることも分かる。ただし、これがFree Softwareであるとははっきりと書かれておらず、そもそもFSFという団体の目的を説明する長い文章の中の一節に過ぎないことから、これをFree Softwareの定義として強く認識している者はさほどいなかったのではないかと考えられる。むしろ、GNU Manifestoによるソフトウェアがあるべき哲学や倫理観のほうが強く意識されていただろう。

当時のGNU’s Bulletinは半年に一度発行される会報だったのだが、最初の号からほどなく同じFSFという組織を説明する文章の中で第二の条件は「ソースコードへの完全なアクセスと改変する自由」となり、長らくGNU’s Bulletinに掲載され続けることになった。これが変化するのは1996年7月号である。ここで「third, the freedom to distribute a modified version and thus help build the community.」(第三に、改変されたバージョンを頒布する自由であり、それによってコミュニティの形成を助ける自由である)という一節が加わり、改変後の頒布について触れられるようになった。当時は現在につながるLinuxディストリビューションや様々なプロジェクトが大きく台頭し始めた頃であり、その成長を意識していたのではないかとは推測している。そして、この1996年頃にGNUプロジェクトの情報配信はwww.gnu.orgでのWeb提供へと徐々に移行を始め、この「三つの自由」がWhat is Free Software?というページで常時公開されるようになった。

これが自由ソフトウェアの定義とされるものがWeb上で公開されるまでの経緯であるが、長期の間において自由ソフトウェアとは何であるかという点を明確に示す文書が常時分かる状態ではなく、またGNUの哲学やコピーレフトの思想が目立つことでそれらに隠れた状態であったことは確かだろう。さらに、1990年代の中頃はRichard StallmanによるX ConsortiumやBSDといったパーミッシブなライセンスを支持する勢力への攻撃的な文書が目立つ場所に置かれていたこともあり、その傾向に拍車をかけていたとも考えられる。

Debianのフリーソフトウェア

ここで自由なソフトウェアの定義の歴史はDebianへ移る。Debianプロジェクトは1993年にIan Murdockによって開始された。彼はDebian Manifestoという文書を作成し、その中でDebianはLinuxとGNUの精神に則り、誰でも自由に利用可能なソフトウェアのみで構成し、オープンで民主的な組織でLinuxディストリビューションを作り上げることを企図することを宣言していた。ここで自由の原則に触れられたと考えられるが、ただし、その自由の定義がされていたわけではない。

このようなDebianの思想とGNUとしてのLinuxディストリビューションの必要性により、翌年の1994年からDebianはFSFの支援を受けることになり、0.9系時代までのDebian GNU/LinuxディストリビューションはFSFにおいても頒布が行われた。Ian MurdockもGNUプロジェクトのメンバーとなり、この時期のDebianはFSFの関係組織であったとみなすこともできるだろう。しかし、このFSFとDebianプロジェクトとの蜜月は、1996年3月にDebianのリーダーがIan MurdockからBruce Perensに代替わりすることで終了した。Bruce PerensはDebianの独立性を重視し、リーダーとなって早々にFSFからの支援を打ち切ったのである。

そして、DebianとFSFとの関係が途切れた翌年の1997年、Debian開発者のEan SchuesslerがあるイベントでRed Hat社の社員らと行った議論の中で事件が起きた。Ean Schuesslerが、Red Hatが会社を拡大していくことで考え方が変わる可能性を危惧し、コミュニティに対してフリーソフトウェアの理想にコミットし続けることを保証する文書を出すべきだろうという提案をRed Hat側の人々へ行った所、Red Hatの創業者であるBob Youngが「That would be the kiss of death.」(それは死のキスだ)と答えたのである。

Bob Youngにとってはそのような制約が将来の利益を生み出す能力を狭めるかもしれないとその場で漠然と考えたのだと思われるが、Debian開発者らにとっては単純な話ではなく、自分達のDebianの思想が変質化しないことをどのように保証するかを考えさせられることになった。この直後から一ヶ月の間にBruce Perensと当時のDebian開発者らの侃侃諤諤な議論が行われ、1997年7月、コミュニティに対して完全に自由なソフトウェアの提供を続ける約束であるDebian社会契約(Debian Social Contract)が策定された。そして、このDebian社会契約を定めるにあたり、この契約でのDebianプロジェクトとしてフリーソフトウェア(Free Software)とは何であるかを明確化するため、同時にDebianフリーソフトウェア・ガイドライン(DFSG)も策定されたのである。

このDFSGの公開後、Debianの組織内に留まらず、フリーソフトウェアの範囲を指し示す定義としてDFSGは広まり始めた。当時自由なソフトウェアを頒布する中心的なサイトとして利用されていたSunSiteでは、即座にSunSiteでの受け入れ基準としてDFSGを採用するということも起きた。このような普及があったのは、Debianプロジェクトが基本的にはLinuxディストリビューションのプロジェクトであり、Linuxディストリビューションが様々な自由なライセンスが付与されたソフトウェアの複雑な集合体であることにも起因するだろう。ライセンスに個々の哲学や思想が含まれていたとしても、コミュニティが自由と考えるソフトウェアを過不足なく、かつ矛盾なく自由なソフトウェアの集合物として扱える基準をDFSGは示したのである。

なお、Debian社会契約とDFSGの策定の議論の間、FSFによる「三つの自由」が参照されたことはないと考えられ、リーダーのBruce Perensもその存在を認識していなかった。また、Bruce PerensはDFSGの策定後にその内容をRichard Stallmanへメールで送付しているが、その返答は「this is a good definition of Free Software.」(適切な自由ソフトウェアの定義である)と返ってきただけとされている。もし、DebianとFSFの関係が希薄になっていなければDFSGが三つの自由に置き換わっていた可能性も考えられるが、これらの時系列を考えると当時はRichard Stallman自身も明確には自分たちが自由ソフトウェアの範囲を定義しているという自覚を持っていなかった可能性もあるだろう。

オープンソースの定義へ

DFSGが策定された1997年はEric Raymondが「伽藍とバザール」を発表した年でもある。Linuxが徐々に一般にも認知され始め、自由なソフトウェアを志向するコミュニティの中には様々な企業もその中へ取り込んでいくことを模索する人々も現れた。

ここからの流れは拙作の「オープンソースの誕生」https://shujisado.com/2017/05/17/612085/ に繋がるので詳しくは書かないが、先ず1998年2月3日にVA Linux Systems社において行われた会議でFree SoftwareをOpen Sourceという用語で代替していく方針が決められた。この会議にはVA Linux Systemsの面々、Foresight Institute、Linux InternationalからJohn “maddog” Hall、SUSE、そしてEric Raymondが加わっていたとされている。そして、当日中にその方針がBruce Perensへ連絡され、2月9日までにDFSGから固有名詞を入れ替える形でオープンソースの定義が策定された。その後、4月7日に自由なソフトウェアを代表する人々が集められたサミットが開催され、投票でOpen Sourceという用語を使用する方針が採択された。この時の出席者は、Tim O’Reilly、Eric Raymond、Linus Torvalds、Brian Behlendorf(Apache)、Larry Wall(Perl)、Guido Van Rossum(Python)、Eric Allman(Sendmail)、John Gilmore(Cygnus Solutions), Michael Tiemann(Cygnus Solutions)等である。

以降のオープンソースという用語の受容は敢えてここで書くようなことはないが、当時の自由なソフトウェアに対する期待と用語の考案、定義付け、主要関係者による承認というプロセスが全て別々の場所と人で進められたというある意味でのドラマ的な展開はその後の受容にとって良い影響を与えたのだろう。

四つの自由と自由ソフトウェアの定義化

オープンソースという用語が爆発的に世間に広まっていく中、FSFとRichard StallmanはこのFree Softwareと基本的には同じ領域を指すと考えられる新しい用語に対し、しばらくは距離感を測りかねていた。しかし、オープンソースという用語が広まる中で、自分達が自由ソフトウェアというソフトウェアの区分を明確に定義していなかったことも認識したのだろう。翌年の1999年までにはFSFはオープンソースという用語ではFSFの考える自由の哲学が伝わらないと判断し、オープンソースとは一線を引いた立場であることを明確にするようになった。

そのような中で、さりげなく「三つの自由」だけを示していたWhat is Free Software?のページは大幅に書き直され、自由ソフトウェアの定義と呼べる内容に改められた。そして、三つの自由の前に「The freedom to run the program, for any purpose (freedom 0).」(目的を問わずプログラムを実行する自由 (第零の自由))が加えられたのである。この時点で現在の「Four Freedoms」(四つの自由)であるフリーソフトウェアの定義がほぼ確定し、細かく修正が加えられているものの現在もそれが維持されている。

ここまでが、実質的に同じ自由な状態を指し示すカテゴリを意味する用語として、四つの自由による自由ソフトウェア、DFSGによるフリーソフトウェア、オープンソースの定義によるオープンソースという三つの定義と名称が存在することになった流れである。ソフトウェアのカテゴリの範囲を指し示す定義としての違いは実用的にはないのではあるが、背景となる思想には差異はある。今後、自由と不自由の境界について考えなければならない時がやってくるだろうと考えられるが、そのような時には歴史を振り返ることで正しい道が見えてくるだろう。

注意

本稿では、Free Softwareの訳語として自由ソフトウェアとフリーソフトウェアを意図的に使い分けている。FSFに依拠する文脈では自由ソフトウェアを使用し、Debianに依拠する文脈ではフリーソフトウェアを使用している。

参考

new UNIX implementation (net.unix-wizardsへのRMS投稿)：
https://groups.google.com/g/net.unix-wizards/c/8twfRPM79u0/m/1xlglzrWrU0J
GNU Manifesto：
https://www.gnu.org/gnu/manifesto.en.html
GNU’s Bulletin 1986年2月号：
https://www.gnu.org/bulletins/bull1.txt
History Roundtable Discussion @ Debconf4, June 2004：
https://gabriellacoleman.org/debian-history-roundtable-discussion/
Debian Social Contract / Debian Free Software Guidelines：
https://www.debian.org/social_contract.en.html
オープンソースの誕生：
https://shujisado.com/2017/05/17/612085/

何故、TerraformのBUSL-1.1へのライセンス変更は反発を受けたのか？

2023年8月10日、長らくオープンソース業界の優等生として一般的に扱われてきたHashiCorp社がTerraformを含む全ての製品と幾つかのライブラリの将来のリリースについて、Mozilla Public License v2.0 (MPL-2.0) からBusiness Source License v1.1 (BUSL-1.1) への移行を発表した。

このプロプライエタリ化に対してオープンソースコミュニティから強い反発の声が上がり、Terraformをフォークする動きが表面化した後、9月20日にはそのフォークがOpenTofuプロジェクトとしてLinux Foundation傘下にて運営されるほどの動きにつながった。本稿では、このメカニズムを明らかにするために、特にライセンス観点から解説していく。

(注：元々、この文書はOpenTofu発足直後に書かれたものであり、当時とは状況が若干異なる可能性がある。)

Business Source Licenseとは？

Business Source License v1.1 (BUSL-1.1)は、MariaDB ABが提唱したライセンスであり、この数年で幾らか採用が散見されるようになった。基本的には、下記のような条件のライセンスとなっている。

複製、改変、二次的著作物の作成、再頒布、および「非本番的な使用」(non-production use)が許諾される
- パラメータと呼ばれる条項を修正することで、「本番使用」(production use)であっても例外的な使用が許諾される範囲を拡張できる
- 上記要件の利用に適合しない場合、商用ライセンスの購入か、もしくは使用を停止しなければならない
対象著作物のリリースから4年後に予め指定されたライセンスへ変更される
- パラメータを修正することで、指定されたライセンスへの変更日を指定できる
対象著作物を複製、改変した二次的著作物には同一のライセンスが伝播する

非常に雑な説明をすると、個人的および社内等での利用であれば複製、改変、頒布を認めるが、リリースから4年経過するまでは商業的なサービスで使用する場合において別途ライセンスを購入しなければならないということである。ただし、この商業的な利用の判定は「本番使用」(production use)という用語で定義されており、この用語の定義が明確でないために正確な基準がどこにあるかはライセンサー側しか判断できない構造になっている。また、著作権の観点では支分権の領域ではない単純な使用用途に制限をかけており、ライセンスというよりも商用ソフトウェアパッケージの世界の使用許諾契約のような性質を帯びている。

パラメータの指定・修正では特に「本番使用」(production use)においても例外的な許諾の範囲を指定できる仕組みが目を引くが、これは例えば使用するインスタンス数が幾つ未満であれば許諾されるとか、特定の領域や利用法以外は許諾される等、任意で使用の態様を指定することが想定されている。

また、このBUSL-1.1は全ての二次的著作物に対しても同一のライセンスが適用されるために「本番使用」の制限は逃れることはできない。この条件によってどこまでもライセンサーによる商用ライセンス強要が伝播するために事実上フォークも制限されているとも言える。

詳細は、ページ末尾の付録にあるBusiness Source License 1.1 (BUSL-1.1)の和訳を参照。

ライセンスとしてのデメリット、メリット

このBUSL-1.1は、MariaDB側の主張ではオープンソースとプロプライエタリの中間的なライセンスであるとのことであるが、単純な使用に制限があり、使用者の差別を行うライセンスであるため、当然ながらオープンソースのライセンスではなくプロプライエタリなライセンスに分類される。また、「本番使用」(production use)という用語に代表される曖昧性は、ライセンサー側に極めて有利な判断を行う余地を残し、汎用的なライセンスとしての使用には適さないと考えられる。

個人および限られた領域での使用であれば余計な追加制限がない限りは比較的自由な利用が可能であるが、それなりの規模の企業内での利用ではソフトウェアのサブライチェーンに厄介な例外を持ち込むことになり、最初から商用製品として扱うほうが無難、つまりおとなしく商用ライセンスを購入するほうが無難であるという結論が導かれる状況が発生する。これはライセンシー側からは大きなデメリットであるが、ライセンサー側からは商用ライセンス販売へ誘導するメリットとも考えられる。

Terraformにおける適用

Terraform 1.7.0では、BUSL-1.1のパラメータとして下記のように指定されている。

追加使用許諾：許諾対象著作物の使用には、HashiCorpの製品と競合するホスト型または組み込み型の許諾著作物を第三者に提供することは含まれません。
変更日：許諾著作物が公表された日から4年間
変更後ライセンス：MPL 2.0

ライセンスの変更までに要する年数は4年とデフォルトのままであり、また、BSL-1.1の以前のライセンスはMPL 2.0であるので、今回のTerraformのBUSL-1.1ライセンスは4年後にこれまでと同様のMPL-2.0ライセンスに戻るという内容になっている。

追加使用許諾のフォームでは「HashiCorpの製品と競合するホスト型または組み込み型の許諾著作物を第三者に提供すること」が追加されており、これを素直に読めば、「本番的な使用」においてもHashiCorp社の商用製品と競合する製品への使用でなければライセンスに反しないことになる。ただし、ここでも「競合する」という曖昧な用語が使用されており、この部分においてもHashicorp社が恣意的に判断できる余地が残されている。

コミュニティの反発の理由

TerraformのBUSL-1.1化に関して、日本国内では反発する声はさほど多く聞かれない。端的に言えば今回のライセンス変更で影響を被るのはTerraformを直接的に使用して商用サービスを展開している業者に限られ、一般のコミュニティユーザーや顧客、開発者には大きな影響はない。このことを持って、日本ではこれまでのHashiCorp社のビジネスへ敬意と今後の立て直しへの期待を込め、むしろ積極的に理解を示す声すら一部から聞かれるのだろう。

一方、グローバルコミュニティにおいては、当然のことではあるが非常に強い拒否反応が見られる。BUSLを最初に発案したMariaDBをはじめとして幾つかの企業での採用事例をみれば、オープンソースのライセンスで提供されていたソフトウェアがコミュニティ側にとっては突然にプロプライエタリライセンスに変更され、利用者側の自由を失うという漠然とした提供企業側への失望感が大きいと考えられる。オープンソースであるという利点を生かしてユーザーと開発者のコミュニティの拡大を加速させてきたにも関わらずクローズドにされるというのは、一種の裏切り行為にも映るだろう。基本的にプロプライエタリなツールがオープンソース化することはよくあることだが、その反対の動きというものはさほど多いわけではなく、往々にして一方通行的であることもそのような感情に拍車をかけることになる。

排除される人々

これらの情感的な理由だけでなく、オープンソースのBUSL化においては直接的に排除される人々が発生するという問題が大きい。

排除を受ける人々として先ず浮かぶのは、BUSLの条文上で直接排除されている「本番的使用」をする者、すなわち商業的な利用をするユーザーである。今回のTerraformの件に関して言えばHashiCorpの製品と直接的に競合する利用に限定されているわけであるが、数が少ないので問題はないという論理にはならない。ライセンサー側が恣意的に判断可能という有利性もあるし、それによって将来はどこまで制限が拡大するか分からないという不確実性が生じることになる。

また、特に大規模な企業ではソフトウェアサプライチェーン上、このようなライセンスのソフトウェアには特段の注意が必要となり、結果的に当該ソフトウェアのエコシステムの縮小が生じる可能性が出てくる。このような事態はビジネスユーザーが望まないだけでなく、一般的なユーザーも望まない。

CLAの罠による貢献者の疎外

もう一点、BUSLの条文上では出てこないが、当該プロジェクトに貢献してきた外部の貢献者が無視されるという問題も発生する。

プロジェクトの開発ポリシーに依存し、大なり小なりと差はあるものの企業系のオープンソースプロジェクトであっても開発面からオープンに運営し、外部の第三者によるコードの貢献を受け入れているケースが多い。この外部からの貢献コードは貢献した第三者が著作権を保持しているが、将来的なトラブルを防ぐために多くのプロジェクトではCLA (Contributor License Agreement：貢献者ライセンス同意書)を貢献者にサインさせ、プロジェクト側で自由に貢献コードを扱えるようにするのが常套手段となっている。 CLAは著作権を譲渡するものでなく、あくまで永久的で取り消しできない著作権利用許諾を与えるものであるが、基本的に貢献者は当該プロジェクトの成果物がオープンソースのままで発展していくことを暗黙のうちに期待している。これはオープンソースのままであればいつまでも自由に利用できるわけであるのである意味当然のことである。

しかしながら、ある種のCLAにサインすることで、貢献者はプロジェクト側へプロプライエタリライセンスへの変更の権利も同時に与えることになる。ある種とは、プロジェクト側に再ライセンスを行う権利を認めるタイプのCLAのことである。この権利によって、Terraformで発生したようなMPL-2.0からBUSL-1.1への変更が一方的に宣言されても、貢献者側にはそれに対して異議を唱える権利もない。オープンソースとして貢献したはずの自分のコードが望まぬままにプロプライエタリコードになるのは気分の良いことではないだろう。これが貢献者による善意の貢献が無視されるということであり、「CLAの罠」とも「コピーレフト免罪符」とも呼ばれるものだ。

まとめると、貢献者による労力と意思が無視され、一部のビジネスユーザーは直接的に排除される。このような場合、オープンソースコミュニティは基本的に排除された者たちに寄り添うことになる。オープンソースは人の差別をしない概念であり、それによって様々な立場の人々による協働作業を実現してきた。よって、それを崩そうとする者には断固として拒否反応を示すのである。

プロジェクトフォークの行方

Terraformの場合、コミュニティの反発が高まり、特に直接排除された者の不満が要因となってOpenTFというフォークプロジェクトが発生することになった。そのOpenTFは、9月20日にはOpenTofuと改名し、Linux Foundation傘下のプロジェクトして開発、運営されることが決定し、現在は活発な活動が行われているようである。

一般的にオープンソースプロジェクトのフォークは成功することが少なく、場合によってはその行動が批判されることもあるが、Terraformの件に関しては直接排除された者が存在し、排除された者たちが取り得る対抗手段はプロジェクトのフォークしか残っていないという状況であったので、この行動を不当だと考えるコミュニティ側の人間はほぼいない。ライセンス変更を実施したHashiCorp社側も高い確率でフォークが起こり得ることだと認識していたことだろう。

通常、プロジェクトのフォークが一定の成功を収めるためには、

(1) メンバーの熱意とリーダーシップ
(2) プロジェクトの明確なビジョンと組織の透明性
(3) 開発および財務リソース

等といった要素が少なくともフォーク元のプロジェクトと同等のレベルで必要になる。しかしながら、BUSL化に伴うフォークのような場合には、最初から排除された者による熱量と継続的に関与し続ける動機というものが存在し、通常時よりもフォークが成功する可能性が高くなると考えられる。また、今回のOpenTofuの場合には、最初からオープンな開発体制を志向し、Linux Foundationの庇護の下に入ったということで、(2)や(3)のような要素においても成功条件をクリアする可能性が高い。特に問題となりやすい資金と人的リソースを数年に渡って確保しているのは大きいだろう。

このような成功条件を備えていてもフォークが成長するかは分からない。結局のところはフォーク元であるTerraformとの支持の取り合いにある程度の勝利をすることが必要になる。それでも、OpenTofuはオープンソースであり、貴重な存在となる可能性は今の所高いと考えられるだろう。

それでも何故 BUSL化を企業は望むのか？

手塩に掛けて育ててきたコミュニティには反発され、高い確率で元のオープンソースコードからフォークを発生させる。このようなデメリットがあるにも関わらずBUSL化を望む企業は何故現れるのだろうか？

詳細には分析しないが、結局の所 BUSL化のような手法を選択する企業に共通するのは、計画していた営業もしくは利益目標に到達しなかったのだろうという一点である。特にベンチャー投資を受けている企業、あるいは既に上場している企業が、株主からのプレッシャーを受けて目先の商用ライセンス販売を増加させる目的で実施しているケースが多いとは思う。

HashiCorp社はオープンソースの優等生と一部では看做されていたようだが、最近の損益の推移は惨憺たる数字となっている。BUSLを生み出したMariaDBは既に破綻に近い状況であるし、上場前のBUSL採用企業に関しても似たような傾向の数字だろう。オープンソースでユーザーベースの急速な拡大を得つつ、それを堅実に収益に結びつけるのではなく、投資から得た100の資金をそのまま営業マーケティング費に当てて50の売上を作り出して次の投資を引き出すという近年よく見られる拡大手法からの転換に失敗しているだけと言える。BUSL化によって、ひょっとすれば短期的には収益が改善するかもしれないが、中長期的にはコミュニティを排除したツケを支払うことになる。

BUSL-1.1のようなライセンスが嫌われるのは、ライセンスそのものというよりもそれを採用する企業が本業のビジネスに失敗しているにも関わらず、その失敗をユーザーから自由を奪うことで穴埋めしようとする姿勢に起因するところもあるだろう。

最後に

オープンソースは自由の精神に溢れるボランティアから企業戦略に則ったビジネスユーザーまで世界中の様々な立場の者が自由に参加できるエコシステムを作り上げてきた。このエコシステムの恩恵を受けるか否かは参加者の自由であり、当然ながらコミュニティから抜ける自由が全ての者にある。しかし、このエコシステムによって寄せられた他の善意の参加者による貢献をコミュニティの外へ許諾無しで持ち出すというのは好ましいことではない。

特に日本では他者の貢献を自分のモノとして捉える傾向、また差別を容認する傾向も見られ、オープンソースコミュニティへの親和性が低く感じることが多々あるが、これからの世代の方々には様々の立場の者が協働する価値というものをオープンソースの世界から感じ取って頂ければと思う。

参考

HashiCorp adopts Business Source License
https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license

Linux Foundation Launches OpenTofu: A New Open Source Alternative to Terraform
https://www.linuxfoundation.org/press/announcing-opentofu

Business Source License
https://www.hashicorp.com/bsl

許諾

付録：Business Source License 1.1 日本語訳

Terraform 1.7.0-devで付与されているBUSL-1.1ライセンスを佐渡が和訳したもの
https://gist.github.com/shujisado/e76ded2795f755e169a08e0241b8bb69

— ここから —

パラメータ

許諾者：HashiCorp, Inc.
許諾対象著作物：Terraform 1.7.0-dev. 許諾著作物は、(c) 2023 HashiCorp, Inc.
追加使用許諾：許諾対象著作物の使用には、HashiCorpの製品と競合するホスト型または組み込み型の許諾著作物を第三者に提供することは含まれません。
変更日：許諾著作物が公表された日から4年間
変更後ライセンス：MPL 2.0

許諾対象著作物の代替ライセンスに関する情報については、licensing@hashicorp.com までお問い合わせください。

告示

Business Source License 1.1

許諾条件

許諾者は、あなたに対し、許諾対象著作物を複製、改変、二次的著作物の作成、再頒布、および非本番的に使用する権利を許諾します。許諾者は、上記の追加使用許諾を行い、限定的な本番使用を許可することができます。

変更日、または本許諾に基づき許諾対象著作物の特定のバージョンが最初に公に頒布されてから4年目のいずれか早い日に、許諾者は本許諾により、変更後ライセンスの条項に基づく権利をあなたへ付与し、上記で付与された権利は終了します。

あなたが許諾対象著作物を使用する際に、本使用許諾に記載されている現在有効な要件に適合しない場合、あなたは、許諾者、その関連団体、または正規の再販業者から商用ライセンスを購入するか、または許諾対象著作物の使用を差し控えなければなりません。

オリジナルおよび改変された許諾対象著作物、および許諾対象著作物の二次的著作物の全ての複製物は、本使用許諾に従うものとします。本使用許諾は、許諾対象著作物の各版に個別に適用され、変更日は、許諾者がリリースした許諾対象著作物の各版毎に異なる場合があります。

あなたは、本許諾を、許諾対象著作物の各オリジナルの複製または改変版の複製に目立つように表示しなければなりません。あなたが第三者から許諾対象著作物のオリジナルまたは改変版を受領した場合、当該著作物の使用には本使用許諾に定める条件が適用されます。

本許諾に違反して許諾対象著作物を使用した場合、許諾対象著作物の現行版およびその他の全ての版について、本許諾に基づくあなたの権利は自動的に消滅します。

本使用許諾は、許諾者またはその関連会社の商標またはロゴに関するいかなる権利もあなたへ付与するものではありません（ただし、あなたは、本使用許諾で明示的に要求される場合には許諾者の商標またはロゴを使用することができます）。

適用される法律で許可される範囲において、許諾対象著作物は「現状有姿」で提供されます。許諾者はここに、明示または黙示を問わず、商品適格性、特定目的への適合性、非侵害、および権原の保証を含む（ただし必ずしもこれらに限定されない）すべての保証および条件を否認します。

DALL-E生成物、パブリックドメイン — DALL-EによるTerraformライセンス変更のイメージ

SSPLのライセンス条文とその適格性に関するメモ

SSPL(Server Side Public License)は2018年10月にMongoDB社が発表したライセンスである。MongoDBはそれまでAGPLv3(GNU Affero General Public License)を採用してきたが、クラウドベンダーがただ乗りしていることを理由として掲げてSSPLの正当性を主張し、現在もその利用を推進している。一方、オープンソースのコミュニティにおいては、SSPLがオープンソースの定義に反するというだけでなく、ライセンスとして使用することへの忌避感も生じている。

本稿では、そのSSPLの条文とオープンソースおよびライセンスとしての適格性について論考する。

SSPL条文分析

SSPLはAGPLv3と同様に主にGPLv3(GNU General Public License)の13条を改変する形で作られている。13条以外のGPLv3との相違点は前文等が削除されている点やMongoDBといった固有名詞の入れ替えがある他、2条に「subject to section 13」(13条に従って)という文言が二箇所挿入されている。これを踏まえて、SSPLの主眼と言える13条を日本語訳付きでここに示す。

13. Offering the Program as a Service.
13. プログラムをサービスとして提供

If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.
あなたが「プログラム」や改変されたバージョンの機能をサービスとして第三者に提供する場合、あなたは「サービス・ソースコード」を本許諾書の条件の下で、誰に対しても無償でネットワーク経由によりダウンロード可能としなければならない。「プログラム」や改変されたバージョンの機能をサービスとして第三者が利用可能にすることには、第三者がコンピュータ・ネットワークを通じて「プログラム」や改変されたバージョンの機能と相互に対話できるようにすること、「プログラム」や改変されたバージョンの価値から完全にあるいは主として派生するサービスを提供すること、あるいはユーザが「プログラム」や改変されたバージョンの主な目的を達成するようなサービスを提供することが含まれるが、これらに限定されない。

“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
「サービス・ソースコード」とは、「プログラム」や改変されたバージョンの「対応するソース」、及び「プログラム」や改変されたバージョンをサービスとして利用可能にするためにあなたが使用する全てのプログラム(管理ソフトウェア、ユーザ・インターフェース、アプリケーション・プログラム・インターフェース、自動化ソフトウェア、監視ソフトウェア、バックアップ・ソフトウェア、ストレージ・ソフトウェア、ホスティング・ソフトウェアを含むがこれらに限定されない)の「対応するソース」を意味する。

この条項は三つのセンテンスで構成されているが、最初のセンテンスにてプログラムの利用条件を述べており、後ろの二つのセンテンスはその利用条件で出現した用語の定義を補強するための例示列挙であってそれ以上の意味はない。最初のセンテンスを分解し、後ろの例示列挙を入れ込むと下記のように表現することができる。

何を？
- SSPLでライセンスされた対象ソフトウェアそのものおよびその改変ソフトウェアの機能
誰にどうする場合？
- 第三者へサービスとして機能を提供する場合
  - 第三者とは、SSPLでライセンスを受けた者以外の全ての者を指す (GPLでは同一組織内の者も第三者に含まれる)
  - 提供とは頒布を伴わないソフトウェアの実行の享受も含まれる
  - サービスとして機能を提供する例には下記が含まれるがそれらに限定はされない (無償か有償かは問われない)
    - ネットワークを通じて対象ソフトウェアの機能と相互に対話 (AGPLv3における対話的なやりとりに近いと考えられる)
- 対象ソフトウェアの価値から派生するサービスを提供
- 対象ソフトウェアの主な目的を達成するようなサービスを提供
条件 (しなければならない)
- 「サービス・ソースコード」をSSPLでライセンスした上で、誰に対しても無償でネットワーク上で公開しなければならない
  - 「サービス・ソースコード」には対象ソフトウェアをサービスとして利用可能にするために使用される全てのプログラムが含まれるがそれらに限定はされない

何を？

まず「何を」の部分であるが、特筆すべきはライセンスを受けた側が対象ソフトウェアを改変した結果物に対してだけでなく、対象ソフトウェアそのものについても含んでいる点である。つまり、ここで定義されるサービスとしての実行であれば、改変しようが改変なしで実行しようが関係なくこの13条の適用となる。AGPLv3の13条では改変されたバージョンに限定されており、これは両者の大きな違いと言える。これについては後でも詳細に触れる。

誰にどうする場合？

「誰にどうする場合」であるか？については、「第三者」であるライセンスを受けた者以外の全ての者に対してサービスとして対象ソフトウェアの機能を提供した場合である。GPL系ライセンスにおける「第三者」は組織の内部であるかを問わないので、ライセンシー側が法人組織とした場合においてその法人所属の者も第三者に該当する可能性はある。

また、ここでの「サービスとして機能を提供」のフレーズは、AGPLv3でも想定されているSaaS(Software-as-a-Service)のようなネットワーク越しでの頒布(伝達)を伴わないソフトウェアの利用が想定される。有償であるか、無償であるかは特に条文では触れられず、関係がないものと考えられる。AGPLv3ではネットワークを通じての対話的なやりとりを行うソフトウェアとされているが、SSPLの場合はソフトウェアの価値から派生もしくは目的を達成するサービスを提供という例示もなされ、どこまでがサービスとして含まれるのかは判然としていない。

例えば、AGPLv3の場合はWebサーバー等の基本的なサーバー機能、Webベースのアプリケーションのような利用法が13条のネットワーク経由での対話的利用の対象となり、SSH等のようにある環境でたまたまネットワーク越しでの対話的利用となるようなケースはAGPLv3 13条の対象ではない。しかし、SSPLの場合はソフトウェアの価値や目的を達成するのであれば該当するわけであり、ネットワーク越しで対象ソフトウェアによる価値や恩恵を得られるのであれば全て該当するのではないかとも考えられる。MongoDB社が自社Webで公開するFAQでは、SaaSアプリケーションのデータベースとして使用する場合は対象外とされているが、その理解で良いという法的な根拠とするには心許ない。

条件 (何をしなければならないか)

最後の「条件」であるが、「サービス・ソースコード」をSSPLでライセンスした上で無償でネットワーク上で公開しなければならないとのことである。これは一見AGPLv3と同様の条項に見えるのだが、違いが二つある。まず、AGPLv3ではコードを公開する対象がネットワーク経由でその該当サービスを利用するユーザーに限定されているのに対し、SSPLではその制限はなく、誰に対してもネットワーク上での公衆送信が可能な状態に置かなければならない。これは利用範囲がごく限定されたサービスの場合には大きな影響の差となり得る。

もう一つの違いは、公開するソフトウェアが改変された対象ソフトウェアではなく、「サービス・ソースコード」という概念に置き換わっていることである。サービス・ソースコードには対象ソフトウェアとその改変物や結合物だけでなく、そのサービス運用上で使用されるソフトウェア全てが含まれる。たまたま使用されるような管理・監視ツールやバックアップツール等も含まれると例示から判断できるが、どこまで影響が及ぶかはこれも判然としない。対象ソフトウェアが動作するサーバーやクラウド上で動作するアプリケーションや基盤ソフトウェア全てに伝搬するようにも考えられるし、異なるネットワーク上で動作するサービス運用のためのソフトウェアにも影響するのだろう。当然ながらAGPLv3では対象ソフトウェアを改変したバージョンそのものだけに影響が留まり、その他をサービスを構成するソフトウェアには影響が伝搬しないわけであり、この差異は非常に大きい。

AGPLv3とSSPLとの違いのまとめ

	AGPLv3	SSPL
何を?	ライセンス対象物を改変したソフトウェア	ライセンス対象物そのものおよび改変等による派生ソフトウェア
誰にどうする場合？	ネットワークを通じての対話的なやりとりをするサービスの提供	ネットワークを通じての対話的なやりとりをするサービスや価値から派生もしくは目的を達成するサービスの提供
条件	サービスのユーザーに対して、改変ソフトウェアを公開	全ての者に対して、対象ソフトウェアならびにサービス運営のために使用される全てのソフトウェアを公開

AGPLv3とSSPLの違いを表にすると上記のようになる。MongoDB社側はAGPLv3 13条の発動要因と範囲について市場で混乱があると主張しているが、発動要因についても影響範囲についてもSSPLのほうが広範囲かつ曖昧である。AGPLv3については多くの法曹関係者からのレビューと多くの採用実績が存在し、不明瞭な部分は特殊なケースしかないと考えられるが、SSPLの場合は意図的に曖昧性を残してあるようにも見え、発動要因ならびに影響範囲共にライセンサーであるMongoDB社の裁量次第になっていると考えられる。

ライセンス条項を一般的に考えられる意味合いで解釈したとして、SSPLでライセンスされた対象物をネットワークサービスの一部で使用してユーザーへその価値を享受させた場合において、サービス運用のために使用している他のソフトウェア全てをSSPL化の上で第三者へ公開を迫られるということになり、あまりにも伝搬の影響力が強いように見える。

オープンソースへの適格性

SSPLが発表された当時、MongoDB社はOpen Source Initiative(OSI)にオープンソース・ライセンスとしての適格性について審査の要求を提出したが、長い論争を経た後にSSPLはオープンソースではないとOSIによって判断された。長い論争があったのはオープンソースとして認めるために些細な差があって論争になったという類の話ではなく、MongoDB社側の対応が誠実さを欠くものであったからであり、オープンソースの定義 (Open Source Definition：OSD)に適合しないことは最初から明らかであった。

具体的には、SSPLはオープンソースの定義に対して主に二つの条項に反している。

一つ目は、「OSD 9条：他のソフトウェアを制限するライセンスの禁止」である。この条項はライセンス対象のソフトウェア以外のソフトウェアに対して何らかの制限をかけることを禁止する条項である。時々、GPL系のライセンスは他のソフトウェアにもGPLが伝搬するので9条に反するという疑問が出されることがあるが、GPLはあくまでGPLの対象となるソフトウェアに発生した著作権が及ぶ範囲において正当な権利を行使しているに過ぎない。GPLは著作権法で規定される二次的著作物の範囲を逸脱することはなく、その権利が及ばないソフトウェアに伝搬することはない。その一方でSSPLは対象ソフトウェア自身に発生した著作権が及ぶ範囲を越え、全く無関係のソフトウェアに対してまでライセンスの効果を及ぼして著作権の利用行為を伴う制限をかけていることになる。これこそはまさにOSD 9条で禁止されている行為そのものである。

二つ目は、「OSD 6条：利用する分野(fields of endeavor)に対する差別の禁止」である。この条項はライセンスにおいてある特定の分野での対象ソフトウェアの使用を制限することを禁止するものであり、一見、条文だけを見るとSSPLの13条はそのような制限をかけていないように見える。しかしながら、SSPL 13条が適用された場合、例えばSaaSのようなサービスの場合は関連するソフトウェアを全てSSPLでライセンスした上で公開しなければならない。これは一般的なソフトウェアはSSPLとの互換性がないことから非現実的な要求であり、実質的にクラウドサービス事業者がSSPLライセンスのソフトウェアを使用することを制限していると見做すことができる。SaaSのようなビジネスモデルの否定とも取れるだろう。クラウドサービス上の基盤においては商用ライセンスもしくはオープンソースの様々なソフトウェアが動作しているが、それら全てのソフトウェアをSSPL化することは法的にも倫理的にも不可能だろう。

よって、SSPLはオープンソースではなく、プロプライエタリの範疇にあるライセンスの一種と考えられる。オープンソースではなく自由ソフトウェアの定義に照らし合わせても、どんな目的に対してもプログラムを望むままに実行する「第零の自由」(freedom zero)に反しているだろう。近年ではSSPLのようなライセンスをSource-availableと表現する者が一部にいるが、状態としてはそれが正しいと考えられる。

ライセンスとしての適格性

SSPLがオープンソースではないことは明らかであるが、だからといってSSPLでライセンスされたソフトウェアを使用できないというわけではない。ただし、その場合において利用されるソフトウェアの利用許諾の意味でのライセンスとしてのSSPLには不明瞭な点が複数存在する。これを説明するためにはまずライセンスとは何か？ということを明らかにしなければならない。

GPLをはじめとするオープンソースのライセンスは一般的に単なる著作権の許諾と看做されている。世界各国の著作権法によって自然かつグローバルに権利者へ認められる複製、翻案、頒布、公衆送信等の権利を行使するという立て付けによって、ソフトウェア著作物に対して利用の許諾を行なっているのである。従って、オープンソースライセンスは基本的に著作権の範疇を越える行為を要求することはない。著作権を基にすることで、利用者が権利者に向けて明示的にライセンスを承諾することもなく、世界のどこにいても同じようにソフトウェアを利用する権利を得られるのである。

一方で、著作権で認められない権利をライセンサー側が主張するためにはどうするべきか？これは一般的には各国での契約法の範疇の問題となる。つまり、許諾の意味でのライセンスではなく、ライセンス契約になるということだ。多くの国には契約の自由があり、二者間での契約とすることで自然に発生する著作権以上の権利をライセンサー側がライセンシーに向けて要求することが可能になる。この契約という手法の場合は確かに著作権で認められる権利を越えた要求を権利者が出すことを可能とするが、許諾行為とは異なりライセンシー側が権利者へ向けて明示的にライセンス契約を承諾する行為が必要となる。また、契約を管轄する法は世界各国で内容に差異があり、契約の効果や有効性等を含めて不確実性が生じることになる。商用ソフトウェアの世界におけるライセンスは著作権の範疇を越える様々な制約が課せられているが、提供側とユーザー側との二者間におけるライセンス契約であるのでそれらの制約が有効なのである。

これを踏まえてSSPLの13条を見渡すと、許諾としてのライセンスには不適格な内容が三点含まれていると考える。

– 対象ソフトウェアの実行行為への制約

SSPL 13条は改変(翻案)されたソフトウェアだけでなく対象ソフトウェアそのものも含まれた条項である。そして、それを「サービスとして提供」するという行為は、すなわちそのソフトウェアを実行(使用)するということでもある。つまり、SSPLはソフトウェアをある状況下で実行することを制限していることになるが、ソフトウェアの著作権で権利者に独占的権利があるのは複製、頒布、翻案、公衆送信等の利用行為であり実行(使用)は含まれない。第三者への実行結果の享受が公衆送信と判断できる余地は残るが、やはりSSPLは著作権でカバーされる以上の範囲に制限をかけていると考えられる。

なお、実行行為への制限は2条に「subject to section 13」(13条に従って)というGPLv3にはない文言が二箇所挿入されており、ここでGPLv3では無条件に実行が許諾されるという内容が13条に従うと変更されている。このことでも実行行為に制限を意図的にかけていることが分かる。

– 対象ソフトウェアから生じる著作権とは無関係の第三者ソフトウェアへの制約

GPL系ライセンスで生じるGPLの伝搬は、対象ソフトウェアの二次的著作物もしくは集合(結合)著作物を創作された場合に原著作者の著作権が及ぶことから正当な権利を主張しているだけに過ぎない。しかし、SSPLにおけるサービス・ソースコードは、対象ソフトウェアに発生する著作権が全く及ばない第三者が権利を保持するソフトウェア著作物であることがほとんどだろうと考えられる。つまり、SSPLは完全に第三者の著作物の利用許諾を出すことを条件としており、その第三者著作物にはSSPLでライセンスされた著作物の権利者の権利が生じていないのだから、著作権の領域を逸脱した制限であることは明らかである。

– 条文の曖昧性、不確実性

SSPL 13条における「サービス」および「サービス・ソースコード」という用語は、条文中で例示列挙はあるものの定義が十分ではなく、ライセンサー側の解釈次第で非常に広い範囲をカバーすると考えられる。少なくとも、策定時もしくは事後に多くの法曹家のレビューを受けたAGPLv3における「リモートからの対話的利用」よりも曖昧で不確実であることは確かだろう。

このように著作権による独占権を大幅に越える制約をライセンシー側へ課し、また条文の及ぶ範囲によりライセンサー側に有利に解釈可能な曖昧性を含むライセンス条文を許諾として扱うことは難しいのではないかと考える。また、ライセンスを二社間の契約と捉えることも、将来的に予期せぬ事態が発生する不確実性も孕むとも考えられる。

主張通りのライセンスであるのか？

一般的にソフトウェアのライセンスはオープンソースである必要はないし、またライセンスが許諾ではなくライセンス契約であってもそのソフトウェアが使えないわけではない。一般的な商用ソフトウェアというものがそれに該当するわけであるので、SSPLもそのようなソフトウェアのライセンス契約だと思えば良い。

しかし、オープンソースではないということは、様々なオープンソースとの互換性の問題が生じ、エコシステムからの恩恵を受けにくくするということでもある。実際、多くのオープンソースのライセンスと矛盾するだろうから、使用に大きな制限があると看做さなければならないだろう。

また、ソフトウェアのコンプライアンス管理上の問題から、同じソフトウェアがSSPLと商用ライセンスのどちらかを選択できるのであれば、多くの組織では商用ライセンスを選択することになるだろう。その方が明確にソフトウェアを管理・運用できるからである。明示的に書かれているわけではないが、SSPLはクラウドサービス、もしくはクラウドサービスを提供する可能性がある組織の利用を排除して商用ライセンス契約を目指す施策と考える方がしっくりくる。

MongoDB社はSSPLに対するFAQのページにてコミュニティに対する自由を主張しているが、ここまでの記述のように実行の自由もなく自由とは程遠いと考えられる。それでも狙い通りにクラウド志向の企業に商用ライセンスを購入させ、同時にオープンソースエコシステムからある程度の恩恵も得られれば良いが、用途制限のあるソフトウェアに喜んで貢献するような企業は多くはないだろう。

また、かつてオープンソースであったソフトウェアのSSPL化は、対象ソフトウェアの市場での立ち位置、財務や開発リソース等の状況次第でフォークを促すと考えられ、中長期的に市場での影響を失うリスクを抱えることにもなるだろう。

使用に関しての注意点

SSPLでライセンスされたソフトウェアを何らかのサービスや製品、あるいは社内にて使用すべきか否かという問いに対して、結論から先に言えばなるべく使用を避けることが望ましいということになる。

「サービス」として第三者へ提供しなければGPLと一緒であるという言説はある意味では正しいのであるが、その「サービス」の範囲はあまりにも広く曖昧である。例示の一つであるソフトウェアの機能と相互に対話するのであればAGPLv3と変わらないが、価値から派生するサービスや主な目的を達成するサービスとは一体何なのだろうか？機能の実行による何らかの価値がリモートから享受できれば条文的にはクリアしているようにも考えられ、それは少なくとも単に対象ソフトウェアそのものだけを提供するSaaSより範囲は広いのだろう。MongoDB社のFAQでは「MongoDBをデータベースとして使用する他のSaaSアプリケーション」には適用されないように書かれているのだが、これは本当にソフトウェアの価値から派生した利用ではないのだろうか？SSPLがライセンス契約である以上、ライセンサー側との契約関係になるわけであり、ここで曖昧性を残したままにするのは非常に大きなリスクを背負いこむことになる可能性がある。

そして、「サービス」での使用の条件の範囲となる「サービス・ソースコード」の範囲は正直どこまでを指すのかは全く不明瞭である。また、多くのオープンソースのライセンスとは矛盾するだろうし、商用ライセンスのソフトウェアとも同じ場での共存はできないだろう。他のネットワークから例えば管理ツールでアクセスするようなことも対象となるのであれば全く収拾がつかない。

これでは少なくとも将来を含めて第三者へ使用させる可能性があるシステムでSSPLのソフトウェアを利用することには不確実性があるとしか言いようがない。

なお、GPL系ライセンスでは、ライセンシーが特定の組織だった場合にその組織内の人間であっても第三者に該当する。つまり、GPLを雛形にする限りは社内に閉じた利用であっても第三者へ提供したということにもなる。MongoDB社のFAQでは、子会社を含む社内利用に関してはSSPL 13条の適用外と書かれているのだが、肝心の条文ではそのように解釈できるかは分からない。GPLv3における「普及」(propagate)や「伝達」(convey)に組織内の人間が含まれないという認識が確立しているが、6条での「オブジェクトコードを所有する者すべてに対して」から推察される考え方を13条にも適用すると、組織内であるかに関わらずサービス・ソースコードを提供するという解釈もあり得るだろう。

これらのことから、この曖昧かつ不確実性を含むライセンスが付与されているソフトウェアを安易に使用することは難しい。MongoDB社のFAQが完全に正しいとしても、対象ソフトウェアの利用が将来ずっと第三者へのサービス提供とならないように管理を継続できる体制と仕組みが必要になると考えられる。それが難しいのであれば、SSPLではなく商用ライセンスを購入する方がずっと簡潔で容易なソリューションとなるだろう。無償であることに意味があると考えるのであれば、MongoDBであればFerretDB、ElasticsearchであればOpenSearchのように代替ツールを利用するしかないだろう。

まとめ

自由かつオープンに見せかけながらもそうではないというライセンスは過去にも多かったが、MongoDB社によるSSPLは、オープンソースという用語への世間からの高い評価を利用することを標榜しつつ、オープンソースならびに自由ソフトウェアが依拠する著作権システムのカバーする領域を大幅な越えて制限をかけようとするものであることは間違いないだろう。プロプライエタリなライセンスという見方をしても、SSPL単独でライセンスされたソフトウェアを問題なく導入可能な組織がどれだけあるのか疑わしい。商用ライセンスとディアル方式にして、その撒き餌となるしかないように思われる。組織内におけるソフトウェアのコンプライアンス管理やオープンソースのエコシステムへ余計な混乱を生じさせるものでしかないだろう。

SSPLを採用するソフトウェアを絶対に使ってはならないということはないし、13条適用を完全に排除できるのであればGPLv3と同様に望ましいライセンスと言える。しかし、13条適用の可能性がないものへSSPLを付与することはないだろうから、結局曖昧性と不確実性を抱える場面での適用となることがほとんどだろう。このことから、オープンソースのコミュニティとエコシステムの健全な発展を願うのであれば、使用には細心の配慮を継続することが必要であり、できる限りの排除を目指すことが望ましい。

参考

Server Side Public License (SSPL)：https://www.mongodb.com/licensing/server-side-public-license
Server Side Public License FAQ：https://www.mongodb.com/licensing/server-side-public-license/faq
GNU Affero 一般公衆利用許諾書日本語訳：https://licenses.opensource.jp/AGPL-3.0/AGPL-3.0.html
The SSPL is Not an Open Source License：https://blog.opensource.org/the-sspl-is-not-an-open-source-license/

Server Side Public LicenseのイメージをDALL-Eに答えさせた図

日米OSDN離合集散、苦闘の21年史

さて、ついに退職エントリだ。私は米国のオープンソース・ムーブメントを日本で再現するためのコアを作るために民間企業へやってきたはずだった。それから21年、随分と長い航海になってしまったが、結局様々な尻拭いを続けてきたという感慨ばかりが起きてくる。一つの歴史として書き残すいいタイミングなのでその苦闘を振り返っておこう。

続きを読む “日米OSDN離合集散、苦闘の21年史”

いわゆるガラパゴス化という言葉の起源

ガラパゴスとは、言わずと知れた東太平洋上の赤道下にあるエクアドル領の島々のことだが、日本においてはもう一つ意味がある。IT界隈を中心にいわゆるガラパゴス化と呼ばれる日本で独自進化を起こすサービスやプロダクトが発生する現象や状態を指す言葉のことであり、先進的な進化という良い面もあれば独自進化が行き過ぎて取り残されるという悪い面もあるというこの用例におけるガラパゴスの起源はおそらく私にある。過去に若干は起源についてTwitterでつぶやいたことはあるが、故あってあまりおおっぴらには語ってこなかったのでその歴史が曖昧なままになっているようだ。

このまま放置しておくほうが良い気もするのだが、歴史に空白を残しておくのは少々気が引ける。時期的にもいろいろと迷惑をかけなくなっているだろうし、ここで供養を兼ねてその歴史を残しておこうと思う。

ガラパゴスの黎明期

スマートフォンといわゆるガラケーが並立していた頃から比べるとガラパゴスという言葉の利用は少しは減っているとは思うが、それでもSNSを検索すれば毎日様々な属性の人々がごく普通にガラパゴスという言葉を使っていることが分かる。もう完全に一般的な日本語として定着しているのだろう。そのガラパゴスの意味はWikipediaによると下記のようになるらしい。

「ガラパゴス化（ガラパゴスか）とは、日本のビジネス用語のひとつで、孤立した環境（日本市場）で製品やサービスの最適化が著しく進行すると、外部（外国）の製品との互換性を失い孤立して取り残されるだけでなく、適応性（汎用性）と生存能力（低価格）の高い製品や技術が外部から導入されると、最終的に淘汰される危険に陥るという、進化論におけるガラパゴス諸島の生態系になぞらえた警句である。」(Wikipedia, ガラパゴス化)

実に高尚な意味があるようだ…。少なくとも私はここまでの高尚な定義をしたことはないが、言葉が一般化する時にはこのような後付けが起きるものなのだろう。

私が自身でガラパゴス諸島の意味ではないガラパゴスを使い始めたのはおそらく2004年の頭のあたりだと思われる。はっきりとは分からないが、ちょうどこの頃のIRCログから下記のような使い方をしていることが分かる。なお、Kazekiriとは私のことで、相手はオープンソースの定義やGPLの日本語訳で有名な八田真行さんである。


---
<mhatta> 英語て
<mhatta> やはり高い参入障壁なのかな
<mhatta> > オソ
<mhatta> 理系はふつう英語は読めるように
<mhatta> なってるはずなんだが
>Kazekiri< 英語 == 南米とガラパゴスの間の海
>Kazekiri< じゃないのか
---

このやり取りから分かるのは、大陸から隔絶された地であるガラパゴス諸島から単に相互の参入のための分厚い壁のことを形容しているということである。隔絶されていることによる独自進化という部分はあまり意識していなかったのではないかと思う。会話相手である八田さんは、坂本龍一さんの「東京は世界の名古屋」というフレーズを割と好んで使っていた記憶があるが、独自進化的な意味だと当時は私もむしろそっちのほうが頭にあったかもしれない。ともかく、分厚い障壁やその状態に置かれている様を表現する言葉として使っていたようだ。

なお、当時はまだガラパゴスという言葉を使っていたのは私の周辺では私一人だけだったようだ。主にDebianやVineなどのLinuxとオープンソース関係者が集まるIRCチャネルぐらいでしか使ってないし、それらのIRCチャネルには携帯電話業界の企業の役職持ちの人間もいたが、佐渡が奇天烈な形容詞を使っているぐらいにしか思ってなかったと思われる。

ガラパゴスの巣立

私一人だけが特定のIRCチャネルでしか使っていなかったガラパゴスであるが、内輪の隠語のようなものにしておけばいいものを当時は若かったのだろうか。2004年6月9日、赤坂プリンスホテルで開催したVA Linux Business Forum 2004にて、私はガラパゴスという言葉を公の場で初めて使用した。

当日イベントの最後の講演… というより最後の締めの挨拶ではあるが25分と長めに取られた枠にてガラパゴスは発声された。実は当日使用したスライド資料は残っていないのだが、MagicPoint形式のファイルの一部をコピペしたと思われるデータがIRCのログとして残っていたのでそれを下記に示しておく。

---
>Kazekiri< OSSガラパゴス諸島 - ニッポン
>Kazekiri<         英語という大海で断絶された地、ニッポン
>Kazekiri<         貧弱な開発力
>Kazekiri<                 パッチ投げっぱなし症候群
>Kazekiri<         使う人はたくさんいるが、作る人がいない
>Kazekiri<                 世界第二位のオープンソース利用大国
>Kazekiri<                 ユーザ会は多いが、開発グループとの関係は希薄
>Kazekiri<                 フェイクの氾濫
>Kazekiri<                 オープンソースでコストを下げたいだけ?
---

「OSSガラパゴス諸島 – ニッポン」がスライドのタイトルであり、これが私が公にガラパゴスと連呼した初出である。スライドには当時も今もちょっと辛辣過ぎる言葉が並んでおり言葉の選び方の悪さには愕然とするばかりなのだが、この前後のスライドはIRCログにも残っていないので完全には何を話していたのかは分からない。ただ、そもそもイベント全体のプログラムを私が作っているので、全体の流れから記憶を手繰り寄せるとおそらくこのようなことを話したと思われる。

「ドットコムバブルの崩壊でVA Linuxもオープンソース業界も酷い目に遭いましたけども、昨年の2003年にはRed Hatも黒字化し、オープンソース企業への投資も回復したことでビジネス環境は整ってきています。我が国を目を移しても、本日の講演からもわかるようにオープンソースの利用は拡大しており、エンタープライズ市場を含めて期待が高まっていると思います。この流れに合わせて経済産業省もオープンソース振興を打ち出してくれているのは我々にとって素晴らしい流れであります。

その一方、英語という大きな障壁があるからか、日本特有の問題も出てきているとも思います。SourceForge等の統計からは日本はオープンソースのダウンロード数では多くがアメリカに次ぐ二位の国であり、オープンソース利用大国であるようです。それを示すように日本には多くのオープンソースのユーザー会が存在し、そのコミュニティが普及を促進しています。ただ、無料のオープンソースの利用についてばかり目がいき、使う人はたくさんいるがそれと比較して作る人が少なく、上位の開発者グループとの関係は希薄に見えます。開発者の数が少ない上にコミュニケーション下手なのかパッチの投げ方の作法も分からずに受け取った開発者が困惑してしまうというケースもあるようです。また、本来のオープンソースではない何かを今のブームに乗じてオープンソースとして売り込むフェイクも氾濫しており、由々しき問題であります。

南米エクアドルの沖にダーウィンが進化論の着想を得たガラパゴスという島々がありますが、英語という大海で断絶された日本はガラパゴスと同じようにオープンソースが進化とも退化とも言える独自の変化を起こしており世界の潮流から取り残される、まさにOSSガラパゴス諸島と言えるでしょう。

ガラパゴスのような独自進化には良し悪しはありますが、日本のオープンソース市場を拡大し、世界をリードしていくためには、必然として日本で閉じることなくグローバルに出て行くことが重要であることは間違いなく、VA Linux Systems Japan社とOSDNはそのために邁進する所存….」

前後の話が実際にはもっと眠くなるような話をしてたような気がするが、ガラパゴスの筋としてはこんなところだったのだろう。ここまでエスパーして書いて思ったのだが、現在ではオープンソース・プログラム・オフィスについて書いた記事でも出てくるオープンソース・エコシステムやアップストリーム・ファーストといったフレーズで簡単に説明できる内容であると思う。エコシステム(生態系)という言葉はガラパゴスに通じるところがあり、「多様な軸で構成されるオープンソースのエコシステムを安定かつ健全に発展させていきましょう！」と言えば済む話だったわけだ。何というか、当時は若く無鉄砲だったのだろう。

ともかく、ここが私からのガラパゴスの初出であり、そのフレーズが刺さったのか、この日からはLinux/オープンソース界隈でそのフレーズを使う者も出てきた。ただ、私のこの講演は、イベントへ取材しに来ていたITmedia、CNet、日経BPらのメディアが出した記事には触れられなかったので、この時点ではまだオープンソース界隈の一部の内輪ネタに近い言葉として留まっていたのだと思う。

ガラパゴスの拡散

VA Linux Business Forumでの講演ではオープンソース界隈のほぼ内輪からのフィードバックに限られていたが、私個人としてはその反応からはガラパゴスという表現に手応えを感じていたのだろう。ガラパゴスという独自の生態系を連想させる言葉は様々な視点からの問題を包括的に扱うのに都合が良いと思っていたように記憶している。

ここへ次のイベントの機会がやってきた。2004年11月30日にパシフィコ横浜で開催されたOpen Source Way 2004である。Open Source Wayはライセンスや特許等の法的な問題やオープンソースの経済圏、経営との関わり等のトピックを扱うカンファレンスであり、2002年から私と八田真行さんで企画し、プログラムを作成していた。2004年は日本OSS推進フォーラムが設立されて産官連携や日中韓連携といった流れもあり、全体的にオープンソース振興というものが一服感が漂いつつあった頃で全体的には前向きなトピックが多く、私としては何かピリッとくるネタを入れておきたかったのだと思う。

生憎と適当な講演者も見当たらず自分で喋ることに決め、数ヶ月前のVA Linux Business Forumで使ったネタをそのまま拡張し、一つ一つの事例もより掘り下げるように話したように思う。これでオープンソース・ガラパゴス諸島の再演となったわけだが、この模様はITmediaの記事になっているので見聞きしたことのある人も多いだろう。私としてはもう少しマイルドな語りだった気がするのだが、大筋としてはこれで合っているかと思う。今読むとやはりエコシステムとアップストリーム・ファーストで説明できる話しかしてないような気がするので頭が痛いのだが。

日本におけるOSSの幻想――OSS界のガラパゴス諸島、ニッポン (ITmedia)

無事にOpen Source Wayは終わったのだが、このITmediaの記事が問題だった。あまりにも反響が大きかったのだ。

当時はまだ炎上という表現は一般的ではないし、SNSとはせいぜいmixiという時期である。技術系の人々もまだtDiaryで頑張って意見表明し、スラドに記事が出ればそこでコメントしていた頃だったのだが、そのような時期にしては非常によく燃えたと言える状態だったのではなかろうか。RubyのMatzさんを含めいろいろな方の意見表明があったと記憶しているし、スラドでも400近いコメントが付く大きな議論になった。また、直接苦情と絶賛のメールが届くというあまりない経験もした。

否定的な方の多くの反応は「問題認識としては合っているがお前らは何もしていない」、「解決策を出さずに投げっぱなし」、「日本には日本でやることある」、「そもそも何様や」といった内容が多かったように思う。実にごもっともであり、恥じ入るばかりである。ただ、この反対に「よくぞ言ってくれた！」と絶賛の言葉をかけてくれる人も多かったように記憶している。これらの意見がぶつかり合い、多角的な論争がなされていったように思う。これは様々な場所において既に火種はあったということなのだろう。そこへ私がガラパゴスと一括りにしてしまったことで火を点けてしまい、泥沼的な大きな論争になってしまった。

表で見えるような論争はまだ意味があるものが多かったが、論争が大きくなるにつれITmediaの記事の露出はどんどん上がり、技術系ではない人々の目に触れるようになった。当時のVA Linux Systems Japan社は既に米VA Linux社の子会社ではなく住友商事の直轄子会社であり、大株主としてNTTデータ、NTTコムウェアが入っていたのだが、講演で事例として出した中にNTTの成果もあり、それをガラパゴスと揶揄したような形となっていたことが問題となった。結局、雲の上の人達の間の腹芸と寝技の応酬で丸く収まったようなのだが、私のほうはこちらの方にしばらく忙殺されることになる。

その中で思ったのはガラパゴスという地名やダーウィンの進化論の経緯を知らない人には単に後進の未開の地と同じだと決め付けられたように感じたということである。単にディスるだけなら同じ太平洋の島でも国家の失敗事例としてわかりやすいオープンソースのナウルとか、あるいは破滅に向かうイメージでガダルカナルを使うのではないかと思うところもあったのだが、ガラパゴスでそれと同等の侮辱だと感じる人達もいたようだ。私の語りが悪かったのだろうけども、ガラパゴス諸島には悪いことをしてしまったなと素直に思っていた。

さらにITmediaの記事が注目を集めたことで、ガラパゴスのGoogle検索の結果が数ヶ月ほどこのオープンソース・ガラパゴス記事関連でジャックされたこともマズいことになったと思わされた。それまではガラパゴスの検索結果は観光情報で占められていたのだと思うが、以降、日本ではいわゆるガラパゴス化が占めるようになってしまったのである。ガラパゴス専門のツアー会社があったとしたら涙目だっただろう。

これらのことで私自身はガラパゴスという表現を公の場で使うことをいったん封印した。これをある程度解禁するのはあまりにもガラパゴスとあちこちで使われだし、もはや日本語として定着してしまった数年後のことである。

ガラパゴスの増殖

私がガラパゴスで論争を引き起こして以降、しばらくすれば少なくともガラパゴスとは誰も言わなくなるのではないか？と私は思っていた。しかし、期待に反してオープンソースの世界でのガラパゴス論争は外の世界へ飛び火していくことになる。オープンソースだけでなく〇〇の製品、〇〇の業界もガラパゴスだよ！という言説が少しずつ広まっていった。

わざわざ私に知らせてくれる者がいたのでこれらは記憶にあるのだが、最初は一太郎やTRONだったと思う。これらの日本発のソフトウェアもガラパゴスではないかと言う言説が出てきて、そのうち日本のソフトウェア業界全体がガラパゴスのような論調もでてきた。こうなると、PC-9800シリーズを抱えていたPC業界にも焦点が行き、そこから実はハードウェアもガラパゴスということになっていった。そのうち日本のあらゆる製品、慣習、文化にもガラパゴス論が適用されていったように思う。これらは2005年から2008年頃にかけてゆっくりと進んだ。

これらの中でも携帯電話の当時の市場は、グローバルではノキア、モトローラ、エリクソンの牙城であり、日本勢は高機能端末で国内で独占しつつも海外では橋頭堡も築けていない状況だった。これをガラパゴスと言っていた人達もいたのだと思うが、その場合おそらく前向きとも悲観的意味合いも共にほぼなく、単に独自進化しているという意味合いだったのではないかと思う。世界的に見ても進化を続けていたPDA、あるいはBlackBerryなどと携帯電話の境目が曖昧になっており、必ずしも日本がガラパゴスと言えず、どの国、どの企業がガラパゴスなのか分からない状況だったように思うからだ。

この携帯電話市場が一般にガラパゴスと呼ばれ、国内勢の高機能端末がガラパゴスケータイ、つまりガラケーと呼ばれるようになったのはiPhone以降のスマートフォンの席巻があってからのことだろう。iPhone 3Gが日本で発売されたのが2008年7月であることを考えれば、それ以降に一般化したのだろう。この後、2010年頃にはガラパゴスという言葉はどこでも聞かれたように思う。その年にはシャープがガラパゴスというブランドでタブレットを発表しているくらいである。

ガラパゴスのまとめ

以上が私から見たガラパゴスの歴史である。正直に言って当時の私はガラパゴスという表現を使用したことは後悔していた。講演の内容が荒っぽいということもあったが、そもそも地名を使うことは弊害が大きかったと思っている。ただ、この用語があまりにも広まり過ぎたことでもはやどうでもよくなってもいる。Twitterでガラパゴス、ガラパゴス化とでも検索すれば流行語としてのブームが過ぎて完全に日本語として定着しているとしか思えない。私はオープンソースのためにこの25年ほどを捧げてきているのだが、私の配偶者ですらオープンソースは知らないがガラパゴスは知っているぐらいである。

ということで、このままだとガラパゴスの人で終わってしまうかもしれないので、オープンソースのためにまだ自分としてやれることをやっていこうと思う次第である。

オープンソース・プログラム・オフィスとは何か？ (ぼくがかんがえた最強のOSPO)

GoogleやMicrosoftといったビッグテックにOpen Source Program Office (OSPOという略で界隈では通じる)という部署が存在することは日本でも知られているが、現在では多くのグローバルIT企業にも同名の部署が存在する。近年では中国系の企業での設置が目立つが、日本でもサイボウズ、メルカリといった企業には存在するようだ。

続きを読む “オープンソース・プログラム・オフィスとは何か？ (ぼくがかんがえた最強のOSPO)”

OSSという日本でしか通用しない三文字略語について

OSSとは… 20年前はOpen Sound Systemを意味する略語のことだった。少なくともLinuxコミュニティではそうだった。

Open Sound SystemはUNIX系のプラットフォームで利用できるサウンドシステム(ドライバ)であり、Linuxでは標準サウンドシステムであった。OSSと言えばこれを指しており、当時生まれたばかりのOpen Sourceという新語の略語としてOSSを使うということはほぼなかった。

続きを読む “OSSという日本でしか通用しない三文字略語について”

オープンソースはソフトウェア限定の用語なのか？

教材をオープンソースにって言う時に毎回オープンソースはソースコードを示す言葉で教材を指す言葉じゃないだろと突っ込みたくなるわけだけど、まあハードウェアでもオープンソースって言ってる人いるから大丈夫やろと思ってる
— おってぃ (@otty_uma) August 3, 2020

上記のようなツイートを見かけた。
特に変わった内容ではないと思われる方も多いと思うが、私にとっては実に興味深い視点で書かれていると感じた。一つはこの方がオープンソースのソースはソースコードのソースであると言っている点。もう一つはオープンソースはソフトウェア(ソースコード)を指し示す用語であると暗に言っている点である。

LinkedInを利用する意義

LinkedInは世界最大のビジネス向けのSNSらしい。ただ、日本ではとりあえず登録したものの人材、不動産、マルチと謎のVIPやセレブからの怪しい勧誘がやってくるサイトという認識を持っている方のほうが多いのではないだろうか。転職に使えないことはないのかもしれないが、他の転職サイトや下手をするとTwitterのほうが日本では転職に使えるケースが多いだろう。

続きを読む “LinkedInを利用する意義”

ドットコムバブルの終焉とVA Linux Systemsの崩壊

LinuxWorldの基調講演という場で華々しく発表されたAndover.netの買収はオープンソースコミュニティへは大きなインパクトを与えたが、市場の反応はその逆だった。ハードウェア事業とはかけ離れた事業に大きく投資する意味を当時では見出すことは難しいことは容易に想像できる。そのため、VA Linux社はまた即座に行動しなければなかった。

何故、VA LinuxはAndoverを買ったのか？

1999年12月9日、VA Linux社は驚異的なIPOを成し遂げたが、直近四半期の売上は1,700万ドル、資産もほとんどがIPOで得た現金であり、1億5000万ドル程度の規模でしかなかった。 100億ドルに迫る時価総額をとうてい正当化しそうもないのは明らかであった。そのため、ある程度の調整が入ることは仕方がないとしても、このあまりにも高過ぎる評価を維持するために即座に行動を起こすことがVA Linux社の取締役会へ求められた。足下のハードウェア事業についてはさらに引き続き高い成長を見せていることは分かっていたが、今は手元に現金と驚異的な評価が付いた株式がある。必然的にこれを効率的に使用して企業買収を行い、VA Linux社の価値を高めなければならなかった。

映画「Revolution OS」について

例によって一回脱線し、既に何度か言及している「Revolution OS」という映画について書いておく。

VA LinuxのIPO：13ドル、23ドル、30ドル、そして 300ドルへ

LinuxOneの騒動でまだコミュニティがごたついていた1999年10月8日、とうとうVA Linux Systems社がIPOを申請した。Red Hatの後に何故か間に3社が挟まれ、それぞれ印象的な結果を残したが、市場はとうとう本命がやってきたと騒ぎ始めた。

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

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

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

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

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

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

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

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

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

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

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

2.5. 契約としての性質

3. オープンソースAI

4. むすび

参考：

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

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

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

定義の策定プロセス

ドラフト版定義解説

前文解説

OSAID定義の本体の解説

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

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

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

チェックリストの解説

必須となるコード

必須となるモデル

必須となるデータ情報

チェックリスト適用の現状

今後と懸念点

参考

嫌いな奴を排除する

利用者が困るライセンシングの実例

オープンソースであるために

今日の倫理を求める勢力

倫理を条件にすることは避けよ

免責の必要性

無保証と免責の歴史

作品がパブリックドメインとなるには

オープンソースとの違い

四つの基本的な自由

オープンソースの定義との比較

両者の差異

ライセンス判定基準としての違い：

哲学の違い：

FSFの自由ソフトウェア

Debianのフリーソフトウェア

オープンソースの定義へ

四つの自由と自由ソフトウェアの定義化

注意

参考

Business Source Licenseとは？

ライセンスとしてのデメリット、メリット

Terraformにおける適用

コミュニティの反発の理由

排除される人々

CLAの罠による貢献者の疎外

プロジェクトフォークの行方

それでも何故 BUSL化を企業は望むのか？

最後に

参考

許諾

付録：Business Source License 1.1 日本語訳

SSPL条文分析

何を？

誰にどうする場合？

条件 (何をしなければならないか)

AGPLv3とSSPLとの違いのまとめ

オープンソースへの適格性

ライセンスとしての適格性

主張通りのライセンスであるのか？

使用に関しての注意点

まとめ

参考

ガラパゴスの黎明期

ガラパゴスの巣立

ガラパゴスの拡散

ガラパゴスの増殖

ガラパゴスのまとめ

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