OSSのライセンス表記・表示について

2024年7月2日 2024年7月2日

a-anezaki

表記・表示の相談例
ライセンス条文を見てみましょう
勘違いの推測
OSSライセンスの表示・表記の仕方
他人の著作権の問題

　MITライセンス、BSDライセンス、Apacheライセンスなどソース開示条件を含まないライセンスをBSDタイプのライセンスと私は呼んでいます。他に、MPLタイプ、LGPLタイプ、GPLタイプと4つに分類しています。

BSDタイプのライセンスは、一般には、BSD like ライセンス、または、大雑把に単にBSDライセンスと呼ばれることもあります。

Webアプリケーション系では、Apache HTTPDとの相性なのか、BSDタイプのライセンスのみで、アプリケーションが作成されることが多いかと思います。

　そういう方から、OSSライセンスのご質問を受ける際、ライセンスの表記・表示の仕方について、相談を受けることが意外に多い。OSSライセンスに関する相談と言えば、GPLのソース開示に関する件が多いですが、それに次いで、表記・表示に関する相談が多いのです。

1. 表記・表示の相談例

ご相談には、例えば、以下のようなものがありました。

お客様が直接実行するプログラムなら
「<コマンド> --show-license」などでライセンス表示すればいいのではないかと思うのですが、
直接実行しないプログラムの場合、どうしたら良いのか？
商品は画面を持たないためライセンス表示ができないが、どうしたら良いのか？
「OSSライセンスの表記義務」を満たせているのか？
「閲覧可能な形でライセンスを公開するという要件」を満たせているのか？

本当のところはよくわかりませんが、なんとなく、ライセンス条件をプログラムに対する機能要件かのように捉えてしまっているのではないか、と疑いたくなります。

OSSライセンスが付いているOSS、つまり、プログラムは一般に「著作物」です。

著作物の著作権は、創作した開発者(または、その法人)が専有します。

Webなどに公開されたOSSをダウンロード(DL)して、実行することは、(商用と違って)自由です。しかし、DLしたものを製品に組み込むなどして、無断で再頒布することは、開発者の著作権を侵害します。

ですから、OSS開発者は、OSSにOSSライセンスを付けて、条件付きで再頒布を許諾しています。

つまり、OSSのライセンスは、再頒布の条件であって、OSSを使ったプログラムへの機能要件ではありません。

2. ライセンス条文を見てみましょう

　ここで、改めて、ライセンスの表記・表示に関する条文が各ライセンスで、どう書かれているか見てみましょう。

BDSタイプのライセンスとして、MITライセンス(Xライセンス)、PostgreSQLライセンス、二条項BSDライセンス、Apache License 2.0を見てみます。

また、参考までに、GPLタイプのライセンスGNU GPLv2も見てみましょう。

なお、PostgreSQLライセンス以外は、「オープンソースライセンスの日本語参考訳」から引用しています。

2-1. MITライセンス

Copyright (c) <year> <copyright holders>
　以下に定める条件に従い、本ソフトウェアおよび関連文書のファイル（以下「ソフトウェア」）の複製を取得するすべての人に対し、ソフトウェアを無制限に扱うことを無償で許可します。これには、ソフトウェアの複製を使用、複写、変更、結合、掲載、頒布、サブライセンス、および/または販売する権利、およびソフトウェアを提供する相手に同じことを許可する権利も無制限に含まれます。
上記の著作権表示および本許諾表示を、ソフトウェアのすべての複製または重要な部分に記載するものとします。

ソフトウェアは「現状のまま」で、明示であるか暗黙であるかを問わず、何らの保証もなく提供されます。ここでいう保証とは、商品性、特定の目的への適合性、および権利非侵害についての保証も含みますが、それに限定されるものではありません。作者または著作権者は、契約行為、不法行為、またはそれ以外であろうと、ソフトウェアに起因または関連し、あるいはソフトウェアの使用またはその他の扱いによって生じる一切の請求、損害、その他の義務について何らの責任も負わないものとします。
licenses.opensource.jp/MIT/MIT.html

「著作権表示および本許諾表示を…記載するものとします」と言われれますと、「どこに、どう記載すれば良いのか」と思うかもしれません。でも、この文章の原文(英文)を見てみますと、

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
The MIT License – Open Source Initiative

'shall be included in'、つまり、本条件表示などは、ソフトウェアのどこかに「含んで」いれば良いように思われます。どこかというのは、二行目にあるように、「本ソフトウェアおよび関連文書のファイル（以下「ソフトウェア」）」のどこかで良いわけです。

2-2. PostgreSQLライセンス

部分的著作権 (c) 1996-2011, PostgreSQL国際開発グループ
部分的著作権 (c) 1994-1996 カリフォルニア大学本校
本ソフトウェアおよびその文書一式は上記の著作権表示と、この文章およびこれに続く二つの段落が全ての複製に添付されている限りにおいて、使用、複製、修正および頒布*の許可を、いかなる目的であっても、無償でかつ同意書無しに行なえることをここに認めます。
カリフォルニア大学は、いかなる当事者にたいしても、利益の壊失を含む、直接的、間接的、特別、偶然あるいは必然的にかかわらず生じた損害について、たとえカリフォルニア大学がこれらの損害について訴追を受けていたとしても、一切の責任を負いません。
カリフォルニア大学は、商用目的における暗黙の保証と、特定目的での適合性に関してはもとより、これらに限らず、いかなる保証も放棄することを明言します。以下に用意されたソフトウェアは「そのまま」を基本原理とし、カリフォルニア大学はそれを維持、支援、更新、改良あるいは修正する義務を負いません。

*:’distribute’の訳は「配布」ではなく、「頒布」に変更しています
FAQ/ja - PostgreSQL wiki

「添付」と訳されていますが、英文を見ると'appear'なので、MITライセンスと同様、(広義の)ソフトウェアのどこかに添付されて、受領者に見えるように「現れれば良い」わけです。

2-3. 二条項BSDライセンス

Note: このライセンスは、「Simplified BSD License」および「FreeBSD License」とも呼ばれています。

Copyright <年> <著作権者>

ソースコード形式かバイナリ形式か、変更するかしないかを問わず、以下の条件を満たす場合に限り、再頒布および使用が許可されます。

ソースコードを再頒布する場合、上記の著作権表示、本条件一覧、および下記免責条項を含めること。

バイナリ形式で再頒布する場合、頒布物に付属のドキュメント等の資料に、上記の著作権表示、本条件一覧、および下記免責条項を含めること。

本ソフトウェアは、著作権者およびコントリビューターによって「現状のまま」提供されており、明示黙示を問わず、商業的な使用可能性、および特定の目的に対する適合性に関する暗黙の保証も含め、またそれに限定されない、いかなる保証もありません。著作権者もコントリビューターも、事由のいかんを問わず、損害発生の原因いかんを問わず、かつ責任の根拠が契約であるか厳格責任であるか（過失その他の）不法行為であるかを問わず、仮にそのような損害が発生する可能性を知らされていたとしても、本ソフトウェアの使用によって発生した（代替品または代用サービスの調達、使用の喪失、データの喪失、利益の喪失、業務の中断も含め、またそれに限定されない）直接損害、間接損害、偶発的な損害、特別損害、懲罰的損害、または結果損害について、一切責任を負わないものとします。
licenses.opensource.jp/BSD-2-Clause/BSD-2-Clause.html

ソースコードを再頒布する場合も、バイナリ形式で再頒布する場合も、「含めること」と訳されていますが、原文を見ると、'retain'と'reproduce'です。つまり、ソースコードの場合は「(プログラム先頭にコメント行で書かれているのを、そのまま)残す」で、バイナリ形式の場合は「(コメント行は見えなくなるから付属資料に)再掲する」という条件になっています。

ソースコードの場合は、(狭義の)ソフトウェアにすでにライセンス文は含まれていますから、そのまま残せば含まれているわけです。バイナリ形式の場合は、ソースコードのコメント行に書かれたライセンス文は見えなくなりますから、付属資料に再掲すれば、それに含まれるわけです。それによって、MITライセンスと同じように、(広義の)ソフトウェアに含まれる条件を満たすことになるわけです。

2-4. Apache License 2.0

長いので抜粋です。

1.定義 …

2.著作権ライセンスの付与 …

3. 特許ライセンスの付与 …

再頒布
あなたは、ソース形式であれオブジェクト形式であれ、変更の有無に関わらず、以下の条件をすべて満たす限りにおいて、成果物またはその派生成果物のコピーを複製したり頒布したりすることができます。

a. 成果物または派生成果物の他の受領者に本ライセンスのコピーも渡すこと。

b. 変更を加えたファイルについては、あなたが変更したということがよくわかるような告知を入れること。

c. ソース形式の派生成果物を頒布する場合は、ソース形式の成果物に含まれている著作権、特許、商標、および帰属についての告知を、派生成果物のどこにも関係しないものは除いて、すべて派生成果物に入れること。

d. 成果物の一部として「NOTICE」に相当するテキストファイルが含まれている場合は、そうしたNOTICEファイルに含まれている帰属告知のコピーを、派生成果物のどこにも関係しないものは除いて、頒布する派生成果物に入れること。その際、次のうちの少なくとも1箇所に挿入すること。(i) 派生成果物の一部として頒布するNOTICEテキストファイル、(ii) ソース形式またはドキュメント（派生成果物と共にドキュメントを頒布する場合）、(iii) 派生成果物によって生成される表示（こうした第三者告知を盛り込むことが標準的なやり方になっている場合）。NOTICEファイルの内容はあくまで情報伝達用であって、本ライセンスを修正するものであってはなりません。あなたは頒布する派生成果物に自分の帰属告知を(成果物からのNOTICEテキストに並べて、またはその付録として)追加できますが、これはそうした追加の帰属告知が本ライセンスの修正と解釈されるおそれがない場合に限られます。

あなたは自分の修正物に自らの著作権表示を追加することができ、自分の修正物の使用、複製、または頒布について、あるいはそうした派生成果物の全体について、付加的なライセンス条項または異なるライセンス条項を設けることができます。ただし、これは成果物についてのあなたの使用、複製、および頒布が、それ以外の点で本ライセンスの条項に従っている場合に限られます。

コントリビューションの提出 …

商標 …

保証の否認 …

責任の制限 …

保証または追加的責任の引き受け …

licenses.opensource.jp/Apache-2.0/Apache-2.0.html

「本ライセンスのコピーも渡す」は、英文では'give'そのままですね。

免責条項にあたる7条、8条は、「本ライセンス」に含まれています。

なお、本筋の話から離れますが、4条a.に著作権表示の条件が抜けているように思えます。4条c.に著作権の告知について書かれているの、「ソース形式の派生成果物を頒布する場合」だけの条件にも見えてしまいます。しかし、1条で以下のように定義されています。

「成果物」とは、ソース形式であるとオブジェクト形式であるとを問わず、製作物に挿入または添付される（後出の付録に例がある）著作権表示で示された著作物で、本ライセンスに基づいて利用が許されるものを指します。
licenses.opensource.jp/Apache-2.0/Apache-2.0.html

つまり、4条の条件は、「成果物またはその派生成果物のコピーを複製したり頒布したりする」際の条件ですから、対象の成果物には、「著作権表示で示され」ている前提で書かれています。よって、著作権表示の条件が抜けているわけではありません。

2-5. GNU GPLv2

　これも長いので抜粋です。

それぞれの複製物において適切な著作権表示と保証の否認声明を目立つよう適切に掲載し、またこのライセンスおよび一切の保証の不在に触れた告知すべてをそのまま残し、そしてこのライセンスの複製物を『プログラム』のいかなる受領者にも『プログラム』と共に頒布する限り、あなたは『プログラム』のソースコードの複製物を、あなたが受け取った通りの形で複製または頒布することができる。媒体は問わない。…

あなたは自分の『プログラム』の複製物かその一部を改変して『プログラム』を基にした著作物を形成し、…

あなたは上記第1条および2条の条件に従い、『プログラム』(あるいは第2条における派生物)をオブジェクトコードないし実行形式で複製または頒布することができる。ただし、…

※ただし、「利用許諾契約書」「契約書」を「ライセンス」に、「節」を「条」に変更しています
licenses.opensource.jp/GPL-2.0/GPL-2.0.html

「ライセンスの複製物を…『プログラム』と共に頒布」は、英文では'give…along with'なので、「共に渡す」。それは、第1条の「ソースコードの複製物を…頒布する」場合に限らず、第3条の「オブジェクトコードないし実行形式で複製または頒布する」場合も、「上記第1条…に従い」と同じ条件が課せられています。

2-6. 各ライセンス条文での記述のまとめ

　以上、5つのライセンス条文での「ライセンス表記・表示」に関する記述を見てきました。まとめると以下の表になります。

ライセンス	日本語参考訳	英文	他の日本語訳
MIT	記載	include in	含む
PostgreSQL	添付	appear in	現れる
二条項BSD	含める	retain/reproduce	残す/再掲する
Apache L 2.0	渡す	give	渡す
GNU GPLｖ２	共に頒布	give …along with	共に渡す

各ライセンスのライセンス表記・表示を求める記述のまとめ

　ライセンスの作成者や著作権者によって、意図は異なる可能性はありますが、総じて、頒布されるプログラムに添付さ(含めら)れて、受領者に渡ることが、意図されているように思われています。
少なくとも、画面に表示することを求めているようには思えません。

　各ライセンス条文を見れば、ライセンスを表記しなければならない、とか、表示しなければならない、とかと解釈する方が難しい気がします。

　では、

どうして、ライセンス表記・表示させなければならない、といった勘違いが出てきたのでしょう。

3. 勘違いの推測

　今でこそ、あまり聞かなくなりましたが、OSSライセンスという言葉が出てから10年20年は、「無料で自由利用を保証するソフトウェアライセンスである」と、「有償で不自由な商用ソフトウェアライセンス」と対比する人が多く居ました。商用ソフトウェアライセンスは、プログラム使用許諾契約書とも呼ばれていましたから、OSSライセンスも自由を保証する契約書であると考え、説明する人が多かったのです。

　そして、ご存じのように、商用ソフトウェアの多くは、インストール時/使用開始時などで、ライセンス文をダイアログやウィンドウに表示し、内容の合意を求めるクリックオン(クリックラップ)の操作で契約します。

　そのダイアログやウィンドウでの表示から、「OSSのライセンス表示」というイメージができあがったのかもしれません。そうして、ライセンス文を表示させなければならないのに、表示器が無い、どうすればいいんだろう？と悩む事になったのかもしれません。

　しかし、そのような(クリックラップ)方法によるライセンスの提示するプログラムは、下記オープンソースの定義の第10条に反する規定です。そのような条件(規定)のあるライセンスのプログラムは、「オープンソース」と呼べないものになりますので、条件に指定されるとは思えません。つまり、OSSライセンスの条文は、クリックラップのような表示方法を求めている条文ではないと言えます。

オープンソースの定義 (v1.9) 注釈付

…

ライセンスは技術中立的でなければならない
ライセンス中に、特定の技術やインターフェースの様式に強く依存するような規定があってはなりません。
理由: この規定で特に念頭に置いているのは、ライセンサーとライセンシーの間で契約を成立させるために明示的な同意の意思表示を必要とするようなライセンスです。いわゆる「クリックラップ(click-wrap)」を要求する規定は、ソフトウェア頒布において重要な手法であるFTPダウンロードや CD-ROMアンソロジー、ウェブのミラーリングなどと衝突する可能性がありますので、このような規定もコードの再利用を妨げてしまいます。よって、本定義に準拠するライセンスは、(a) ソフトウェアの再頒布が、ダウンロード時のクリックラップをサポートしないようなウェブ以外の経路で起こりうるという可能性 (b) ライセンスで保護されるコード (あるいは保護されるコードの再利用された部分) はポップアップダイアログをサポートできない非GUIの環境でも実行されれうるという可能性を認めなければなりません。

オープンソースの定義 (v1.9) 注釈付 – Open Source Group Japan – オープンソース・グループ・ジャパン

閑話休題

頒布するプログラムは、「ソース形式であれオブジェクト形式であれ」関係ありません。
どちらの形式でもプログラムを頒布することになります。
オブジェクト形式は、ソース形式の二次的著作物ではありません。
コンパイルで何か創作性が生まれるわけではありませんので、著作権的には、単なる複製の扱いです。
ソフトウェアは一般に、プログラムと付属文書の集合体と解されますが、
あまり、明確に使い分けされている感じはありません。

4. OSSライセンスの表示・表記の仕方

　以上のことから、OSSライセンスでの条件としては、ライセンス文を表示・表記しなさい、ということではなく、下図のようになります。

頒布するプログラムがソースコードの場合(スクリプト言語などのLightweight Language (LL)の場合も含みます)、コード中に元々掲載・記載されているライセンス文を残せば、受領者に渡るので条件を満たせます。
頒布するプログラムがバイナリ形式の場合は、ソースに記載のあったライセンス文も見えなくなりますので、付属文書に再掲・添付すれば、受領者に渡るので条件を満たせます。
以上のことから、どちらにしても、頒布物にライセンス文が含まれていれば、受領者に渡り、受領が見ようと思えばどこかに現れるのですから、条件を満たせます。

5. 他人の著作権の問題

　単独、つまり、自分一人で作成したプログラムの著作物ならば、上記の対応で済みます。しかし、多くの場合、プログラム開発する場合、既存の他人のプログラム(著作物)を流用して、自分が望む機能に改造して開発することは少なくありません。確かに、望む機能を有するプログラムを開発したのは、あなた自身かもしれませんが、そのプログラムには、他人の著作物が含まれていれば、含まれている著作物の開発者(著作者)の著作権を無視してはいけません。つまり、表記・表示するライセンス文や著作権表示には、その含まれる他人の著作権の行使の条件も満たさなければなりません。結果、表記・表示するライセンス文・著作権表示は複数になります。

ライセンス文が複数になります
著作権表示は、それよりも多くなります

5-1. ライセンス文が複数になります

BSDライセンスのプログラムには、複数の種類のBSDライセンスが含まれることが多くあります。二条項BSDライセンスのプログラムもあれば、四条項BSDライセンスのプログラムもある、といった具合です。

このように複数のライセンスを含むプログラムを頒布する場合、含まれているプログラム全てのライセンス文を受領者に渡す必要があります。渡さなければ、そのプログラムの再頒布の条件を満たしておらず、著作権侵害になってしまうからです。

流用するプログラムが既に複数のライセンスを含むプログラムの場合、気の利いたディストリビューションならば、ソースツリーのtop辺りにCOPYRIGHTやLICENSEという名称のファイルで、複数のライセンス文をまとめてくれています。

自分で他のOSSを流用していなければ、このファイルが受領者に渡るように、プログラムに添付するなどすれば条件を満たすことができます。

なお、Apache License 2.0は、BSDライセンスやApache Software License 1.1に比べ、プログラム先頭にコメント行で掲載するには大幅に長くなりました。そのためか、初めから、ライセンス文は、LICENSEファイルに掲載される形になっています。流用される他の著作者のライセンス文もLICENSE 文にサブコンポーネントとして、まとめて記載されています。そのため、ApacheのOSSごとに、流用しているプログラムは違うわけですから、当然、LICENSEファイルの内容も異なります。

よく、GitHubなどで、Apache License 2.0を選ぶだけで開発プログラムをUploadし、LICENSEファイルをUploadしていない例を見かけますが、流用したサブコンポーネントがあったならば、それらの再頒布条件を満たしていません。著作権侵害になってしまいますので注意しましょう。

ここで蛇足かもしれませんが、「プログラムを開発したのは自分。そのプログラムに自分が選択したライセンスを付けて何が問題あるのか？」と言う人がいるかもしれません。確かに、既存のOSSを流用して作成した新しいOSSの著作者は、作成したあなたです。しかし、あなただけが著作権を持っているわけではありません。

著作権法第二十八条（二次的著作物の利用に関する原著作者の権利）
二次的著作物の原著作物の著作者は、当該二次的著作物の利用に関し、この款に規定する権利で当該二次的著作物の著作者が有するものと同一の種類の権利を専有する。
著作権法 | 国内法令 | 著作権データベース | 公益社団法人著作権情報センター　CRIC

あなたが開発したプログラムは二次的著作物ですから、流用したプログラム、つまり、原著作物の著作者にも、あなたと同じ権利が存在するということです。また、

著作権法第十一条
二次的著作物に対するこの法律による保護は、その原著作物の著作者の権利に影響を及ぼさない。
著作権法 | 国内法令 | 著作権データベース | 公益社団法人著作権情報センター　CRIC

なので、原著作物の著作者である開発者が指定した再頒布の条件のライセンスは、あなたのプログラムでも有効です。

つまり、二次的著作物の利用(頒布)には、作成した二次的著作者の他に、原著作者の許諾も必要と法律に定義されています。

5-２. 著作権表示は、それよりも多くなります

　前項の最初の図、FreeBSDの二つのソースファイルの著作権表示部分を見てみると、root/sbin/devfs/devfs.c　には、著作権表示は、一つです。

しかし、root/sys/kern/init_main.c　には、著作権表示は三つもありました。

(c) UNIX System Laboratories, Inc. All or some portions of this file are derived from material licensed to the University of California by American Telephone and Telegraph Co. or Unix System Laboratories, Inc. and are reproduced herein with the permission of UNIX System Laboratories, Inc.

これら、すべての著作権表示が受領者に渡らなければ、ライセンス文同様、著作権違反になります。ライセンス文は複数のプログラムで同じこともありますが、著作権表示は一つのプログラムに複数存在し得ることが、まず、抽出の手間が掛かる問題になります。

さらに、著作権表示をソースコード上でgrepコマンドで探すにしても厄介な問題があります。まず、上の3つの著作権表示を見てもわかるように、著作権表示が1行に収まっておらず、grepしても二行目以降を探して抽出しなければならないことがあります。また、著作権表示にはいくつかの形式があり、grepで条件を指定しづらいという問題があります。例えば、どのような形式があるかというと、日本などで遵守されている万国著作権条約での形式

万国著作権条約第三条

…著作権者の名及び最初の発行の年とともに©の記号を表示…

万国著作権条約パリ改正条約 | 条約 | 著作権データベース | 公益社団法人著作権情報センター　CRIC

記号が機種依存文字のため、ソースプログラムに記述する際には、'(c)'で代用することは慣習的に行われています。

一方、多くのOSS開発者は米国民のためか、米国著作権法での形式で書かれているようです。

米国著作権法　第401条

(b)表示の形式－コピーに表示がなされる場合、以下の三つの要素を含まなければならない。
(1) ©記号（丸の中にC の文字）、または「Copyright」の語、または「Copr.」の略語。
(2) 著作物が最初に発行された年。…
(3) 著作物に対する著作権者の名称、…
第４章－著作権表示、納付および登録 | 外国著作権法一覧 | 著作権データベース | 公益社団法人著作権情報センター　CRIC

万国著作権条約の記号以外に、「Copyright」の語、または「Copr.」の略語も可能になっています。そのため、記号だけではなく、また、「Copyright」の文字列だけでもなく、「Copr.」の略語でもヒットするような条件でgrepする必要があります。そして、米国以外にも、万国著作権条約と異なる表示形式を認めている国があるかもしれません。

このような事情から、機械的に著作権表示を抽出するというのは、なかなか難しいものがあります。

5-3. 少々大胆な代替案

　以上のように、ライセンス文を抽出するのは可能でも、著作権表示を抽出するのは、流用しているOSSが多くなると難しいと言わざるを得ません。だからといって、受領者にそれらが渡らなければ、著作権侵害になってしまいます。多くの著作者は(面倒くささから)黙認してくれる可能性は高いですが、企業が頒布する製品・サービスにおいては、それに甘えるわけにはいきません。

では、どうするかというと、少し大胆な代替案になりますが、ソースコードを添付してしまうことです。

BSDタイプのライセンスには、ソース開示の条件はありません。しかし、ソースを付ければ、確実に、漏れなく対応できる可能性が高くなります。もちろん、元のソースコードに抜けがあれば対応できませんが。