GNU General Public License
Linux Journal誌の記事によれば、IP法の専門家でOSIの法務顧問 (General counsel)も務めるローレンス・ローゼンは、リンクの動的・静的を含む種別は、ある種のソフトウェアが二次的著作物であるか否かについての問題とは概ね関係がない、すなわち、そのソフトウェアが、クライアントソフトウェアとライブラリ、またはそれら個別とのインタフェースが意図されているか否かについての問題のほうがより重要である、と主張している。彼は、「新規のプログラムが二次的著作物であるか否かの主な指標は、原著作物のプログラムのソースコードが、『複製と添付(コピーアンドペースト)』する意図をもって利用され、新たなプログラムを作成する任意の手段において、改変、翻案またはその他の変更を加えたか否かに係っている。もしそうでないならば、私はその新規のプログラムは二次的著作物ではないと主張するだろう」と述べる。また、彼はこの記事の中で、ソフトウェアの組み合わせ・バンドリング、リンクのメカニズムなど、その他関連する多くの指摘意図を挙げている。さらに、彼は、彼の弁護士事務所のウェブサイトにて、このような「市場原理」的要素はライブラリリンクの原理といった技術的な要素よりも重要であると主張している。
プラグインまたはモジュール(例えば、フリーなドライバ"nouveau"とは別個に存在する、NVIDIAのプロプライエタリなデバイスドライバ、またATI FireGL RXなどのグラフィックカード用カーネルモジュールがその一例)が固有の著作物と合理的に見なされる際、それらライブラリがGPLに従わなければならないか否かという、別個の問題もある。これに対する見解は、著作物がGPLv2ならば、分離していると合理的に理解されるプラグインまたは、プラグインを利用するために設計されたソフトウェア用のプラグインは、任意のライセンスで許諾され得る。GPLv2の条文段落において特に注目される箇所は以下の条文である。
You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
...
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
...
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
実際にはGPLv3でも同じであり、条項の文面は多少異なっているが、上記と同様の内容が、以下となる(詳しくはセクション"改変版ソースの伝達"を参照)。
You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
...
c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
...
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
事例分析として挙げると、DrupalやWordPressのようなGPLv2でリリースされていたCMSに対し、それらに提供されていたプロプライエタリと想定されるプラグイン、テーマ (コンピュータ)、スキンなどは、両プロジェクトサイドにて議論が巻き起こる共に、非難されるようになってしまった。
一方、Linuxカーネルではこのような結合の状況分析を行うことなく、カーネルの著作権の影響範囲とユーザ空間プログラムが派生物ではないことをライセンステキスト冒頭で述べている。
<pre>
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".[...]
</pre>
参考訳:
<pre>
注意! この(Linuxカーネルの)著作権は通常のシステムコールによる
カーネル・サービスを利用するユーザ空間プログラムを影響下に置くことは「ない」。
このことは、カーネルの通常利用を考慮したものであるに過ぎない。
そして、このことは「派生物」との分類を受けるものでは「ない」。(後略)
</pre>
前述のセクションの実例を挙げる。GPLソフトウェアへのパッチを提供した場合は、そのパッチが「適用したGPLソフトウェアとは別の著作物」とみなされる可能性も含んでいる。これは、前述の通り、
GPLv2の第2節後半部分 These requirements [...]  do not apply to those sections when you distribute them as separate works.
GPLv3第5項最終段落 Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
に規定されている。即ちGPLソフトウェアを含む「集積物(aggregate)の他の部分」と認められれば、GPLに反しない、言い換えればGPLよりパーミッシブ・ライセンスでパッチを公開しても良い。例えばパッチが単なる修正ではなく、単体で再利用可能な全く別種の機能強化と見なされればそれは集積物の別の部分と規定でき、そのパッチのみに対しGPLと矛盾せずかつGPL以外のライセンス(BSDライセンスやzlib Licenseなど)を適用する事も可能である。一例をあげると、MySQLは、「リンク例外条項付きGPLv2」と商用ライセンスとでデュアルライセンシングされている。これに対しGoogleはMySQL向けのパッチをBSDライセンスで提供していた。このパッチはオリジナルのMySQLに由来しないコードのため、GPLで保護されたMySQLの「集積物とは別の部分」となる。BSDライセンスは独占的なライセンスであろうとも両立するので、結果的にこのパッチは、MySQLをGPLで利用するライセンシーと共に商用ライセンスで利用する者も適用可能である。また同時にそのパッチからサブルーチンのみを取り出し、BSDライセンスされたソフトウェアにも同様のルーチンを導入する事も可能となる。
GPLなソフトウェアと別のプログラムが単に結合している場合は、本来、全てのソフトウェアをGPLにすることも要求されない、そしてGPLなソフトウェアを非GPLソフトウェアとともに頒布することも要求されない。しかし、稀な条件において、GPLの権利を保証することを妨げる障害が取り除かれるであろう。次の文は、GNU.org ウェブサイトに存在するGPL FAQからの引用である。これは、ソフトウェアが、バンドルされたGPLプログラムと結合を許される範囲がどこまでかを記述している。
What is the difference between an “aggregate" and other kinds of “modified versions"?
An “aggregate" consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are non-free or GPL-incompatible. The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program's individual license would grant them.
Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
このように、FSFは「ライブラリ」と「その他のプログラム」とを、次の2つの観点双方を用いて線引きしている。
データ・情報交換に係る「複雑さ」(complexity)と「親密さ」(intimacy) (「セマンティクス」)
セマンティクスだけではなくメカニズム(mechanism rather than semantics)
しかし、FSFは、この問題は明確な結論はなく、複雑さの条件について判例("case law")により決められる必要があるだろう、と譲歩している。
GPL FAQでは「結合メカニズム」(「コミュニケーションのメカニズム」)の例として、プロセス間通信、遠隔手続き呼出し (RPC)、カーネル空間・ユーザー空間の通信やシステムコール、パイプ、execによるプロセス起動などを挙げている。これら「結合メカニズム」を用いてGPLなソフトウェアと接続する場合は、個別のプログラムであるため結合ではないとも見なせるが、そのやり取りするデータの如何によって接続先が二次的著作物であると見なされる余地も残されている(「コミュニケーションのセマンティクス」)。これに対する明確な法廷判断はまだない。
GPLの条文自体はGFDLやGPLの下に自由に配布されているわけではなく、ライセンス著作者は条文の改変(modifications)を許可していない(GPLの条文自体の著作権はフリーソフトウェア財団が持つ)。GPLはプログラムの受領者に(本ライセンスの直接の対象となる)本プログラムと共に本ライセンスの複製を(a copy of this License along with the Program)得る権利を与えているため、未改変のライセンスの複製と頒布(distribution; 配布)は許されている。GPL FAQによると、仮に改変する場合は、別の名前とし、「GNU」について言及せず、フリーソフトウェア財団から許諾を得ている場合を除いて改変版ライセンスからGPLの前文(Preamble)を削除した場合に限り、GPLの改変版を利用して新たなライセンスを作成しても良い。そのようにして作成された派生ライセンスに対し、FSFは一切の法的異議申し立てを行うことはないが、そういったライセンスは一般にGPLと両立しない(互換性が無い、incompatible)ので、FSFは推奨していない 。
前述のとおり、GPLの条文自体は著作権で管理されており、その保持者はFSFである。しかしながら、FSFはGPLのもとリリースされた著作物の著作権は保持しない。これも前述したが、例外は、著作権者が明示的にFSFに著作権を譲渡した場合である。ただし、そのような事例はGNUプロジェクトに属するプログラムや寄贈されたプログラムを除いてあまりない。ライセンス違反が発生した場合、個々の著作権者のみが、訴訟を起こす権限を持つ。
FSFは、FSFの許可なくGPLの前文(Preamble)を含めた、派生ライセンスを使用しない限り、GPLに基づいた新しいライセンスを作成することを許可する。しかしながら、このようなライセンスはGPLと両立しない(incompatible)場合があるので、作成しないほうがよい。またそれは、明らかにライセンスの氾濫を生じさせる。翻訳も翻案権の行使であるため、ライセンスの翻訳は原則認められないが、その翻訳が非公式であることを明記し、FSFの求めに応じて翻訳をアップデートできるならば翻訳を許可される。
その他、GNUプロジェクトにより作成されたライセンスには、GNU Lesser General Public License、GNU Free Documentation 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のもと実装し頒布しようとしたとしても、それでもなおサン(現在はオラクル)の許諾が必要となると予想される。
他の一部のフリーソフトウェア・プログラムは、複数のライセンスによりデュアルライセンスされているものがある。その中にはライセンスの一つにGPLが選択されていることもよくあり、「デュアルライセンスはもっと広まる」と独立ソフトウェア・コンサルタントのテッド・ロシュ(Ted Roche)は指摘している。この方法だと、GPLを適用しないまま二次的著作物を頒布することを認めることができる。これは、二次的著作物に有償の商用ライセンスを適用することも可能にする。MySQLなどはまさにこの例に当てはまる特筆すべき例である。
一般的にプロプライエタリソフトウェアはGPLソフトウェアと組み合わせることはできない。しかしこのような場合でも、マルチライセンスを利用することでGPLソフトウェアを組み合わせることも可能となる。
GPLのもとで頒布するとともに、静的リンクなどを使用する場合やそうではなく動的リンクを使用する場合においても、パッケージにプロプライエタリなコードを組み合わせたいと望む企業のため、二次的著作物を独占的な条件・ライセンスで頒布・販売可能にする商用ライセンスを同時に提供するマルチライセンシング・ビジネスモデルが多く存在する。このようなビジネスモデルを採用する企業と採用したソフトウェアには、Oracle社(MySQL AB社のMySQL)、Digia社(旧Trolltech社のQtフレームワーク
)、Namesys社(ReiserFS)、Red Hat社(Cygwin)、Riverbank Computing社(PyQt)などがある。
その他、Mozilla Application Suite、Mozilla ThunderbirdそしてMozilla Firefoxを製品に持つMozilla Foundation(Mozilla Corporation)のような企業はGPLだけではなく同時に他のオープンソースライセンスでも頒布可能なようにマルチライセンスを採用するケースがある。
GPLv3はGPLv2と比べ、条文の大幅な変更にも関わらず、内容自体には大きな変更はないとも言える。しかし全く無いわけではなく、とりわけGPLv3の特許関連条項と、(反DRM条項改め)反TiVo化条項などは、GPLv2の第6節にある「(GPLv2で認められた)これ以上他のいかなる制限」(further restriction、同様の条項がGPLv3の第10項のさらなる権利制限)に相当するため、原則GPLv3はGPLv2と両立しない。ただし、GPLv2で保護される著作物が“version 2 or later,"でリリースされていれば両立する。
GPLはフリーあるいはオープンソースソフトウェア用のライセンスとして圧倒的な人気がある。
きわめて大きいソフトウェア・アーカイブをもつibiblioの1997年の調査では、約半数をGPLのソフトウェアが占めていた。
2001年の調査では、Red Hat Linux 7.1 に使われているソースコードの 50%がGPLでライセンスされている。
2006年1月の時点で、SourceForge.netにホスティングされているプロジェクトの約68%が、2007年8月の時点で、Freshmeatに掲載されている43,442のフリーソフトウェア・プロジェクトのうち65%近くが保護されるライセンスとしてGPLを使用している(両サイトを運営しているのはLinuxとGPLに造詣の深い企業Geeknet社である)。
Black Duck Software社により管理される"Open Source License Resource Center"によると、フリーソフトウェア/オープンソースライセンスでリリースされたソフトウェアパッケージ全体の約60%がGPLをライセンスに採用していると示されている。