ライセンスの互換性

ウィキペディア

ライセンスの互換性

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2023/02/04 05:55 UTC 版)

ライセンスの互換性（ライセンスのごかんせい、License compatibility）は、ライセンスの共存可能性とも言い、著作権に基づく著作物に適用されるライセンス、とりわけソフトウェアパッケージのライセンスについて、異なるライセンスを持つ著作物を組み合わせることが可能であるか否かの判断を指す。新しい著作物を作成する目的で複数のパッケージのソースコードや複数の著作物のコンテンツを組み合わせ、著作権法に則り合法的に頒布することができなくなるような、矛盾した要求を含むライセンスについての問題が、本稿の主題である。

ウィキペディア小見出し辞書

ライセンスの互換性

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2020/12/23 16:35 UTC 版)

「オープンソースライセンス」の記事における「ライセンスの互換性」の解説

詳細は「ライセンスの互換性」を参照 オープンソースソフトウェア開発において自身のソフトウェアが課するライセンスの選定、およびソフトウェアが利用するソースコードのライセンスの検証は重要である。 「自身のソフトウェアが課すライセンス」はそのソフトウェアの「ソースコードに課すライセンス」であるが、オープンソースソフトウェアのためのライセンスは多数存在しており、ソフトウェア開発の手段や目的、ソースコードの利用者に課すべき制約に合わせて適切なライセンスを選択しなければならない。ソフトウェアのソースコードの利用、修正、再頒布を認めるオープンソースソフトウェアとしての定義の遵守の他、広告条項の付与、コピーレフト条項の付与、著作権の放棄などを考慮すべきである。ソフトウェア利用者のライセンスの解釈を検証する労力を減らすため（ライセンスの氾濫を防ぐため）、オープンソースソフトウェアには独自のライセンスを作成、適用するのではなく既存のライセンスから選択することが望ましい。 「ソフトウェアが利用するソースコードのライセンス」はモジュールとして利用するソフトウェアの各個ライセンスについて検証しなければならない。Apache Licenseのように広告条項が含まれている場合は、広告条項に基づいてソースコードリポジトリのCOPYRIGHT、LICENSEファイルに利用しているソフトウェアの名前を連ねる必要があったり、ソフトウェアの利用者が必ず閲覧できる箇所にソフトウェアの名前を表示させなければならない。GNU GPLのようにコピーレフト条項が含まれている場合は、コピーレフト条項に基づいて自身のライセンスを決定し、自身のソフトウェアで使っている他のソフトウェアとのライセンスの互換性を検証しなければならない。 ライセンスの互換性は特に注意すべきで、ソフトウェアが利用するソースコードにライセンスの互換性がない場合、そのソースコードおよびソフトウェアを利用することは出来ない。例えば、「GNU GPLでソースコードの公開が必須となるオープンソースソフトウェア」と「商用契約でソースコードの開示を禁じられたプロプライエタリソフトウェア」を併用しようとした場合、GNU GPLを遵守すると商用契約に違反し、商用契約を遵守するとGNU GPLに違反することになる。

ライセンスの互換性

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/03/13 21:10 UTC 版)

「自由ソフトウェアライセンス」の記事における「ライセンスの互換性」の解説

詳細は「ライセンスの互換性」を参照 ソフトウェアパッケージ群のそれぞれのライセンス間で要求に矛盾があると、それらのソースコードをまとめて新たなソフトウェアパッケージを作ることはできない。 例えば、あるライセンスで「改変版では、広告で開発者に言及しなければならない」とし、別のライセンスでは「改変版には追加の帰属条項を含めてはならない」とある場合、両方のライセンスのソフトウェアをまとめようとすると、両方の要求を同時に満たすことができないため、再配布できないことになる。したがって両者のライセンスは非互換である。

ライセンスの互換性

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/06/10 02:45 UTC 版)

「GNU General Public License」の記事における「ライセンスの互換性」の解説

詳細は「ライセンスの互換性」を参照 あるオープンソースソフトウェアでライセンス上考慮すべき点があるなどして、またはもっと極端な例では、GPLの思想的な面に反発があるなどして、GPLと両立性を欠くようなライセンスを著作物に敢えて採用するケースがあるかもしれない。しかし、GPLを採用するフリーソフトウェア、オープンソースソフトウェアが多数存在するため（セクション"採用実績"を参照）、現実問題としてそのような行為はコードの再利用性を著しく欠く結果につながる（記事"ライセンスの氾濫"を参照）。このため、自身の採用するライセンスをGPLと非互換にしないよう、GPLとのライセンス両立性を考慮することは重要である。 著作物全体として影響を受けるライセンスの持つ制限の組み合わせにより、GPLが許諾する事項を越えるいかなる追加的制限が課されない限り、他のライセンスで許諾されたコードは、GPLで許諾されたプログラムと衝突することなく組み合わせることも可能である。また二次的著作物の観点として、互換性のあるフリーソフトウェアライセンス/オープンソースソフトウェアライセンスで許諾されるコードを組み合わせる場合は、原則コードの組み合わせ全体に、そのコピーレフト性が最も強くなるライセンスの影響を受ける。GPLの正規の条項に加えて、追加的な制限や許諾を適用することができる組み合わせは以下の通りである。 異なるバージョンのGPLのもとライセンスされるコードを組み合わせたいと考える場合は、より古いバージョンのGPLのコードに"any later version" statement(「任意の以後のバージョン」という表明文)が認められているのならば許可される LGPLのもとライセンスされるコードは、そのコードのライセンス如何に関わらず（独占的なコードでさえも）、いかなるその他のコードともリンク可能である。組み合わせた全体の著作物がGPLv2またはGPLv3でライセンスされる場合において、LGPLv2でライセンスされたコードに"any later version" statementが存在しない場合はコードを当該ライセンスで再ライセンスすることができる。 上述1.について、よくある表明文の例は、"either version 2 of the License, or (at your option) any later version"(「本ライセンスのバージョン2、または（あなたの選択で）任意の以後のバージョン」)である。これと対照的な例はLinuxカーネルや、バージョン1.9.2までのプログラミング言語Rubyの処理系（インタプリタ）である。これらは"any later version" statementなしのGPLv2単独でライセンスもしくはGPLv2を内部的に参照する形式を採るRubyライセンスである（後者はデュアルライセンスに類似する）。従ってGPLv3のコードを組み合わせることはできないので注意を要する。しかし、Rubyの処理系はデュアルライセンスのGPLを、バージョン1.9.3より、GPLよりパーミッシブ・ライセンスである2条項BSDライセンスに変更したため、以後のバージョンのRubyの処理系ではGPLv3で保護されるプログラムを組み合わせることも可能である。このような許諾変更が許されるのは、デュアルライセンスの片方であるRubyライセンスには著作権者（Rubyの処理系の場合はまつもと）に許諾変更を一任する条項（2.(d)）が存在する為である。一般的に、ソフトウェアのライセンスを非互換なライセンスに変更する場合は、コードの全著作権者からライセンス変更の同意を取り付けなければならない。LinuxカーネルのライセンスはGPLv2単独であり、Ruby処理系のような特殊な規定を持っているわけではないので、仮に変更する場合はそうせざるを得ない。GNUプロジェクトはこのような事態に陥ることを回避するため、前述の通り著作権者からコードの著作権をFSFに譲渡するよう勧め、またソフトウェアのライセンスほぼ全てに"any later version"表明文を付したGPLを適用している。 FSFは、GPLと両立するフリーソフトウェアライセンスのリストを維持管理している。そのようなライセンスは、もっとも広く利用されている、オリジナルのMIT/X license、（現行の3条項形式の）BSDライセンスそしてArtistic License 2.0などを対象としている。 デイヴィッド・A・ウィーラー（英語版）は、GPLと非互換なライセンスを利用すると、他者のフリーソフトウェア/オープンソースソフトウェアプロジェクトへの参加や、コードの貢献を困難にするため、フリー/オープンソース開発者はGPL互換なライセンスのみ採用するよう強く主張し続けている。 特筆すべきライセンス非互換の例として、旧サン・マイクロシステムズのZFSが、GPLでライセンスされたLinuxカーネルに組み込めないというものが挙げられる。なぜなら、ZFSはGPL非互換なライセンス、CDDLで許諾されているからである。これに加え、ZFSは特許で保護されており、ZFSの機能を持つソフトウェアをサンとは独立にGPLのもと実装し頒布しようとしたとしても、それでもなおサン（現在はオラクル）の許諾が必要となると予想される。

ライセンスの互換性

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2020/12/25 16:37 UTC 版)

「パーミッシブ・ライセンス」の記事における「ライセンスの互換性」の解説

一般的なパーミッシブ・ライセンスは多くの他のソフトウェアライセンスとライセンスの互換性を持っている。 パーミッシブ・ライセンスはその非制限性のため、他の多くのライセンスと互換性のないコピーレフト・ライセンスとですらライセンスの互換性がある。コピーレフト・ライセンスは、コピーレフト・ライセンスのソースコードと他ライセンスのソースコードから結合して作成されたソフトウェアでしばしば必要となる追加の制限条項を補足することを認めていない。 古いパーミッシブ・ライセンスの中には、4条項BSDライセンス・PHP License・OpenSSL Licenseなど、著作者の広告表示を要求する条項がありコピーレフト・ライセンスと互換性のないものが存在する。新しく一般的なパーミッシブ・ライセンスは、MIT License・3条項BSDライセンス・zlib Licenseなど、広告表示を要求する条項はなくコピーレフト・ライセンスと互換性がある。一部のパーミッシブ・ライセンスは、Common Development and Distribution License・Microsoft Public Licenseなど、再頒布に新たな制限を加えることを認めていないものがある。ただし、そのような制限により他のソフトウェアライセンスとの互換性を失っている場合がある。一部のパーミッシブ・ライセンスは、緩やかではあるが、フリーソフトウェア財団の承認するフリーソフトウェアライセンスとは認められていない。

ライセンスの互換性

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/02/27 06:44 UTC 版)

「デュアルライセンス」の記事における「ライセンスの互換性」の解説

デュアルライセンスを採用する第2の形態として、ライセンスの互換性を確保するため、異なるフリーソフトウェアライセンスでソースコードを配布する場合がある。利用者は自分のソフトウェアに最も適合するライセンスを選択することができる。 ライセンスの互換性のためにデュアルライセンスで配布されているソフトウェアには、Mozilla Application Suite, Mozilla Thunderbird, Mozilla Firefox, Perl, Ruby 等がある。それぞれ、GPL と、それ以外のオープンソフトウェア・ライセンスの複数のライセンスで配布されている。