Loading article…
GNU General Public Licenses ( GNU GPLまたは単にGPL ) は、広く使用されているフリーソフトウェアライセンスのシリーズです。GPL はコピーレフトライセンスであり、エンド ユーザーにソフトウェアを実行、研究、共有、または変更する自由を保証しますが、派生作品または変更を配布する場合は、同じまたは同等のライセンス条件でソース コードを受け手に提供する必要があります。一般に公開する必要はありません。[ 7 ] GPL は、一般使用が可能な最初のコピーレフト ライセンスでした。元々は、フリー ソフトウェア財団(FSF)の創設者であるリチャード ストールマンがGNU プロジェクトのために作成しました。このライセンスは、コンピュータ プログラムの受け手にフリー ソフトウェア定義の権利を付与します。[ 8 ] GPL は、GNU Lesser General Public Licenseよりも再配布に関する義務が多く、 BSD、MIT、Apacheなどの広く使用されている寛容なソフトウェア ライセンスとは大きく異なります。
歴史的に、GPL ライセンスファミリーは、フリーおよびオープンソースソフトウェア(FOSS) の分野で最も人気のあるソフトウェアライセンスの 1 つです。 [ 7 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] GPL の下でライセンスされている著名なフリーソフトウェアプログラムには、Linux オペレーティングシステムカーネルとGNU コンパイラコレクション(GCC) があります。David A. Wheeler は、GPL によって提供されるコピーレフトがLinux ベースのシステムの成功に不可欠であり、貢献するプログラマーに、自分たちの仕事が世界に利益をもたらし、コミュニティへの貢献を求められていないソフトウェア企業によって悪用されることなく、フリーのままであるという保証を与えたと主張しています。[ 13 ]
2007年、ライセンスの第3版（GPLv3）がリリースされた。これは、長期間の使用を通じて明らかになった第2版（GPLv2）の欠点に対処するためであった。
ライセンスを最新の状態に保つため、GPLにはオプションの「それ以降のバージョン」条項が含まれており、ユーザーは元の条項、またはFSFによって更新された新しいバージョンの条項の2つのオプションから選択できます。オプションの「それ以降のバージョン」条項でライセンスされているソフトウェアプロジェクトにはGNUプロジェクトが含まれますが、LinuxカーネルなどのプロジェクトはGPLv2のみでライセンスされています。「それ以降のバージョン」条項は、 GPLライセンスの異なるバージョンのソフトウェアを組み合わせても互換性を維持できるため、 「救命ボート条項」と呼ばれることもあります。
GPLの使用は2010年代以降着実に減少しており、特に上述の複雑さに加え、ライセンスが現代のオープンソース領域の成長と商業化を阻害しているという認識がその理由となっている。[ 14 ] [ 15 ]
オリジナルの GPL は、 1989 年にRichard StallmanによってGNU プロジェクトの一部としてリリースされたプログラムで使用するために作成されました。このライセンスは、GNU Emacsテキストエディタ、GNU デバッガ、およびGNU C コンパイラの初期バージョンで使用されていた同様のライセンスを統合することに基づいていました。[ 16 ] [ 17 ]これらのライセンスには、現代の GPL と同様の条項が含まれていましたが、各プログラムに固有のものであったため、同じライセンスであるにもかかわらず互換性がありませんでした。[ 18 ] Stallman の目標は、あらゆるプロジェクトで使用できる単一のライセンスを作成し、それによって多くのプロジェクトがコードを共有できるようにすることでした。
ライセンスの第2版であるGPLv2は1991年にリリースされました。その後15年間、フリーソフトウェアコミュニティのメンバーは、GPLv2ライセンスの特定の問題点について懸念を抱くようになりました。これらの問題点は、ライセンスの意図に反する方法でGPLライセンスのソフトウェアを悪用することを可能にするものでした。[ 19 ]これらの問題点には、次のようなものがありました。
上記の懸念事項に対処するためにGPLのバージョン3が開発され、2007年6月29日に正式にリリースされました。[ 20 ]
1989年2月25日にリリースされたGNU GPLのバージョン1は、ソフトウェア配布者がフリーソフトウェアを定義する自由を制限する2つの主要な方法から保護するために書かれた。[ 21 ] [ 22 ]
最初の方法は、実行はできるが人間が読み取ったり変更したりできないバイナリファイルを公開することです。この制限を回避するため、GPLv1では、プログラムのいかなる部分のコピーを複製および配布する場合、同じライセンス条件の下で人間が読めるソースコードも提供しなければならないと規定しています。[ a ]
2 つ目の方法は、ライセンスに直接制限を追加するか、配布に関する制限が異なる他のソフトウェアとソフトウェアを組み合わせることによって制限を追加することです。このような制限のセット 2 つを組み合わせると、結合された作品に適用され、許容できない制限が追加されます。この状況を防ぐために、GPLv1 では、変更されたバージョンは全体として GPLv1 の条件の下で配布されなければならないと規定しています。[ b ]その結果、GPLv1 の条件の下で配布されるソフトウェアは、より寛容な条件の下で配布されるソフトウェアと組み合わせることができます。なぜなら、この組み合わせによって全体が配布できる条件が変わらないからです。しかし、GPLv1 の下で配布されるソフトウェアは、より制限的なライセンスの下で配布されるソフトウェアと組み合わせることはできません。なぜなら、この組み合わせは、全体が GPLv1 の条件の下で配布可能であるという要件と矛盾するからです。
リチャード・ストールマンによれば、GPL バージョン 2 の大きな変更点は「自由か死か」条項、すなわち第 7 条であった。[ 18 ]この条項では、ライセンシーは、他の法的義務の有無にかかわらず、ライセンスのすべての義務を履行できる場合にのみ、 GPL でカバーされる作品を配布できると規定している。言い換えれば、ライセンスの義務は、相反する義務によって分離することはできない。この規定は、いかなる当事者も、特許侵害の主張やその他の訴訟を利用して、ライセンスに基づくユーザーの自由を侵害することを阻止することを目的としている。[ 18 ]
1990 年までに、より制限の少ないライセンスが、C 標準ライブラリと既存のプロプライエタリ ライブラリと同じタスクを処理するソフトウェア ライブラリの 2 種類のライブラリにとって戦略的に有用であることが明らかになりました。[ 23 ] 1991 年 6 月に GPLv2 がリリースされたとき、同時に 2 番目のライセンスが導入されました。これは GNU ライブラリ一般公衆ライセンス (LGPL) であり、2 つのライセンスが補完的であることを示すためにバージョン 2 と番号が付けられました。[ 24 ] 1999 年に LGPL のバージョン 2.1 がリリースされ、その哲学における役割を反映するためにGNU Lesser General Public Licenseに改名されたときに、バージョン番号が分岐しました。GPLv2 は LGPL の新しい名前を参照するように更新されましたが、GPL のバージョン番号は同じままでした。その結果、元の GPLv2 はソフトウェア パッケージ データ エクスチェンジ (SPDX)で認識されませんでした。[ 25 ]
GPLには「ライセンスのバージョン2、または（ご希望に応じて）それ以降のバージョン」を指定するよう指示が含まれており、バージョン2または3のどちらでも柔軟に使用できるようになっていますが、一部の開発者はこの指示を変更して「バージョン2」のみを指定するようにしています。
2005 年後半、フリー ソフトウェア財団(FSF) は GPL のバージョン 3 の開発作業を発表しました。2006 年 1 月 16 日、GPLv3 の最初の「議論草案」が公開され、パブリック コンサルテーションが開始されました。公式の GPLv3 は、2007 年 6 月 29 日に FSF によってリリースされました。GPLv3 は、ソフトウェア自由法センターのエベン モグレンとリチャード フォンタナの法律顧問のもと、リチャード ストールマンによって書かれました。[ 26 ] [ 27 ]
Stallmanによると、最も重要な変更点は、ソフトウェア特許、フリーソフトウェアライセンスの互換性、「ソースコード」の定義、およびソフトウェアの変更（ tivo化など）に対するハードウェア制限であった。[ 26 ] [ 28 ]その他の変更点には、国際化、ライセンス違反の処理、および著作権者による追加の許可の付与が含まれる。ソフトウェア伝播という用語は、ソフトウェアのコピーと複製として明確に定義された。
公開協議プロセスは、フリーソフトウェア財団がソフトウェア自由法センター、フリーソフトウェア財団ヨーロッパ、その他のフリーソフトウェアグループの協力を得て調整した。[ 29 ]意見は、専用に作成されたstetというソフトウェアを使用して、 gplv3.fsf.orgウェブポータル[ 30 ]を通じて一般から収集された。意見募集期間終了までに、合計2,636件の意見が提出された。[ 31 ]
GPLv3の第3草案は2007年3月28日に公開された。[ 32 ]この草案には、物議を醸したマイクロソフトとノベルの契約のような特許関連の契約を防止することを目的とした文言が含まれていた。また、草案では、反ティボイゼーション条項を「ユーザー」と「消費者製品」の法的定義に限定した。さらに、草案では「地理的制限」のセクションが明示的に削除されており、このセクションの削除は公開協議の開始時に発表されていた。
4番目で最後の議論草案は2007年5月31日に公開されました。[ 33 ]この草案では、 Apache Licenseバージョン2.0との互換性が導入され（以前のバージョンは互換性がないため）、外部請負業者の役割が明確化され、Microsoft-Novellスタイルの契約で認識されている問題を回避するための例外が設けられ、第11条第6項で次のように述べられています。
ソフトウェア配布事業を営む第三者との間で、あなたが著作物の配布活動の程度に応じて第三者に支払いを行い、かつ、その第三者があなたから著作物を受け取る当事者に対し差別的な特許ライセンスを付与する取り決めを締結している場合、あなたは当該著作物を配布することはできません 。
この例外規定は、将来そのような取引を無効にすることを目的としていた。このライセンスはまた、マイクロソフトに何らかの行動を起こさせることも意図していた。つまり、ノベルの顧客にGPLv3ソフトウェアの使用に関して付与した特許ライセンスを、そのGPLv3ソフトウェアのすべてのユーザーに拡大することである。この拡大は、マイクロソフトがGPLv3ソフトウェアの法的「伝達者」である場合にのみ可能であった。[ 34 ]
GPLv3 の初期草案では、ライセンサーがAGPLと同様の要件を追加して、アプリケーション サービス プロバイダーに関する GPL の抜け穴を解消することも認められていました。[ 35 ] [ 36 ]ソース コードを実行、研究、共有する自由、およびコピー レフト保護を保証する自由は、ウェブ サービスの文脈ではやや曖昧です。しかし、GPLv3 の初期草案で提案された追加要件についてコードをチェックする管理コストについて懸念が提起され、最終的には GPL と AGPL を分離したままにすることが決定されました。[ 37 ]
他の回答者、特にLinus Torvalds、Greg Kroah-Hartman、Andrew Mortonなどの著名な Linux カーネル開発者は、メディアのコメントや公式声明を使用して、GPLv3 ドラフトの一部に反対しました。[ 38 ]カーネル開発者は、DRM (および tivoization)、特許、および「追加の制限」に関する条項に反対し、さらに「オープンソースの世界」の「バルカン化」を警告しました。 [ 38 ] [ 39 ] Linux カーネルに GPLv3 を採用しないことを選択した Linus Torvalds は、数年後に批判を繰り返しました。[ 40 ] [ 41 ] [ 42 ]
GPLv3 は、Apache License (バージョン 2.0) や GNU Affero General Public License (GPLv2 とは組み合わせることができなかった) など、いくつかのフリー ソフトウェア ライセンスとの互換性を向上させました。[ 43 ]ただし、GPLv3 ソフトウェアは、GPLv2 ソフトウェアと組み合わせてコードを共有できるのは、次の 2 つの条件が満たされた場合のみです。使用されている GPLv2 ライセンスにオプションの「またはそれ以降」条項が含まれていること、およびソフトウェアが GPLv3 にアップグレードされていること。FSF では「GPLv2 またはそれ以降のバージョン」条項が GPLv2 ソフトウェアのライセンスの最も一般的な形式であると考えられていますが、[ 44 ] Toybox開発者の Rob Landley はこれを救命ボート条項と表現しました。[ c ]オプションの「またはそれ以降」条項でライセンスされているソフトウェア プロジェクトには、Joomla [ 47 ]やGNU プロジェクト[ 48 ]などがありますが、この条項のない顕著な例としては Linux カーネルがあります。[ 40 ] [ 49 ]
GPLv3のライセンステキストの最終版は2007年6月29日に公開されました。[ 50 ]
GPLの条件は、GPLライセンスが適用された作品のコピーを受け取るすべての人（「ライセンシー」）に提供されなければなりません。条件を遵守するライセンシーは、作品を改変するだけでなく、作品またはその派生版を複製および再配布する許可を与えられます。ライセンシーは、このサービスに対して料金を請求することも、このサービスを無償で提供することもできます。この後者の点が、商用再配布を禁止するソフトウェアライセンスとGPLを区別する点です。FSFは、フリーソフトウェアは商用利用に制限を設けるべきではないと主張しており、GPLはGPL作品は任意の価格で販売できることを明示的に述べています。[ 51 ]
GPLはさらに、配布者は「GPLによって付与された権利にさらなる制限を課してはならない」と規定している。この規定は、秘密保持契約や契約に基づいてソフトウェアを配布するなどの行為を禁じている。
GPLv2の第4項とGPLv3の第7項では、プリコンパイル済みバイナリとして配布されるプログラムには、ソースコードのコピー、プリコンパイル済みバイナリファイルと同じ方法でソースコードを配布する旨の書面による申し出、またはGPLに基づいてプリコンパイル済みバイナリファイルを受け取った際にユーザーが入手したソースコードを取得するための書面による申し出のいずれかを添付する必要があると規定されています。GPLv2の第2項とGPLv3の第5項では、プログラムとともにライセンスを配布することも規定されています。GPLv3では、第7項を満たすために、ソースコードを他の方法で提供することも認められています。これらの方法には、隣接するネットワークサーバーからソースコードをダウンロードすることやピアツーピア送信などが含まれますが、コンパイル済みコードが同じ方法で入手可能であり、ソースコードの入手先が明確に示されていることが条件となります。
FSFは、著作者が明示的に著作権をFSFに譲渡しない限り、GPLに基づいて公開された作品の著作権を保有しません。GNUプロジェクトの一部であるプログラムを除き、このような譲渡はめったに起こりません。ライセンス違反が疑われる場合、訴訟を起こす権限を持つのは個々の著作権者のみです。
GPL に基づくソフトウェアは、商用目的を含むあらゆる目的で使用でき、GPL ライセンスのコンパイラを使用する場合のように、プロプライエタリ ソフトウェアを作成するためのツールとしても使用できます。[ 52 ] GPL ライセンスの作品 (ソフトウェアなど) を配布するユーザーまたは企業は、コピーに対して料金を請求したり、無料で提供したりできます。この点が、GPL を他の 2 種類のライセンスと区別しています。1 つは、個人使用のためのコピーは許可するが商用配布は禁止するシェアウェアソフトウェア ライセンス、もう 1 つは著作権法によってコピーが禁止されているプロプライエタリ ライセンスです。FSF は、自由を尊重するフリー ソフトウェアは商用利用および配布 (再配布を含む) を制限すべきではないと主張しています。[ 51 ] [ 53 ]
純粋に私的（または内部）な使用、つまり販売や配布を行わない場合は、ソースコードを公開することなく、ソフトウェアコードを変更したり、一部を再利用したりすることができます。販売または配布を行う場合は、コードの変更や追加を含め、ソースコード全体をエンドユーザーに提供する必要があります。その場合、コピーレフトが適用され、エンドユーザーが上記で定義された自由を保持できるようになります。
ただし、GPL ライセンスのオペレーティングシステム (Linux など) 上でアプリケーション プログラムとして実行されるソフトウェアは、GPL の下でライセンスされる必要も、ソース コードが利用可能である状態で配布される必要もありません。ライセンスは、使用されるライブラリとソフトウェア コンポーネントのみに依存し、基盤となるプラットフォームには依存しません。[ 54 ]例えば、プログラムがオリジナルのソース コードのみで構成されている場合、または他のソフトウェア コンポーネントのソース コードと組み合わされている場合、[ d ]カスタム ソフトウェア コンポーネントは GPL の下でライセンスされる必要はなく、ソース コードを提供する必要もありません。使用される基盤となるオペレーティングシステムが GPL の下でライセンスされている場合でも、システム上で実行されるアプリケーションは派生著作物とはみなされません。[ 54 ]プログラムで GPL ライセンスの部分が使用され (かつプログラムが配布される場合) にのみ、プログラムの他のすべてのソース コードが同じライセンス条件の下で利用可能にする必要があります。 GNU Lesser General Public License (LGPL)は、GPL よりもコピーレフトを弱めるように設計されており、LGPL では、独自に開発されたソースコード (LGPL ライセンスの対象となる部分とは別) を同じライセンス条件で公開することを義務付けていません。
GPLv3の第5項では、GPLライセンスのコードはWIPO著作権条約第11条で定義される有効な「技術的保護措置」とはみなされないこと、また、作品を伝達する者は、「対象作品に関して本ライセンスに基づく権利を行使することによって回避が行われる範囲において」技術的保護措置の回避を禁止するすべての法的権限を放棄すると規定している。この規定は、ユーザーが米国のデジタルミレニアム著作権法（DMCA）などの法律の下で、GPLv3ライセンスのコードに実装されたDRMを回避したとして責任を問われることはないことを意味する。[ 55 ]
GPLによって付与される、改変版作品の配布権は無条件ではありません。GPLライセンス作品に独自の改変を加えたものを配布する場合、作品全体を配布するための要件はGPLの要件を超えることはできません。この要件はコピーレフトと呼ばれ、ソフトウェアプログラムにおける著作権の使用から法的効力を得ています。
GPL作品は著作権で保護されているため、ライセンスを受けた者は、ライセンスの条件に従う場合を除き、作品を再配布する権利を有しません。著作権法によって通常制限される権利（再配布など）を行使したい場合にのみ、GPLの条件に従う必要があります。逆に、GPLの条件に従わずに作品のコピーを配布した場合（例えば、ソースコードを秘密にするなど）、著作権法に基づき原著作者から訴訟を起こされる可能性があります。
著作権法は、歴史的に、著作者の許可を得ていない者による作品の配布を防ぐために用いられてきました。コピーレフトは、同じ著作権法を用いて全く異なる目的を達成します。コピーレフトは、すべての当事者が後続の当事者に同じ権利を与え、さらにその当事者が次の当事者に同じ権利を与えるという条件で、すべての当事者に配布権を付与します。このようにして、GPLやその他のコピーレフトライセンスは、作品とその派生作品への自由なアクセスを強制しようとします。 [ 56 ]
GPLライセンスのプログラムの多くは、実行ファイルにソースコードを同梱しています。コピーレフトの要件を満たす別の方法として、要求に応じてソースコードを物理媒体（CDなど）で提供する旨を文書で提示する方法があります。実際には、多くのGPLライセンスのプログラムはインターネット経由で配布されており、ソースコードはFTPまたはHTTPプロトコルを介して提供されています。インターネット配布の場合、この方法はライセンスに準拠しています。
コピーレフトは、プログラムを再配布しようとする場合にのみ適用されます。開発者は、変更したソフトウェアを他の人に配布しない限り、変更内容を開示する義務なしに、私的な変更版を作成できます。コピーレフトはソフトウェアにのみ適用され、その出力には適用されません（出力自体がプログラムの派生作品である場合を除く）。[ e ]例えば、GPL ライセンスのコンテンツ管理システムの変更された派生版を実行しているパブリック Web ポータルは、その変更を基盤となるソフトウェアに配布する必要はありません。これは、変更された Web ポータルが再配布されているのではなくホストされていること、および Web ポータルの出力が GPL ライセンスのコンテンツ管理システムの派生作品ではないためです。
ソースコードを難読化して公開することが、例えば著者がソースコードの公開に消極的な場合などに、GPLv1 に違反するかどうかについて議論が交わされてきた。議論の結論としては、そのような公開は非倫理的ではあるが、ライセンス違反ではないということになった。この問題は、GPL がバージョン 2 で変更され、「推奨」バージョンのソースコードを公開することが義務付けられた際に明確になった。[ 58 ]
GPLは契約ではなくライセンスとして設計されました。 [ 59 ]コモンロー法域の中には、ライセンスと契約の法的区別が重要なものがあります。契約は契約法によって強制執行されるのに対し、ライセンスは著作権法によって強制執行されます。しかし、大陸法系など、契約とライセンスに違いのない多くの法域では、この区別は役に立ちません。[ 60 ]
GPLの条件を拒否する人は、著作権法の下で、GPLライセンスのソフトウェアまたは派生作品をコピーまたは配布する許可を得ていません。ただし、これらの人がGPLライセンスのプログラムを再配布しない場合、組織内でソフトウェアを自由に使用することはでき、プログラムを使用して作成された作品（プログラムを含む）はこのライセンスの対象とする必要はありません。[ 61 ] [ 62 ] [ 63 ] [ 64 ] [ 65 ] [ 66 ] [ 67 ]
2007年、ソフトウェア開発者のアリソン・ランダルは、GPLv3（ライセンスとして）は専門家以外の読者にとって不必要に分かりにくく、同じ条件と法的効力を維持しながら簡素化できると主張した。[ 68 ]
2017年4月、米国連邦裁判所はオープンソースライセンスは法的拘束力のある契約であるとの判決を下した。[ 69 ]
2021年10月、ソフトウェア・フリーダム・コンサーバンシー（エンドユーザー）は、契約違反を理由にVizio社（著作権者）を提訴した。訴訟の目的は、Vizio社のテレビのソースコードを入手することであった。連邦判事は、GPLはエンドユーザーにとって強制力のある契約であり、著作権者にとってもライセンスであると暫定的に判決を下した。[ 70 ]
GPLの条文は著作権で保護されており、その著作権はフリーソフトウェア財団が保有しています。
FSFは、派生ライセンスがGPLのプレアンブルを許可なく使用しない限り、GPLに基づいて新しいライセンスを作成することを許可しています。ただし、このようなライセンスはGPLと互換性がない可能性があり[ 71 ] 、ライセンスの増殖につながる可能性があるため、この使用は推奨されません。
GNUプロジェクトによって作成されたその他のライセンスには、GNU Lesser General Public License、GNU Free Documentation License、およびGNU Affero General Public Licenseなどがあります。
GPL のテキストは GPL の対象外です。ライセンスの著作権は、ライセンス自体の変更を禁止しています。ライセンスのコピーと配布は許可されています。GPL は、受領者に「プログラムとともにこのライセンスのコピー」を受け取ることを要求しているからです。[ 72 ] GPL FAQによると、次の 3 つの条件を満たせば、誰でも GPL の修正版を使用して新しいライセンスを作成できます。ライセンスに別の名前を使用すること。「GNU」に言及しないこと。前文を削除すること。ただし、フリーソフトウェア財団 (FSF) から許可を得れば、修正されたライセンスで前文を使用できます。[ 73 ]
GNAT修正一般公衆ライセンス（略称：修正GPL、GMGPL ）は、コンパイル済みユニットおよびAdaプログラミング言語の汎用機能向けに特別に修正されたGNU一般公衆ライセンスのバージョンです。修正内容は以下のとおりです。
GNAT Adaコンパイラは、コンパイラディレクティブを使用して、一部のGPLソフトウェアライセンスの問題に対する適合性チェックを自動化できます。これを使用してpragma License (Modified_GPL);、修正GPLに対するチェックを有効にします。GNATリファレンスマニュアル[ 74 ]には、License [ 75 ]プラグマと他のコンパイラディレクティブが記載されています。
FSFによると、「GPLは、改変版またはその一部を公開することを要求していません。改変を行い、公開することなく私的に使用することは自由です。」[ 76 ]しかし、GPLライセンスのエンティティを公開した場合、リンクに関する問題、つまり、GPLライブラリを使用するプロプライエタリプログラムがGPLに違反しているかどうかという問題が生じます。
この重要な問題は、GPL以外のソフトウェアがGPLライブラリに静的リンクまたは動的リンクを合法的に行うことができるかどうかである。この点については様々な意見がある。GPLは、 GPLに基づく派生著作物はすべてGPLの下でなければならないと明確に規定している。GPLライブラリの使用や、GPLソフトウェアをより大きなパッケージ（静的リンクによってバイナリファイルに混入するなど）にバンドルすることに関して、曖昧さが生じる。
フリーソフトウェア財団は、GPLライセンスの著名なソフトウェア製品とライセンス文自体の著作権を保有しています。同財団は、動的にリンクされたライブラリを使用する実行ファイルは確かに派生著作物であると主張しています。ただし、この主張は、互いに通信する別々のプログラムには適用されません。[ 77 ]
フリーソフトウェア財団は、GPLとほぼ同じだが、「ライブラリを使用する」目的でのリンクを許可する追加の権限が付与されたLGPLも作成した。
リチャード・ストールマンとFSFは、特にライブラリ作成者にGPLライセンスの下でライセンスを付与することを推奨しており、これによりプロプライエタリなプログラムがライブラリを使用できなくなり、プロプライエタリな世界よりも多くのツールを提供することでフリーソフトウェアの世界を保護しようとしている。[ 78 ]
静的リンクは派生作品を生み出すが、GPL コードに動的にリンクする実行ファイルが派生作品とみなされるべきかどうかは不明であると考える人もいる（弱いコピーレフトを参照）。Linux の作者である Linus Torvalds は、動的リンクによって派生作品が作られる可能性があることには同意しているが、その状況については意見が異なる。[ 79 ]
Novellの弁護士は、動的リンクが派生的ではないことは「理にかなっている」が「明確ではない」と述べ、善意の動的リンクの証拠は、独自のLinuxカーネルドライバの存在に見られると述べている。[ 80 ]
Galoob v. Nintendo事件において、米国第 9 巡回控訴裁判所は、派生著作物を「形式」または「永続性」を有するものと定義し、「侵害著作物は、何らかの形で著作権で保護された著作物の一部を取り込んでいなければならない」と指摘した。しかしながら、今日までこの特定の問題を明確に解決した裁判所の判決はない。[ 81 ]
Linux Journalの記事によると、ローレンス・ローゼン(かつてOpen Source Initiativeの顧問弁護士を務めていた) は、ソフトウェアが派生著作物であるかどうかという問題において、リンクの方法はほとんど関係ないと主張している。より重要なのは、そのソフトウェアがクライアント ソフトウェアやライブラリとインターフェースすることを意図していたかどうかという問題である。[ 82 ] ローゼンは、「新しいプログラムが派生著作物であるかどうかの主な指標は、元のプログラムのソース コードが (コピー ペーストの意味で) 使用されたか、修正されたか、翻訳されたか、あるいは何らかの方法で変更されて新しいプログラムが作成されたかどうかである。そうでない場合は、派生著作物ではないと私は主張する」と述べており、意図、バンドル、リンク メカニズムに関する他の多くの点を挙げている。[ 82 ] さらに、同氏は自身の事務所の Web サイトにおいて、そのような「市場ベースの」要因はリンク技術よりも重要であると主張している。[ 83 ]
また、プラグインやモジュール（ NVIDIAやATIグラフィックカードのカーネルモジュールなど）が、それ自体が独立した著作物とみなせる場合、GPLライセンスでなければならないのかという具体的な問題もあります。この見解では、GPLv2ライセンスであれば、合理的に独立したプラグイン、あるいはプラグインを使用するように設計されたソフトウェアのプラグインは、任意のライセンスでライセンスできるとされています。特に注目すべきは、GPLv2の以下の条項です。
プログラムの複製物またはその一部を改変して、プログラムに基づく著作物を作成し、上記第1項の条件に従って、かかる改変物または著作物を複製および頒布することができます。ただし、以下のすべての条件を満たす必要があります 。
b) 配布または公開する作品のうち、全体または一部が本プログラムまたはその一部を含むか、または本プログラムまたはその一部から派生したものについては、本ライセンスの条件に基づき、すべての第三者に対して無償で全体としてライセンス供与されなければなりません。 … これらの要件は、改変された作品全体に適用されます。その作品の識別可能な部分が本プログラムから派生しておらず、それ自体が独立した別個の作品と合理的にみなせる場合、それらの部分を別個の作品として配布する際には、本ライセンスおよびその条件はそれらの部分には適用されません。しかし、同じ部分を本プログラムに基づく作品の一部として配布する場合、作品全体の配布は本ライセンスの条件に従わなければならず、他のライセンシーに対する本ライセンスの許可は作品全体に及び、したがって、誰が書いたかに関わらず、すべての部分に及びます。
GPLv3には異なる条項があります。
第4項の規定に基づき、プログラムに基づく著作物、またはプログラムからその著作物を生成するための改変物をソースコードの形式で伝達することができます。ただし、以下のすべての条件を満たす必要があります 。
c) 著作物全体を、複製物を所有するすべての人に、このライセンスに基づいてライセンス供与しなければなりません。したがって、このライセンスは、適用可能な第 7 条の追加条項とともに、著作物全体およびそのすべての部分に、パッケージ化方法に関係なく適用されます。このライセンスは、著作物を他の方法でライセンス供与する許可を与えるものではありませんが、別途許可を得ている場合は、そのような許可を無効にするものではありません。 … 対象著作物と、その性質上対象著作物の拡張ではなく、より大きなプログラムを形成するように結合されていない、他の独立した著作物とのコンパイルは、そのコンパイルおよびそれによって生じる著作権が、個々の著作物が許可する範囲を超えてコンパイルの利用者のアクセスまたは法的権利を制限するために使用されていない場合、「集合体」と呼ばれます。対象著作物が集合体に含まれている場合でも、このライセンスが集合体の他の部分に適用されることはありません。
事例研究として、GPLv2コンテンツ管理システム（CMS ）用のいわゆる独自プラグインやテーマ（またはスキン）が批判にさらされており、議論の両陣営が存在します。これらのシステムの例としては、DrupalやWordPressなどがあります。[ 84 ]
FSFはプラグインの呼び出し方法によって区別を設けています。プラグインが動的リンクによって呼び出され、GPLプログラムの関数呼び出しを行う場合、そのプラグインは派生作品である可能性が非常に高いです。[ 85 ]
他のプログラムと通信する行為だけでは、すべてのソフトウェアが GPL である必要はありません。また、GPL ソフトウェアを非 GPL ソフトウェアと一緒に配布する場合も同様です。ただし、GPL ソフトウェアの権利が制限されないようにするためのいくつかの条件に従う必要があります。以下は、ソフトウェアが GPL プログラムと通信したり、GPL プログラムとバンドルしたりすることがどの程度許可されているかを説明する GPL FAQ ( gnu.org ) からの引用です。[ 86 ]
「集約版」とその他の種類の「修正版」との違いは何ですか？
「アグリゲート」とは、複数の独立したプログラムを同じCD-ROMなどのメディアにまとめて配布したものです。GPLでは、他のソフトウェアのライセンスが非フリーまたはGPLと互換性がない場合でも、アグリゲートを作成および配布することが許可されています。唯一の条件は、各プログラムの個別のライセンスでユーザーに認められている権利の行使を禁止するライセンスの下でアグリゲートをリリースしてはならないということです。
2つの独立したプログラムと、2つの部分からなる1つのプログラムの境界線はどこにあるのでしょうか？これは法的な問題であり、最終的には裁判官が判断することになります。適切な基準は、通信のメカニズム（exec、パイプ、RPC、共有アドレス空間内での関数呼び出しなど）と通信の意味論（どのような種類の情報が交換されるか）の両方に依存すると考えられます。
モジュールが同じ実行ファイルに含まれている場合、それらは間違いなく1つのプログラムに統合されます。モジュールが共有アドレス空間内でリンクされて実行されるように設計されている場合、それはほぼ間違いなく、それらを1つのプログラムに統合することを意味します。
対照的に、パイプ、ソケット、コマンドライン引数は、通常、2つの独立したプログラム間で通信を行うためのメカニズムです。そのため、これらが通信に使用される場合、モジュールは通常、別々のプログラムとして扱われます。しかし、通信の意味が十分に密接で、複雑な内部データ構造を交換するような場合は、2つの部分を1つの大きなプログラムとして統合する根拠にもなり得ます。
FSFは、情報交換の「複雑さ」と「親密さ」、そして（意味論ではなく）その仕組みという2つの側面を通して、「ライブラリ」と「その他のプログラム」を区別している。しかし、同財団は、この問題は明確ではなく、複雑な状況においては判例が結果を左右すると認めている。
GPLの最初の既知の違反は1989年に発生し、NeXT社がGCCコンパイラを拡張してObjective-Cをサポートするようにしたものの、変更内容を公表しなかった。[ 87 ]調査の後、同社は公開パッチファイルを作成した。この違反に関して訴訟は提起されなかった。[ 88 ]
2002年、MySQL ABは、米国連邦裁判所でProgress NuSphere社を著作権および商標権侵害で訴えた。NuSphere社は、MySQLのGPLライセンスのコードをNuSphere Geminiテーブルにリンクしたが、ライセンスを遵守しなかったため、MySQLの著作権を侵害したとされた。2002年2月27日の予備審理の後、両当事者は和解交渉に入り、最終的に和解した。[ f ]審理後、FSFは、裁判官が「GNU GPLを強制力のある拘束力のあるライセンスと見なしていることを明確にした」とコメントした。[ 89 ]
2003 年 8 月、SCO グループは、GPL には法的効力がないと信じており、SCO UnixからLinux カーネルにコピーされたとされるコードの部分について訴訟を起こすつもりであると表明した。これは SCO にとって問題のある立場だった。なぜなら、彼らはCaldera OpenLinuxディストリビューションで Linux やその他の GPL ライセンスのコードを配布しており、GPL の条項以外ではそうする法的権利があったという証拠はほとんどないからである。2018年 2 月、連邦巡回裁判所の判決、控訴、巡回裁判所への一部差し戻しの後、当事者は残りの請求を改めて表明し、最終判決に向けての計画を提示した。[ 90 ]残りの請求はプロジェクト モンテレーに関するもので、2021 年 11 月に IBM が TSG (旧 SCO) の破産管財人に 1425 万ドルを支払うことで和解した。[ 91 ]
2004年4月、Netfilter / iptablesプロジェクトは、Sitecom GermanyがGPLの条項に違反してNetfilterのGPLライセンスソフトウェアの配布を中止することを拒否したため、ミュンヘン地方裁判所からSitecom Germanyに対する仮差止命令を獲得した。NetfilterのHarald Welteは、Institut für Rechtsfragen der Freien und Open Source Software（ifrOSS、英語では「自由およびオープンソースソフトウェアに関する法的問題研究所」）の共同創設者であるTill Jaegerによって代理された。2004年7月、ドイツの裁判所はこの差止命令をSitecomに対する最終判決として確定した。[ 92 ]裁判所の正当化理由は次のとおりです。
この判決は、FSFのエベン・モーグレンが以前に予測していた通りのものでした。この判決は2つの点で重要でした。1つは、GPLの条項に違反することが著作権侵害になり得ることを裁判所が初めて確認したこと、もう1つは、ドイツ法の下でGPLv2の執行可能性に関する判例を確立したことです。 [ 93 ]
2005年5月、ダニエル・ウォレスはインディアナ州南部地区でフリーソフトウェア財団を相手取り訴訟を起こし、GPLは価格を（ゼロに）固定しようとする違法な試みであると主張した。この訴訟は2006年3月に、ウォレスが有効な反トラスト法違反の主張を立証できなかったことを理由に却下された。裁判所は「GPLは、自由競争とコンピュータオペレーティングシステムの配布を阻害するのではなく、むしろ促進しており、その利益は消費者に直接渡る」と指摘した。[ 94 ]ウォレスは訴状をさらに修正する機会を与えられず、FSFの訴訟費用を支払うよう命じられた。
2005年9月8日、ソウル中央地方裁判所は、GPLライセンス作品から派生した営業秘密に関する訴訟において、GPLは重要ではないとの判決を下した。 [ 95 ]被告側は、GPLを遵守しつつ作品を配布しながら営業秘密を維持することは不可能であるため、営業秘密の侵害には当たらないと主張した。この主張は根拠がないと判断された。
2006年9月6日、gpl-violations.orgプロジェクトは、 D-Link Germany GmbHが配布するストレージデバイスでLinuxカーネルの一部を著作権侵害的に使用した件に関して、D-Link Germany GmbHに対する訴訟で勝訴した。 [ 96 ]判決では、GPLは有効であり、法的拘束力があり、ドイツの裁判所で有効であるとされた。[ 97 ]
2007年後半、BusyBoxの開発者とソフトウェア自由法センターは、組み込みシステムにおけるBusyBoxの販売業者からGPL準拠を勝ち取るためのプログラムを開始し、準拠しない販売業者を提訴した。これらの訴訟は、GPLの義務履行のために裁判所を利用した米国初の事例であると主張された（BusyBox GPL訴訟を参照）。
2008年12月11日、フリーソフトウェア財団（FSF ）は、シスコシステムズ社を、同社のLinksys部門による著作権侵害で提訴した。侵害の対象となったのは、FSFのGPLライセンスのcoreutils、readline、Parted、Wget、GNU Compiler Collection、binutils、およびGNU Debuggerソフトウェアパッケージである。Linksysは、これらのパッケージをWRT54GワイヤレスルーターのLinuxファームウェア[ 98 ]やその他多数のデバイスに配布している。これらのデバイスには、DSLモデムやケーブルモデム、ネットワーク接続ストレージデバイス、VoIPゲートウェイ、仮想プライベートネットワークデバイス、ホームシアター（またはメディアプレーヤー）デバイスなどが含まれる[ 99 ] 。
FSFは、6年間にわたる数々の問題を受けてシスコを提訴した。
シスコは6か月後、いくつかの措置に同意することで訴訟を和解させた。
2011年、GNU EmacsがGPLの意図する精神に反して、対応するソースコードのないバイナリファイルを誤って2年間リリースしていたことが発覚し、著作権侵害となった。[ 101 ]リチャード・ストールマンはこの事件を「非常に悪い間違い」と表現し、[ 102 ]すぐに修正された。FSFは、これらのバイナリファイルを配布することで意図せずGPLに違反した下流の再配布者を訴えることはなかった。
2017年、 Ghostscriptインタープリタの開発元であるArtifexは、Ghostscriptを含むオフィススイートの開発元であるHancomを提訴した。ArtifexはGhostscriptに対して2つのライセンスを提供している。1つはAGPLライセンス、もう1つは商用ライセンスである。HancomはArtifexから商用ライセンスを取得せず、またオフィススイートをフリーソフトウェアとしてリリースすることもなかった。Artifexは米国地方裁判所でHancomを提訴し、2つの主張を行った。1つ目は、HancomによるGhostscriptの使用は著作権侵害である、2つ目は、HancomによるGhostscriptの使用はライセンス違反である、という主張である。裁判所は、GPLライセンスは有効な契約であり、Hancomは契約違反を犯したと判断した。[ 103 ] [ 104 ]
2021年7月20日、オープンソースのチェスエンジンStockfishの開発者は、チェスソフトウェアの作成者であるChessBaseをGPLv3ライセンス違反で訴えた。[ 105 ] Stockfishの開発者は、ChessBaseがStockfishのコードにわずかな変更を加えただけで、新しいチェスエンジン（Fat Fritz 2とHoudini 6）を顧客に販売したと主張した。[ 106 ]さらに、Fat Fritz 2は革新的なチェスエンジンであるかのように宣伝された。Stockfishの見解では、ChessBaseはGPLに従ってこれらの製品をフリーソフトウェアとして配布しなかったため、ライセンスを侵害した。
1年後の2022年11月7日、両当事者は合意に達し、紛争は終結した。近い将来、ChessBaseはStockfishコードを含む製品の販売を中止し、同社のウェブページ上の適切な通知を通じて顧客にこの変更を知らせることになった。しかし、1年後にはChessBaseのライセンスは復活することになった。Stockfishは損害賠償や金銭的補償を求めなかった。[ 107 ] [ 108 ] [ 109 ]
複数の他のライセンスでライセンスされたコードは、GPL に基づくプログラムと矛盾なく組み合わせることができます。ただし、作品全体に対する制限の組み合わせが、GPL で許可されている範囲を超える追加の制限を課さないことが条件です。[ 110 ] GPL の通常の条項に加えて、適用できる追加の制限と許可があります。
FSFは、オリジナルのMIT/Xライセンス、BSDライセンス（現在の3条項形式）、Artistic License 2.0 [ 117 ]など、最も一般的なライセンスの多くを含むGPL互換フリーソフトウェアライセンスのリスト[ 115 ]を維持しています[ 116 ]。
GPLv3以降、特定の素材は他の素材と一方的に互換性があります。クリエイティブ・コモンズ表示-継承4.0国際ライセンスの下にある素材（テキストやその他のメディアなど）は、GPLライセンスの素材（主にソフトウェア）にリミックスできますが、その逆はできません。これは、ゲームエンジン（GPLライセンス）とゲームスクリプト（ CC BY-SAライセンス）などのニッチなユースケースに当てはまります。[ 118 ] [ 119 ]
David A. Wheeler は、フリー (またはオープンソース) ソフトウェア開発者は GPL 互換ライセンスのみを使用するべきだと主張している。なぜなら、他のライセンスを使用すると、他の人が参加してコードを提供することが難しくなるからである。[ 120 ]ライセンスの非互換性の具体的な例として、Sun MicrosystemsのZFSファイルシステムは、GPL と互換性のないCommon Development and Distribution Licenseの下でライセンスされているため、GPL ライセンスの Linux カーネルに含めることができない。さらに、ZFS は特許で保護されているため、GPL と互換性のある独自開発の実装を配布するには、Oracle の許可が必要となる。[ 121 ]
多くの企業は、マルチライセンス方式を採用し、GPL版を配布するとともに、パッケージを独自のコードと組み合わせたい企業（静的リンクまたは動的リンクを使用する企業）に独自のライセンスを販売しています。こうした企業の例としては、 MySQL AB、Digia PLC（Qtフレームワーク、2011年以前はNokia製）、Red Hat（Cygwin）、Riverbank Computing（PyQt）などが挙げられます。Mozilla Foundation （ Mozilla Application Suite、Mozilla Thunderbird、Mozilla Firefoxなどの製品を提供）のような他の組織も、マルチライセンス方式を採用し、GPLやその他のオープンソースライセンスに基づくバージョンを配布しています。
ソースコードが何であるかが明確であれば、テキスト文書（またはより一般的にはあらゆる種類のメディア）にGPLを使用することが可能です。ソースコードは「作品に変更を加えるための好ましい形式」と定義されています。[ 122 ]ただし、マニュアルや教科書については、FSFは代わりに、この目的のために財団が作成したGNUフリー文書ライセンス（GFDL）の使用を推奨しています。 [ 123 ]それにもかかわらず、2006年に採択された決議で、Debianの開発者は、GFDLがGPLと互換性がないため、プロジェクトのドキュメントをGPLでライセンスすることを推奨しました。[ 124 ]つまり、GFDLでライセンスされたテキストは、GPLソフトウェアに組み込むことはできません。[ 125 ]同様に、フリーソフトウェアのマニュアル作成に専念しているFLOSS Manuals財団は、2007年に、テキストにGFDLではなくGPLを使用することを選択しました。[ 126 ]
コンピュータフォントにGPLを使用する場合、これらのフォントで作成された文書や画像もGPLの条件に基づいて配布する必要があるかもしれません。この依存関係は、書体（つまりフォントの外観）を有用物とみなし、著作権の対象とならない国では適用されませんが、フォントファイルは著作権で保護されたコンピュータソフトウェアとみなされます。この状況は、文書がフォントに「リンク」されているとみなされる可能性があるため、フォントの埋め込みを複雑にする可能性があります。言い換えれば、文書にベクターフォントを埋め込むと、文書がGPLの下でリリースされることになりますが、フォントのラスタライズレンダリングはGPLの対象になりません。FSFは、この依存関係が望ましくない場合のためにGPLフォント例外を提供しています。[ 127 ]
歴史的に、GPLファミリーはFOSSドメインで最も人気のあるソフトウェアライセンスの1つです。[ 7 ] [ 128 ] [ 9 ] [ 10 ] [ 11 ] [ 129 ]
1997年に当時最大のフリーソフトウェアアーカイブであったMetaLabを調査したところ、GPLライセンスのソフトウェアが全体の約半分を占めていることが分かった。[ 128 ]同様に、2000年にRed Hat Linux 7.1を調査したところ、ソースコードの53%がGPLライセンスで提供されていたことが判明した。[ 9 ] 2003年現在SourceForge.netに掲載されているプロジェクトの大部分はGPLファミリーに属しており、掲載されている全プロジェクトの約68%、オープンソース業界認証を受けたライセンスプロジェクトの82.1%を占めている。[ 130 ] 2008年8月現在 GPLファミリーは、Freecodeに掲載されている44,927のフリーソフトウェアプロジェクトのうち70.9%を占めている。[ 10 ]
2007 年 6 月に GPLv3 がリリースされた後、この新しいライセンス バージョンの採用について広く議論され、一部のプロジェクトはアップグレードしないことを決定しました。[ 131 ]例えば、Linux カーネル、MySQL、BusyBox、AdvFS、[ 132 ] Blender、VLC メディア プレーヤー、MediaWiki はGPLv3 の採用を見送りました。[ 40 ] [ 42 ] [ 133 ] [ 134 ] [ 135 ] [ 136 ] [ 137 ] [ 138 ] それでも、GPLv3 のリリースから 2 年後、Google のオープンソース プログラム オフィス マネージャーのChris DiBona は次のように報告しました。Google Codeサービスでホストされているプロジェクトを含め、GPL ライセンスのオープンソース プロジェクトの 50% が GPLv2 から GPLv3 に移行しました。[ 11 ]
2011年、GPLv3のリリースから4年後、Black Duck Softwareのデータによると、オープンソースのライセンスプロジェクト全体の6.5%がGPLv3であり、42.5%がGPLv2であった。[ 139 ] [ 140 ] 2011年後半、451 Groupのアナリスト、Matthew Aslettは、Black Duck Softwareの統計に基づいて、コピーレフトライセンスは減少し、寛容なライセンスが増加したとブログ記事で主張した。[ 141 ]同様に、2012年2月、Jon Buysは、 GitHubプラットフォームの上位50プロジェクトのうち、デュアルライセンスおよびAGPLプロジェクトを含め、GPLライセンスの下にあるプロジェクトはわずか5つだったと報告した。[ 142 ]
2009年から2013年までのGPLの使用統計は、ライセンスの普及を分析する際に、Walter van HolstがFreecodeウェブサイトのデータから抽出したものです。[ 12 ]
2013 年 8 月、Black Duck Software によると、同社の Web サイトのデータでは、オープンソース プロジェクトの 54% が GPL ライセンス ファミリーを使用しており、個々のライセンスの内訳は下の表のとおりであると示されました。[ 129 ]しかし、2013 年後半に行われた調査では、GPL ライセンス ファミリーでライセンスされたソフトウェアは実際に増加しており、Black Duck Software のデータでも GPL でライセンスされたソフトウェア プロジェクトの総数が増加していることが示されました。この後の調査では、Debianプロジェクトのリポジトリから収集された公開情報を使用しており、この調査では、Black Duck Software が統計の収集に使用した方法論を公開していないことを批判しています。[ 145 ]カナダのビクトリア大学コンピュータ サイエンス学科の Daniel German 教授は、2013 年に、どのフリー ソフトウェア ライセンスが最も広く使用されているかを決定する方法論上の課題について講演し、Black Duck Software の結果を再現できないことを示しました。[ 146 ]
Black Duckによると、2015年にはGPLv2はMITライセンスに首位の座を奪われ2位に転落し、GPLv3は4位に後退、Apacheライセンスは3位を維持した。[ 7 ]
2015 年 3 月、 GitHubのリポジトリの分析により、ライセンスされたプロジェクトの約 25% が GPL ライセンス ファミリーを使用していることが明らかになりました。[ 152 ] 2016 年 6 月、 Fedora プロジェクトコミュニティのパッケージの分析により、最も人気のあるライセンスは GNU GPLv2 以降であり、最も人気のあるライセンス ファミリーは GNU GPL ファミリーであることが明らかになりました (MIT、BSD、GNU LGPL ファミリーがそれに続きます)。[ 153 ]
2018年4月、whitesourcesoftware.comはFOSSエコシステムを分析しました。その結果、GPLv3は3位（18%）、GPLv2は4位（11%）となり、MITライセンス（26%）とApache 2.0ライセンス（21%）に次ぐ結果となりました。[ 154 ]
GPLは、Mac App Storeや特定の他のソフトウェア配信プラットフォーム（スマートフォンやPC上）など、多くのデジタルアプリケーション配信システムと互換性がありません。問題は「隣人にコピーを提供する権利」にあります。この権利は、有料ソフトウェアのコピーを防止するためにプラットフォームに組み込まれているデジタル著作権管理（DRM）システムによって侵害されるためです。問題のアプリケーションストアでアプリケーションが無料であっても、コピーするとそのアプリケーションストアの利用規約に違反する可能性があります。[ 155 ]
DRM で制限されたソフトウェアを独自のライセンスで販売するアプリ ストアと、オンライン ソフトウェアリポジトリを介したデジタル配信というより一般的な概念には違いがあります。NetBSD 、FreeBSD、Ubuntu、Fedora、Debianなど、ほぼすべての最新の Unix システムとLinux ディストリビューションにはアプリケーション リポジトリがあります。これらの特定のアプリケーション リポジトリにはすべて GPLライセンスのソフトウェア アプリが含まれており、コア プロジェクトがベース システムで GPL ライセンスのコードを許可していない場合でも (たとえば OpenBSD) 含まれています。[ 156 ] Ubuntu App Storeなど、独自の商用ソフトウェア アプリケーションと GPL ライセンスのアプリケーションの両方が同じシステムで利用できる場合もあります。Mac App Store (および同様のプロジェクト) が GPL ライセンスのアプリと互換性がないのは、アプリ ストアの概念に内在する理由によるものではなく、ストア内のすべてのアプリが Apple DRM 制限を使用するという Apple の利用規約の要件によるものです。[ 155 ]対照的に、Ubuntu のアプリ ストアにはそのような要件はありません。「これらの規約は、適用されるオープンソース ソフトウェア ライセンスに基づくお客様の権利を制限または制約するものではありません。」[ 157 ]
2001年、マイクロソフトのCEOスティーブ・バルマーはLinuxを「知的財産権の意味で、触れるものすべてに付着する癌」と表現した。[ 158 ] [ 159 ]マイクロソフトによるGPLへの攻撃に対し、著名なフリーソフトウェア開発者や支持者らが共同声明を発表し、ライセンスを支持した。[ 160 ]マイクロソフトはGPLライセンスのコードを含むMicrosoft Windows Services for UNIXをリリースした。2009年7月、マイクロソフトは約2万行のLinuxドライバコードをGPLライセンスでリリースした。[ 161 ]このリリースのHyper -VハイパーバイザコードはGPLライセンスのオープンソースコンポーネントを使用していた。このコードは元々、GPLライセンスのソフトウェアでは許可されていない独自のバイナリ部分に静的にリンクされていた。[ 162 ]
GPLを「ウイルス性」と表現する表現は、「General Public Virus」または「GNU Public Virus」（GPV）と呼ばれることもあり、GPLv1がリリースされた翌年にまで遡ります。[ 163 ]
2001年、マイクロソフトの上級副社長であるクレイグ・マンディがGPLを「ウイルス性」と表現したことで、この用語はより広く一般に知られるようになった。[ 164 ]マンディは、GPLはプログラム全体の伝達のみを許可するという点で「ウイルス性」の効果があると主張している。これは、 GPLライブラリにリンクするプログラム自体がGPL互換ライセンスの下にある必要があり、そうでない場合は結合して配布できないことを意味する。
2006年のインタビューで、リチャード・ストールマンは、マンディの「ウイルス」という比喩は不適切だと答えた。GPLの下でのソフトウェアは、他のソフトウェアを「攻撃」したり「感染」させたりするものではないからだ。したがって、ストールマンは、GPLをウイルスに例えるのは不適切であり、GPLの下でのソフトウェアのより適切な比喩はクモの植物であると考えている。つまり、この植物の一部を別の場所に置いても、そこでも育つということだ。[ 165 ]
しかしながら、GPLのウイルス性という概念は後に他の人々にも採用されました。[ 166 ] [ 167 ]例えば、2008年の記事では、「GPLライセンスは『ウイルス性』であり、以前にGPLライセンスされていたソフトウェアのごく一部でも含む派生作品を作成する場合は、GPLライセンスの下でライセンスされなければならない」と述べています。[ 168 ]
FreeBSDプロジェクトは、「GPLのあまり知られていない意図せざる用途として、ソフトウェア企業を出し抜こうとする大企業にとって非常に有利な点がある。言い換えれば、GPLはマーケティングの武器として利用するのに適しており、全体的な経済的利益を低下させ、独占的行動につながる可能性がある」と述べている。また、同プロジェクトは、GPLは「ソフトウェアを商業化して利益を得ようとする人々にとって、深刻な問題となる可能性がある」とも述べている。[ 169 ]
リチャード・ストールマンは、倫理的に許容される商業化の一例として、フリーソフトウェアライセンスの例外を販売する慣行について論じた。この慣行は、特定のソフトウェアの著作権者が次の2つのステップを踏むことを意味する。
ストールマン氏は、例外の販売という慣行を「1990年代から容認されてきたものであり、時折企業に提案してきた。この方法によって、重要なプログラムがフリーソフトウェアになったこともある」と考えている。FSFは例外の販売は行っていないものの、この商業化手法が倫理的に容認されるべきであるという示唆として、X11ライセンス（コピーレフトではないフリーソフトウェアライセンス）との比較を提案している。コピーレフトではないフリーソフトウェアライセンスの下で特定のプログラムをリリースすれば、そのコードをプロプライエタリソフトウェアに組み込むことが可能になる。ストールマンは、「X11 ライセンスの下で何かをリリースするのは間違っていると結論付けるか（これは受け入れがたいほど極端な結論だと思う）、この含意を拒否するかのどちらかだ。コピーレフト以外のライセンスを使うのは弱いし、通常は劣った選択肢だが、間違っているわけではない。言い換えれば、例外を販売することでプロプライエタリ ソフトウェアへの埋め込みが一部可能になり、X11 ライセンスではさらに多くの埋め込みが可能になる。これが X11 ライセンスを不適切としないのであれば、例外を販売することも不適切とはならない」と述べている。[ 170 ]
2000年、開発者であり著者でもあるニコライ・ベズロウコフは、 GPLの基盤とストールマンのソフトウェア開発モデルに関する分析と包括的な批判をまとめた「ソフトウェアの自由の迷宮」を出版した。[ 171 ] [ 172 ]
GPLのパロディとして、Do What The Fuck You Want To Public License (WTFPL) のバージョン2が、2004年にDebianプロジェクトリーダーのSam Hocevarによって作成されました。[ 173 ]
2005年、オープンソースソフトウェアの提唱者であるエリック・S・レイモンドは、当時のFOSSエコシステムにおけるGPLの関連性に疑問を呈し、「もはやGPLは必要ない。GPLは、オープンソースソフトウェアは脆弱で保護する必要があるという考えに基づいている。GPLが多くの人々の採用に対する不安を招かなければ、オープンソースはもっと早く成功していたはずだ」と述べた。[ 174 ]リチャード・ストールマンはこれに対し、「GPLは、プログラムのすべてのユーザーが、実行、ソースコードの調査と変更、コピーの再配布、修正版の公開といった基本的な自由を確実に得られるように設計されている。 レイモンドは、ソフトウェアの共有と変更の自由を守ることを含まない『オープンソース』の目標と価値観という観点からこの問題に取り組んでいる」と反論した。[ 175 ]
2007年、 GPL草案委員会に参加したアリソン・ランダルは、GPLv3がGPLv2と互換性がないこと[ 176 ]、および定式化が不明確であること[ 68 ]を批判した。同様に同年、ウィリアム・ハーレー（別名ワーリー）は、GPLv3が開発者に焦点を当てていないため、開発者が寛容なライセンスに移行することを促し、GPLの衰退を予見した[ 177 ] 。
InformITのウェブサイトに掲載された2009年の記事で、David Chisnallは「GPLの失敗」について、その非互換性やライセンス条項の複雑さなどの問題点を説明した。[ 178 ]
2014年、開発者兼経営者のブライアン・カントリルは、コピーレフトGPLを「反協調的」であるとして「企業向けオープンソースのアンチパターン」と呼び、代わりに寛容なソフトウェアライセンスを推奨した。[ 179 ]
2006年9月、GPLv3の草案作成過程において、Linus Torvalds、 Greg Kroah-Hartman、Andrew MortonといったLinuxカーネルの著名な開発者数名が、FOSSコミュニティの分裂を警告した。「GPLv3のリリースは、我々が頼りにしているオープンソースの世界全体のバルカン化を予兆するものである」 [ 38 ]。同様に、Benjamin Mako Hillもほぼ同時期に、単一のライセンスよりも、団結し協力し合うコミュニティの方が重要だと主張した[ 180 ] 。
2007年にGPLv3がリリースされた後、一部のジャーナリスト[ 42 ] [ 139 ] [ 181 ]とToybox開発者のRob Landley [ 45 ] [ 46 ]は、このリリースを批判した。GPLv3の導入により、オープンソースとフリーソフトウェアのコミュニティ間の分裂が広がった。なぜなら、大幅に拡張されたGPLv3は、基本的にGPLv2と互換性がないからである。[ 111 ]互換性は、GPLのオプションの「またはそれ以降」条項の下でのみ提供される。このオプションは、Linuxカーネルなどのソフトウェアでは採用されなかった。[ 40 ] Bruce Byfieldは、GPLv3のリリース前は、GPLv2がオープンソースとフリーソフトウェアのコミュニティ間の統一要素であったと指摘した。[ 139 ]
LGPLv3 に関して、GNU TLS のメンテナーである Nikos Mavrogiannopoulos 氏も同様に、「もし [LGPLv3 の] 主な目的がフリー ソフトウェアで使用されることだと仮定するならば、それは明らかにその目的に反している」と主張しました。この発言は、ライセンスの互換性の問題により、Mavrogiannopoulos 氏がGnuTLSライブラリのライセンスを LGPLv3 から LGPLv2.1 に戻した後になされたものです。[ 182 ] [ 183 ]
2007年、弁護士でコンピュータ専門家のローレンス・ローゼンは、GPLv3によってGPLv2とApacheライセンスソフトウェアの互換性の問題が解決されたため、Apacheライセンスを使用するコミュニティがGPLコミュニティと互換性のある方法で協力できるようになったことを称賛した。この流れで彼は、「GPLv3の最大の成功事例の1つは、フリーでオープンソースのソフトウェアの宇宙全体を、世界中の顧客向けの包括的なオープンソースソリューションに統合できるという認識になるだろうと私は予測している」と述べた。[ 184 ]
2013年7月、Flaskフレームワークの作成者であるアーミン・ロナッハーは、FOSSエコシステムにおけるGPLの互換性について、あまり楽観的ではない結論を下した。「GPLが関係する場合、ライセンスの複雑さは、面白くない謎解きになる」。彼はまた、Apache License 2.0とGPLv2の間の対立が依然としてエコシステムに影響を与えていることにも言及した。[ 185 ]
… このページでは、特定のライセンスがDebianフリーソフトウェアガイドライン（DFSG）にどのように準拠しているかについてのdebian-legalコントリビューターの意見を紹介します。 … 現在Debian mainに含まれるライセンスには以下が含まれます。
- ...
- 海外駐在員/MITスタイルのライセンス
- ...
...
これはGNU GPLの最新バージョンです。フリーソフトウェアライセンスであり、コピーレフトライセンスです。
...
GPLv3はGPLv2と単独では互換性がありません。しかし、GPLv2でリリースされたほとんどのソフトウェアでは、GPLの後のバージョンの条項も使用できます。この場合、GPLv3のコードを使用して、目的の組み合わせを作成できます。
...
…
以下のライセンスはOSIによって承認されています。
…
- GNU一般公衆利用許諾契約書バージョン2（GPL-2.0）
- GNU一般公衆利用許諾契約書バージョン3（GPL-3.0）
- ...
…
これはGNU GPLの以前のバージョンです。フリーソフトウェアライセンスであり、コピーレフトライセンスです。
…
GPLv2自体はGPLv3と互換性がありません。しかし、GPLv2でリリースされたほとんどのソフトウェアでは、GPLの後のバージョンの条項も使用できます。この場合、GPLv3のコードを使用して、目的の組み合わせを作成できます。
…
60.5%、GPLv2 6.9%、GPLv2 1.9%、GPLv3 1.6%
は企業が関与するたびに勢いを失っているが、GPLのプログラムは企業が関与するたびに勢いを増している。
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)ファイル「gplv3-draft-1」のコメントを表示中
... 727 件見つかりました
「gplv3.fsf.org ドラフト 3 へのコメント」 。2008年 7 月 3 日のオリジナルからアーカイブ済み。2008年3 月 31 日に取得。
ファイル「gplv3-draft-3」内のコメントを表示中 ... 649 件見つかりました「gplv3.fsf.org ドラフト 4 へのコメント」 。2008年 10 月 2 日にオリジナルからアーカイブ済み。2008年3 月 31 日に取得。
ファイル「gplv3-draft-4」内のコメントを表示中 ... 298 件見つかりました
の現行バージョン (ディスカッション ドラフト 2) は、解決しようとしている GPLv2 の実質的かつ特定された問題がないという理由で、セクション 1 の必要性テストに初読で不合格です。しかし、より深く読み解くと、現在の FSF ドラフトには他にもいくつかの問題があることがわかります。5.1 DRM 条項
... 5.2 追加制限条項
... 5.3 特許規定
... FSF はすべてのプロジェクトを GPLv3 に移行し、他のすべての GPL ライセンスのプロジェクトにも移行するよう圧力をかけることを提案しているため、GPLv3 のリリースは、私たちが頼りにしているオープンソースの世界全体の
バルカン化の
前兆であると予想されます。
第二に、GPLv3 をめぐる Linus Torvalds と他のカーネル開発者とフリー ソフトウェア財団 (FSF) の間の争いは続いており、Torvalds は FSF にうんざりしていると述べています。
カーネルに関して有効なGPLのバージョンは、明示的に別途規定されていない限り、_この_特定のバージョンのライセンス（つまりv2、v2.2やv3.xなどではない）のみです。
「ある意味では、Linux は、FSF が推進しているものと、オープンソースや Linux が常に目指してきたものとの分裂を明確にしたプロジェクトでした。オープンソースや Linux は、自由に対する宗教的な信念ではなく、技術的な優位性を重視してきました」とトーバルズ氏はゼムリン氏に語った。「GPL バージョン 3 は FSF の目標を反映しており、GPL バージョン 2 はライセンスが果たすべき役割とかなり一致しています。そのため、現在カーネルはバージョン 2 を採用しています。」
私が直接指摘したい唯一の注目すべき点は、COPYINGファイルにおける明確化であり、カーネルに有効なGPLの特定のバージョンのみが明確にされていることです。これは、0.12あたりからずっと使われているライセンスと同じなので、驚くことではありませんが、それを明示しておこうと思いました。
ほぼ完成した草稿を見ると、彼らが簡潔さを優先事項として考えたことはおそらくないだろうし、そもそも考えたことすらないだろうと言わざるを得ない。...
オープンソース ライセンスの言語選択は、その自由をサポートし、ユーザーと開発者に力を与えることができる。GPLv3 はそうではない。
いいえ。インストール情報を提供するという要件など、GPLv3 の要件の一部は GPLv2 には存在しません。そのため、これらのライセンスは互換性がありません。両方のライセンスでリリースされたコードを組み合わせようとすると、GPLv2 のセクション 6 に違反することになります。ただし、GPL「バージョン 2 以降」でリリースされたコードは、GPLv3 が許容するオプションの 1 つであるため、GPLv3 と互換性があります。
LibreCAD と FreeCAD はどちらも LibreDWG を使用したいと考えており、DWG ファイル形式ライブラリをサポートするためのパッチも用意しているが、統合することができない。これらのプログラムは一般的な GPLv2 ライセンスに依存しているが、フリー ソフトウェア財団は LibreDWG を GPLv3 でのみ使用することを許可しており、GPLv2 では許可していない。プロクディン、アレクサンドル（2012年12月27日）。「LibreDWG騒動：終焉か、それとも新たな始まりか？」。librearts.org 。 2025年2月4日取得。
…LibreDWGを介したフリーCADソフトウェアにおけるDWGファイルのサポートに関する残念な状況。私たちは、今となってはこの問題は解決されるべきだと考えています。FSFから最終的な回答を得ました。 …「ライセンスを変更するつもりはありません。」
のマニュアルからテキストを借用して、いかなるフリー ソフトウェア プログラムにも組み込むことはできません。これは単なるライセンスの不適合ではありません。GFDL が特定のフリー ソフトウェア ライセンスと互換性がないというだけではなく、あらゆるフリー ソフトウェア ライセンスと根本的に互換性がないのです。したがって、新しいプログラムを作成し、使用するライセンスについて、フリー ライセンスであること以外に何の制約もない場合、GFDL のテキストを含めることはできません。現状の GNU FDL は、Debian フリー ソフトウェア ガイドラインを満たしていません。上記のように、ライセンスには重大な問題があり、そのため、GNU FDL でライセンスされた作品を配布物として受け入れることはできません。
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)「ライセンス -> OSI: ... GNU General Public License (GPL) (32641 プロジェクト)、GNU Library or Lesser General Public License (LGPL) (4889 プロジェクト)」(全 45727 プロジェクト中、82.1%)
現在、GPL v2 から GPL v3 への移行の決定は、多くのオープンソース プロジェクトで激しく議論されています。IP コンプライアンス ソフトウェアのプロバイダーである Palamida によると、GPL v2 からそれ以降のバージョンに移行したオープンソース プロジェクトは約 2489 件あります。
は非常に多くの組み込みシステムで使用されているため、GPLv3のDRM反対論争の中心となっている。...
しかし、実際の結果は以下の通りである。BusyBoxは次のリリースからGPLv2のみとなる。一般的に、「またはそれ以降のバージョン」という文言を削除することは法的に正当化可能であり、他のGPLv2のみのコードを統合することでいずれにせよこの問題が発生すると認められている。
Landley, Rob (2006 年 9 月 9 日) 「Re: GPLv2 と v3 の移行について...」 lwn.net 2015 年11 月 21 日取得。
どうか藁人形論法をでっち上げないでください。BusyBox を GPLv3 でライセンスすることは、役に立たず、不必要で、過度に複雑で、混乱を招くものであり、さらに実際のデメリットもあると考えています。 1) 役に立たない: GPLv2 を廃止することはありません。
[BlenderのToni Roosendaal氏:] 「Blenderもまだ『GPLv2以降』です。今のところ、私たちはそれに固執しており、GPL 3に移行しても私が知る限り明らかなメリットはありません。」
2001年、VLCはOSI承認のGNU General Public Licenseバージョン2の下でリリースされ、その「それ以降のバージョン」を使用するオプションが一般的に提供されていました（ただし、当時はそれ以降のバージョンはありませんでした）。2007年6月29日にフリーソフトウェア財団（FSF）がGNU General Public License（GPL）の新しいバージョン3をリリースした後、VLCメディアプレーヤーおよびvideolan.orgでホストされている他のソフトウェアプロジェクトの貢献者は、VLCメディアプレーヤーおよびホストされている他のプロジェクトの将来のバージョンのライセンス条項をGPLバージョン3に更新する可能性について議論しました。
... これらの新しい追加要件が、特に家電市場において、現代の産業および経済の現実と一致しない可能性があるという強い懸念があります。ライセンス条項をGPLバージョン3に変更することは、現時点ではコミュニティ全体の利益にならないと考えています。そのため、VLCメディアプレーヤーの今後のバージョンは、引き続きGPLバージョン2の条項に基づいて配布していく予定です。
で開発しているソースコードは、デフォルトでGNU GPLバージョン2以降としてライセンスされています。
当時、この決定は行き詰まりに直面した状況では賢明に思えた。しかし現在、Black Duck Softwareによると、フリーソフトウェアの42.5%でGPLv2が使用され、GPLv3は6.5%未満で使用されている。
上記のチャートから、GPLファミリーが最も多く使用されていることが明らかです（以前はMITと誤って計算していました）。その他の主要なライセンスは、MIT、BSD、LGPLファミリー、Artistic（Perlパッケージ用）、LPPL（texliveパッケージ用）、ASLです。
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)ウイルス性はライセンスの増殖を促し、「GPL強制悪夢」に寄与する。これは、他の多くのライセンスが論理的にGPLと互換性がなく、Linux環境で作業する開発者にとって不必要に困難な状況となる（KDEはその良い例であり、Pythonはあまり知られていない例である）。
はGPLのパロディであり、同様の著作権ヘッダーと変更の許可リスト（つまり、なし）があります。たとえば、gnu.org/licenses/gpl-3.0.en.htmlを参照してください。WTFPLの文言の目的は、GPLよりも自由度を高めることです。
はもう必要ありません。オープンソースソフトウェアは脆弱で保護する必要があるという考えに基づいています。GPLが多くの人々の採用に対する不安を招かなければ、オープンソースはもっと早く成功していたでしょう。」
は、ソフトウェアの共有と変更の自由をソフトウェア利用者が守ることを含まない「オープンソース」の目標と価値観という観点からこの問題に取り組んでいる。おそらく彼は、これらの目標を達成するために GNU GPL は必要ないと考えているのだろう。
ないに違いないと思うかもしれません。...
ライセンスが純粋に GPLv2 のクリーンアップ版であれば、非互換性はなく、FSF はプロジェクトを新しいライセンスに更新させることに何の意図も持たず、同時にプロジェクトが更新に反対する理由もありません。順調に進むでしょう。
バージョン3は、リチャード・ストールマンとフリーソフトウェア財団を、そもそもこの組織を非常に影響力のあるものにしている開発者たちから遠ざけることになるだろう。
アンチパターン：反協調的ライセンス
GPL は、フリーおよびオープンソース ソフトウェア コミュニティのほぼ全員が共通して持っているものの 1 つです。そのため、改訂版は意見の相違、意見の相違、ビジネス モデルの違い、戦術の違いを浮き彫りにする可能性があります。
... GPL が協力する能力を阻害する可能性は、FSF が提案する最も根本的なテキストの変更よりもはるかに危険であることを覚えておくのが賢明でしょう。 ...
何よりも、私たちのコミュニティとその目標は、どんなに広く普及しているライセンスであっても、単一のライセンスよりも重要であることを覚えておく必要があります。
...これは、トーバルズのようなビジネス志向の開発者とフリーソフトウェアの純粋主義者との間で、オープンソースコミュニティにおける分裂が拡大していることを示す最新の兆候である。
LGPLv3 は、GNU Lesser General Public License の最新バージョンです。これは、成功を収めた LGPLv2.1 ライセンスに続き、Free Software Foundation によって GNU General Public License バージョン 3 の対応物としてリリースされました。GNU Lesser General Public License の目標は、プロプライエタリ ソフトウェアとフリー ソフトウェアの両方で使用できるソフトウェアを提供することです。この目標は、これまで LGPLv2.1 によってうまく達成されており、このライセンスを使用するライブラリが多数存在します。現在、最新版として LGPLv3 がありますが、問題は、LGPLv3 がこの目標をどの程度達成しているかということです。私の意見では、ほとんど達成されていません。その主な目標がフリー ソフトウェアで使用されることだと仮定すると、明らかにその目標に失敗しています。
ライセンスの互換性の混乱 – GPL が関係する場合、ライセンスの複雑さは、面白くない謎解きバージョンになります。考慮すべきことが非常に多く、考慮すべき相互作用も非常に多くあります。そして、GPL の非互換性が依然として人々に影響を与える問題であるという事実を、多くの人が忘れているようです。たとえば、すべてが GPLv3 にアップグレードされた今、GPLv2 と Apache Software License 2.0 の非互換性は過去のものになっているはずだと考える人もいるでしょうが、実際には、GPLv2 しか使えない人や GPLv3 に同意しない人が十分にいるため、Apache Software License のプロジェクトの一部は移行する必要があることがわかります。たとえば、Twitter の Bootstrap は現在、ASL2.0 から MIT に移行していますが、これはまさに、GPLv2 との互換性をまだ必要とする人がいるためです。影響を受けたプロジェクトの中には、Drupal、WordPress、Joomla、MoinMoin Wikiなどがありました。この事例からもわかるように、Joomla 3は互換性のないライセンス（GPLv2とASL 2.0）であるにもかかわらず、Bootstrapをバンドルしました。GPLと互換性がないもう1つの伝統的な例は、GPLと相性の悪いライセンスを持つOpenSSLプロジェクトです。このライセンスはGPLv3とも互換性がありません。この一連の騒動は、あまり好ましくない一部の人々がGPLライセンスを通じてライセンストローリングを始めたため、特に興味深いものとなっています。ロナッハー、アーミン（2009）。「GPL を使用したいですか？」。lucumr.pocoo.org。
