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に答えさせた図