OSSライセンスの歴史概観
public.icon
1980~2000: "Free Software" License
Unix が私有化と商用利用によってバラバラになり、改善が共有されなくなったことによる反省から始まった 2000~2020: "Open Source" License
これらは最も一般的なライセンス
2020 年の時点でOSS 全体の半数以上はこの２つのいずれかを採用 2020~ "Source Available" License
たとえば "MIT + Commons Clause" で一つのライセンス
内容は、「当該ソフトウェアの価値を、実質的にそのまま提供するようなサービスで利益を得てはならない」という一文を追加するものです。
もっとわかりやすく言うと、開発元のビジネスと競合してはならない と言っているのとほぼ同義です。多分
SSPL は、 MongoDB が 2018 年に独自に作成したライセンスです。 SSPL, Commons Clause の問題点
SSPL, Commons Clause が、オープンソースの定義から外れてしまった理由は Open Source Initiative (OSI) の定義する「オープンソースソフトウェア」の定義の第９条 "ライセンスは他のソフトウェアに対して制限を加えるようなものであってはならない" に違反するためです。 いずれの場合も、ライセンスが影響する範囲がソフトウェアから、その周辺を含む "サービス" 全体になるためです。これは GPL、 AGPL との明確な違いです。
例えば、 MongoDB で言えば、普通の Web サービスの背後に MongoDB を使うことは問題ありませんが、ユーザーが自由なデータをそこに保存できるようにしたらアウトになります。これは、DB 自体ではなく、その「使いかた」つまり周辺サービスに依存します。
さらに、 SSPL の場合は、共有すべき範囲も周辺サービスに広げています。 AGPL をより広範囲にしたようなイメージです。
OSS であるかどうかって重要なの？と思うかもしれませんが、
各 Linux の Distribution が MongoDB の配布を取りやめたのはまさにそのためであるといえば、重要性がわかるのではないでしょうか
独自ライセンスの台頭
上記のような問題から、ごく最近大手 COSS に SSPL や Commons Clause を廃して独自ライセンスを策定するところが現れました。具体的には Redis と Elastic です。 独自のライセンスの策定は大手以外には難しく、始まったばかりのプロジェクトが採用できるようなものではありません。
さらに言うまでもありませんが、独自ライセンスを採用するソフトウェアが増えるとその内容を理解するのに時間を割かなくてはならないため導入のコストが上がります。(あるいは誰も読まなくなります。)
そのため、このような問題に対処できる統一的な枠組みが求められているわけです。