SSPLが良くない理由
- SSPL（Server Side Public License）は、すべてのユーザー、企業、そして一般的にコミュニティにとってひどいライセンス
- SSPLライセンスの製品はオープンソースではなく、クラウドおよびマネージドサービスの競合を潰し、ホスティング価格を引き上げ、オープンソースを壊すことを目的としている
- SSPLの目的は、大企業と戦うことよりも、投資家に資金を還元することに近いのかもしれない
SSPLとは何か
- SSPLは2008年にMongoDB, Incによって導入され、MongoDBの利用を制限するためのライセンス
- Elasticsearch、Kibana、Graylogのような製品も現在はSSPLライセンスを使用している
- 第13条によれば、製品を直接顧客に提供したい場合は、「サービスのソースコード」を公開しなければならない
SSPLがみんなにとって良くない理由
- SSPLは、一部の悪質なクラウド企業がコミュニティに貢献せず利益を得るのを防ぐための良い解決策として提示されたが、実際には自由への脅威であり、競合を潰すライセンス
- このライセンスは、かつてオープンソースだった製品を「無料」という偽りの理念の背後に隠し、商用製品の中に閉じ込めるにすぎない。今ではこのようなソフトウェアを「Freemium」ソフトウェアと呼ぶべきかもしれない
- MongoDB、Elasticsearch、Kibana、Graylogはもはやオープンソース製品ではなく、これらの企業はいまや顧客に製品を提案できる相手を完全に決められる。これは競合を潰すことになる
- 競合なしで自社のクラウドホスティングソリューションを提供できるようになり、ソースコードを公開することなく、自分たちが定めた料金で競争とイノベーションを殺せる
- これは、顧客である私たちにとって、もはやクラウドプロバイダーを選ぶ権限がないことを意味する
- 機械的にホスティング価格は上昇し、私たちの唯一の選択肢は、自前のインフラでホスティング部分を管理する専任チームを置くこと程度になる。まさにここ数年、クラウドホスティングソリューションによって避けようとしてきたことだ
SSPLを使っている企業
- MongoDB製品は2018年からSSPLライセンスを使用しており、その背後にはMongoDB, Incがある
- Elasticsearch製品は2021年からSSPLライセンスを使用しており、その背後にはElastic NVがある
- Graylog製品は2020年からSSPLライセンスを使用しており、その背後にはGrayLog, Inc.がある
私たちが自分自身に問うべきいくつかの質問
- もはやオープンソースを使っていない企業が、どうして他者に「コミュニティへ還元しろ」と求められるのか?
- 自社のクラウドサービスのソースコードを公開しない企業が、どうして他者にソースコードの公開を求められるのか?
- 非オープンソースライセンスを使いながら、オープンソースが自社のDNAの一部だと宣言する企業は、どうしてそんなことができるのか?
- 3000人を超える従業員のうち、自分の業務やソースコードをコミュニティと共有している人は何人いるのか?（ネタバレ: ずっと少ない）
- コミュニティと共有したい技術企業なのか、それとも投資家の利益を増やしたいセールス企業なのか?
SSPLに関する誤った主張
- 「私はクラウドプロバイダーではないから関係ない」という主張については、実際には誰もがこの問題に関係していることを認識すべき
- 「これらの企業は生き残るためにお金が必要だ」という主張については、オープンソースでお金を稼ぐこと自体が悪いわけではないが、SSPLは正しい解決策ではないことを理解すべき
- 「競合は今でも存在する。SSPLは交渉可能だ」という主張は、実際には市場を支配する企業が競合の価格と条件を決められるようになることを意味する
- 「SSPLは大手クラウド事業者と戦うものであり、小規模事業者には良い」という主張については、SSPLが実際には小さな競合を倒産させ、消滅させうることを認識すべき
オープンソースプロジェクトへの助言
- SSPLは最初は良い解決策のように見えるかもしれないが、その過ちを犯さないことを勧める
- 一部のクラウドプロバイダーに問題があるなら無視はできず、私たち全員で一緒に戦わなければならない。オープンソースの世界から外れて戦うのは良い方法ではない
- 収益性が必要なら、エンタープライズライセンスとプレミアムサポートを利用すること: 「サポートが必要であれば、私たちにはそのための最高のチームがあります。」
- コピーレフトライセンスを使い、企業がコミュニティへ還元できるようにすること: 「私たちのコードを修正したなら、コミュニティと共有してください」
- それでもSSPLライセンスを選ぶなら.. あなたは :
- 多くの独立した貢献者や大企業の従業員による貢献者を失う
- オープンソースソフトウェアを改善するために努力してきた貢献者を裏切る
- オープンソースの世界を去り、部分有料の（Freemium）ソフトウェアを開発することになる
- 製品を非常に悪い評判と結び付ける
- 世界中で製品の普及を助けてくれる数多くの多様なプレイヤーの恩恵を失い、その結果プレミアムサポートの必要性が高まる
3件のコメント
オープンソースだからこそ選べますが、オープンソースだからこそ選択肢から外されることもありますよね。
AWSがMongoDBを持っていってDynamoDBを作ったことがきっかけで出てきたライセンスなのでしょうが、オープンソースが好きな方々から見るといぶかしく感じられるかもしれません。
AGPL と比較してみるのも面白そうですね。
https://sktelecom.github.io/guide/use/obligation/agpl-3.0/
ドメイン名とサイト名
SSPL is BADが示すとおり、意図を持って作られたウェブサイトです。やや飛躍が大きい面もあります。以下のHacker Newsの意見とあわせてご覧ください。
Hacker Newsの意見
SSPLに対する原則的な反対意見はあるものの、その背景への理解も存在する。第13条の描写は客観的な分析というより扇情的な意図を持っている、という批判もある。
SSPLは利用者にとって有害であり、独占を促進し、コミュニティ参加を減らして、最終的にはすべての利用者に影響を及ぼすという主張。
人々がお金を稼ごうとするのは当然であり、SSPLプロジェクトを使わないと選ぶこともできる。SSPLライセンスで公開されたソフトウェアは、何もないよりはましだという見方。
現在のエコシステムは10年前と大きく異なっており、小規模企業が競争の中で生き残り、成長できる道が必要だという意見。BSL（Business Source License）のようなライセンスは完璧ではないかもしれないが、健全な中間路線を探る試みと見ることができる。
SSPLを批判しながらAGPLに触れていないのはおかしい、という意見。自由ソフトウェアを使いたいが、貢献はしたくない人々への指摘。
どちらか一方に偏らず、個々のケースごとに異なるアプローチを取るべきだという意見。SSPLはクラウドの巨大企業に対抗して生き残ろうとする一部の企業には有益かもしれないが、貢献者を利用しようとする一部の企業にとっては有害かもしれない。
MongoDB、Elasticsearch、Graylogの製品を顧客に直接提案することが禁止されている。SSPLの「直接」という語が法的な争点の余地を与えており、その点を人々が懸念している。
FSL（Functional Source License）は、2年後にApache 2.0またはMITへ自動的に変換される良い代替ライセンスである。シンプルで、ソースを公開しつつ、SaaS企業が事業を成り立たせられる合理的な方法を提供する。
SSPLが2008年に導入されたという誤情報の訂正。実際には2018年に導入された。
著作権の未来に関する一面的な見方への批判。