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発足直後に書かれたものであり、当時とは状況が若干異なる可能性がある。)

1. Business Source Licenseとは？
   1. ライセンスとしてのデメリット、メリット
   2. Terraformにおける適用
2. コミュニティの反発の理由
   1. 排除される人々
   2. CLAの罠による貢献者の疎外
3. プロジェクトフォークの行方
4. それでも何故 BUSL化を企業は望むのか？
5. 最後に
6. 参考
7. 許諾
8. 付録：Business Source License 1.1 日本語訳

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

許諾

Copyright 2023 Shuji Sado
本文書はクリエイティブ・コモンズ 表示-継承ライセンスのもとで利用できる。挿絵は単純プロンプトのAI生成物であり、パブリックドメインである。

---

付録：Business Source License 1.1 日本語訳

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

— ここから —

ライセンス書面の著作権 (c) 2020 MariaDB Corporation Ab, All Rights Reserved.
Business Source Licenseは、MariaDB Corporation Abの商標です。

パラメータ

許諾者：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年目のいずれか早い日に、許諾者は本許諾により、変更後ライセンスの条項に基づく権利をあなたへ付与し、上記で付与された権利は終了します。

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

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

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

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

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

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

---

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

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

1. SSPL条文分析
   1. 何を？
   2. 誰にどうする場合？
   3. 条件 (何をしなければならないか)
   4. AGPLv3とSSPLとの違いのまとめ
2. オープンソースへの適格性
3. ライセンスとしての適格性
4. 主張通りのライセンスであるのか？
5. 使用に関しての注意点
6. まとめ
7. 参考

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/

Copyright 2023 Shuji Sado
本文書はクリエイティブ・コモンズ 表示-継承ライセンスのもとで利用できる。挿絵は単純プロンプトによるAI生成物であり、パブリックドメインである。