Elastic社のブログをきっかけに、最近見かける新しいライセンスについて個人的に調べてみた。私は専門家ではないので要注意。公開情報も隅々まで追えているわけではないし。
なお一部ライセンスはOpen Source Initiative (OSI)による承認を受けていないので、ここではオープンソースライセンスではなく単に「ライセンス」と書くことにする。
新しいライセンスが誕生している背景
- 従来のオープンソースライセンスが再頒布以外の利用をあまり想定していなかった。
- Open-core modelないし完全オープンソース戦略を採る企業が自衛策を必要とした。
- 既存のライセンスが難解なため、理解しやすいライセンスが求められた。
- OSS活動を収入に繋げるためのモデルが試行錯誤されている。
新しいライセンスを導入しているプロジェクト（一例）
| プロジェクト | ライセンス |
|---|---|
| Elastic | SSPLと独自ライセンス |
| MongoDB | SSPL |
| Redis Modules | 独自ライセンス |
| MariaDB | BSL |
| Artifex | AGPL3と独自ライセンス |
| Husky v5 | License Zero Parity 7.0.0 and MIT (contributions) with exception License Zero Patron 1.0.0 |
各種ライセンス
GNU Affero General Public License (AGPL3)
言うほど新しくない。2010年に公開されたnippondanji氏のスライドを参照。
Business Source License (BSL)
MariaDBが作成、v1.1が最新。以下説明文をサイトから引用：
BSL is a new alternative to Closed Source or Open Core licensing models. Under BSL, the source code is freely available from the start and it is guaranteed to become Open Source at a certain point in time (i.e., the Change Date). Usage below a specific level in the BSL is always completely free. Usage above the specified level requires a license from the vendor until the Change Date, at which point all usage becomes free.
一定期間後にオープンソースになる（MaxScaleならGPLのv2以降になる）ということは、旧バージョンのサポートをユーザ自身が行うことも他の企業が請け負うことも可能ということ。最新バージョンの開発に注力したいLicensorと、サポートが切れたときの対応を懸念するユーザとの双方に利がありそう。以下のQ＆Aはこれを意図しての記載と思われる。
Q: What are the main benefits for a company using BSL for their product?
A: BSL allows anyone to work on the code, both for their own benefit and that of others. It also generates trust in the BSL product, as there is no lock-in to a single software vendor.
このときusage limitsの定義はLicensorに委ねられている。例えばMaxScaleだとサーバ台数で絞っていて、2台までならどのような用途でも制限なく利用可能。このため”自衛策”になると期待される。
ちょっと気になるのはChange Dateの変更タイミングで、FAQには以下のようにメジャーバージョンごとに設定するものとある。マイナーバージョンごとにEOLを設定したいケースもあると思うのだけど。
Q: Will the Change Date remain constant?
A: No. Each new major version of the software will have its own Change Date.
Server Side Public License (SSPL)
今回Elasticが採用したライセンスで、MongoDBも利用している。GPLv3をベースにしているらしい。
AGPLv3をベースにしなかった理由として、AGPLv3のRemote Network Interactionの定義が曖昧で市場に混乱を生んでいたと書いてある。AGPLv3との違いが公式サイトで配布されているので具体的な違いを容易に確認できる。
このライセンスはAGPLv3同様、改変したソースコードの公開を求めるだけ。ソースコードを変更することなくサービスとして提供する場合は、特に制約はない。 このため完全オープンソースなプロジェクトよりは、基本機能のみオープンソースにする（サービス化のキー機能をクローズドに開発している）Open-core戦略向きと言える。
言い換えると、SSPLを適用するだけでは他の企業に "as a Service"を展開される可能性は残ってしまう。事実Elasticは追加機能（Gold+）のソースコードは商用ライセンスのみでの提供としている。Elastic Licenseの方もBSLの精神を引き継ぐシンプルなものにしたいと考えているようだ。
Parity Public License
Husky v5が採用しているライセンス。7.0.0が最新。GitHubで各種ドキュメントが公開されている。あまりアクティブじゃなさそうというか、さほど導入実績がなさそうというか、Huskyもよく使う気になったなぁという感じ。READMEにはアーリーアクセスが完了したらMITに戻すとも書いてあるので、試用という立ち位置なのだろうか。
無償で自由に使えるし共有も可能だが、ライセンスされたソフトウェアを使ってビルドされたソフトウェア（software that builds on it）もまた同様に公開されなければならない。このbuilds on itという表現が珍しい。Huskyで使われているということは、ライブラリとしてリンクしたソフトウェアだけではなく、このソフトウェアをdevDependenciesに入れて利用したすべてのソフトウェアに対して効力があるものと推測される。ホントか？
またライセンスにDon’t make any legal claimという文が入っているのも気になる。Facebookが”BSD + Patents”でやらかしたのと何が違うんだろう。ここまでくるとIANALなのでさっぱりわからない。
Patron License
Husky v5が採用しているライセンス。1.0.0が最新。他のライセンスと組み合わせて使う。 支払いを行うことで他のライセンスが持つnoncommercial or copyleftの制約を外すことができる。つまり商用利用やソースコード改変がしたかったら支払いをするように、ということ。
Husky v5は自身のライセンスを「License Zero Parity 7.0.0 and MIT (contributions) with exception License Zero Patron 1.0.0」としているが、整理すると：
- OSSプロジェクトではv4同様に無制限で利用可能
- 貢献はMITライセンスに準拠可能である必要がある
- 例外的に、GitHub SponsorsかOpen Collectiveでプロジェクトを支援すれば商用利用・ソースコード改変も可能
ということらしい。Huskyは2年前からnpm install時に寄付を呼びかけていたので、金銭的支援を得ることがライセンス導入の主目的と思われる。サービスではないOSSが選択可能な収益につながるライセンスは現状他になさそうなので、Huskyが先鞭をつけてくれるといいなぁ。
結局こうしたライセンスは勝手に "as a Service"されることへの自衛策になるのか
- BSLを適用することで、サーバ台数などに制限をかけることができそう。Elasticの語る将来の計画を見る限りでは、有償モジュールの代替機能開発・利用を禁止する拘束力を持たせることも可能と見ているのかも。
- 完全にソースコードを公開しているプロジェクトの場合、AGPLやSSPLを適用しても"as a Service"への抑止力は得られないが、サービス提供側に改変内容を公開する必要性が生じる。それでも大規模なインフラを持っているクラウドベンダーに目をつけられると競争力を発揮できなさそう。このあたりはReadTheDocsのような会社が今後どう動くか、vercelのようなOSSそのものはサービス化しない会社がどうなっていくかを注視したい。
- Open-core戦略を採るプロジェクトの場合、AGPLやSSPLを適用しても"as a Service"への抑止力は得られないが、サービス提供側に改変内容を公開する必要性が生じる。非公開モジュールと同じ機能を持つモジュールをクラウドベンダーが実装し"as a Service"を実現することに対する抑止力をどう持たせるかが課題か？
- Patron Licenseは商用利用自体を制限するライセンスと組み合わせなければならず、"as a Service"だけを制限したい場合には使いにくそう。
揺らぐオープンソースの定義
これらのライセンスを適用すると厳密な意味でのオープンソースではなくなるわけだが、より強力かつ実情に沿ったコピーレフトを実現するという意味でも、オープンソースの定義自体が更新を必要としていると見ることもできそう。"as a Service"を自由に提供できるのも、ひとつのopennessではあるわけで。
どんどん「オープン」の定義がすれ違っている。
— 名前がコロコロ変わる (@Kengo_TODA) December 23, 2019
私から見ればカネが落ちなければベンダもコミュニティも立ち行かなくなるのは明白で、AWS主張の方が顧客中心でないというかサステナブルでないと映る。 https://t.co/NY1YYgmT7U
ライセンスが乱立しても良いことはないので、OSIなどの団体がいずれBSLなどを追認するような流れになると良いなぁと思う。