OSSライセンスの歴史概観
public.icon
from OSS ライセンスの最近の潮流: PolyForm License について
#OSSライセンス
1980~2000: "Free Software" License
Unix が私有化と商用利用によってバラバラになり、改善が共有されなくなったことによる反省から始まった
GNU/Linux に代表され、General Public License (GPL)が中核をなすが、GPLにも課題があった
GPLはソフトウェアがユーザー端末で実行されることを前提としている
2000~2020: "Open Source" License
MIT, Apache v2, BSD Licenseなどが台頭した
これらは最も一般的なライセンス
2020 年の時点でOSS 全体の半数以上はこの２つのいずれかを採用
この時期にCOSS企業の台頭が始まり、AWSによるstrip-mining問題なども起こってきた
2020~ "Source Available" License
AWSによるstrip-mining問題に対応した「Commons Clause」は、厳密にはOpen Source Initiative (OSI)の言う、「OSSライセンス」ではなくなってしまった
単体ではなく、他のOSSライセンス (Apache 2.0, MIT など) と一緒に利用する
たとえば "MIT + Commons Clause" で一つのライセンス
内容は、「当該ソフトウェアの価値を、実質的にそのまま提供するようなサービスで利益を得てはならない」という一文を追加するものです。
"実質的に" (substantially) ってなんやねんと思いましたが、法律家的にはよくある言い方らしいです。
もっとわかりやすく言うと、開発元のビジネスと競合してはならない と言っているのとほぼ同義です。多分
自分の観測範囲だと、ビットコイン関連 OSS にいくつか使われています。例: lily-wallet, Coldcard Wallet
SSPL
SSPL は、 MongoDB が 2018 年に独自に作成したライセンスです。
General_Public_License_(GPL), Affero General Public License (AGPL) を更に強力にしたようなもので、「当該ソフトウェアの機能をサービスとして提供する場合、その周辺ソフトウェア (管理用ツールなど) も公開しなくてはならない」というような内容です。
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 です。
独自のライセンスの策定は大手以外には難しく、始まったばかりのプロジェクトが採用できるようなものではありません。
さらに言うまでもありませんが、独自ライセンスを採用するソフトウェアが増えるとその内容を理解するのに時間を割かなくてはならないため導入のコストが上がります。(あるいは誰も読まなくなります。)
そのため、このような問題に対処できる統一的な枠組みが求められているわけです。