はじめに
クラウドプラットフォームによるオープンソースソフトウェアの商用利用が急速に拡大する中、従来のオープンソースライセンスでは対応できない「クラウドプロバイダー問題」を解決するために生まれたSSPL(Server Side Public License)。
MongoDB社が2018年に開発したこのライセンスは、AGPL v3をさらに強化し、クラウドプロバイダーによるマネージドサービス提供を実質的に禁止する革新的なライセンスです。
オープンソースの自由を守りつつ、開発企業のビジネスモデルを保護する新しい試みとして注目を集めています。
SSPL(Server Side Public License)ライセンスとは
SSPLは、MongoDB社によって2018年10月に開発された最も制限的なオープンソース系ライセンスです。
(OSI承認を受けていないため、厳密にはオープンソースライセンスではありません。)
正式には「Server Side Public License」と呼ばれ、GNU AGPL v3をベースとしながら、クラウドプラットフォームによるマネージドサービス提供に対してより厳格な制限を課します。
「クラウドプロバイダーからオープンソース企業を守る」という明確な目的を持つ、商用志向の強いライセンスです。
主な特徴
1. AGPL v3を超える最強の制限
SSPLは「AGPL v3よりも厳格」な制限を持ちます:
- AGPL v3の全条項を継承:ネットワーク経由でのサービス提供時のソース公開義務
- サービス提供プラットフォームの公開義務:マネージドサービス提供時のインフラコード公開
- 実質的なクラウドプロバイダー排除:AWS、Azure、GCPでの商用サービス提供の阻止
2. 第13条の強化(Service Source Code Provision)
AGPL v3の第13条をさらに強化:
“SSPLライセンスのプログラムをサービスとして提供する場合、そのサービスを提供するために使用するすべてのプログラムのソースコードを公開しなければならない”
3. マネージドサービス対策
特にクラウドプラットフォームを標的とした条項:
- Database-as-a-Service(DBaaS)の禁止:MongoDB Atlas以外の類似サービス提供禁止
- インフラストラクチャコードの公開義務:オーケストレーション、監視、バックアップシステム等
- 商用クラウドでの提供実質禁止:競合サービス提供の事実上の阻止
4. MongoDB社の戦略的意図
- AWS DocumentDB対策:MongoDB互換サービスへの対抗
- 収益保護:MongoDB Atlasへの顧客誘導
- 競合排除:大手クラウドプロバイダーによる無償提供阻止
SSPLライセンスの全文
SSPLライセンスは比較的短く(約2,000語)、AGPL v3をベースに第13条を大幅に強化した構造になっています。公式の全文はServer Side Public Licenseで確認できます。
主要セクションの構成:
SERVER SIDE PUBLIC LICENSE
Version 1, October 16, 2018
Copyright © MongoDB, Inc.
TERMS AND CONDITIONS
1. License Grant and Conditions.
2. Copyleft.
3. Service Source Code. ← SSPL固有の核心条項
4. Offering the Program as a Service. ← クラウドサービス規制
5. Termination.
6. Disclaimer of Warranties.
7. Limitation of Liability.
8. Litigation.
9. Miscellaneous.
※日本語での解説は各所で提供されていますが、公式な翻訳は存在しません。
何ができるのか
自由な利用(制限付き)
- 個人利用・研究利用:完全に自由
- 企業内部利用:外部提供しなければ制限なし
- 改変・カスタマイズ:ソース公開前提で可能
- オンプレミス展開:顧客環境での利用は自由
できないこと(実質的制限)
- マネージドサービス提供:DBaaS、PaaS等での商用提供禁止
- クラウドプラットフォーム統合:AWS、Azure、GCP等での類似サービス禁止
- 競合サービス構築:元のソフトウェアと競合するサービス提供禁止
- インフラコード秘匿:サービス提供時のインフラ関連コードの非公開禁止
SSPLのコピーレフトの仕組み
SSPLの極めて強力なコピーレフトメカニズム:
1. 拡張されたサービス提供の定義
従来のAGPL v3:
- ネットワーク経由でのプログラム機能提供
SSPL:
- プログラム機能の提供
- サービス提供に必要なすべてのソフトウェアスタック
- 運用・監視・管理ツール
- データベース・ストレージシステム
2. Service Source Code(第3条)
SSPLソフトウェアをサービスとして提供する場合:
必要なソースコード公開範囲:
├── SSPLライセンスのプログラム本体
├── 管理・運用ツール(監視、バックアップ、レプリケーション)
├── オーケストレーションシステム(Kubernetes、Docker Compose等)
├── ロードバランサー・プロキシ
├── 認証・認可システム
├── データ処理パイプライン
└── ユーザーインターフェース(Web UI、API等)
3. 商用クラウドでの提供阻止メカニズム
例:AWS DocumentDB(MongoDB互換サービス)
↓
SSPLのMongoDB使用時:
- DocumentDBのすべてのソースコード公開必須
- AWS内部のインフラ管理コード公開必須
- 監視・運用システムの公開必須
↓
実質的に提供不可能(企業機密の公開リスク)
注意すべき点
1. オープンソースとして認められていない
Open Source Initiative(OSI):
- SSPLはOSI承認ライセンスではない
- 「オープンソース」を名乗れない
- 「Source Available License」として分類
Free Software Foundation(FSF):
- 自由ソフトウェアとして認定されていない
- 他のオープンソースプロジェクトでの利用困難
2. ライセンス互換性の極度の限定
互換性のあるライセンス:
- SSPL同士のみ(実質的に)
- 一部のパブリックドメイン
互換性のないライセンス:
- AGPL v3(SSPLの追加条項により実質的に非互換)
- GPL v3/v2
- Apache-2.0、MIT、BSD
- ほぼ全てのオープンソースライセンス
3. 企業採用における法的リスク
不明確な適用範囲:
- 「サービス提供」の境界が曖昧
- インフラコード公開範囲の解釈困難
- 法廷での争いが未発生(判例なし)
コンプライアンス負荷:
- 継続的なソースコード公開管理
- 競合企業への技術情報開示
- 顧客情報処理ロジックの公開リスク
4. ビジネスモデルへの根本的制約
影響を受けるビジネス:
- Database-as-a-Service(DBaaS)
- Platform-as-a-Service(PaaS)
- Software-as-a-Service(SaaS)(SSPLコンポーネント使用時)
- マネージドクラウドサービス
他のライセンスとの比較
ライセンス | OSI承認 | SaaS制限 | インフラ公開 | クラウド影響 | 企業採用 |
---|---|---|---|---|---|
SSPL | なし | 極厳格 | 必須 | 提供禁止 | 困難 |
AGPL v3 | あり | 厳格 | 不要 | 制限あり | 困難 |
GPL v3 | あり | なし | 不要 | 制限なし | 普通 |
Apache-2.0 | あり | なし | 不要 | 制限なし | 容易 |
MIT | あり | なし | 不要 | 制限なし | 容易 |
実際の使用例
SSPLライセンスを採用している主要プロジェクト:
MongoDB社製品
- MongoDB Community Server – NoSQLデータベース(v4.0以降)
- MongoDB Compass – GUI管理ツール
- MongoDB Tools – 各種ユーティリティ
注意:多くの企業がSSPLライセンス採用に伴い、オープンソースコミュニティとの関係悪化や代替プロジェクトの出現を経験しています。
開発者として気をつけること
プロジェクトでSSPLライセンスを採用する場合
1. ライセンス明示の徹底
# プロジェクトルートに配置
curl https://www.mongodb.com/licensing/server-side-public-license/faq > LICENSE
2. ソースファイルへのヘッダー追加
/*
* Copyright (C) [year] [fullname]
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the Server Side Public License, version 1,
* as published by MongoDB, Inc.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* Server Side Public License for more details.
*
* You should have received a copy of the Server Side Public License
* along with this program. If not, see
* <http://www.mongodb.com/licensing/server-side-public-license>.
*/
3. README.mdでの明確な警告
## License
This project is licensed under the Server Side Public License v1.0 (SSPL-1.0) - see the [LICENSE](LICENSE) file for details.
### ⚠️ CRITICAL WARNING FOR SERVICE PROVIDERS
This is **NOT** an OSI-approved open source license. If you provide this software as a service:
**YOU MUST DISCLOSE:**
- Complete source code of this program
- **ALL management, orchestration, and monitoring software**
- **ALL supporting infrastructure software**
- Database systems, load balancers, proxies
- Any software used to provide the service
**PROHIBITED ACTIVITIES:**
- Offering this software as a managed cloud service
- Providing Database-as-a-Service using this software
- Creating competing managed services
### Commercial Alternative
For managed service providers and enterprises, contact [your-company] for commercial licensing options.
### Freedom to Use (with restrictions)
- Personal and internal business use: ✅ Allowed
- Modifications and improvements: ✅ Allowed (source disclosure required)
- On-premises deployment for customers: ✅ Allowed
- Managed cloud services: ❌ **PROHIBITED without source disclosure**
4. Service Source Code 提供システム
# Flask での Service Source Code 提供例
from flask import Flask, render_template, send_file
import os
app = Flask(__name__)
@app.route('/service-source-code')
def service_source_code():
"""SSPL第3条に基づくService Source Code提供"""
return render_template('service_source.html', {
'components': [
{
'name': 'Application Source',
'description': 'Main application source code',
'download_url': '/download/app-source.tar.gz',
'repository': 'https://github.com/yourorg/yourapp'
},
{
'name': 'Infrastructure Code',
'description': 'Kubernetes, Docker, and orchestration',
'download_url': '/download/infra-source.tar.gz',
'repository': 'https://github.com/yourorg/yourapp-infra'
},
{
'name': 'Monitoring Systems',
'description': 'Prometheus, Grafana configurations',
'download_url': '/download/monitoring-source.tar.gz',
'repository': 'https://github.com/yourorg/yourapp-monitoring'
},
{
'name': 'Database Systems',
'description': 'Database setup and management scripts',
'download_url': '/download/database-source.tar.gz',
'repository': 'https://github.com/yourorg/yourapp-database'
}
]
})
@app.route('/sspl-compliance-check')
def sspl_compliance():
"""SSPL遵守状況の確認ページ"""
return {
'license': 'SSPL-1.0',
'service_provider': 'Your Company Name',
'last_updated': '2024-01-15',
'source_code_available': True,
'service_source_available': True,
'contact_email': 'legal@yourcompany.com'
}
SSPLライセンスのソフトウェアを利用する場合
1. 利用前の厳重な検討
企業でのSSPL利用判断フレームワーク:
Phase 1: ライセンス分析
├── OSI承認ライセンスではないことを確認
├── オープンソースポリシーとの整合性確認
├── 法務部門との詳細協議
└── コンプライアンスチームとの調整
Phase 2: 技術的影響評価
├── サービス提供予定の有無確認
├── 必要なソースコード公開範囲の特定
├── インフラストラクチャコード公開の影響評価
└── 競合優位性への影響分析
Phase 3: ビジネス影響評価
├── 将来的なサービス化計画との衝突確認
├── パートナー・顧客への影響評価
├── 代替ソリューションのコスト比較
└── 最終的な採用可否決定
2. 社内利用時の注意点
// 社内システムでのSSPL利用例
// MongoDB使用のCRMシステム
const config = {
// 社内のみ利用の場合は制限なし
internal_use_only: true,
// ただし、以下の場合は即座にSSPL義務発生
external_access: {
customer_portal: false, // 顧客向けポータルなし
partner_api: false, // パートナー向けAPIなし
vendor_access: false, // 外部ベンダーアクセスなし
subsidiary_access: false // 子会社アクセスも要注意
},
// 将来的なサービス化の可能性
future_saas_plans: false, // SaaS化予定なし
license_compliance: {
license_type: 'SSPL-1.0',
compliance_contact: 'legal@company.com',
last_review_date: '2024-01-15'
}
};
3. 代替ライセンス検索の強化
# MongoDB代替の検索例
# PostgreSQL + JSONB機能
npm install pg
# または
# CouchDB(Apache-2.0)
npm install nano
# または
# ArangoDB(Apache-2.0)
npm install arangojs
# Elasticsearch代替
# OpenSearch(Apache-2.0)
npm install @opensearch-project/opensearch
# または
# Apache Solr(Apache-2.0)
npm install solr-node
4. デプロイ時のライセンス監視
# docker-compose.yml でのライセンス明示
version: '3.8'
services:
mongodb:
image: mongo:4.4 # SSPL-1.0ライセンス
environment:
- LICENSE_WARNING=SSPL-1.0_NOT_OSI_APPROVED
labels:
- "license=SSPL-1.0"
- "osi_approved=false"
- "commercial_use=restricted"
- "service_provision=prohibited"
app:
build: .
environment:
- SSPL_DEPENDENCY=mongodb
- SERVICE_PROVISION=false
depends_on:
- mongodb
AGPL v3との主要な違い
1. オープンソース認定の有無
- AGPL v3:OSI承認オープンソースライセンス
- SSPL:非OSI承認、Source Availableライセンス
2. Service Source Code条項
- AGPL v3:プログラム本体のソース公開のみ
- SSPL:サービス提供に使用するすべてのソフトウェアスタック公開必須
3. 商用クラウドへの影響
- AGPL v3:クラウドでの提供は制限されるが可能
- SSPL:大手クラウドプロバイダーでの提供は実質不可能
4. ライセンス互換性
- AGPL v3:GPL v3との一方向互換性
- SSPL:他のオープンソースライセンスとほぼ非互換
5. 法的確実性
- AGPL v3:確立された法的枠組み
- SSPL:法的先例なし、解釈に曖昧さ
まとめ
SSPL(Server Side Public License)は、クラウド時代におけるオープンソース企業の収益保護を目的とした革新的だが論争の多いライセンスです。AGPL v3を超える制限により、実質的にクラウドプロバイダーによるマネージドサービス提供を阻止します。
SSPLを選ぶべき場合:
- クラウドプロバイダーによる競合サービス提供を阻止したい
- デュアルライセンス戦略で収益を最大化したい
- オンプレミス・エンタープライズ市場に集中したい
- 自社マネージドサービス(MongoDB Atlas等)への顧客誘導を図りたい
SSPLを避けるべき場合:
- OSI承認オープンソースライセンスのみ使用したい
- 将来的にSaaS/マネージドサービス提供を検討している
- クラウドファーストの開発戦略を取っている
- オープンソースコミュニティとの良好な関係を重視する
- ライセンス互換性を重要視するプロジェクト
SSPLは「オープンソース企業の収益保護」という明確な目的を持つ一方で、従来のオープンソースの理念とは異なる方向性を示しています。採用にあたっては、技術的な適合性だけでなく、ビジネス戦略、法的リスク、コミュニティとの関係性を総合的に評価する必要があります。特に「OSI未承認」という事実は、多くの企業のオープンソース戦略と衝突する可能性があり、慎重な判断が求められます。
用語解説
※1 Server Side Public License(SSPL):MongoDB社が開発したライセンス。AGPL v3をベースに、サービス提供時のインフラストラクチャコード公開義務を追加したもの。
※2 Service Source Code:SSPLの核心概念。サービス提供に使用するすべてのソフトウェア(監視、管理、オーケストレーション等)のソースコードを指す。
※3 OSI(Open Source Initiative):オープンソースライセンスの承認・認定を行う非営利組織。SSPLは同組織の承認を得ていない。
※4 Source Available License:ソースコードは公開されているが、OSI承認を得ていないライセンスの総称。商用利用に制限があることが多い。
※5 Database-as-a-Service(DBaaS):データベースをクラウドサービスとして提供するビジネスモデル。MongoDB Atlas、AWS RDS等が該当。
※6 SaaS の抜け穴:従来のGPLライセンスでは、ソフトウェアをネットワーク経由でサービス提供してもソースコード公開義務が発生しない問題。AGPLとSSPLはこれを解決する。
この記事は一般的な情報提供を目的としており、法的アドバイスではありません。SSPLライセンスの適用については、必ず法務専門家にご相談ください。また、SSPLはOSI承認ライセンスではないため、多くの企業のオープンソースポリシーに抵触する可能性があります。