鷲ノ巣

C# とか PowerShell とか。当ブログの記事は（特に公開直後は）頻繁に改定される場合があることをご了承ください。

OSSライセンス、あるいはどんぐりの木の話

※お断り※
私はライセンスや法的事項の専門家ではありません。
以下の内容の正確性は保証されませんのでご注意ください。

皆さん、OSS書いてますか。コントリビュートしてますか。私は（あまり）してません。
ところで、OSSにはライセンスがつきものですよね。どんなライセンスが好きでしょうか。どんなライセンスをお使いでしょうか。
今回はそんなライセンスについての話をしたいと思います。

追記

詳しい方から頂いたコメントを記事末尾に追記しておりますので、併せてお読みください。

ライセンスの人気度

GitHubが公開しているInnovation Graphを見ると、GitHub内でのライセンスの人気度がわかります。
innovationgraph.github.com

MIT Licenseが不動の一位ですね。
あとはまぁ多少の上下はあるものの、Apache License 2.0、GPL 3.0などが上位を維持しています。

以下、ライセンスのいくつかの特徴について見ていきましょう。

同一ライセンス条項

このライセンスのもとで公開されているソフトウェアは、その派生物を作った場合にも、同じライセンスで公開しなければならないというルールです。
これを備えるライセンスの代表格はGPLですね。GPLが好まれている最大の理由であり、嫌われている最大の理由でもあります（たぶん）。
嫌う人はこれを指して「感染性」などと呼んだりします。

5. Conveying Modified Source Versions.
【中略】
c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy.

GNU General Public License version 3, Section 5.c

特許条項

特許条項を備えるライセンスは数多くあります。GPL 3.0にもありますが、ここではApache License 2.0を例にして紹介しましょう。
Apache License 2.0の特許条項は2つの部分に分けることができます。便宜上、前半部を特許利用許諾条項、後半部を防衛的特許終了条項と呼ぶことにします。

まずは前半部の特許利用許諾条項です。

3. Grant of Patent License.
Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted.

Apache License, Version 2.0, Section 3

これは、コントリビューターが、自身が保有する特許技術を用いた実装をコントリビュートした場合、当該コントリビューターはこのソフトウェアの利用者に対し、ライセンスに従っている限り、その特許の利用を許諾するというものです。
つまり、こっそり特許を使用したコントリビューションをしておいて、後から「お前、うちの特許を使っているな！」と訴えることを封じているわけです。

続いて後半部の、防衛的特許終了条項。

3. Grant of Patent License.
【中略】
If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

Apache License, Version 2.0, Section 3

これは、もしあなた（コントリビューターであるかどうかを問わない）が、このソフトウェアに対して特許権侵害の訴えを起こした場合、前半の条項によってあなたに許諾されていた利用権が停止されるということを言っています。
精神的には、このソフトウェアの発展に対して害をなすような者には、このソフトウェアを使わせない（ということをもって、特許訴訟を抑止している）と言えるでしょう。

ただし、この条項があるからといって、特許訴訟を確実に防げるわけではありませんし、訴訟に勝てるわけでもありません。このソフトウェアをもともと利用するつもりがないなら、何ら痛手を被ることなく訴訟することは可能です。

特許条項を備えないライセンス

人気のあるライセンスの中でも、MIT License、BSD License、ISC Licenseなど、条文の短いシンプルなライセンスの多くには特許条項がありません。
つまり、これらのライセンスでは、特許権者による “bait and switch”（おとり戦法）を仕掛けられる恐れがあるわけです。

GPLの本家であるフリーソフトウェア財団（FSF）が公開しているライセンス選択ガイドでは、小さなプログラムにはApache License 2.0を適用することが推奨されています。
その理由として、Apache License 2.0が特許条項を備えるという点が挙げられています。

Small programs
It is not worth the trouble to use copyleft for most small programs. We use 300 lines as our benchmark: when a software package's source code is shorter than that, the benefits provided by copyleft are usually too small to justify the inconvenience of making sure a copy of the license always accompanies the software.

For those programs, we recommend the Apache License 2.0. This is a weak, lax, “pushover” (non-copyleft) software license that has terms to prevent contributors and distributors from suing for patent infringement. This doesn't make the software immune to threats from patents (no software license can achieve that), but it does prevent patent holders from setting up a “bait and switch” where they release the software under free terms then require recipients to agree to nonfree terms in a patent license.

How to Choose a License for Your Own Work

防衛的特許終了条項の罠

いくつかのライセンスは、特許利用許諾条項だけを持ち、防衛的特許終了条項を持ちません。一例を挙げると、UPL 1.0がそうなっています。
FAQでは、UPL 1.0が防衛的特許終了条項を備えない理由が説明されています。

Why isn't there a defensive patent termination provision?
A defensive patent termination provision may sound like a great idea at first, especially for a pure open source project, but does not really work for contributions to software that is also licensed on commercial terms.

Why? A company that takes on commercial obligations with respect to a piece of code needs to retain the ability to keep supporting and shipping that code. A defensive patent termination provision allows someone who makes a contribution and then breaches the project license to the project to then potentially effectively block infringement suits against them, even when they have willfully and flagrantly disregarded community norms and IP rights in the project. Such a provision is therefore in reality as much of a sword as it is a shield.

The Universal Permissive License (UPL), Version 1.0, FAQ #5

何が問題なのか簡単に説明しましょう。以下のようなシナリオを考えます。

  1. GadgetCo社（以下G社）が中心になって開発されているGadgetXという製品があるとします。この製品にはG社が保有する特許gが使われています。GadgetXの利用者は、ライセンスに従う限り、特許gの利用を許諾されています。
  2. GadgetXに対して、WidgetCo社（以下W社）が、自社の持つ特許wを用いたコントリビュートを行いました。特許gと同様に特許wも、ライセンスに従う限り、その利用が許諾されます。これで、G社とW社は、ライセンスのもとでお互いの特許を利用しあう関係になりました。
  3. ここでW社がGadgetXを、ライセンスに反して不正に扱ったとします。W社がライセンスに反したので、G社はW社をライセンス違反で訴えることができます。また、もしこのライセンスがUPL 1.0だとすれば、違反したW社には特許gの利用が許諾されないことになりますから、G社は特許権侵害でもW社を訴えることができます。
  4. しかし、もしこのライセンスがApache License 2.0だったらどうでしょう。G社がW社を特許権侵害で訴えた場合、防衛的特許終了条項によって、W社からG社に対して許諾されている特許wの利用権までもが消失してしまうことになります。ライセンス違反をしたといえど、Ｗ社が行ったコントリビュートや、W社が保有する特許wの権利までもが無効化されるわけではないからです。
  5. すると、G社はGadgetXから特許wを用いた実装を取り除くまで、GadgetXを提供したり販売したりすることができなくなってしまいます。この事態を避けるためには、G社はW社を特許権侵害で訴えることを諦めなければなりません。つまり、防衛のためにあるはずの条項が、かえって自分の首を絞めることになりかねないのです。

変更箇所の明示

派生物において変更を加えた場合は、そのことを明記しなければならないという条項を持つライセンスもあります。
中でもApache License 2.0には、ちょっと使いづらいんじゃないかこれと思う条文があります。

4. Redistribution.
【中略】
2. You must cause any modified files to carry prominent notices stating that You changed the files; and

Apache License, Version 2.0, Section 4

変更したすべてのファイルに、変更した旨の記載をしなければならないというのです。これは、GitHubでコミットログを公開していればいいというものではありません。
これをキッチリと守っている人も、守っていないことに目くじらを立てる人も、あまりいないんじゃないかと思いますが（個人の感想です）。

コントリビューションに関する条項

Apache License 2.0ばかり例に使って申し訳ないのですが、このライセンスには特徴的な条項があります。

5. Submission of Contributions.
Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

Apache License, Version 2.0, Section 5

このソフトウェアに対して行われるコントリビューションは、別段の定めがない限り、このライセンスのもとで行われるということを明記したものです。
つまり、コントリビューションが受け入れられた後で、「あれはやっぱりGPLでやりたかったんだ」というようなことができないということですね。
このような条項を持つライセンスはあまりありません。

コントリビューションとGitHubとプルリクエスト

しかし、このような条文は現代的とは言えないのではないかと思います。
それも仕方のない話です。Apache License 2.0が作られたのは2004年、GitHubがオープンしたのは2008年です。
Apache License 2.0が作られた頃、コントリビューションとは、パッチをメールで送るという方法で行われるものでした。

もしGitHub上でプルリクエストを用いた開発手法をとる場合、コントリビュートは、以下のような手順で行われるでしょう。

  1. 元のリポジトリをフォークする
  2. フォークしたリポジトリに変更を加えてプッシュする
  3. フォークしたリポジトリから元のリポジトリにプルリクエストを出す

ここで2に注目してください。もしこの時、同時にライセンスも変更していなければ、この時点であなたは、自分の変更の利用を同じライセンスの下で全世界に許諾したことになります。
メールで送る場合、この2の状態は存在しません。

Apache License 2.0では、「コントリビューション」とは、元のソフトウェアに取り込まれることを意図してライセンサーに提出された著作物を指します。提出の具体的な方法は定められていませんが、GitHubを使うならプルリクエストを使うのが一般的でしょう。

1. Definitions.
【中略】
“Contribution” shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner

Apache License, Version 2.0, Section 1

この定義に従えば、上記の2の時点ではまだ、これは「コントリビューション」ではありません（自分のリポジトリで公開することが「提出」にあたらないとすれば）。
しかしあなたは自身の変更をApache License 2.0で公開しています。
もし気が変わってプルリクエストを出さなかったとしても、偶然、元のリポジトリの関係者があなたのフォークを見つけて、その変更を取り込んだとすれば、結果的には同じことになります。
つまり、Apache License 2.0が定義するところの「コントリビューション」をしなくても、あなたの変更は同じライセンスで扱われる（し、ライセンスを勝手に変えたら十中八九マージされない）のです。

なのでまぁ、GitHubでプルリクエストを使うならという前提のもとでの話にはなりますが、この第5条は要らない（この条項があることはApache License 2.0を選ぶ理由にならない）んじゃないかな、と思います。

使いやすいOSSライセンス

個人的に好ましいと思うOSSライセンスの要件をまとめてみます。

  • 派生物のライセンスが拘束されない
  • ソースコードの公開義務がない
  • 変更したファイルにいちいち変更したことを明記しなくてよい
  • 特許利用許諾条項がある
  • 防衛的特許終了条項がない
  • 無保証、無責任である
  • ライセンス文書が短くシンプルである

そんな都合のいいライセンスはあるのでしょうか。実はあります。Blue Oak Model Licenseがそれです。
opensource.org

Blue Oak Councilによって策定されたもので、Open Source Initiativeによって承認されたのは2024年と、かなり新しいライセンスです。
もし私が何かOSSを開発することがあったら、このライセンスを使ってみたいと思います。MIT Licenseほどの知名度がないのが難点ですが、よかったら使ってみてはいかがでしょうか。

Blue Oak Councilによって公開されているライセンス リストを参考にしてもよいでしょう。
ここでは次点としてBSD-2-Clause Plus Patent Licenseも推奨されています。
また、特許条項の節でも紹介した、UPL 1.0もなかなかいいライセンスかなと思います。

Blue Oak Councilはアメリカの非営利法人で、ソフトウェア ライセンスに関する法的問題の支援をしている団体です。
なお、私はBlue Oak Councilの回し者ではありません。本記事の公開について、Blue Oak Councilからは何ももらっていないことを申し添えておきます。

※Blue Oakとはコナラの木のことだそうです。どんぐりのなる代表的な木ですね。

追記

識者の方からコメントを頂きました。

#License #OSS

aetos382 読者になる

関連記事
コメントを書く