MongoDBライセンス徹底解説！種類とSSPL/AGPLの違い

はじめに：なぜMongoDBのライセンスを理解する必要があるのか？

現代のウェブサービスやアプリケーション開発において、NoSQLデータベースの代表格であるMongoDBはその柔軟性と高いスケーラビリティから広く利用されています。開発者にとって使いやすく、ドキュメント指向という特徴が多くのユースケースにフィットするため、スタートアップから大企業まで、様々な規模のプロジェクトで採用されています。

しかし、MongoDBを利用する上で、非常に重要な、かつ多くの開発者や企業が見落としがちな点があります。それが「ライセンス」です。特に、MongoDBが2018年末に行ったライセンスの大きな変更は、テクノロジー業界に波紋を広げ、多くのユーザーに混乱をもたらしました。

「オープンソースだから自由に使えるだろう」と考えがちですが、データベースソフトウェアのライセンスは、その利用形態、特に「サービスとして提供するかどうか」によって、許諾される範囲や義務が大きく変わってきます。知らずに利用していると、意図せずライセンス違反を犯してしまう可能性もゼロではありません。ライセンス違反は、法的な問題やビジネス継続性のリスクに直結します。

この記事では、MongoDBのライセンスについて、その歴史的変遷から、現在主流となっているSSPL（Server Side Public License）と、かつて主要ライセンスだったAGPLv3（Affero General Public License）の違い、そしてその他の関連ライセンスまで、徹底的に解説します。特に、多くのユーザーが懸念を抱くSSPLの「サービス提供」に関する条項に焦点を当て、具体的な利用シーンごとにライセンスがどのように適用されるのかを詳細に掘り下げます。

この解説を通じて、あなたがMongoDBを安心して、かつ正しく利用するための知識を習得できることを目指します。

MongoDBライセンスの歴史的変遷：なぜライセンス変更は必要だったのか？

MongoDBは、その開発初期からオープンソースの精神に基づいてコミュニティに貢献してきました。当初、MongoDB Community Editionのライセンスは、GNU Affero General Public License Version 3（AGPLv3）でした。

AGPLv3は、伝統的なGPLv3（GNU General Public License Version 3）に、ネットワーク越しにソフトウェアを利用する場合のソースコード開示義務を追加したライセンスです。GPLv3は、ソフトウェアを「配布」する場合にソースコードの開示義務が発生しますが、ウェブアプリケーションのようにサーバー上で動作するソフトウェアの場合、クライアントはネットワークを通じてサービスを利用するため、ソフトウェア自体を受け取るわけではありません。この場合、GPLv3の下ではソースコード開示義務が発生しないという「ASP (Application Service Provider) Loophole」と呼ばれる問題がありました。AGPLv3は、この抜け穴を塞ぎ、ネットワーク経由でサービスを提供する場合でも、利用者にそのサービスを構成するソフトウェアのソースコードを入手可能にする義務を課すものです。

AGPLv3は、フリーソフトウェアの理念をより広範な利用形態に適用するための強力なライセンスでした。MongoDBがAGPLv3を採用したことは、そのソフトウェアをオープンかつ自由に利用・改変・共有できる状態に保つという意図の表れでした。

しかし、時代が進み、クラウドコンピューティングが普及するにつれて、新たな問題が顕在化しました。それは、多くのクラウドベンダーが、AGPLv3で提供されているMongoDBをそのまま利用し、自社のクラウドプラットフォーム上で「マネージドデータベースサービス」として提供し始めたことです。これらのベンダーは、MongoDB本体にはほとんど手を加えず、運用管理機能などを付加価値として提供することで収益を上げていました。

MongoDB Inc.（MongoDBの開発元企業）の視点から見ると、これは彼らが開発・維持に多大な投資を行ってきたソフトウェアが、他の企業によって「ただし乗り」され、その成果が収益に直結しないという状況でした。AGPLv3は、ソフトウェアのソースコード開示を義務付けていましたが、クラウドベンダーが自社開発した運用管理ツールやプラットフォーム側のコードまでは開示義務の範囲外でした。また、マネージドサービスとして提供する場合、エンドユーザーはデータベースソフトウェア自体を入手するわけではないため、AGPLv3の「ネットワーク越し」の条項が想定する開示義務の適用についても解釈の余地がありました（多くの解釈では、AGPLv3ソフトウェア本体のソースコード開示は必要とされる）。しかし、より根本的な問題として、MongoDB Inc.が開発したソフトウェアから収益を上げるメカニズムが弱まるというビジネス上の課題がありました。

このような背景から、MongoDB Inc.は、クラウドベンダーによるマネージドサービスの提供をより強く制限し、自社のビジネスモデル（MongoDB Atlasなどのマネージドサービス提供や商用ライセンス販売）を保護するために、新たなライセンスの導入を決定しました。それが、Server Side Public License（SSPL）です。

2018年10月、MongoDB Inc.はMongoDB Community EditionのライセンスをAGPLv3からSSPLv1に変更することを発表しました。この変更は、OSSコミュニティや他のクラウドベンダーの間で大きな議論を巻き起こしました。特に、SSPLが定める「サービス提供」に関するソースコード開示義務の範囲が、従来のオープンソースライセンスとは一線を画す、非常に広範なものだったからです。

このライセンス変更により、MongoDB Community Editionは、かつてのような「一般的なオープンソースソフトウェア」とは異なる位置づけとなりました。現在、MongoDBのライセンスを理解する上で、このSSPLの特性を正確に把握することが最も重要となっています。

現在のMongoDBの主要ライセンス：SSPL (Server Side Public License)

SSPL、すなわちServer Side Public Licenseは、MongoDB Inc.が策定し、MongoDB Community Editionの新しいライセンスとして採用されました。その目的は明確に、ソフトウェアをサービスとして提供する際の条件を定めることにあります。

SSPLv1の概要説明

SSPLv1は、基本的にGNU GPLv3をベースにしており、そこにネットワークサービス提供に関する独自の条項を追加したものです。AGPLv3がGPLv3にネットワーク条項を追加したのと同じような構造ですが、SSPLのネットワーク条項はAGPLv3よりもはるかに厳しいものです。

SSPLは、自身のことを「ソースコードを利用可能にするライセンス（Source Available License）」と位置づけていますが、多くのオープンソースコミュニティや機関からは、オープンソースライセンスとは見なされていません。その最大の理由は、OSI（Open Source Initiative）が定めるオープンソースの定義を満たしていないからです。OSI基準では、ライセンスは特定の分野のプログラムの使用を妨げてはならない、特定の技術を制限してはならない、といった条項が含まれますが、SSPLのサービス提供に関する厳しい条項は、特定のビジネスモデル（マネージドサービスの提供）を事実上制限するため、OSI基準から外れると判断されています。

SSPLの主要条項の解説：特に条項13「Offering a Service」

SSPLの核心であり、最も物議を醸す条項が、条項13「Offering a Service」です。この条項は、SSPLでライセンスされたソフトウェアを「サービスとして外部に提供する」場合に適用される義務を定めています。

条項13の内容を平易に説明すると、以下のようになります。

あなたがSSPLでライセンスされたソフトウェア（例えばMongoDB Community Edition）を、ネットワーク経由で利用できるサービスとして（例えばSaaSのバックエンドデータベースとして、あるいは顧客向けのマネージドデータベースサービスとして）提供する場合、
そのサービスを提供する際に使用する「Management Software, system software, operating system, or any other software needed to make available the Functionality of the Program to users over a computer network」（管理ソフトウェア、システムソフトウェア、オペレーティングシステム、あるいはプログラムの機能をコンピュータネットワークを介してユーザーに提供するために必要なその他のあらゆるソフトウェア）
これらの「Supporting Software」全てのソースコードを、SSPLまたはSSPLと互換性のあるライセンスの下で公開しなければならない。

この条項の厳しさは、「プログラムの機能をユーザーに提供するために必要なあらゆるソフトウェア」という開示範囲の広さにあります。これは、SSPLライセンスを受けたMongoDB本体のソースコードだけでなく、そのMongoDBを動作させるために必要なOS（Linuxなど）、ミドルウェア、データベース管理ツール、モニタリングツール、ロードバランサーなど、システム全体を構成する全てのソフトウェアに及びうる、と解釈されています。

例えば、あなたがMongoDB Community Editionをバックエンドとして利用するSaaSを提供しているとします。このSaaSを動かすためには、Linuxサーバーが必要ですし、そこにMongoDBをインストールし、運用管理のためのスクリプトやツール、バックアップシステム、監視システムなどが稼働しているでしょう。SSPL条項13によれば、これらの全てのソフトウェア（Linux本体、各種管理ツール、自社開発の運用スクリプトなど）のソースコードを、SSPLまたは互換ライセンスの下で公開する義務が発生する可能性がある、ということになります。

これは、現実的にほとんどの企業にとって受け入れがたい、あるいは不可能な要件です。自社開発のノウハウが詰まった運用管理ツールや、特定の構成に基づいたシステム全体を構成するソフトウェア群のソースコードを全て公開するということは、ビジネス上の競争優位性を失うことを意味します。また、SSPLと互換性のあるライセンスを持つソフトウェアだけでシステム全体を構成するというのも、非常に困難な作業です。

SSPLの影響

このSSPLの条項13は、特にクラウドベンダーやSaaSを提供する企業に大きな影響を与えました。

クラウドベンダー: SSPLでライセンスされたMongoDBを、そのままマネージドサービスとして提供することは、上述のソースコード開示義務が発生するため、事実上不可能となりました。もし提供するならば、システム全体をSSPLまたは互換ライセンスで公開するか、あるいはMongoDB Inc.から商用ライセンスを取得するかのいずれかを選択する必要があります。多くの大手クラウドベンダーは、SSPLへのライセンス変更後、自社のマネージドデータベースサービスにMongoDBを公式にラインナップすることを避け、あるいは他のデータベースへの移行を推奨する動きを見せました。例えば、AWSはDocumentDB、AzureはCosmos DB (MongoDB API互換)といった互換性のあるサービスを開発・提供しています。
SaaSを提供する企業: 自社のSaaSのバックエンドデータベースとしてMongoDB Community Edition（SSPL）を利用する場合、そのSaaSがネットワーク経由で利用される限り、条項13のサービス提供に該当すると解釈される可能性が非常に高いです。結果として、「サービスを実行する全てのソフトウェア」のソースコード開示義務が発生し、Community Editionをそのまま利用することが困難になります。

SSPLライセンス下での利用方法

では、SSPLでライセンスされたMongoDB Community Editionはどのように利用すれば良いのでしょうか？

自社内システムでの利用:
- 外部にサービスとして提供しない、純粋な社内業務システムや、特定の顧客向けではない自己完結型のアプリケーションのバックエンドとして利用する場合、SSPLの条項13は適用されません。この場合、MongoDB Community Editionを自由に利用できます。
- ただし、「サービスとして外部に提供するかどうか」の線引きは曖昧な場合もあり、慎重な判断が必要です。例えば、社内システムの一部を関連会社や特定のパートナーにネットワーク経由で提供する場合など、法務部門に確認することをお勧めします。
商用ライセンスの購入:
- MongoDB Inc.は、SSPLの制約を受けない商用ライセンス「MongoDB Enterprise Advanced」を提供しています。SaaSのバックエンドとして利用したい、マネージドサービスとして提供したい、エンタープライズ向けの高度な機能（例えば暗号化、監査、高度な監視ツールなど）を利用したいといった場合は、この商用ライセンスを購入する必要があります。商用ライセンスの条件は、MongoDB Inc.との契約（EULA: End User License Agreement）によって定められます。
- MongoDB Atlasは、MongoDB Inc.自身が提供するマネージドサービスであり、ユーザーはAtlasの利用規約に基づいてMongoDBを利用します。この場合、ユーザーが直接SSPLの義務を負うわけではありません。

要するに、SSPLはMongoDBを「サービスとして提供すること」に対して非常に厳しい制約を課すライセンスです。この制約を回避してMongoDBをサービス提供に利用したい場合は、MongoDB Inc.から商用ライセンスを購入するか、同社のマネージドサービスであるMongoDB Atlasを利用するのが一般的な選択肢となります。

過去の主要ライセンス：AGPLv3 (Affero General Public License)

AGPLv3（Affero General Public License Version 3）は、かつてMongoDB Community Editionの主要ライセンスでした。SSPLを理解するためには、AGPLv3の性質と比較する視点が不可欠です。

AGPLv3の概要説明

AGPLv3は、フリーソフトウェア財団（FSF: Free Software Foundation）によって策定された、強力なコピーレフトライセンスです。GNUプロジェクトの一環として開発され、その目的は、ソフトウェアがどのように利用されようとも、そのソースコードが常に利用可能であり、改変や再配布が自由に行える状態を保つことにあります。

AGPLv3は、標準的なGNU GPLv3をベースにしています。GPLv3は、ソフトウェアを「配布」する場合にソースコードの開示義務（対象のソフトウェアとその改変版のソースコードを、受け取った人が入手できるようにすること）を課します。これにより、ソフトウェアの利用者（配布を受けた人）は、そのソフトウェアがどのように動いているのかを知り、自由に修正したり、その修正版をさらに配布したりすることが可能になります。これは、フリーソフトウェアの理念である「実行の自由」「研究・改変の自由」「再配布の自由」「改変版の再配布の自由」を保証するための重要なメカニズムです。

AGPLv3の特徴：「ネットワークサービス提供」の場合のソースコード開示義務

GPLv3には前述の通り「ASP Loophole」と呼ばれる問題がありました。つまり、ソフトウェアをサーバー上で実行し、その機能をネットワーク経由でユーザーに提供する場合（例えばウェブアプリケーションやSaaS）、ソフトウェア自体を「配布」しているわけではないため、GPLv3のソースコード開示義務が発生しないという解釈が可能でした。これにより、企業はGPLv3のソフトウェアを改変して利用しつつも、その改変版のソースコードを公開せずにサービスを提供することができてしまいました。

AGPLv3は、この問題を解決するために、「ネットワーク越しにプログラムの機能をユーザーに提供する場合」にも、ソースコードを開示する義務を追加しました。具体的には、AGPLv3でライセンスされたソフトウェアをサーバーで実行し、その機能がネットワークを通じて遠隔地のユーザーに提供される場合、サービス提供者はそのユーザーに対して、サービスに使用しているAGPLv3ソフトウェア（およびその改変版）のソースコードを入手可能にする手段を提供しなければならない、と定めています。

この開示義務の対象となるのは、AGPLv3でライセンスされたソフトウェア本体です。AGPLv3は、そのソフトウェアを実行するために必要なOSや他のミドルウェア、あるいはサービス提供者が別途開発したシステム全体の運用管理ツールなど、AGPLv3とは異なるライセンスで提供されている周辺ソフトウェアにまでソースコード開示義務を広げるものではありません。AGPLv3の目的は、AGPLv3ソフトウェア自体のソースコードを、そのソフトウェアの利用者（サービスのエンドユーザーを含む）が利用できるようにすることにあります。

AGPLv3は、フリーソフトウェアの「コピーレフト」の考え方を、ウェブサービスが主流となった現代のソフトウェア利用形態にも適用しようとする試みであり、強力なオープンソースライセンスとして多くのプロジェクトで採用されています。

SSPLとAGPLv3の比較：決定的な違いとは？

AGPLv3とSSPLは、どちらもネットワーク越しにソフトウェアを提供する際のソースコード開示義務を持つコピーレフトライセンスという点では似ています。しかし、その義務の「範囲」において、両者には決定的な、そしてビジネスに大きな影響を与える違いがあります。

特徴	AGPLv3	SSPLv1
ライセンス元	フリーソフトウェア財団 (FSF)	MongoDB Inc.
ベース	GPLv3	基本的にGPLv3に類似 (条項13が独自)
OSI認定	あり (オープンソースライセンス)	なし (Source Available Licenseとされることが多い)
コピーレフト性	あり	あり (ただし、対象範囲が極めて広い)
ネットワークサービス提供時のソースコード開示義務	あり	あり (条項13)
開示義務の範囲	AGPLv3ライセンスされたソフトウェア本体とその改変版	サービスを実行するのに使用する全てのソフトウェア (OS、ミドルウェア、管理ツール等も含む可能性が高い)
目的	フリーソフトウェアの理念をネットワークサービスに適用	クラウドベンダー等によるMongoDBのマネージドサービス提供の制限、自社ビジネスモデルの保護

共通点:

コピーレフト性: どちらのライセンスも、ソフトウェアの改変版や、特定の条件下での利用に対して、そのソースコードを開示・共有する義務を課します。これにより、ソフトウェアがプロプライエタリな（非公開の）ソフトウェアに閉じ込められることを防ごうとします。
ネットワークサービス提供時の開示義務: どちらも、ネットワーク経由でソフトウェアの機能を提供する際に、何らかのソースコード開示義務が発生します。

決定的な違い:

最も重要な違いは、ソースコード開示義務の「範囲」です。

AGPLv3の開示範囲: AGPLv3の下でサービスを提供する際に開示が求められるのは、基本的にはそのAGPLv3でライセンスされているソフトウェア本体（およびその改変版）のソースコードです。例えば、AGPLv3のデータベースをSaaSのバックエンドとして使用する場合、データベースソフトウェア本体のソースコードを利用者が入手できるようにする義務が発生します。しかし、そのデータベースを動かすサーバーのOS、アプリケーションサーバー、あるいは自社開発のSaaSアプリケーション自体のソースコードまで開示する必要はありません。
SSPLv1の開示範囲 (条項13): 一方、SSPLv1の条項13の下でサービスを提供する際に開示が求められるのは、「プログラムの機能をユーザーに提供するために必要なあらゆるソフトウェア」のソースコードです。前述のように、これはOS、システムソフトウェア、管理ツールなど、MongoDB Community Editionを動作させ、その機能をサービスとして提供するために使用されるシステム全体のソフトウェア群を指すと解釈される可能性が極めて高いです。この範囲の広さが、AGPLv3とは一線を画す最大の特徴です。

この範囲の違いが、ビジネスにおける利用可能性に大きな差を生み出します。

AGPLv3は、そのライセンスを受けた特定のソフトウェア自体をオープンに保つことを重視しています。SaaS事業者にとっては、AGPLv3のデータベースを利用する場合、そのデータベースソフトウェアのソースコードを開示する必要はありますが、自社のコアビジネスロジックを含むアプリケーションコードや運用インフラ全体のソースコードまで開示する必要はありません。
SSPLv1は、MongoDBを「サービスとして提供する」という行為そのものをターゲットにしています。サービス提供のために使用されるシステム全体がSSPLのコピーレフトの対象となりうるため、SSPLでライセンスされたMongoDB Community Editionをそのまま利用してマネージドサービスやSaaSのバックエンドを提供することは、多くの企業にとって非現実的な選択肢となります。事実上、この条項は、MongoDB Inc.以外の企業がMongoDB Community Editionを使って収益性の高いマネージドサービスビジネスを展開することを防ぐための「キラー条項」として機能しています。

OSI認定の有無:

もう一つの重要な違いは、OSIによるオープンソースライセンスとしての認定の有無です。AGPLv3はOSIによって認定されており、広くオープンソースライセンスの一つとして認知されています。一方、SSPLはOSIの認定基準を満たさないと判断され、オープンソースライセンスとしては認められていません。MongoDB Inc.自身も、SSPLを「オープンソースライセンス」ではなく「Source Available License（ソースコード利用可能ライセンス）」と呼ぶことが多いです。これは、SSPLが特定の利用形態（サービス提供）に対して商業的に不利益をもたらすような強い制約を課しているためです。

SSPLは、オープンソースの形式（ソースコード公開）を取りながらも、特定の競争相手（クラウドベンダーなど）を排除するためのライセンス戦略として開発されたという側面が強いと言えます。

その他のMongoDB関連ライセンス

MongoDBには、SSPLで提供されるCommunity Editionの他にも、いくつかのライセンス形態や関連ソフトウェアが存在します。

MongoDB Community Edition (SSPL)

これが、私たちがこれまで主に解説してきた、SSPLv1でライセンスされたバージョンです。無料でダウンロードして利用できますが、上述の通り、特にサービス提供に関する厳しい制約があります。主に開発用途、テスト用途、あるいは外部にサービスを提供しない社内システムでの利用に適しています。

MongoDB Enterprise Advanced (商用ライセンス)

MongoDB Inc.が提供する商用プロダクトです。SSPLの制約は受けず、MongoDB Inc.との別途契約（EULA）に基づき利用します。Community Editionと比較して、エンタープライズ向けの高度な機能（インメモリストレージエンジン、Encryption at Rest、LDAP/Active Directory統合、監査機能、Kerberos認証など）が提供されます。

SaaSのバックエンドとしてMongoDBを利用したい場合や、マネージドサービスとして提供したい場合など、SSPLの条項13の制約を回避する必要がある場合は、このEnterprise Advancedの商用ライセンスを購入するのが一般的な選択肢となります。ライセンス費用は、利用規模や契約内容によって異なります。

MongoDB Atlas (マネージドサービス)

MongoDB Inc.自身が提供するフルマネージドのクラウドデータベースサービスです。AWS、Azure、Google Cloud Platform上で利用できます。Atlasを利用する場合、ユーザーはMongoDBソフトウェア自体のライセンス（SSPLやEnterprise AdvancedのEULA）に直接拘束されるわけではなく、MongoDB Atlasの利用規約（Terms of Service）に基づいてサービスを利用します。

Atlasは、MongoDBの運用管理（プロビジョニング、パッチ適用、バックアップ、監視、スケーリングなど）をMongoDB Inc.が行うため、ユーザーはデータベースの管理負担から解放されます。SSPLのライセンス問題に頭を悩ませることなく、MongoDBをサービスとして利用したい場合に最適な選択肢と言えます。利用料金は従量課金制が基本です。

MongoDB Driver、Toolsなどのライセンス

MongoDB本体とは別に、アプリケーションからMongoDBに接続するためのドライバ（各言語用のクライアントライブラリ）や、コマンドラインツール、GUIツールなども存在します。これらの多くは、MongoDB本体のSSPLとは異なり、より緩やかなオープンソースライセンス（例えばApache LicenseやMIT Licenseなど）で提供されています。

これは、アプリケーション開発者がMongoDBを利用するためのツールやライブラリは、ライセンスの制約を気にすることなく自由に利用できるようにすることで、MongoDBエコシステムの普及を促進するためです。アプリケーション開発者は、自身のアプリケーションコードをこれらのライブラリとリンクさせて利用しても、自身のアプリケーションコードをSSPLで公開する義務を負うことはありません（これは、リンキングに関するライセンスの特性に基づきます）。ただし、ツール自体の改変や再配布には、それぞれのツールのライセンスが適用されます。

これらの関連ソフトウェアのライセンスは個別に確認する必要がありますが、一般的にはMongoDB本体のライセンスほど厳しい制約はありません。

利用シーン別ライセンス解釈と注意点

ここまで見てきたライセンスの種類と特性を踏まえ、具体的な利用シーンごとにMongoDBのライセンスがどのように適用されるのか、そしてどのような点に注意すべきかを解説します。

1. 自社内システムでの利用

利用形態: 会社の内部業務システム、従業員向けのアプリケーション、開発・テスト環境など、外部にサービスとして提供しない形態での利用。
推奨ライセンス/サービス: MongoDB Community Edition (SSPL)
注意点:
- SSPLの条項13「Offering a Service」に該当しない利用形態であれば、MongoDB Community Editionを無料で利用できます。
- 「外部にサービスとして提供しない」の線引きは、法務部門に確認することをお勧めします。例えば、グループ会社や関連会社にネットワーク越しにシステムを利用させる場合、あるいは限定的なパートナー向けにAPIなどを公開する場合などが、「サービス提供」と見なされるかどうかの判断が分かれる可能性があります。
- 高度なエンタープライズ機能（監査、高度なセキュリティなど）が必要な場合は、MongoDB Enterprise Advanced（商用ライセンス）の検討が必要です。

2. SaaS/クラウドサービスでのバックエンドデータベースとしての利用

利用形態: 顧客に提供するウェブサービスやモバイルアプリケーションのバックエンドデータベースとしてMongoDBを利用する形態。
推奨ライセンス/サービス: MongoDB Enterprise Advanced（商用ライセンス）または MongoDB Atlas（マネージドサービス）
注意点:
- MongoDB Community Edition (SSPL): この形態でCommunity Editionをバックエンドとして利用することは、SSPLの条項13に該当する可能性が極めて高いです。条項13が適用されると、「サービスを実行するのに使用する全てのソフトウェア」（OS、ミドルウェア、運用管理ツール等を含む）のソースコードをSSPLまたは互換ライセンスで開示する義務が発生します。これは現実的にほとんど不可能であるため、SaaSのバックエンドにCommunity Editionをそのまま利用することは、実質的に推奨されません。無断で利用した場合、ライセンス違反となるリスクが非常に高いです。
- MongoDB Enterprise Advanced (商用ライセンス): SSPLの制約を受けないため、商用ライセンス契約に基づいてSaaSのバックエンドとして利用できます。この場合、SSPL条項13のような厳しいソースコード開示義務は発生しません。高可用性、セキュリティ、パフォーマンスに関するエンタープライズ機能も利用できます。
- MongoDB Atlas: MongoDB Inc.が提供するマネージドサービスを利用する場合、ユーザーはAtlasの利用規約に基づいてMongoDBを利用するため、SSPLやEnterprise Advancedのライセンス問題を直接考慮する必要がありません。運用管理をMongoDB Inc.に任せられるため、SaaS事業者はアプリケーション開発に集中できます。コストは従量課金制です。

3. MongoDBをマネージドサービスとして提供する場合

利用形態: ユーザーにMongoDBデータベースのインスタンスを提供し、運用管理も含めてサービスとして提供する形態（例: PaaSの一部としてのDBサービス）。
推奨ライセンス/サービス: MongoDB Enterprise Advanced（商用ライセンス）の再販またはサービス提供に関する特別な契約、あるいはMongoDB Atlasのパートナープログラム。
注意点:
- MongoDB Community Edition (SSPL): SSPLの条項13がまさにこの利用形態をターゲットにしています。サービス提供者は、「サービスを実行するのに使用する全てのソフトウェア」のソースコードをSSPLまたは互換ライセンスで開示する義務を負います。これは、現実的にほぼ不可能です。そのため、SSPLでライセンスされたCommunity Editionをそのまま使用してマネージドサービスを提供することは、ライセンス違反となります。
- マネージドサービスを提供するには、MongoDB Inc.と別途、再販やサービス提供に関する特別な商用契約を結ぶ必要があります。MongoDB Atlasのリセラーやパートナーとしてサービスを提供するプログラムも存在します。

4. MongoDBドライバやツールを利用してアプリケーションを開発する場合

利用形態: アプリケーション（デスクトップアプリ、モバイルアプリ、ウェブアプリなど）からMongoDBに接続するために、公式またはコミュニティ製のドライバやツールを利用する形態。
推奨ライセンス/サービス: 各ドライバやツールのライセンス（多くはApache License, MIT Licenseなど）。
注意点:
- ほとんどのMongoDBドライバやツールは、MongoDB本体のSSPLとは異なり、Apache LicenseやMIT Licenseのような緩やかなライセンスで提供されています。
- これらのライブラリを自身のアプリケーションコードとリンクさせて利用しても、通常、自身のアプリケーションコード全体をSSPLで公開する義務は発生しません。自身のアプリケーションコードのライセンスは、自身の希望するライセンス（プロプライエタリ、他のオープンソースライセンスなど）で配布できます。
- ただし、ドライバやツール自体を改変して再配布する場合は、それぞれのライセンス（例えばApache License）に従って、ソースコード開示やライセンス表記などの義務が発生する場合があります。

これらの利用シーン別解説からわかるように、SSPLでライセンスされたMongoDB Community Editionは、外部にサービスとして提供する形態での利用には強い制約があるという点が最も重要です。特に、SaaSのバックエンドとして利用したり、顧客向けにマネージドデータベースサービスとして提供したりする場合は、SSPLの条項13に注意し、通常は商用ライセンスやMongoDB Atlasの利用を検討する必要があります。

よくある疑問と誤解

MongoDBのライセンス、特にSSPLに関しては、様々な疑問や誤解が生じやすいです。ここでは、よくある疑問とその回答をまとめます。

Q1: SSPLは本当にオープンソースではないのですか？

A1: 多くのオープンソースコミュニティやOSI（Open Source Initiative）の定義においては、SSPLはオープンソースライセンスとは見なされていません。SSPLはソースコードは公開されており「Source Available」ではありますが、特定の分野（サービス提供）におけるプログラムの使用を制限する条項（条項13）が含まれているため、OSIが定める「オープンソースの定義」のいくつかの基準を満たしません。例えば、「特定の分野のプログラムの使用を差別しない」「派生ソフトウェアの配布に特定の技術を制限しない」といった基準に反すると解釈されています。MongoDB Inc.自身も、SSPLを「オープンソースライセンス」とは呼ばず、「Source Available License」と表現することが多いです。

Q2: Community Editionは完全に無料で使えるのですか？

A2: 自社内システムでの利用や開発・テスト用途であれば、基本的に無料で利用できます。しかし、外部にネットワーク経由で「サービスとして提供する」場合には、SSPLの条項13が適用され、非常に厳しいソースコード開示義務が発生します。この義務を履行しない限り、サービス提供目的でのCommunity Editionの利用はライセンス違反となります。したがって、「完全に無料」という表現は、利用形態によっては正しくありません。サービス提供目的の場合は、実質的に商用ライセンスやAtlasの利用が必要となり、費用が発生します。

Q3: 自社内で使うだけならSSPLは関係ないのですか？

A3: 基本的には関係ありません。外部にサービスとして提供しない、純粋な社内システムや開発・テスト用途での利用であれば、SSPLの条項13は適用されません。この場合、Community Editionを無料で問題なく利用できます。ただし、将来的にそのシステムの一部を外部にサービスとして提供する可能性が少しでもある場合は、SSPLの制約を考慮に入れる必要があります。

Q4: AGPLv3とSSPLの「ネットワーク越し」の定義は同じですか？

A4: 「ネットワーク越しに機能を提供する」という行為そのものを指す点では似ていますが、その結果として生じる開示義務の「対象範囲」が大きく異なります。AGPLv3は、そのAGPLv3ライセンスを受けたソフトウェア本体のソースコード開示を求めます。一方、SSPLは、サービス提供に使用される全てのソフトウェア（OS、ミドルウェアなども含む可能性）のソースコード開示を求めます。SSPLの方が、ネットワークサービス提供という行為に対する制約が圧倒的に広範で厳しいと言えます。

Q5: なぜMongoDBはAGPLv3からSSPLに変更したのですか？

A5: 主な理由は、クラウドベンダーによるMongoDBの「ただし乗り」問題に対応するためです。AGPLv3では、クラウドベンダーがMongoDB Community Editionをそのまま利用し、自社プラットフォーム上でマネージドサービスとして提供しても、MongoDB本体のソースコード開示以外の大きな義務が発生せず、MongoDB Inc.のビジネス（特にMongoDB Atlasや商用ライセンス）を圧迫するという状況がありました。SSPLは、サービス提供に利用するシステム全体をSSPLのコピーレフトの対象とすることで、MongoDB Inc.以外の企業がMongoDB Community Editionを使ってマネージドサービスビジネスを展開することを事実上不可能にする目的で設計されました。これにより、MongoDB Inc.は自社の商用サービスやライセンス販売への誘導を強化しています。

Q6: SSPLライセンスのソフトウェアを改変して使っても良いですか？

A6: SSPLは、GPLv3をベースとしているため、改変の自由は認められています。ただし、改変版を配布する場合や、改変版をネットワーク経由でサービスとして提供する場合には、SSPLのコピーレフト条項（特に条項13）に従って、改変版を含む関連するソフトウェアのソースコードを開示する義務が発生します。

これらの疑問への回答からも、SSPLが特に「サービス提供」という利用形態に対して厳しい制約を課すライセンスであることが理解できるかと思います。MongoDB Community Editionを利用する際は、自身の利用形態が「サービス提供」に該当しないかを十分に確認することが不可欠です。

結論：MongoDBライセンスを正しく理解し、適切な選択を

MongoDBは、その優れた機能と開発者フレンドリーな特性により、多くのプロジェクトで採用されています。しかし、そのライセンス、特にServer Side Public License（SSPL）への変更は、特に商用利用やサービス提供を検討しているユーザーにとって、注意深く理解すべき重要なポイントです。

この記事で解説したように、MongoDB Community Editionに現在適用されているSSPLv1は、かつてのAGPLv3と比較して、ネットワーク経由でソフトウェアをサービスとして提供する場合のソースコード開示義務の範囲が格段に広くなっています。SSPLの条項13は、サービス提供に使用される全てのソフトウェア（OS、ミドルウェア、管理ツールなどを含む可能性）のソースコードをSSPLまたは互換ライセンスで公開することを求める、非常に厳しい内容です。

このSSPLの特性により、以下の点が明確になります。

自社内システムや開発・テスト用途: 外部にサービスとして提供しない形態であれば、SSPLの制約を受けることなく、MongoDB Community Editionを無料で利用できます。
SaaSのバックエンドやマネージドサービス提供: MongoDB Community Editionをそのまま利用してこれらのサービスを提供することは、SSPLの条項13により、現実的に不可能なほど広範なソースコード開示義務が発生するため、実質的に不可能です。

したがって、MongoDBをサービス提供目的で利用したい場合は、以下のいずれかの選択肢を検討する必要があります。

MongoDB Enterprise Advanced（商用ライセンス）の購入: SSPLの制約を受けずに、商用契約に基づいてMongoDBを利用できます。高度なエンタープライズ機能も利用可能です。
MongoDB Atlasの利用: MongoDB Inc.が提供するフルマネージドサービスを利用します。ライセンス問題を気にすることなく、運用負担を軽減しながらMongoDBをサービスとして利用できます。
他のデータベースの検討: SSPLのライセンス条項を受け入れられない場合や、コスト面などの理由から商用ライセンスやAtlasの利用が難しい場合は、他のNoSQLデータベース（例えばPostgreSQL with JSONB, Cassandra, Couchbase, DocumentDB, Cosmos DBなど）の利用を検討することも選択肢の一つです。

MongoDBのライセンス変更は、オープンソースソフトウェアの開発元が直面する「ただし乗り」というビジネス上の課題に対する一つの回答として行われました。しかし、これによりMongoDB Community Editionの利用可能な範囲は、特にサービス提供という観点からは大きく制限されることになりました。

MongoDBをプロジェクトに採用する際は、「オープンソースだから無料・自由に使える」という安易な考え方ではなく、どのような形態で利用するのかを明確にし、SSPLの条項13が自身の利用形態にどのように影響するかを慎重に評価する必要があります。必要に応じて、法務部門やライセンスの専門家、あるいはMongoDB Inc.の担当者に相談することをお勧めします。

ライセンスを正しく理解し、自社のビジネスやプロジェクトの要件、そして利用形態に合った適切なライセンスまたはサービスを選択することが、法的なリスクを回避し、安心してMongoDBを活用するための第一歩となります。

参考文献/補足情報:

Server Side Public License (SSPL): https://www.mongodb.com/licensing/server-side-public-license (公式ページ)
GNU Affero General Public License v3.0: https://www.gnu.org/licenses/agpl-3.0.html (公式ページ)
Open Source Initiative (OSI): https://opensource.org/ (オープンソースの定義など)
MongoDB Licensing FAQs: https://www.mongodb.com/licensing/faqs (公式FAQ)

これらの情報源も参照しながら、ご自身の状況に合わせてさらに詳細な情報を確認してください。