2026年5月30日土曜日

SSPL（Server Side Public License）は、MongoDB社が2018年に策定した強力なコピーレフト系ライセンスです。

 SSPL（Server Side Public License）は、MongoDB社が2018年に策定した強力なコピーレフト系ライセンスです。AGPLv3をベースにしていますが、SaaS／マネージドサービス提供に対して極めて厳しい公開義務を課す点が最大の特徴です。

核心ポイント

  • サービス提供時の全面公開義務
    SSPLソフトを使って第三者向けサービスを提供する場合、
    そのソフト本体だけでなく、

    • 管理ツール

    • UI

    • API

    • オーケストレーション

    • 監視・バックアップ

    • インフラ関連コード
      など、サービス全体を構成するコード一式をSSPLで公開する必要があります。

  • OSI非承認（オープンソースではない扱い）
    OSI（Open Source Initiative）は、SSPLを
    「特定の利用形態（クラウド/SaaS）を差別している」
    としてオープンソースライセンスと認めていません。

  • クラウド事業者対策が目的
    AWSなどがOSSをそのままマネージドサービス化することへの対抗策。
    実質的に「無断SaaS化」を強く牽制します。

実務的な意味（重要）

  • 社内利用・オンプレ配布
    → 通常のAGPLに近い感覚で使える

  • SaaS・クラウドで提供
    → 自社の管理・運用コードまで公開義務が発生する可能性あり（非常に重い）

代表例

  • MongoDB（Community）

  • Elasticsearch / Kibana（過去の一時期）

  • Redis（2024年にSSPL系へ移行後、2025年にAGPLへ再変更）

一言で言うと：

SSPLは「SaaS化したら自社サービスの中身を全部公開せよ」という、事実上“クラウド封じ”のライセンス

SSPLが抑止したいのは、次のような**「中身は他人のOSS、利益は自社」というサービス形態**です。

  • Amazon Web Servicesが、MongoDBをそのままマネージドDBとして提供
    OSS本体は公開のまま使い、運用・自動化・監視などの付加価値部分だけを非公開で囲い込む形。

  • クラウド事業者が検索エンジンや分析基盤を“◯◯ as a Service”として提供
    OSS作者には還元されず、利用者は公式かどうか区別がつかない。

  • OSSを改変せず、ラッパーだけ作ってSaaS化するケース
    技術的貢献は最小限でも、商業的リターンは最大化できてしまう。

SSPLはこうした状況に対し、
「サービスとして使うなら、裏側も含めて全部出してください」
という条件を突きつけ、安易なマネージド化を思いとどまらせる思想です。

投稿者