OSS ライセンスの最近の潮流: PolyForm License について

まえがき

開発中のソフトウェアのライセンスを策定するため、現時点でのベストプラクティスについて探っていたところ、ここ数年の OSS ライセンスの動向が面白かったので復習も兼ねてまとめました。

特に、Umbrel が採用したという PolyForm という新しいライセンス形態が面白かったので、これについて詳しく述べます。

なぜ今ライセンスについてまとめるのか

私はソフトウェアやサービスをマネタイズする方法について興味があり、特にビットコインの応用について調べたりしています。

ビットコイン (Lightning Network) を HTTP で利用することで、Web API の課金方法の可能性は大きく広がることは間違いないのですが、これはあくまで単なる支払いの手法であって、広く使われる事を前提としたソフトウェアの開発を支える手法にすることは(それだけでは)難しいという問題があります。

ソフトウェアの収益化にまつわる問題は昔から存在します。DAO とか ICO などといった新しい手法で解決を目指す潮流も有るようですが、フリーライダー問題をトラストレスに防ぐのは一般に非常に難しくどうしても法律マターにならざるを得ないと私は考えています。Bitcoin 自体がパクられまくっているから言うまでもないですね。パクれないのは BTC の価値だけです。

OSS を開発・利用する可能性がある人はもちろんですが、今やすべての企業はソフトウェア企業である事を思えば、 OSS に関するお金の流れを知っておくことはすべての社会人の基礎教養と言えるのではないでしょうか。そういった内容に興味がある人のためにまとめました。

... というのは建前です。本音は、自分で開発していた OSS をいつも何も考えず MIT ライセンスにしていたのですが、早い段階から人を巻き込む方法や収益化の指針を立てておいたほうが開発の持続性という観点から良さそうだな。と思ったためです。

OSS ライセンスの歴史概観

まずは歴史について、独断と偏見に基づいて書きます。

OSS ライセンスの歴史は大きく３つに分けられます

1. 1980~2000: "Free Software" License
2. 2000~2020: "Open Source" License
3. 2020~ "Source Available" License

Free Software License

Unix が私有化と商用利用によってバラバラになり、改善が共有されなくなったことによる反省から始まった Free Software Movement に基づくものです。
GNU/Linux に代表され、中核と成るライセンスは GPL です。

フリーソフトウェア・コピーレフトの功罪については色々なところで述べられているのでここでは割愛します。

AGPL

GPL の一番の特徴は、リンク先にも Copyleft を強制する点、つまり GPL のライブラリを一部でも使っているソフトウェアはそれ自身も GPL にしなければならないという点にありました。

これの問題点は、ソフトウェアがユーザー端末で実行されることを前提としている点にあります。
WWW の普及によってソフトウェアの大部分がサーバー側で実行されるようになると、ソフトウェアを配布しなくても営利サービスが運営できてしまうので、GPL ライセンスの意味がなくなってしまったのです。

これに対応するため、 2000 年頃に AGPL というライセンスができました。
これは、ソフトウェアを誰でもアクセスできる環境で実行した場合(つまり WWW に公開した場合)、 GPL でバイナリを配布した場合と同じ様にソースコード公開の義務が発生するというものです。

Open Source License

フリーソフトウェア運動は、営利企業に対する対抗心が常にその動機の中心にありました。一方で「オープンソースソフトウェア」はよりイデオロギー感が薄い用語で、活動の一部が営利的であるようなものを指すためにも使う事ができ、特に 2000 年以降盛り上がりはじめました。

皆さんは「オープンソースソフトウェア」の定義は何だと思うでしょうか？
「ソースコードがオープンになっていること」ではありません。より厳密な定義があります。
Open Source の定義及び Free Software と Open Source Software の違いについては、専用の Wiki ページがわかりやすいです。

このような定義に準拠したライセンスである Open Source License には、 GPL, AGPLに加えて更によりゆるいライセンスも含めます。以下が主なものです。

MIT, Apache v2, BSD License

MIT, Apache V2 などは、GPL, AGPL などよりもよりゆるく
「出典を明示して、私(作者)を訴えたりしないなら好きにしていいよ」という内容です。

最も一般的なライセンスであり、 2020 年の時点でOSS 全体の半数以上はこの２つのいずれかを使っています。

BSD ライセンス (正確には３条項 BSD ライセンス) もほぼ同じです。「宣伝する時に私(作者)の名前を勝手に使わないで」という決まりが入っている点だけが違います。

COSS 企業の台頭

OSS の開発・管理を行ったことが有る人なら誰でも知っていると思うのですが、非営利で行うのは大変です。
その OSS が第三者のビジネスに直結していたり、セキュリティに関連するものであったりすると、メンテナンス不足が致命的な結果を招く場合もあります。

このような重要な OSS の保守をどうやって経済的にサステイナブルにするかは、昔から問題視されていました。
2000 年以降のトレンドは OSS 単位で会社を作り、SaaS として提供したり、中核部分以外を有料ライセンスを用意したりするような手法です。

このような企業を COSS 企業 (Commercial Open Source Software Company )と呼びます。MongoDB とか Redis とか、Elastic などが有名ですね。実際 IPO する COSS 企業の数は 2013~2020 の間に飛躍的に増えています。

AWS による strip-mining 問題

COSS 企業の台頭に伴い、パブリッククラウド事業者との対立が鮮明になってきました。特に AWS です。(厳密には AWS に限った話ではないのですが、わかりやすさのために限定します)

Amazon の AWS 運用方針は「少しでもユーザーに需要がありそうなものはとにかく全部サービスとして提供する」というものです。その中には Elastic Search や MongoDB をほぼそのまま提供するようなものが多くありました。

もちろん商用利用すること自体は問題ではないのですが、 AWS がそれらによって多くの利益を得ているにもかかわらず、そこでの改善点がオリジナルのソースコードに還元されていないことが長らく問題視されていたのです。
上に挙げたライセンスのうち最も厳しい AGPL でさえ、インターネット越しにユーザーにウェブサービスを提供するケースを考慮したものであり、このようなクラウド環境に閉じたソフトウェアの利用は考慮していませんでした。
そのため、 AWS は当該ソフトウェアに関連するソフトウェア(ユーザー向けの UI, 安定して管理するためのモニタリングソフトウェアなど) を公開する義務がありませんでした。

このような問題を、Strip-mining 問題と呼びます

Strip-mining とは露天掘りのことです。 「公有地から大企業が搾取する」 というイメージから連想した言葉かと思われます。

この問題は 2018 年以降、 MongoDB, Inc. や Elastic 社が AWS に対抗するためにライセンスを変更した事によって顕在化してきました。

Source-available License

上記の Strip-Mining 問題に対する対策として新しいライセンスが提案された結果、それらはオープンソースライセンスの厳密な定義から外れてしまいました。

このようなライセンスを "Source Available" License と呼びます。共通するのは「その気になれば誰でもソースを見ることができる」という一点のみです。

Commons Clause

上記の問題を受けて作られたのが、 Commons Clause です。
これは、他のオープンソースライセンス (Apache 2.0, MIT など) に付け足して使うことを想定されています。(たとえば "MIT + Commons Clause" で一つのライセンスになります)

内容は、「当該ソフトウェアの価値を、実質的にそのまま提供するようなサービスで利益を得てはならない」という一文を追加するものです。

"実質的に" (substantially) ってなんやねんと思いましたが、法律家的にはよくある言い方らしいです。

もっとわかりやすく言うと、開発元のビジネスと競合してはならない と言っているのとほぼ同義です。多分

自分の観測範囲だと、ビットコイン関連ソフトウェアにいくつか使われています。例: lily-wallet,  Coldcard Wallet

Commons Clause は何よりもシンプルであるという利点があるのですが、誤解を招きやすいという点から普及は下火になっているようです。「 Commons Clause をつけることによって (狭義の) OSS でなくなってしまうにもかかわらず、その点に気づかない」というケースが頻発したためです。

SSPL

SSPL は、 MongoDB が 2018 年に独自に作成したライセンスです。
GPL, AGPL を更に強力にしたようなもので、「当該ソフトウェアの機能をサービスとして提供する場合、その周辺ソフトウェア (管理用ツールなど) も公開しなくてはならない」というような内容です。

ライセンス自体がかなり長いですが、実用上は Commons Clause で言っている内容とそう変わりはありません。
単に、「~してはならない」という言い方を「〜するならば〇〇しなくてはならない」という言い方に変えただけです。

SSPL, Commons Clause の問題点

SSPL, Commons Clause が、オープンソースの定義から外れてしまった理由は OSI の定義する「オープンソースソフトウェア」の定義の第９条 "ライセンスは他のソフトウェアに対して制限を加えるようなものであってはならない" に違反するためです。

いずれの場合も、ライセンスが影響する範囲がソフトウェアから、その周辺を含む "サービス" 全体になるためです。これは GPL、 AGPL との明確な違いです。

例えば、 MongoDB で言えば、普通の Web サービスの背後に MongoDB を使うことは問題ありませんが、ユーザーが自由なデータをそこに保存できるようにしたらアウトになります。これは、DB 自体ではなく、その「使いかた」つまり周辺サービスに依存します。
さらに、 SSPL の場合は、共有すべき範囲も周辺サービスに広げています。 AGPL をより広範囲にしたようなイメージです。

OSS であるかどうかって重要なの？と思うかもしれませんが、
各 Linux の Distribution が MongoDB の配布を取りやめたのはまさにそのためであるといえば、重要性がわかるのではないでしょうか

独自ライセンスの台頭

上記のような問題から、ごく最近大手 COSS に SSPL や Commons Clause を廃して独自ライセンスを策定するところが現れました。具体的には Redis と Elastic です。

独自のライセンスの策定は大手以外には難しく、始まったばかりのプロジェクトが採用できるようなものではありません。
さらに言うまでもありませんが、独自ライセンスを採用するソフトウェアが増えるとその内容を理解するのに時間を割かなくてはならないため導入のコストが上がります。(あるいは誰も読まなくなります。)

そのため、このような問題に対処できる統一的な枠組みが求められているわけです。

PolyForm とは

ここでようやく冒頭で述べた PolyForm に戻ります。
これは「ソフトウェアのためのクリエイティブ・コモンズ」を目指したもので、Heather Meeker さんという方が起草しています。上記の Commons Clause や SSPL を作成したのと同じ方です。
策定およびバージョン管理は こちらの github レポジトリで行われています。

PolyForm License の種類

すべて、非営利での使用は許可しています。
制限する対象となるのは、配布・変更と、営利目的での使用です。

• PolyForm NonCommercial
  • 非営利であれば自由に配布・変更して良い。
  • Creative Commons の、 表示-非営利 4.0 と実質的に同じと思われる。
• PolyForm Perimeter
  • 当該ソフトウェアと競合しない限り、自由にしてよい。
• PolyForm Shield
  • 当該ソフトウェアを提供している会社と競合しない限り、自由にしてよい。
  • Commons Clause と実用上は同じ (多分)
• PolyForm Strict
  • 当該ソフトウェアの再配布や変更をできない。使うだけなら良い。
  • 最も厳しい。ほとんどプロプライエタリと同じだが、ソースを見ることができる点が違う。
  • Creative Commons の表示-非営利-改変禁止 4.0 と同等と思われる
• PolyForm Internal Use
  • 公に再配布できない。特定法人の内部で利用する限りは自由である。
    • 非営利企業での利用の場合、通常は NonCommercial で問題ないが、例えば研究機関等の場合法人の一部が営利活動を行っている可能性がある。そのような場合に対処するためのライセンス
    • 他のライセンスに比べて重要性は低いと思われる。
    • 参考
• PolyForm Small Business
  • 売上100万ドル以下で、従業員が100人以下なら自由に使って良い。
  • 貨幣価値の変化は、アメリカ労働統計局の消費者物価指数に応じて調整する。
  • Unity みたいなモデル
• PolyForm Free Trial
  • 32 日間は好きに利用・変更して良い。再配布はできない
    • 通常、別の商用利用ライセンスと組み合わせて使う。
    • BSL License を、よりコンポーザブルにした感じ

所感

• PolyForm は長過ぎないのが嬉しいです。 SSPL とか長すぎて全部読めませんでした。
• 更にフォーマットが統一されているので比較が容易なのも嬉しいです。
• 普及してほしいのでみんな使ってください自分は使います。

まとめ

• ライセンス関連の知識はソフトウェアを生業にしていたら必須なので、頭の片隅に入れておきましょう。使う側も作る側も、全く知らないでいると後々トラブルになるかもしれません
• PolyForm には Creative Commons などと違い執筆時点で日本の法律への対応例が一切ないので、これを読んでる法律関係者の方がいたら日本支部的なの作ってくださいお願いします
• OSS 企業の経済規模はこの 10 年で更に大きくなっていることを考えると、ライセンスのプラクティスはエンジニア以外のビジネスパーソンにとっても無視できないものになっていくはずです。

追記

20210824追記:

「OSS ライセンス (以下 OSL)」という用語を Source Available License (以下 SAL) まで含むように使っているのはおかしくないか？ という指摘をいただきました。
OSL は、 SAL の一種とみなせるので、本当は全体を通して SAL というべきです。タイトルも「SAL ライセンスの最近の潮流」とすべきですね。
ただ、この用語がまだ一般的ではないことと、 SAL 自体が OSL の拡張という形で生まれたことから、あえてこのままにしようかと思います。
単に「ソフトウェア・ライセンス」としても良かったのですが、それだと文脈が伝わらないと思い却下しました。

また、「なぜ今ライセンスについてまとめるのか」で一部書き方が分かりづらかったため修正しました。
「そのままではスケールしそうにないということに気づいたため」 -> 「早い段階から人を巻き込む方法や収益化の指針を立てておいたほうが開発の持続性という観点から良さそうだな。と思ったため」

20210903追記：

"BSD ライセンス" に対する説明が、正確には"３条項 BSD ライセンス"の説明になっていたことを明示しました。

その他参考記事

• GNUアフェロGPLの理由
• 最近バズっていた記事を呼んでソフトウェアライセンスについて考える
• Elastic License 2.0 and the Evolution of Open Source Licensing
• Everything you need to know about Umbrel’s new license
• Forbes: This Software Giant Declared War On Amazon. Will Other Open Source Companies Follow?
• The After Open Source Era Has Started
• Kengo's blog: 最近見かける新しいライセンスについて
• AWSをElasticが名指しで非難。ElasticsearchとKibanaのライセンスを、AWSが勝手にマネージドサービスで提供できないように変更へ