ライセンスの互換性

ライセンスの互換性とは、異なるソフトウェアライセンスを持つソフトウェアを一緒に配布できるようにする法的枠組みです。このような枠組みが必要になるのは、異なるライセンスに矛盾する要件が含まれる場合があり、別々にライセンスされたソフトウェアのソースコードを合法的に組み合わせて新しいプログラムを作成して公開することが不可能になるためです。^{[1] [2] [検証失敗]}プロプライエタリライセンスは一般にプログラム固有で互換性がありません。著者はコードを結合するために交渉する必要があります。コピーレフトライセンスは一般にプロプライエタリライセンスと意図的に互換性がないようにされており、コピーレフトソフトウェアがプロプライエタリライセンスの下で再ライセンスされ、プロプライエタリソフトウェアになってしまうのを防ぎます。多くのコピーレフトライセンスは、他のコピーレフトライセンスの下での再ライセンスを明示的に許可しています。許容ライセンスは（わずかな例外はありますが）プロプライエタリライセンスを含むすべてのものと互換性があります。したがって、すべての派生作品が許容ライセンスの下に留まるという保証はありません。^[3]

ライセンスの互換性は、「集合的/結合的/集約的作品」と「派生的作品」という概念を中心に定義できます。最初の「集合的作品」ライセンスの互換性の定義では、さまざまなライセンスの作品を結合されたコンテキストで使用することを許可します。

2つ（またはそれ以上）のライセンスの特性。この特性に従って、これらのライセンスの下で配布されるコードを組み合わせて、より大きな配布可能なソフトウェアを作成することができます。[強調追加]

— フィリップ・ローラン、GPLv3と互換性の問題、EOLE 2008 ^{[4] : 3  [より良い情報源が必要]}

より強力な定義には、ライセンスを変更する機能が含まれます。最も顕著な例は、さまざまなライセンスのコードから結合された「派生作品」全体がコピーレフト ライセンスに適用されるというコピーレフト ライセンスの要求です。

ライセンスの互換性: このライセンスに基づいて配布されるコードを、別のライセンスに基づいて配布されるより大きなソフトウェアに統合できるというライセンスの特性。[強調追加]

— フィリップ・ローラン、GPLv3と互換性の問題、EOLE 2008 ^{[4] : 4  [より良い情報源が必要]}

結合された作品は、複数の異なるライセンスの部分で構成されます（再ライセンスの回避）。コピーレフトライセンスのコンポーネント（派生作品につながる可能性のあるウイルス性の特性を持つ）を含む結合された作品を実現するには、適切な分離を維持する必要があります。

個別にライセンスされたソース コードファイルでは、複数の非相互ライセンス (許容ライセンスや独自のプロプライエタリ コードなど) を分離できますが、結合されたコンパイル済みプログラムは再ライセンスできます (ただし、これは必須ではありません)。このようなソース コード ファイルの分離は、コピーレフト/相互ライセンス (GPL など) には弱すぎます。なぜなら、それらのライセンスでは、派生作品として完全な作品を相互ライセンスの下で再ライセンスする必要があるためです。

もう少し強力なアプローチは、バイナリオブジェクトコード（静的リンク）を使用してリンク段階で分離することです。この場合、結果のプログラムのすべてのコンポーネントは同じプロセスとアドレス空間の一部になります。これは、「弱いコピーレフト/標準の相互」を組み合わせた作品（LGPLライセンスのものなど）を満たしますが、「強いコピーレフト/強い相互」を組み合わせた作品は満たしません。リンク（静的リンクや動的リンクも）は、強いコピーレフトの作品の派生物を構成すると一般に認められていますが、^{[6] [7] [8] [9]}別の解釈もあります。^{[10] [11]}

「強力なコピーレフト」モジュールを組み合わせた作品には、より強力な分離が必要です。これは、プログラムを独自のプロセスで分離し、バイナリABIまたはその他の間接的な手段を介してのみ通信を許可することで実現できます。^[7]例としては、AndroidのBionicによるカーネル空間とユーザー空間の分離や、強力なコピーレフトカーネルを搭載しているにもかかわらず独自のバイナリブロブが含まれているLinuxディストリビューションなどがあります。^{[5] [12]}

一部の分野では分離が適切かどうかの合意が存在するが、係争中で現在まで法廷で検証されていない分野もある。例えば、2015年にSFCは、ロード可能なカーネルモジュール（LKM）がGPLのLinuxカーネルの派生作品であるかどうかという進行中の紛争でVMwareを訴えた。^{[13] [14]}

フリーソフトウェアやオープンソースソフトウェア（FOSS）に共通するライセンスは必ずしも互換性があるわけではなく、^{[16]コンポーネントのライセンスが異なる場合、}オープンソースコードを混在（またはリンク）させることが法的に不可能になることがあります。たとえば、Mozilla Public License（MPL）バージョン1.1でリリースされたコードとGNU General Public License（GPL）のコードを組み合わせたソフトウェアは、ライセンスの条項の1つに違反することなく配布することはできませんでした。^{[17] [より適切な情報源が必要]これは、両方のライセンスが}Open Source Initiative ^[18]とFree Software Foundation ^[19]の両方によって承認されているにもかかわらずです。

コピーレフトライセンスと他のライセンス間のライセンス互換性は、多くの場合、一方向の互換性に過ぎず、コピーレフトライセンス（GPL、および他のほとんどのコピーレフトライセンス）は、プロプライエタリな商用ライセンスや、多くの非プロプライエタリなライセンスと互換性がありません。^{[20] [自己出版ソース？ ] [21] [自己出版ソース？ ]}この「一方向の互換性」の特性は、より寛容なApacheライセンスでライセンスを提供しているApache Foundationから批判されています。^[22]このような非コピーレフトライセンスは、多くの場合、それほど複雑ではなく、ライセンスの互換性が向上します。^{[23] [24]}

他のFOSSライセンスとの互換性に優れたライセンスの例としては、Artistic License 2.0が挙げられます。これは、他のFOSSライセンスの下でソースコードを再配布することを許可する再ライセンス条項を備えているためです。^[25]

あなたは、改変バージョンをソースとして配布することができます（無償または配布料を支払って、改変バージョンのコンパイル形式の有無にかかわらず）[...] ただし、以下の少なくとも 1 つを実行する必要があります: […]

（ｃ）改変版のコピーを受け取った者は、改変版のソース形式を、

（i）オリジナルライセンスまたは

(ii)被許諾者が受け取ったコピーに適用されるのと同じライセンス条件を使用して、被許諾者が改変版を自由にコピー、改変、再配布することを許可するライセンスであり、改変版のソース形式およびそれから派生したすべての作品は、ライセンス料は禁止されるが配布料は許可されるという形で自由に利用できるようにすることを要求するライセンス。[強調追加]

共通開発配布ライセンス(CDDL) は、 GPLライセンスとBSD / MIT許容ライセンスの中間に位置する弱いコピーレフトライセンスであり、CDDL ライセンスのソース コード ファイルと他のライセンスのソース コード ファイルを混在させることを許可し、ソース コードが CDDL で利用可能である限り、結果として得られるバイナリを別のライセンスでライセンスして販売できることを規定することで、ライセンスの互換性の問題に対処しようとしています。^{[26] [27] [28] [ユーザーが生成したソース? ]}

FOSSエコシステムにおけるライセンスの増殖とライセンスの非互換性を最小限に抑えるために、一部の組織（たとえばフリーソフトウェア財団）や個人（David A. Wheeler）は、広く使用されているGPLとの互換性がソフトウェアライセンスの重要な特徴であると主張しています。^{[29] [自費出版ソース? ]}最も一般的なフリーソフトウェアライセンスの多く、特にオリジナルのMIT/Xライセンス、BSDライセンス（3条項形式と2条項形式、オリジナルの4条項形式ではない）、MPL 2.0、LGPLなどの許容ライセンスは、 GPLと互換性があります。つまり、それらのコードはGPLのプログラムと競合することなく組み合わせることができ、新しい組み合わせにはGPLが全体に適用されます（ただし、他のライセンスはそのようには適用されません）。

コピーレフトのソフトウェアライセンスは、本質的に GPL と互換性がありません。GPLv2 ライセンス自体も GPLv3 や LGPLv3 と互換性がありません。^{[8] [30] [31]}開発者がどちらかの後の GPL ライセンスでリリースされたコードを GPLv2 コードと組み合わせようとした場合、非互換性の原因である GPLv2 の第 6 条に違反することになります。ただし、後のライセンスのコードは、GPL バージョン 2 以降でライセンスされたコードと組み合わせることができます。^{[32] [自己出版ソース? ]} GPLv2 でリリースされたほとんどのソフトウェアでは、GPL の後のバージョンの条項も使用できます。また、異なるライセンスまたはライセンスバージョンのソフトウェアと組み合わせることを許可する例外条項があるものもあります。^[33] Linuxカーネルは、GPLv2 の条項のみで配布されている注目すべき例外です。^{[34] [35]}

フリーソフトウェア財団が推奨するGNUフリードキュメンテーションライセンス^[8]はGPLライセンスと互換性がなく、GFDLでライセンスされたテキストをGPLソフトウェアに組み込むことはできません。^[要出典]そのため、Debianプロジェクトは2006年の決議で、ドキュメントをGPLでライセンスすることを決定しました。^[36] FLOSSマニュアル財団は2007年にDebianに追随しました。 ^[37] 2009年にウィキメディア財団は、プロジェクトのメインライセンスをGFDLからクリエイティブコモンズCC-BY-SAライセンスに切り替えました。^{[38] [39]}

責任あるAIライセンス（RAIL）は、一般的にGPLと互換性がありません。^[40]これは、RAILには、RAILでライセンスされた素材をユーザーが利用できる方法を制限する「使用制限」が含まれているのに対し、GPLではそのような制限が禁止されているためです。

GPLの互換性が問題となる別のケースは、CDDLライセンスのZFSファイルシステムとGPLv2ライセンスのLinuxカーネルです。^[41]どちらもコピーレフトライセンスのフリーソフトウェアであるにもかかわらず、ZFSはDebianなどのほとんどのLinuxディストリビューションでは配布されていません^{[42] [43] （ただし、} FreeBSDでは配布されています）。これは、CDDLがGPLのLinuxカーネルと互換性がないと、Free Software FoundationおよびFSFと関係のある一部の団体が考えているためです。^{[19] [44]}この組み合わせがGPLカーネルの結合作品または派生作品を構成するかどうか、またいつ構成するかについての法的解釈は、曖昧で議論の的となっています。^{[45] 2015年、} LinuxディストリビューションUbuntuがOpenZFSをデフォルトで含めると発表したとき、CDDLとGPLの互換性の問題が再浮上しました。 ^{[46] 2016年、Ubuntuは法的なレビューの結果、Linuxでバイナリ}カーネルモジュールとしてZFSを使用することは法的に安全であるという結論に至ったことを発表しました。^[47] Ubuntuの結論を受け入れた人もいた。例えば、弁護士のJames EJ Bottomleyは「説得力のある害悪理論」を展開することは不可能であり、訴訟を起こすことは不可能だと主張した。^{[48] [自費出版ソース]} GPLv3の共著者でありSFLCの創設者であるEben Moglenは、GPLの文言は違反されるかもしれないが、両方のライセンスの精神は遵守されており、それが法廷で重要な問題になるだろうと主張した。^[49]一方、Software Freedom ConservancyのBradley M. KuhnとKaren M. Sandlerは、バイナリZFSモジュールはLinuxカーネルの派生作品となるため、Ubuntuは両方のライセンスに違反すると主張し、法廷に持ち込むことでもこの問題を明確にする意向を表明した。^[50]

2015年10月8日、クリエイティブ・コモンズはCC BY-SA 4.0がGPLv3と互換性があると結論付けました。^[51]

クリエイティブコモンズ ライセンスはコンテンツに広く使用されていますが、推奨およびサポートされている 7 つのライセンスの組み合わせすべてが互いに互換性があるわけではありません。さらに、これは一方向の互換性のみであることが多く、完全な作品は親作品の最も制限の厳しいライセンスの下でライセンスされる必要があります。^{[引用が必要]}

JSON開発者のダグラス・クロックフォードは、当時のブッシュ大統領の言葉に触発され、「悪を行う者」JSONライセンス（「ソフトウェアは、悪ではなく善のために使用されなければならない」）を策定しました。この主観的かつ道徳的なライセンス条項は、他のオープンソースライセンスとのライセンスの非互換性の問題を引き起こし、^[54] JSONライセンスが無料のオープンソースライセンスではなくなった結果となりました。^{[55] [56] [57]}

プロジェクトによっては、互換性のないライセンスになってしまうことがありますが、その解決方法としては、互換性のない部分のライセンスを再設定するしかありません。ライセンスの再設定は、関係するすべての開発者やその他の関係者に連絡を取り、ライセンスの変更に同意を得ることで実現します。フリーおよびオープンソースの分野では、多くの貢献者が関与するため、100% の同意を得ることは不可能な場合が多いですが、Mozillaライセンス再設定プロジェクトでは、コードベース全体のライセンス再設定には 95% の同意で十分であると想定しています。^{[58] [信頼できない情報源? ] FOSS 分野の}Eric S. Raymondなどの他の人々は、コードベース全体のライセンス再設定の要件に関して異なる結論に達しました。^[59]

ライセンスの非互換性を理由にライセンスの再適用に成功したプロジェクトの初期の例としては、MozillaプロジェクトとFirefox ブラウザが挙げられます。NetscapeのCommunicator 4.0ブラウザのソースコードは、1998 年にNetscape Public License / Mozilla Public License ^[60]の下で最初にリリースされましたが、Free Software Foundation (FSF) とOSIからGNU General Public License (GPL) と非互換であると批判されました。^{[61] [62]} 2001 年頃、 Time Warner はNetscape Public License の下での権利を行使し、Mozilla Foundation の要請により、Netscape Public License の下で使用されていた Mozilla のすべてのコード (他の貢献者によるコードを含む) を MPL 1.1/GPL 2.0/ LGPL 2.1の3 者ライセンスに再適用し^[63] 、 GPL との互換性を実現しました。^{[64] [自費出版ソース? ]}

VorbisライブラリはもともとLGPLとしてライセンスされていましたが、2001年にリチャード・ストールマンの支持を得て、ライブラリの採用を加速させるために、より制限の少ないBSDライセンスに変更されました。^{[65] [66]}

VLCプロジェクトはライセンスの非互換性のために複雑なライセンス履歴があり、2007年にプロジェクトはライセンスの互換性のために、リリースされたばかりのGPLv3にアップグレードしないことを決定しました。[ 67 ^{] 2011年10月、2011年の初めにVLCが}Apple App Storeから削除された後、VLCプロジェクトはより良い互換性を実現するためにVLCライブラリのライセンスをGPLv2からLGPLv2に変更しました。^{[68] [69] 2013年7月、ソフトウェアは}Mozilla Public Licenseの下で再ライセンスされ、VLCアプリケーションはiOS App Storeに再提出されました。^[70]

フリーソフトウェア財団のGNUフリードキュメンテーションライセンスバージョン1.2は、広く使用されているクリエイティブ・コモンズの 表示-継承ライセンスと互換性がなく、例えばWikipediaでは問題となっていました。 ^{[71] [自費出版ソース? ]そのため、}ウィキメディア財団の要請により、FSFはGFDLバージョン1.3に、GFDLを使用する特定の種類のウェブサイトがCC BY-SAライセンスの下で作品を追加で提供できるようにする期間限定のセクションを追加しました。^[72]これに続いて、2009年6月、ウィキメディア財団は、より広範なフリーコンテンツのエコシステムとのライセンスの互換性を向上させるために、以前使用していたGFDLに加えて、クリエイティブ・コモンズの表示-継承ライセンスをメインライセンスとして二重ライセンスでプロジェクト（Wikipediaなど）を移行しました。^{[38] [39] [73 ]}

もう一つの興味深い事例は、GoogleがAndroidライブラリBionicのGPLv2ライセンスのLinuxカーネル ヘッダーファイルをBSDライセンスに再ライセンスしたケースである。Googleは、ヘッダーファイルには著作権で保護できる作品が一切含まれておらず、著作権で保護できない「事実」にまで低下しており、したがってGPLの対象ではないと主張した。^{[74] [75]この解釈に対して}、ヒューストン大学ローセンターの法学教授レイモンド・ニマーが異議を唱えた。^[76] Androidのアプリとドライバーは、Androidの機能の多くを提供しているが、徐々に許容ライセンスから独占ライセンスに再ライセンスされている。^[77]

2014年、FreeCADプロジェクトはGPLv3/GPLv2の非互換性のため、ライセンスをGPLからLGPLv2に変更しました。^{[78] [79]}また、2014年に、Gang Garrison 2はライブラリの互換性を向上させるためにGPLv3からMPLに再ライセンスされました。^{[80] [81]}

KaiOSモバイルオペレーティングシステムは、 Firefox OS/Boot to Geckoオペレーティングシステムから派生したもので、寛容なMPL 2.0の下でリリースされました。同じライセンスの下で再配布されていないため、現在は再ライセンスされており、プロプライエタリ（ただし大部分はオープンソース）であると考えられます。^{[82] [83]} KaiOSは、Androidでも使用されているGPL Linuxカーネルも使用しています。 ^[84]

• ライセンスの増殖
• フリーソフトウェアとオープンソースソフトウェアのライセンスの比較（ライセンスの互換性も）
• 下位互換性
• 前方互換性

• 結合データセットの再ライセンス (ReCoDa) – オンラインライセンス互換性チェック