SSPLの問題点と主要Linuxディストリビューションから除外されるMongoDB

「クラウドベンダなどによるサービス利用を制限したMongoDBの新ライセンス『SSPL』を理由にDebian、Fedora、RHELがMongoDBの配布取りやめを表明」という記事を読んで、私自身はMongoDBのユーザではないものの、今後他の製品にも波及しそうな話題だったので経緯を少しだけ調べてみた。SSPLってそんなに問題のあるライセンスだったのだろうか。

非常に大まかな経緯

MongoDBの経緯はこんな感じである。

GPLとAGPLの歴史的な経緯

話を整理するために、MongoDBがかつて使用していたAPGLとはなんなのかについて少しまとめる。

オリジナルのAffero General Public License（AGPL）は、Affero, Inc.によって2002年に策定されたコピーレフトなオープンソースライセンスである。このバージョンのAGPLはGPLv2の抜け穴の一つ、いわゆる「ASPループホール」を埋めるために作られた。ASPループホールとは、たとえGPLv2でライセンスされたプログラムを改変して使用している場合も、派生したプログラムそれ自体を配布するのではなく、そのプログラムを用いてASP型のサービス（今でいうと「SaaS」のほうが伝わるだろうか）を提供する場合は、GPLv2に基づくソースコードの開示を求められることができない、という問題だ。オジリナルのAGPLははこの問題を解決するために、「もしプログラムがネットワーク越しにユーザとやり取りする場合、（中略）そのプログラムのソースコードを要求する機会を提供すること」という条項（2.d）を定めている。これによって、ASP型のサービスにAGPLでライセンスされたプログラムもしくはその派生物が使用された場合、そのサービスのユーザはASP提供者にそのプログラムのソースコードを要求することが出来るようになっている。

現在主に使用されているいわゆるAGPLは、GNUによってGPLv3と合わせて策定された新しいバージョンで、ベースはGPLv3になっている。このバージョンは今では単にAGPLと呼ばれたり、GNU AGPLと呼ばれたり、あるいはAGPLv3と呼ばれる。このバージョンのAPGLでも、オリジナルのAGPLと同じく、ネットワーク経由で使用されるプログラムのソースコード開示をライセンシーに要求している。GNU AGPLの内容自体はほぼGPLv3と同一で（互換性もある）、13条にネットワーク経由の利用についての要求が追加されている。MongoDBが使用していたのもこのバージョンのAGPLである。

AGPLの限界と開発者の利益

AGPLが要求するのは、AGPLでライセンスされたプログラム、もしくはその派生物のソースコードを公開することである。言い換えると、プログラム本体に変更を加えていなければ、公開を求められるソースコードは、オープンソース版のそれと同一となる。MongoDBの場合で言えば、コミュニティ版のMongoDB本体を何らかの形で改変しない限り、マネージドサービスを提供するにあたって必要なほかの部品については非公開でも問題がない。

このAGPLの性質は、MongoDB社のようなオープンソース版をベースとしたマネージドサービス（MongoDB Atlas）を商売としている会社にとっては、必ずしも都合が良くない。というのも、MongoDBが言っている通り、体力のあるクラウドプロバイダーがコミュニティー版を元にしてマネージドサービスを始めてしまうと、MongoDB自身で提供しているマネージドサービスが売れなくなってしまうからだ。マネージドサービス化にあたって必要な機能は、MongoDB本体に対する改変よりもむしろ、その周辺の運用システム（「wapper」とも呼ばれる）となることから、その部分についてはAGPLに基づいたソースコードの公開も要求できない。MongoDB社からすれば、せっかく自分たちで開発したプログラムを使って他社が競合サービスを始めた上に、自分たちやオープンソースコミュニティへの貢献すらしてくれない、という非常に辛い状況になる。

開発者に有利な新しいライセンスで解決

この問題を解決するためにMongoDBが選んだのが、Server Side Public License（SSPL)という新しいライセンスの策定である。このライセンスもGPLv3をベースとしており、AGPLと同じく13条だけが改変されて、以下のようになっている。

もしそのプログラムもしくは改変版の機能が第三者にサービスとして提供される場合、そのService Source Codeを無料かつ同一のライセンスでネットワークからダウンロード可能にしなければならない。（中略）「Service Source Code」とは、そのプログラムもしくは改変版のソース（Corresponding Source)と、そのプログラムもしくは改変版をサービス化するために必要な、管理ソフトウェア、ユーザインターフェース、アプリケーションインターフェイスプログラム、自動化ソフトウェア、モニタリングソフトウェア、バックアップソフトウェア、ストレージソフトウェア、ホスティングソフトウェアを含む、（中略）すべてのプログラムのソースである。

つまり、MongoDBを使ってマネージドサービスをするなら、周辺のプログラムもすべてソースコードをSSPLで公開しろということである。これによって、MongoDBを用いたマネージドサービスを提供する会社は、強制的にコミュニティへの還元を求められることになる。

SSPLは「オープンソースライセンス」か

開発者に有利なSSPLはオープンソースコミュニティに受け入れられるべきものに感じられるが、実際は主要なLinuxディストリビューションからの除外という結果になってしまった。これはなぜか。 MongoDB社はSSPLがGPLv3に最小限の変更を加えただけであり、オープンソースライセンスになるであると主張している。ここで、「オープンソースライセンス」とはOpen Source Initiative（OSI）が定義しているOpen Source Definition（OSD）に適合して、承認されたライセンスをいう。

しかし、OSIでの議論はMongoDB社の意図とは裏腹に、SSPLはOSDに適合しないという方向で一致しつつある。具体的に特に問題となっているのが、OSDの9条（OSD9）である。OSD9には「ライセンスは、そのソフトウェアとともに配布される他のソフトウェアに対して制限を課してはならない。たとえば、ライセンスは、同じ媒体上で配布されるすべてのプログラムにオープンソースソフトウェアであることを要求してはならない」と書かれている。この項目とSSPLの要求は、直感的にも適合しない。AGPLがプログラム本体についてのみのソースコード要求であるのに対して、SSPLは本体以外のソースコード公開も求めるのが主要な変更点であることから、その差分を考えるに、SSPLがOSD9に適合するという主張はかなり難しいように思われる。OSIのメーリングリストでは、OSDを起案したBruce Perensが「私は まさに このような行為を禁止するために、OSD9を書いたのだ」と言ってしまっているので、おそらくSSPLがオープンソースライセンスとして認証されることは無さそうに見受けられる。

なお、MongoDB社はSSPLが認められないという流れになった結果、SSPLv2という修正版を新たに提案しているが、これについても根本的な問題が解決していないため、議論に大きな影響はないようである。

SSPLがOSDに適合しないということは、SSPLは他のオープンソースライセンスとの相互運用上問題があるということが暗示されるので、Linuxディストリビューションは自身のパッケージリストにMongoDBを含めるのが難しくなってくる。今回DebianやFedoraといったディストリビューションからMongoDBが除外されるという話になったのも、SSPLが他のプログラムとの相互運用上問題となるからであろう。単純な例として、MongoDBをDockerコンテナ上で提供するサービスを作った場合、Dockerのソースコードを（SSLPもしくは他のFLOSSライセンスで）開示する必要があるのだろうか。あるいはChefやAnsibleでMongoDBをセットアップする場合はどうだろうか。SSPLの13条が定めるService Source Codeはその範囲が非常に広く、はたしてどこまでがSSPLに影響されてるのかが非常に曖昧である。

なおOSIの議論では、MongoDB社のやりかた自体への批判もなされており、この点も興味深い。MongoDB社は公開非公開含めて何の議論も行わずに新しいライセンスを作り、さらには表立った共同作業は何も行わないにも関わらず、たったの35日で新しいバージョンまでつくって事後承認のスタンプを求めてくる、などと言われたり、「（MongoDBには）OSD準拠のラインセンスを作ろうという誠意（good faith）が感じられない。（中略）。OSIのボランティアの労力を浪費（exploit）しようとするのはフェアでない」、あるいは「もし（MongoDB社に）ボランティアで活動しているOSIのボードメンバーへのリスペクトが少しでもあるのであれば、提案を取り下げるべきなのではないか」などと言われてしまっている。

今後はどうなるのか

メーリングリストでの議論では、この問題は多くのベンダーに影響しているので、統一されたライセンスが存在しないのは将来的にライセンスの乱立という問題（結果として法務コストの増大）を生むであろう、という問題提起もなされていて、その点については賛意も見受けられる。しかしながら、やはりSSPL自体はオープンソースライセンスとして認証できないし、そもそもオープンソースライセンスは万能ではない、というのがOSIの主流意見のように見える。前述のBruce Perensなどは、SSPLのOSI承認を否定しながらも、OSIの外でならこの問題を解決する手助けができるとコメントしており、もしかするとOSIの枠組みの外で統一されたライセンスの策定が行われることになるかもしれない（その場合、MongoDBは「オープンソース」ではなくなり、MongoDB社は「Open Source Company」ではなくなってしまうかもしれないが）。実際に各社が個別にライセンスを作り始めている状況なので、この部分は何らかの形で解決するとOSSコミュニティには利益がありそうに思われる。

リンク

個別にOSIの議論メールを読むのが面倒な場合は、月次レポートを読むと流れがわかりやすい。