利用者:Exec second/GNU General Public License
GNU General Public Licenseとは、GNUプロジェクトでの利用のためリチャード・ストールマンが作成したフリーソフトウェアライセンスである。八田真行によるライセンスの日本語翻訳版ではGNU 一般公衆利用許諾書と呼称している[6][注釈 2]。GNU GPLまたは単にGPLとも呼ばれる。 概要GPLはderived work[注釈 3]の頒布条件を同一のライセンス条件に限定できるという、コピーレフト型のソフトウェアライセンスとしては初めてのものであり、広く利用されている[7]。この考えに基づき、GPLはプログラムの受領者（recipient）にフリーソフトウェアの定義に基づく権利を付与し、たとえ著作物（works[注釈 4]に変更や改変が加えられる場合であっても、または追加があろうとも、ソフトウェアの自由を守るためコピーレフトを行使する。これはBSDライセンスをはじめとする緩やかなフリーソフトウェアライセンス（寛大型フリーソフトウェアライセンス）とは明確に異なる。 ただし、GPLの条文自体はGPLの下配布されているわけではなく、ライセンス著作者は条文の改変(modifications)を許可していない。GPLの条文自体の著作権はフリーソフトウェア財団（Free Software Foundation, 以下略称のFSFと呼ぶ）が持つ。GPLはプログラムの受領者に当該プログラムと共に本ライセンスの複製（a copy of this License along with the Program）を得る権利を与えているため、未改変のライセンスの複製と頒布(distribution, 配布)は許容される[8]。GPL FAQ[9]によると、仮にライセンスを改変する場合は別の名前とし、「GNU」について言及せず、FSFから許諾を得ている場合を除いて改変版ライセンスからGPLの前文(Preamble)を削除する場合に限り、GPLの改変版を利用した新たなライセンスを作成しても良い。そのようにして作成された派生ライセンスに対し、FSFは一切の法的異議申し立てを行うことはないが、そういったライセンスは一般にGPLと両立しない(互換性が無い、incompatible)ので、FSFは推奨していない。 GPLはFSFによって公開され、管理されているが、その他FSFが著作権を持つライセンスには、GNU Lesser General Public License(GNU LGPL)、GNU Free Documentation License(GNU FDL、またはGFDL)そしてGNU Affero General Public Licenseバージョン3(GNU AGPLv3)がある。 歴史GPLは1989年にリチャード・ストールマンによって、GNUプロジェクトのソフトウェアの配布を目的に作られた。オリジナルのGPLは、初期のGNU Emacs、GNUデバッガそしてGNU Cコンパイラの配布に利用していた類似のライセンスを基に、それらを組み合わせたものをベースとしている[10][11]。前記3つのライセンスは、現在のGPLと似たような条文を含んでいる。しかし、それらは各プログラム固有のライセンスであり、似通っているとはいえ、互いの互換性は全くなかった[12]。ストールマンの目標は、いかなるプロジェクトでも使用可能で、それゆえ多くのプロジェクトがコードを共有することを可能にさせる単一の汎用的なライセンスを作り出すことだった。 ちなみにGPL誕生以前、Emacsの頒布条件となっていたライセンス(Emacs General Public Licence)が生まれたきっかけは、ジェームズ・ゴスリンが作成し、当初自由な利用が認められていたGosling Emacsのコードが突如ゴスリンにより独占的な許諾条件にされてしまったことが契機となっている[11][13]。この許諾条件の変更の影響により、ストールマンは自身のEmacsのコードを書き換えなければならなくなった。 またGPL、GNUプロジェクトの誕生について、次のような逸話もある。 当時、ストールマンはMIT人工知能研究所でSymbolics社製のLISPマシンで動くソフトウェアを開発していたが、ストールマンがSymbolics社に対して提供したソースコード（ストールマンが作ったものであるが、パブリックドメイン版であるもの）の改変版について、同社が著作権を根拠にソースコードを開示しなかったことに腹を立てGPLを考案したといわれる[14]。 いずれにせよ、これ以降いかにしてソースコードの自由な利用を保証するかということにストールマンは腐心するようになる。 ストールマンは、ソフトウェアに対する自由と は何かという問題を提起し、そのひとつの答えを提示した。GPLは、「自由なソフトウェア」を、有償・無償に関係なく、頒布できるようにした、という単純 な意味だけでなく、「ソフトウェアは自由であるべき」という思想が存在することを一般に認知させたという意味において極めて重要な意義がある。 普及度GPLはフリーあるいはオープンソース・ソフトウェア用のライセンスとして圧倒的な人気がある。2007年8月の時点で、Freshmeatに掲載されている43,442のフリーソフトウェア・プロジェクトのうち65%近くが、2006年1月の時点で、SourceForge.netにホスティングされているプロジェクトの約68%が保護されるライセンスとしてGPLを使用している[15]（両サイトを運営しているのはLinuxとGPLに造詣の深い企業Geeknet社である）。同様に2001年の調査では、Red Hat Linux 7.1 に使われているソースコードの 50%がGPLでライセンスされており[16]、きわめて大きいソフトウェア・アーカイブをもつMetalabの1997年の調査では、約半数をGPLのソフトウェアが占めていた[17]。 GPLでライセンスされている傑出したフリーソフトウェアのプログラムには、LinuxカーネルやGNUコンパイラコレクション(GCC)がある。 他の一部のフリーソフトウェア・プログラムは、複数のライセンスによりデュアルライセンスされているものがある。その中にはライセンスの一つにGPLが選択されていることもよくあり、「デュアルライセンスはもっと広まる」と独立ソフトウェア・コンサルタントのテッド・ロシュ(Ted Roche)は指摘している[18]。この方法だと、GPLを適用しないまま二次的著作物を頒布することを認めることができる。これは、二次的著作物に有償の商用ライセンスを適用することも可能にする。MySQLなどはまさにこの例に当てはまる特筆すべき例である。詳しくはセクション"マルチライセンス"を参照せよ。 GPLにより付与される強力なコピーレフトはGNU/Linuxの成功にとって重要な役割を果たしているとも言われる。なぜなら、コミュニティに全く還元しようとしないソフトウェア企業にただ搾取されるのではなく、著作物が世界全体に貢献し、自由であり続けるという確証をGPLはプログラマに与えたからである[19]。 GPLは幾度か改訂されており、1991年にはバージョン2がリリースされている。バージョン3がリリースされるまで、それに従うこと15年間、FLOSSコミュニティの幾人かは、GPLでライセンスされているプログラムを、ライセンスの意図に反し、搾取する事につながる抜け道(loopholes; 抜け穴、ループホール)に対し懸念を抱くようになった[20]。これらの懸念の中には、TiVo化（Tivoization。GPLでライセンスされたプログラムが含まれているにも関わらず、改変版ソフトウェアの稼動を拒絶するハードウェアについての問題）、Webインタフェースの裏側に隠れ公開されることのない改変版GPLソフトウェアの利用、AGPLバージョン1と同等の互換性問題、FLOSSコミュニティと敵対するための武器として特許を行使する企てと見なされる、マイクロソフトとある特定のFLOSSディストリビュータ間の特許契約などがある。 FSFならびにFLOSSコミュニティは、これら懸念に対し真剣に取り組むべく、バージョン3への改訂作業を始めた[21][22]。2007年6月29日、GPLバージョン3は公式にリリースされた[23]。 主な特徴GPLは、プログラム（日本国著作権法ではプログラムの著作物）の複製物を所持している者に対し、概ね以下のことを許諾するライセンスである。
GPLと、BSDライセンスなどをはじめとする、より制限の緩いフリーソフトウェアライセンスとの間の主な違いは、GPLが二次的著作物[注釈 3]についても、上記の4点の権利を保護しようとする点である。この仕組みはコピーレフトと呼ばれ、GPLでライセンスされた著作物は、その二次的著作物に関してもGPLでライセンスされなければならない。これは、BSDライセンスが、二次的著作物を独占的なものとして再頒布することを許しているのとは対照的である。 バージョン履歴バージョン1バージョン1は、1989年2月25日にリリースされた[24][25]。このライセンスは、ソフトウェア頒布者が制限しようとする主に2つの手段から、フリーソフトウェアの定義たる自由を守る働きを持っていた。第一の問題は、頒布者がバイナリ、すなわち実行ファイルのみを公開するかもしれないということである。しかしながらバイナリは人間にとって読み取れる形式ではなく、また改変もできない。このことを防ぐため、GPLv1では、バイナリを頒布するいかなるベンダーも、同じライセンスの条項のもと、機械可読なソースコードの形で利用できるようにしなければならないとしている（ライセンスの第3a節、第3b節を見よ）。 第二の問題は、ライセンスに追加の制限を加える、もしくは頒布において別の制限があるソフトウェアを組み合わせることのどちらかにより、頒布者が追加の制限を加える可能性があるということだった。もしこのことが成されれば、その時、制限の2つの集合の和は、 組み合わされた著作物に適用されるだろうが、それはすなわち、受け入れられない制限が加えられたことに等しい。この様な事態を避けるため、GPLv1で は、改変版は、全体として、GPLv1の条項の下頒布されなければならないと規定している（ライセンスの第2b節、第4節を見よ）。このため、GPLv1 の条項の下頒布されているソフトウェアは、それよりも緩やかなライセンスで保護されるソフトウェアと組み合わせて頒布することが可能となる。なぜなら、組 み合わせによって全体を通して頒布に係るライセンス条項に変化はないからである。しかし、GPLv1の条項の下頒布されているソフトウェアとそれよりも制 限の厳しいライセンスで頒布されるソフトウェアを組み合わせることは、GPLv1の条項の下全体が頒布されるという要件と衝突するため、できない。 バージョン2リチャード・ストールマンによれば、GPLv2で最大の変更は第7節、彼に言わせると、パトリック・ヘンリーの名文句「自由か然らずんば死を」("Liberty or Death")の一節である[26]。他の利用者の自由を尊重するような方法で、GPLで保護されたソフトウェアの頒布が妨げられる場合（たとえば、法的規制によりソフトウェアをバイナリ形式でしか頒布できないとき）、この節に従えば、頒布は一切できない。GPLv3でも同様の条項が存在し、幾分簡素化されたうえ主旨が明確になっている。これは、フリーソフトウェア開発者や、フリーソフトウェアを単に使用する者から金を脅し取ろうと特許を行使する企業の企みをすこしでも減らすことを見込んでいる。 1990年までには、現存するプロプライエタリなライブラリと本質的には同等な機能を持つCライブラリやその他のソフトウェア・ライブラリに対して制限の緩いライセンスのほうが戦略的に有効なことが、明らかになってきた[27]1991年6月にGPL第2版がリリースされた際、第2のライセンス、つまりLibrary General Public License (LGPL) が、(初版にもかかわらずGPLと相補的なことを示すため第2版として) 同時に導入された。GNUの思想における位置づけを反映させるため、Lesser General Public Licenseと名を変え、1999年、LGPL2.1がリリースされた。 バージョン3→詳細は「§ GPLv3にまつわる話題」を参照
 GNU General Public License version 3（略称GNU GPLv3、単にGPLv3とも）は、ソフトウェア（プログラム・ライブラリなど）を含む著作物に対し、著作物の著作者・著作権保持者やライセンス受諾者[A]の権利や、プログラムの受領者のためにライセンス許諾者が与える権利、またソフトウェアの自由と衝突するような法や法的権利の制限（DRM、特許の利用、他者を差別するような特許ライセンスの排除）などに関する基本理念を以前のバージョンのライセンスより明文化している。 2005年後半、FSFは、GPLバージョン3(GPLv3)の策定に関するアナウンスを行った[28]。2005年の時点でGPLは様々なFLOSSプロジェクトのソフトウェアに採用されていたこともあり、FSFが単独で改訂することにより起こりえる問題を回避するため、改訂プロセスは公開で行うことが同時に発表された[28]。2006年1月16日、GPLv3の最初の議論用草稿(discussion draft)が公開され[29]、公開協議プロセスを開始した。当初公開協議は9ヶ月から15ヶ月を想定していたが、終わってみると、4つの草稿公開に延べ18ヶ月にまで要した。公式のGPLv3は2007年6月29日、FSFにより発表された。GPLv3は、リチャード・ストールマンにより起草され、エベン・モグレンならびにSoftware Freedom Law Center(SLFC)による法的助言を受けている[30]。 ストールマンによると、もっとも重要な改訂点は、ソフトウェア特許、他のフリーソフトウェア・ライセンスとの両立性(compatibility; 互換性)、「ソースコード」とは何を指すのかの定義[A]、ソフトウェアの改変に関するハードウェアの制限(TiVo化)そしてデジタル著作権管理(Digital Rigits Management, DRM)との関連がある[30][31]。その他の改訂点は、国際化[A]、ライセンス違反時の対処手段そして可能ならば著作権者により追加的条項（additional terms[注釈 6]）を与える手段に関連している。 他注目に値する改訂点としては、GPLv3で保護された著作物の著作権者が、パッチなどを提供しそれに改変を加えた貢献者(contributor)に対し、ある種の条件または要求を課すということを許諾する条項が加えられている。これらに加えて、新しく導入された要件の一つには、時折Affero条項(Affero clause、Affero節)とも呼ばれるが、Software as a serviceのようなASPモデルによるGPLの条項を回避しようとする試み(ASP loophole; ASPの抜け道[32])に対し、これを封じようと意図しているものも含まれる。この条項が追加された結果、GNU Affero General Public Licenseバージョン3(GNU AGPLv3)が作成されている。GPLv3とAGPLv3は互いに両立はしないが、リンクや結合のみを認める相補的な条項を共に持っている。 また、GPLv3で許諾されるソフトウェアは、米国のDMCAや日本の著作権法、不正競争防止法が規定している「技術的制限手段」（技術的保護手段、例: DRM）の「解除」を認める条項が追加されている[33]（詳細はセクション"技術的保護手段回避を禁ずる法への対抗措置"を参照）。 公開協議プロセスは、FSFを調整役、SFLC・Free Software Foundation Europe(FSFE)[34]その他フリーソフトウェア開発組織による支援のもと進められた。この間、gplv3.fsf.org[35]というウェブポータルサイトが立ち上げられ、ここを経由し多くの一般からのコメントが集められた[36]。このポータルサイトは、策定プロセスのために開発されたstet[37]というソフトウェア上で稼働している。これらコメントは、およそ130名ほどから成る4つの協議グループ(committee)[38]に渡された。この130名はFSFの目標に対しそれを支持する人物並びにそれと対立する人物双方が含まれている。これら協議グループは一般から提示されたコメントを精査し、新しいライセンスがどうあるべきか決定するため、ストールマンにその要約を回付した。 公開協議プロセスを経て、初回の草稿には962ものコメントが提出された[39]。終わってみると、延べ2,636ものコメントが提出されていた[40][41][36]。 初版の草稿公開ののち、GPLv2とGPLv3の非公式な差分（ただし、これはdiff出力による行単位ごとの単純な差分）が、FLOSSコミュニティ向け法律サイトGroklawにより公開された[42]。  2006年7月27日、GPLv3の討議用第2次草稿[43]が、LGPL第3版(GNU LGPLv3)の初版草稿とともに公開された[44]。初稿と第2稿の差分は、FSF[45]とFSFE[46]からそれぞれ提示されている。第2稿ではDRMに対抗する明確な目標が取り入れられている[47]。 第3稿は2007年3月28日に公開された[48][49]。この草稿は、かの物議を醸したマイクロソフトとノベルが締結したような特許相互ライセンス(patent cross-license)[50][51][52][53][54]を排除する意図を持つ文言を含んでおり[41][55]、反TiVo化条項(anti-tivoization clauses)はユーザ製品(User Product)・コンシューマ製品(Consumer Product)といった一般家庭で使用される製品に限定する旨定めている[41][56]。また、公開協議開始時点で削除が予告されていた地理的(頒布)制限(Geographical Limitations)[57]の項については、明白に削除されている。 最終稿となった第4の議論草稿[58][59]は2007年5月31日に公開された。この草稿では、Apache Licenseとの組み合わせを可能にする条項が導入された他、外部契約者(contractor)の役割を明確化し、マイクロソフト–ノベル間の契約のような明白な問題を回避する例外条項を加えている。この最後の例外条項は、第11項[注釈 7]第7段落に次のように記載されている（条文は正式公開版と同一である）。
こ れは、そのような契約を将来に渡って無効化することを目的としている。また本ライセンスは、マイクロソフトが、あるGPLv3ソフトウェアを利用するノベ ルの顧客に許諾したような特許契約（特許ライセンス、特許許諾、パテントライセンス）を、まさにそのGPLv3ソフトウェアを利用するユーザーすべてにまで（ユーザーの行為如何に全く関わらず）自動的に拡大適用することを意味する。ただし、マイクロソフトが法的にGPLv3ソフトウェアの伝達者(conveyor; 譲渡者)でもない限り、それは不可能である[60][61]。これはある種、特許契約に対しそれを他者に無制限に提供してしまうことから、ポイズンピルのような働きを持つとの意見もある[62]。ただし本条項導入の直接の契機となった、ノベルの行為そのものに対しては、本項第7段落最後に例外を設け、既得権条項を適用している[63][64]。 一方、態度を鮮明にしている幾人かの有名なLinuxカーネル開発者は、マスメディアに対しコメントを出し、議論用の初稿ならびに第2稿の一部に反対する旨の声名を発表した[65]。リーナス・トーバルズは、GPLv3の反DRM条項により、GPLv3でライセンスされたソフトウェアがDRMを利用したコンピュータ・セキュリティのメカニズムを享受できなくなるとして、LinuxカーネルのGPLv3への移行には明確に反対している[66]。リチャード・ストールマンは、2007年初めにもこの動きは収束すると期待していた[67]。第3稿に関しては、（反TiVo化条項が幾分緩められたため）リーナスは「満足している」と語っていた[68]、が最終稿が提出された後のコメントで、GPLv3はGPLv2と比べ（両者のデュアルライセンスが可能か考慮に入れた上、コードの全著作者からライセンス移行の合意を得るという途方も無い手間[69]を掛けたとしても）移行するメリットはないと述べていた[70][71]。 概ねこれらの議論は本質的には全く同じ視点に立ってはいるが、主にソフトウェアのコードの自由を重視するオープンソース陣営とそれのみではなくソフトウェアを利用するユーザーの自由の最大化を目的とするフリーソフトウェア陣営の考え方の違いが浮き彫りになったに過ぎない。ソフトウェアの自由な利用のためには、ソフトウェアの範疇に留まらず、広く働きかけることを厭わないとする後者の考え方が、GPLv3には色濃く出ている。 GPLv3はGPLv2と比べ、条文の大幅な変更にも関わらず、内容自体には大きな変更はないとも言える。しかし全く無いわけではなく、とりわけGPLv3の特許関連条項と、（反DRM条項改め）反TiVo化条項などは、GPLv2の第6節にある「(GPLv2で認められた)これ以上他のいかなる制限」(further restriction、同様の条項がGPLv3の第10項のさらなる権利制限)に相当するため、原則GPLv3はGPLv2と両立しない（ただし、GPLv2で保護される著作物がある条件を満たすとこれは解決する）[72]。 利用条件「GPLが適用された著作物の複製を受け取る全ての者」（Recipients; 受領者）は、GPLの条項と条件(terms and conditions; 利用条件)を遵守しなければならない。利用条件を遵守するライセンシー（the licensee; 被許諾者、ライセンシー[注釈 8]）は著作物を改変する許諾を与えられるのと同時に著作物または二次的著作(派生 derivative) 物の複製と頒布を許諾される。ライセンシーは、このようなサービスを提供するのに料金を課してもよいし、また無料で行ってもよい。この後者の許諾は、 GPLと商用再頒布禁止のソフトウェアライセンスとの相違点である。FSFは、フリーソフトウェアは商用利用を制限するべきではないと主張している[73]。また、GPLは、GPLが適用された著作物を如何なる値段で販売しても良い旨、明確に述べてある。 加えて、GPLは、頒布者がGPLにより許諾される以上のさらなる権利制限(further restrictions on the rights granted by the GPL)を課してはならないと述べている（GPLv2第6節、GPLv3第10項）。これは（純粋に契約である）秘密保持契約(non-disclosure agreement, non-disclosure contract)のもとソフトウェアを頒布するような手法を禁ずる。GPLのもと、頒布者はまた、GPLなソフトウェアにおける特許を行使するために、ソフトウェアにより行使されるいかなる特許をも「ライセンス」（特許ライセンス）として許諾する。 GPLv2の第3節とGPLv3の第6項によると、事前コンパイルされたバイナリとして頒布されるプログラムは次のいずれかを満たさなければならない。
また、GPLv2の第1節とGPLv3の第4項は、プログラムの受領者すべてにプログラムと共にGPLライセンスの複製を(all recipients a copy of this License along with the Program) 与えなければならないと規定している。GPLv3ではその第6項を満たす限りにおいて、ソースコードを利用可能な状態にするために、GPLv2で指定され た物理媒体以外にも、明示的に追加の手段を講じても良いとする。コンパイル済みコードを取得する方法とソースコードのありかが明確に分かる場合、近くの ネットワークサーバからまたはP2P送信によりソースコードをダウンロードさせる手段などもこの追加の手段に含まれる。 コピーレフト→詳細は「コピーレフト」を参照
改変された著作物を頒布する権利は、GPLにより無制限に付与されるわけではない。頒布者自身による改変が加えられたGPLによる著作物を頒布する際に、著作物全体を頒布するための要件は、GPLよりも強い要件であってはならない。 その要件とは、コピーレフト (Copyleft)として知られている。これは、ソフトウェアプログラムに関し、著作権 (copyright)を利用した法的な権能をもたらす効果がある。GPLで保護される著作物もまた、著作権で保護されているため、改変された形態でなくとも、ライセンスで規定されている場合を除き、ライセンシーはその著作物の再頒布の権利を持たない（フェアユースを除く。ただし、その記事やGPL FAQ[74]で述べられている通り、フェアユースにworld-wide principle; 世界的な原則、統一見解などない）。再頒布のような、通常著作権法で制限される権利をある人物が行使しようと考える場合、その人物はGPLの条項をただ従う必要がある。逆に、GPLの条項を遵守せず（例えば、ソースコードを開示しない）著作物の複製を頒布すると、著作権法に基づき著作権保持者から頒布差止等で提訴される可能性がある。 コピーレフトは、これ故、著作権法を本来の使用目的と正反対の目的を実現するために利用する。すなわち制限を課す代わりに、コピーレフトは、権利がのちに消失しないような方法で、他者への権利を許諾する[注釈 9]。GPLはまた、ライセンシーに対し再頒布の権利を無制限に許諾するのではなく、コピーレフトが主張する点において発見されるのは法律上の任意の欠陥であるべきことを保証している。 GPLで保護されるプログラムを頒布する多くの者は、ソースコードと共に実行ファイルを添付する。コピーレフトを満たす別の方法は、要求に応じて（CDのような）物理媒体を用いてソースコードを提供するという文書を提示することである。また事実としてGPLで保護されるプログラムの多くは、インターネット上で頒布されており、ソースコードはFTPまたはHTTPなどを用いてソースコードを遣り取りできるようにしているものが多い。インターネット上での頒布は本ライセンスを満たしている。 コピーレフトが適用されるのは、ある人物がプログラムを再頒布しようと求める場合にのみである。改変したソフトウェアを他の誰にも頒布しない限り、改変箇所 を公開しなければならない如何なる義務も免ぜられ、その改変版を私的な物とすることは許される。また、コピーレフトはソフトウェア自身のみに適用されるのであって、ソフトウェアの出力(outputs, アウトプット)には適用されないことには注意しておきたい（ただし、そのアウトプット自身がプログラム自体の二次的著作物ではない場合）。例えば 、GPLで保護されたコンテンツ管理システム("Contents Management Systems"; CMS)に対しその改変した派生版を動作させる一般ウェブポータル（ブログソフトウェアなど）は、その出力自体はプログラム自体の派生物ではないから、土台としたソフトウェアならびにその改変部分を頒布する必要はない。反例は、GPLで保護されたソフトウェア"GNU bison"である。この構文解析器の出力は、その派生物の一部をまさに含んでおり、そのため、この事実に対しGNU bisonにより許諾される特殊な例外条項(a special exception)が仮に存在しないならば、出力結果はGPLで保護される派生物となっていたであろう[75]。最新のGNU bisonでは、事実として、出力コードのヘッダにAs a special exception...という特殊例外条項が記述されている[76]。 なお（GPLに従う著作物に限ったことではないが）、GPLのもとで公開された著作物の著作権は、前述の通り譲渡しなければ個々のコードの著作権者が保有している。従ってGPLを無視した再頒布に対して、頒布の差止やGPL違反是正（エンフォースメント）を求める権利があるのはプログラムの著作権者だけであり、一般のライセンシーにはない[77]。ただ、大規模なFLOSS開発プロジェクトは一般的にワールドワイドであり、開発者の居住国が多岐に渡るため、多かれ少なかれ差異がある各国の著作権法にプロジェクト全体で合致させるのは困難を要す。このため一部のFLOSSプロジェクトでは各著作権者に代わり、コードの著作権を一括してプロジェクト（またはそれを統括する団体・法人組織）が引き受ける場合もある。GNUプロジェクトは、コードの受け入れに関し、米国著作権法の庇護を享受するため、ライセンス如何に関わらず、寄贈されたコードの著作権を原著作者より明示的にFSFに譲渡する場合にのみ受け入れている[78]。CMSのPloneならびにPlone財団(Plone Foundation)も似たような形式を採用している。 ライセンスと契約にまつわる問題GPLは契約ではなくライセンスとして設計されている[79][80]。コモン・ローの法的な権限の及ぶ範囲において、契約は契約法により支配されるが、他方ライセンスは著作権法のもと行使されるため、ライセンスと契約の法的な区別はいくらか重要である。しかしながら、大陸法のような契約とライセンスの相違点がない多くの法体系ではこの区別は意味を成さない[81]。 まず、GPLなソフトウェアを受け取ったライセンシーはどの国の著作権法に従うことになるかであるが、これは著作権やライセンスの一般論として知られており、すなわち著作権の準拠法は著作物の利用のあった国の法である（これを属地主義という。ただし異論もある）。よってGPLなソフトウェアを受け取ったライセンシーはその利用地の国の著作権法に従わなければならない。 GPLの条件に同意しない（"do not agree to"）、またはそれらを承諾しない（"do not accept"）人は、著作権法のもと、GPLライセンスされたソフトウェアまたはその二次的著作物(派生物)を複製または頒布する許諾を得ることはない（GPLv2第5節、GPLv3第9項）。しかしながら、もし彼らがGPLで保護されたプログラムを再頒布しないならば、彼らは猶も彼らの組織内でそのソフトウェアを好きなように使用しても構わない。そして、プログラムの利用により作成された著作物（生成されたプログラムもこの中に当てはまる）はこのライセンスの影響範囲に含めることを要求されない。 アリソン・ランダルは、ライセンスとしてのGPLv3はその支持者を不必要に混乱させており、同一の条件や法的効力を維持しつつ、簡略化すべきだと主張した[82]。 情報処理推進機構がSoftware Freedom Law Centerの協力の下作成した「GNU GPLv3 逐条解説書」[83]によると、GPLが契約かライセンスかの論争は、GPLがエンフォーシブル（enforceable）か否かという問題と同値であると結論付けられている[84]。すなわち、ライセンス違反が発生し、その法的な解決が法廷で争われる場合、GPLソフトウェアの著作者に認められる要求が著作権侵害請求に基づく違反者の頒布差止や損害賠償請求に留まるのか、はたまた、ライセンスをエンフォース（強制）し、ソースコードの開示にまで持っていけるのか、といった議論がしばしば起こるが、実際はGPLソフトウェアの利用地における準拠法によって、GPLが契約とみなせるか否かという問題に帰着すると述べている。例えば日本の民法ではGPLを契約と見なせるので（とりわけGPLv2の第2節、GPLv3の第9項は申込と承諾の意思表示であると解釈できる）、仮に法的な解決を求められる場合、裁判所は著作権侵害ではなく契約違反であるとの法的判断を下し、契約に定められているソースコードの開示まで請求できる可能性があるとの解釈が述べられている。ただし実際にそのような法的判断を下すのは裁判所及び裁判官であり、状況によってはGPLがライセンサーの単なる権利不行使宣言であるとみなされ、民法上の権利濫用の禁止や禁反言を始めとする信義則の主張だけに過ぎないという判断が下される場合も想定される[85]。また契約とみなされない場合、ライセンス違反者が行った行為が著作権侵害であるというライセンサーの主張は、GPLが要求する義務が著作権法上で定められる義務に含まれない場合があるため（日本の著作権法の場合、GPLの一部義務がこれに当てはまる）、その主張は認められない可能性がある[85]。いずれにせよ、GPLを法的な契約と認める、または認めない判例は両者とも未だもって存在しない。 ライセンス条文の著作権者前述のとおり、GPLの条文自体は著作権で管理されており、その保持者はFSFである。しかしながら、FSFはGPLのもとリリースされた著作物の著作権は保持しない。これも前述したが、例外は、著作権者が明示的にFSFに著作権を譲渡した場合である。ただし、そのような事例はGNUプロジェクトに属するプログラムを除いて滅多にない。ライセンス違反が発生した場合、個々の著作権保持者のみが、訴訟を起こす権限を持つ[77]。 FSFは、FSFの許可なくGPLの前文(Preamble)を含めた、派生ライセンスを使用しない限り、GPLに基づいた新しいライセンスを作成することを許可する。しかしながら、このようなライセンスはGPLと両立しない(incompatible)場合があるので、作成しないほうがよい[9]。またそれは、明らかにライセンスの氾濫を生じさせる。翻訳も翻案権の行使であるため、ライセンスの翻訳は原則認められないが、その翻訳が非公式であることを明記し、FSFの求めに応じて翻訳をアップデートできるならば翻訳を許可される[86]。 その他、GNUプロジェクトにより作成されたライセンスには、GNU Lesser General Public License、GNU Free Documentation Licenseが含まれる。 リンクと派生物ライブラリFSFによると、「GPLは改変版、もしくは改変版の一部のリリースを要求することは述べていない。改変版を一切公開せず、改変を加えることや、私的に利用することは自由である。」と主張している[87][88][89]。しかしながら、仮にある人物がGPLライセンスされたオブジェクトを公開するならば、ライブラリリンクに関する問題が提起される。すなわち、もし、プロプライエタリなプログラムがGPLなライブラリを使用するならば、そのプロプライエタリなプログラムは（一般にプロプライエタリ・ソフトウェアはソースコードが自由な許諾の下利用できない為）GPLに違反する、はたまたそうではないのか、という問題がある。 この重要な論点は、非GPLソフトウェアがライセンス的、すなわち著作権法的に、GPLなライブラリに静的リンクまたは動的リンク可能であるか否かという問題に行き着く。この問題に関して、異なるいくつかの見解が存在する。GPLのもとリリースされるコードの二次的著作物が全て、それら自身もまた、GPLに従わなければならないとの要求は明白である。しかし、GPLなライブラリを使用する、そして、GPLなソフトウェアをより巨大なパッケージと組み合わせる(bundle, バンドルする)（概ね静的リンクによりバイナリを混合する場合などを想定すればよい）点に関しては、曖昧さが惹起する。これは究極的には、GPLそれ自体(per se, in itself)とは無関係の問題であるが、著作権法が二次的著作物をどう定義するかということと関連した問題である。この議論に関して、次のようないくつかの異なる見解が存在する。 見解: プロプライエタリ・ソフトウェアを動的リンク、静的リンクすることはGPLに違反するGPLのライセンス条文自体の著作権を保持する法人組織でもあり、GPLでライセンスされる著名なソフトウェア製品を多数提供しているFSFは、動的リンクされたライブラリを利用する実行ファイルは、実際には二次的著作物である、と強く主張している。しかしながら、このことは、お互いを「結合する」(連携する、communicate)だけの分離された別個のプログラムには適用されないとしている[90][注釈 10]。 FSFはまた、コピーレフトという点で、GPLとはほぼ同一であるが、「ライブラリ利用」という目的のために、リンクの許諾を追加的に与える、LGPLというライセンスも作成した。 リチャード・ストールマンとFSFは、プロプライエタリな世界と比較し、より豊富なツールを提供することによりフリーソフトウェアな世界を護持することを目的として、ライブラリ作者に対し、GPLの下でのライブラリのライセンシングを明確に促している。これは、プロプライエタリ・プログラムがGPLで保護されたライブラリを一切使用できないようにすることを狙っている[91]。 プラグインFSFは、プラグインの呼び出し方法についてはまた別であると認識している。もし、プラグインが動的リンクにより呼び出され、関数呼び出しをGPLプログラムに提供するならば、その時には、プラグインは、概ね二次的著作物であると見なされる[92]。 見解: プロプライエタリ・ソフトウェアを静的リンクすることはGPLに違反するが、動的リンクに関しては不明瞭静的リンクは二次的著作物を生じるが、他方、GPLコードに動的リンクされた実行ファイルが二次的著作物であると考慮されるべきか否かははっきりしないとする意見もある。詳細は弱いコピーレフト(Weak copyleft)を参照せよ。Linuxカーネルの著作権者リーナス・トーバルズは、状況により、動的リンクは派生物を生じ得るとの見解に同意する場合と同意しない場合があるとしている[93]。 ノベルの弁護士は、動的リンクが二次的著作物でないのは「もっともらしい」が「断言」はできないとし、善意による動的リンクの証拠として、プロプライエタリなLinuxカーネルドライバの存在に見てとれる、と文書にて記載している[94]。 ガルーブ対任天堂訴訟において、アメリカ合衆国第9連邦巡回区控訴裁判所は、二次的著作物を「『形式』または永続性」を所持するものと定義し、「当件における侵害された著作物が、ある形式で著作権の適用された著作物の一部と協働しなければならない」と言い渡した[95]。しかし、特にこの対立を解決する明白な法的結論は出ていない。 見解: リンクは無関係であるLinux Journal誌の記事によれば、IP法の専門家でOSIの法務顧問 (General counsel)も務めるローレンス・ローゼンは、リンクの動的・静的を含む種別は、ある種のソフトウェアが二次的著作物であるか否かについての問題とは概ね関係がない、すなわち、そのソフトウェアが、クライアントソフトウェアとライブラリ、またはそれら個別とのインタフェースが意図されているか否かについての問題のほうがより重要である、と主張している[96]。 彼は、「新規のプログラムが二次的著作物であるか否かの主な指標は、原著作物のプログラムのソースコードが、『複製と添付(コピーアンドペースト)』する 意図をもって利用され、新たなプログラムを作成する任意の手段において、改変、翻案またはその他の変更を加えたか否かに係っている。もしそうでないなら ば、私はその新規のプログラムは二次的著作物ではないと主張するだろう」と述べる[96]。また、彼はこの記事の中で、ソフトウェアの組み合わせ・バンドリング、リンクのメカニズムなど、その他関連する多くの指摘意図を挙げている。さらに、彼は、彼の弁護士事務所のウェブサイト[97]にて、このような「市場原理」的要素はライブラリリンクの原理といった技術的な要素よりも重要であると主張している。 プラグインまたはモジュール（例えば、フリーなドライバ"nouveau"とは別個に存在する、NVIDIAのプロプライエタリなデバイスドライバ、またATI FireGL RXなどのグラフィックカード用カーネルモジュールが その一例）が固有の著作物と合理的に見なされる際、それらライブラリがGPLに従わなければならないか否かという、別個の問題もある。これに対する見解 は、著作物がGPLv2ならば、分離していると合理的に理解されるプラグインまたは、プラグインを利用するために設計されたソフトウェア用のプラグイン は、任意のライセンスで許諾され得る。GPLv2の条文段落において特に注目される箇所は以下の条文である。
実際にはGPLv3でも同じであり、条項の文面は多少異なっているが[注釈 11]、上記と同様の内容が、以下となる（詳しくはセクション"改変版ソースの伝達"を参照）。
事例分析として挙げると、DrupalやWordPressのようなGPLv2でリリースされていたCMSに対し、それらに提供されていたプロプライエタリと想定されるプラグイン、テーマ、スキンなどは、両プロジェクトサイドにて議論が巻き起こる共に、非難されるようになってしまった[98][99][100][101][102]。 一方、Linuxカーネルではこのような結合の状況分析を行うことなく、カーネルの著作権の影響範囲とユーザ空間プログラムが派生物ではないことをライセンステキスト冒頭[103]で述べている[注釈 12]。 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".[...] 参考訳: 注意! この（Linuxカーネルの）著作権は通常のシステムコールによる カーネル・サービスを利用するユーザ空間プログラムを影響下に置くことは「ない」。 このことは、カーネルの通常利用を考慮したものであるに過ぎない。 そして、このことは「派生物」との分類を受けるものでは「ない」。（後略） 集積物の別の部分と見なされるパッチ前述のセクションの実例を挙げる。GPLソフトウェアへのパッチを提供した場合は、そのパッチが「適用したGPLソフトウェアとは別の著作物」とみなされる可能性も含んでいる。これは、前述の通り、
や
に規定されている。即ちGPLソフトウェアを含む「集積物(aggregate)の他の部分」と認められれば、GPLに反しない、言い換えればGPLより緩やかなライセンスでパッチを公開しても良い[注釈 13]。例えばパッチが単なる修正ではなく、単体で再利用可能な全く別種の機能強化と見なされればそれは集積物の別の部分と規定でき、そのパッチのみに対しGPLと矛盾せずかつGPL以外のライセンス（BSDライセンスやzlib Licenseなど）を適用する事も可能である。一例をあげると、MySQLは、「リンク例外条項付きGPLv2」と商用ライセンスとでデュアルライセンシングされている。これに対しGoogleはMySQL向けのパッチをBSDライセンスで提供していた[105]。 このパッチはオリジナルのMySQLに由来しないコードのため、GPLで保護されたMySQLの「集積物とは別の部分」となる。BSDライセンスは独占的 なライセンスであろうとも両立するので、結果的にこのパッチは、MySQLをGPLで利用するライセンシーと共に商用ライセンスで利用する者も適用可能で ある[106][107]。また同時にそのパッチからサブルーチンのみを取り出し、BSDライセンスされたソフトウェアにも同様のルーチンを導入する事も可能となる[107]。 非GPLプログラムとの結合や組み合わせGPL なソフトウェアと別のプログラムが単に結合している場合は、本来、全てのソフトウェアをGPLにすることも要求されない、そしてGPLなソフトウェアを非 GPLソフトウェアとともに頒布することも要求されない。しかし、稀な条件において、GPLの権利を保証することを妨げる障害が取り除かれるであろう。次 の文は、GNU.org ウェブサイトに存在するGPL FAQからの引用である。これは、ソフトウェアが、バンドルされたGPLプログラムと結合を許される範囲がどこまでかを記述している。
このように、FSFは「ライブラリ」と「その他のプログラム」とを、次の2つの観点双方を用いて線引きしている。
しかし、FSFは、この問題は明確な結論はなく、複雑さの条件について判例("case law")により決められる必要があるだろう、と譲歩している。 GPL FAQでは「結合メカニズム」(「コミュニケーションのメカニズム」)の例として、プロセス間通信、リモート・プロシージャ・コール、カーネル空間・ユーザー空間の通信やシステムコール、パイプ、execによるプロセス起 動などを挙げている。これら「結合メカニズム」を用いてGPLなソフトウェアと接続する場合は、個別のプログラムであるため結合ではないとも見なせるが、 そのやり取りするデータの如何によって接続先が二次的著作物であると見なされる余地も残されている(「コミュニケーションのセマンティクス」)。これに対する明確な法的結論はまだない。 法廷におけるGPL2002年、MySQL ABは著作権侵害ならびに商標権侵害でProgress NuSphere社[110][111]をアメリカ合衆国マサチューセッツ連邦地方裁判所に提訴した。伝えられる所では、NuSphereは、MySQLのGPLで保護されるコードを自社のGeminiテーブル型モジュール[112]に静的リンクしたが、GPLの条項に従わず、Geminiのソースコードを一切公開しなかった。このためMySQLの著作権を侵害していたとされる[113][114][115]。2002年2月27日、パティ・サリス判事の予備審問ののち、当事者らは和解協議に入り、最終的に事実上合意に至った[116]。審問終了後、FSFは「サリス判事は、GNU GPLが強制力と束縛力を持つライセンスであることが分かったことを表明した」とのコメントを発表した[117][118]。 2003年8月、SCOグループは、「GPLに法的な有効性などない」と本気で考え、彼らはSCO UnixからLinuxカーネルへと不正に複製されたと疑わしいソースコードの断片を法廷で取り上げるつもりだと主張した。彼らは、当時GNU/Linuxディストリビューションを頒布しており、またそのディストリビューション、Caldera OpenLinuxディストリビューションに含まれていたその他GPLで保護されたコードも頒布していたため、これは問題のある行動であり、しかも、GPLの条項に従うことを除いてそのような問題行動をとる法的な権利などほとんど有って無いに等しかった。詳しくは、記事「SCO-Linux論争」と「SCO対IBM事件」も参照せよ。 ドイツのネットワーク機器メーカーSitecomは、GPLの条項に違反して、netfilter/iptables[注釈 14]プロジェクトのGPLで保護されたソフトウェアを頒布していたが、彼らは頒布停止を拒絶した。この後、事態は法廷に持ち込まれ、2004年4月、ミュンヘン地方裁判所はnetfilter/iptablesプロジェクトの訴えに対し、Sitecomドイツ法人の製品に対する予備的差止命令（仮処分差止命令）を認める決定を下した。2004年7月、ドイツの法廷は、この差止命令がSitecomへの判決になると確定し、結審した[119]。法廷で認められたのは次の内容である。
参考訳:
netfilter/iptablesの開発者でその著作権を持つもののひとりでもある、ハラルト・ヴェルテは、ドイツにあるFLOSS関連の法的係争を扱う組織、ifrOSSの共同設立者、ティル・イェーガー(Till Jaeger)に自身の法的代理人を要請した。この判決文は当時FSFの顧問だったエベン・モグレンが以前予想した通りの内容を反映していた。これは、GPLの条項違反が著作権侵害に与える影響を法廷が初めて認めた重要な判決だった。 2005年5月、ダニエル・ウォレス(Daniel Wallace)は「GPLは価格を零にしようとする違法な企て、すなわち価格固定やダンピングである」と主張し、FSFをアメリカ合衆国インディアナ南部連邦地方裁判所に提訴した。2006年3月、ウォレスはGPLが反トラスト法に違反する行為を促すとの正当な主張を法廷で証明することができなかったため、原告申立ては棄却された。「GPLは、自由競争、コンピュータ・オペレーティングシステム・ソフトウェアの頒布、消費者が直接得られる利点を阻害するというより、むしろ促進している」と、法廷は言い渡した[120]。その後、ウォレスは、不服申立の控訴状も却下され、FSFへの訴訟費用の支払いを命じられた。 2005年9月8日、ソウル中央地方法院(서울중앙지방법원, Seoul Central District Court, ソウル中央地方裁判所)は、GPLでライセンスされた著作物から派生した二次的著作物を企業秘密[注釈 16]とする契約事項に対し、GPLは本件と関連なしとの判決を下した[121][122]。判決主文の英文抄訳より事件のあらましを述べると、係争にあがった著作物は、GPLv2で保護されたソフトウェアVTunで ある。被告の一人はVTunをベースとした二次的著作物であるソフトウェアを、原告である企業に雇用されている間作成した。彼が原告企業を退社後、そのソ フトウェアのソースコードを個人的に複製しており、そのバグ修正を行ったうえ、そのソフトウェアを利用した商用サービスをもう一人の被告と立ち上げた[注釈 17]。これに対し、原告はそのサービスが自社の企業秘密の漏洩であると主張した。 被告らは、GPLを遵守して著作物を頒布する限りは、企業秘密を維持することなど不可能であるので、守秘義務違反ではないと主張した。ソウル地裁はこの主張の法的根拠を認めず、「ライセンス如何にかかわらず、企業秘密の漏洩により公平な競争者に対抗し不公平な利益を得ることを守秘義務で縛ることは妥当である。また企業秘密は特許とは別であり、技術的である必要は無い（1998年大韓民国大法院判決による）。」と述べた。 2006年9月6日、gpl-violations.orgプロジェクトは、D-Link Germany GmbH（Dリンクのドイツ法人）を提訴し、これに勝訴した。原告は、被告が販売する（即ちこれ自体「対価を取って頒布する」ことであり、なんら問題ない）NAS機器に、Linuxカーネルの一部を利用していたが、GPLに違反した使用であり、著作権侵害である、と主張した[123]。この判決[124][125]により、GPLの有効性、法的拘束力がドイツの法廷で支持されたという判例が与えられたことになった。 2007年後半より、BusyBoxの開発者ならびにSoftware Freedom Law Center(SFLC)は、組み込みシステムに利用するBusyBoxの頒布者からGPLを遵守する旨の言質を得ることや、GPLを遵守しないものを提訴する計画に乗り出した。これら一連の訴訟は、アメリカ合衆国において、GPLの責務に対する強制力を法廷で争った初の機会であると述べられている。 →詳細は「BusyBox § GPL違反問題」を参照
2008年12月11日、FSFはシスコシステムズを提訴した[126]。被告はそのLinksys部門にて、原告のFSFがGPLでライセンスした著作物である、 ソフトウェアパッケージを、Linksysの次に述べる製品のファームウェアにGNU/Linuxシステムの形で組み込んで、対価を取って頒布、すなわち販売していたが、GPLの条項に違反していたためFSFの著作権を侵害している、と原告のFSFは主張した[127]。該当する製品は、Linksysの有名な無線LANルーターWRT54Gやその他DSLモデム、ケーブルモデム、NAS機器、VoIPゲートウェイ、VPN機器そしてホームシアター、メディアプレーヤー機器などその他多くの機器にも及ぶ[128]。 FSFがシスコを提訴するまでの6年間、FSFはシスコに何度も申立を行ったが、シスコは、「われわれは、（GPLで保護されたプログラムの全てのソースコード ならびにその改変箇所を含む完全な複製を提供しなかったというGPLの）条項違反についての問題を修正する予定もしくは修正中である」と回答した。しかし、その後もより多くの製品から新たな違反が発覚したとの報告を受けたFSFはLinksysと多くの会談をとり行うこととなったが、結局実りは少なかった。FSFのブログでは、この過程を「5年間にも及ぶモグラ叩きゲーム」("five-years-running game of Whack-a-Mole")と評している[129][128]。この6年間の過程を経たのち、FSFは遂に本件を法廷に持ち込むことを決意した。 その後シスコは本訴訟の和解のテーブルに着き、6ヵ月後、
以上の和解内容に合意した[131]。 →詳細は「フリーソフトウェア財団対シスコシステムズ事件」を参照
両立性とマルチライセンス あるオープンソースソフトウェアでライセンス上考慮すべき点があるなどして、またはもっと極端な例では、GPLの思想的な面に反発があるなどして、GPLと両立性[注釈 18]を欠くようなライセンスを著作物に敢えて採用するケースがあるかもしれない。しかし、GPLを採用するフリーソフトウェア、オープンソースソフトウェアが多数存在するため（セクション"採用実績"を参照）、現実問題としてそのような行為はコードの再利用性を著しく欠く結果につながる（記事"ライセンスの氾濫"を参照）。このため、自身の採用するライセンスをGPLと非互換にしないよう、GPLとのライセンス両立性を考慮することは重要である。 著作物全体として影響を受けるライセンスの持つ制限の組み合わせにより、GPLが許諾する事項を越えるいかなる追加的制限が課されない限り、他のライセンスで許諾されたコードは、GPLで許諾されたプログラムと衝突することなく組み合わせることも可能である[132]。また二次的著作物の観点として、互換性のあるフリーソフトウェアライセンス/オープンソースソフトウェアライセンスで許諾されるコードを組み合わせる場合は、原則コードの組み合わせ全体に、そのコピーレフト性が最も強くなるライセンスの影響を受ける[注釈 19]。GPLの正規の条項に加えて、追加的な制限や許諾を適用することができる組み合わせは以下の通りである。
上 述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)）が存在する為である。一般的に、ソフトウェアのライセンスを非互換なライセンスに変更する場合は、コードの全著作権者からライセンス変更の同意を取り付けなければならない[69]。LinuxカーネルのライセンスはGPLv2単独であり、Ruby処理系のような特殊な規定を持っているわけではないので、仮に変更する場合はそうせざるを得ない[69]。GNUプロジェクトはこのような事態に陥ることを回避するため、前述の通り著作権者からコードの著作権をFSFに譲渡するよう勧め、またソフトウェアのライセンスほぼ全てに"any later version"表明文を付したGPLを適用している。 FSFは、GPLと両立するフリーソフトウェアライセンスのリストを維持管理している[136][137][138]。そのようなライセンスは、もっとも広く利用されている、オリジナルのMIT/X license、（現行の3条項形式の）BSDライセンスそしてArtistic License 2.0などを対象としている[139]。 デイヴィッド・A・ウィーラーは、GPLと非互換なライセンスを利用すると、他者のフリーソフトウェア/オープンソースソフトウェアプロジェクトへの参加や、コードの貢献を困難にするため、フリー/オープンソース開発者はGPL互換なライセンスのみ採用するよう強く主張し続けている[17][注釈 20]。 特筆すべきライセンス非互換の例として、旧サン・マイクロシステムズのZFSが、GPLでライセンスされたLinuxカーネルに組み込めないというものが挙げられる。なぜなら、ZFSはGPL非互換なライセンス、CDDLで許諾されているからである。これに加え、ZFSは特許で保護されており、ZFSの機能を持つソフトウェアをサンとは独立にGPLのもと実装し頒布しようとしたとしても、それでもなおサン（現在はオラクル）の許諾が必要となると予想される[140]。 →詳細は「ソフトウェアライセンスの一覧」を参照 マルチライセンス→詳細は「デュアルライセンス」を参照
一般的にプロプライエタリ・ソフトウェアはGPLソフトウェアと組み合わせることはできない。しかしこのような場合でも、マルチライセンスを利用することでGPLソフトウェアを組み合わせることも可能となる。 GPLのもとで頒布するとともに、静的リンクなどを使用する場合やそうではなく動的リンクを使用する場合においても[注釈 21]、パッケージにプロプライエタリなコードを組み合わせたいと望む企業のため、二次的著作物を独占的な条件・ライセンスで頒布・販売可能にする商用ライセンスを同時に提供するマルチライセンシング・ビジネスモデルが多く存在する。このようなビジネスモデルを採用する企業と採用したソフトウェアには、Oracle社（MySQL AB社のMySQL）、Digia[141]社(旧Trolltech社のQtフレームワーク[142] )、Namesys社(ReiserFS)、Red Hat社(Cygwin)、Riverbank Computing社(PyQt)などがある。 その他、Mozilla Application Suite、Mozilla ThunderbirdそしてMozilla Firefoxを製品に持つMozilla Foundation（Mozilla Corporation）のような企業はGPLだけではなく同時に他のオープンソースライセンスでも頒布可能なようにマルチライセンスを採用するケースがある。 採用実績Black Duck Software社により管理される"Open Source Resource Center"によると、フリーソフトウェア/オープンソースライセンスでリリースされたソフトウェアパッケージ全体の約40%がGPLv2を、約6%がGPLv3をライセンスに採用しているとのデータが示されている[7]。 テキストメディアならびに他のメディアにおける利用コンピュータ・プログラムの代わりにテキスト文書、またはより一般的にはあらゆる種類のメディア全てにGPLを採用することは可能である。ただしその条件は、それらメディアが「ソースコード」（その定義としては、「それ自身を変更することを可能にさせる著作物の好ましい形態」）を構成できるか明らかである必要がある[143]。マニュアルや教科書は、FSF自身はGNU Free Documentation License (GFDL)の利用を代わりに薦めるが、この目的において前述の要件を形成できる媒体である[144]。しかしながら、FSFの勧告にも関わらず、Debian開発者らは（2006年に採択された決議に基づき）、彼らのプロジェクトにおける文書をGPLの もとライセンスする勧告を出した。なぜなら、プログラム・メディア双方の著作物における「ソースコード」という概念に対し、GFDLにはGPLの条項と非 互換な取り扱いが存在するからである。すなわちGFDLのもとライセンスされたテキストはGPLで保護されるソフトウェアに組み込めないというのである[145]。詳細については、記事"Debianフリーソフトウェアガイドライン#GFDL"を参照せよ。また、フリーソフトウェア用のマニュアルなどの作成に貢献している組織、FLOSS Manuals Foundationは、2007年に、本組織のテキストにGFDLの採用を忌避しGPLの採用を決定した[146]。 仮にGPLがフォントのライセンスに採用された場合、このようなフォントにより形成されるあらゆる文書、画像、PDFは、これまたGPLの条項に従って配布する必要があるかもしれない。このケースは、著作権法がフォントの書体(appearance of fonts, typeface)には及ばない国々（アメリカ合衆国とカナダのような国[注釈 22]）では問題とならない。日本の場合も同じく、フォントの書体は意匠権を持ち、意匠法により管掌されると同時に、独創性と美的特性のない書体に著作権はないとの考えは現状一般的である。しかし、フォントヒンティング・テクノロジーなどのフォントファイル内に存在するプログラムコードは（それが「プログラム」である[147]から、）猶も著作権法で保護され得るとの主張もある（詳細は記事"知的財産権#その他の権利" "タイプフェース"を参照）。また、セクション"リンクと派生物"で述べたことと同様に、フォント埋め込みは文書がフォントと「リンク」していると見なされる[注釈 23]ので、事態をより複雑にさせる。FSFはこの想定外の事態に対し、GPLでフォントをライセンスする際には著作権者は「例外条項」を設けるべきと勧告している[148][149]。 →詳細は「GPLフォント例外」を参照
GPLv3にまつわる話題ここではGPLv3で改訂された内容や新規に導入された事項を理解するため、条項の逐条的な説明を行う。内容はIPAの「GNU GPLv3 逐条解説書」[83]を参考に、一部を除き括弧内に対応する条項名を記載した。「SFLCによると」の部分は、原典のIPAの「GNU GPLv3 逐条解説書」と同一の扱いである。 主要な用語の定義Aバージョン2以前のGPLで使用された用語は、米国著作権法に準拠したものが多い。GPLv3ではこのことを踏まえ、各種用語を定義し直し、主張する内容を明瞭化した。よって各国著作権法との親和性は幾分かは上がった。この点を述べてライセンスの米国法依存脱却、すなわち「国際化」と呼んでいる[150]。また用語の曖昧さについては、詳細な定義を加えることにより極力排除されている。しかし実は、国際私法の観点において、GPLに準拠する法は、GPLv2でもGPLv3でも同じく、いかなる国の法はGPLの準拠法となり得る[151]。実際の実務として検討する課題は少し存在するが[152]、 この法的解釈はGPLv2からは何も変わっていない。このことは、議論用第2次草稿と同時に提出された"Opinion on Denationalization of Terminology"（「用語の特定国家依存からの脱却に関する意見」）に記載されている、"Rejection of Choice of Law Clauses"（「法の選択条項の拒絶」）[153]にて明確に趣旨が説明されている。すなわち、ライセンシーは「法の選択」に係る条件を下流の受領者に課すことはできない。なぜなら、法の選択はGPLに規定がなく、後述する第7項第1段落の、ライセンシーが自由に追加・削除可能な「追加的許可条項」（additional permissive terms）ではない。さらに第7項第3段落の小項b)で明示的に「特定の合理的な法律上の告知事項」は、ライセンサーにのみ追加が認められる「追加的非許可条項」（"non-permissive additional terms"）であることが示されている。仮にライセンシーが、ライセンサーが認めていない法選択を強制したならば第10項第3段落の「さらなる権利制限」（"further restrictions"）となり第8項の終了条件に抵触する。 条文の主要な用語に関しては、正式リリースされたGPLv3の主に第0項、第1項を中心に、場合によっては各項の冒頭段落にて定義されている。
基本的な許可
GCCランタイムライブラリ例外現行のGCCはGPLv3で保護される作品である。しかし、GCCやその頒布物のソースコードを利用していない「ソースコード」形式の作品はそれが従う許諾条件によらず、GCCのランタイムライブラリをリンクしない限り、出力される「オブジェクトコード」形式の作品がGPLに従う必要はない[75]。そのような場合、通常Cで書かれたソースコードは
その他多数のGCCの頒布物に同梱されている各種演算補助用ライブラリなどである。 さ て、そのソースコードが各種演算補助を利用して作成されている時、GCCのランライムライブラリに動的、静的問わずリンクされる場合がある。これらのライ ブラリはGCCの頒布物であるから、GPLで保護される。よって原則、GCCのランタイムライブラリとリンクする場合は、GPLに従う必要がある（この件 については派生物としての疑義があるとする人々も多いが、GCCの著作権者であるFSFは、前述の通り、GPLのライブラリは静的、動的問わずGPLに従わなければならないとの立場である）。これではプロプライエタリなソースをはじめとして、GPL非互換なソフトウェアは一切コンパイルして頒布できなくなる。これに対して、FSFは「GCCのランタイムライブラリ例外」（GCC Runtime Library Exception）[173]を 設けている。これは後ほど述べる通り、GPLv3の第7項に規定されている「追加的許可条項」と呼ばれる、GPLの制限を緩める条項である。この条項を追 加することはGPLv3第7項で許可されている。この例外により、GPL非互換なソースコードのコンパイルを許可する仕組みは以下の通りである[174]。 通常、ソースコードをコンパイルするとき、言語やコードにより常に全てとは限らないが、主に次のような段階を踏む。 コンパイラたるGCC本体はこのうち、3.を担っており、これを「コンパイルプロセス」（Compilation Process）と呼ぶこととする（のちほど正確な定義を述べる）。またソースコードをGCCに入力してから、3.のプロセスが終了した直後出力される、物理CPUもしくは仮想機械をターゲットとしたコードのことを「ターゲットコード」（Target Code）と定義する。ただしターゲットコードには、「コンパイルプロセス中に生成されるコンパイラ中間表現」やコンパイラ中間表現を生成する目的のコードを含まない。ターゲットコードは、4.のプロセス以降で使用されるアセンブラ・リンケージエディタの入力コードまたは実行ファイルである。この考え方から、コンパイルプロセスは、より正確には、「中間（表現）言語を除く、人間が作成可能な高水準コードやJavaバイトコードな どで完全に表現されているコードを、ターゲットコードに変換する過程」であると理解できる（実際にそのように例外条項の中で定義している）。そしてコンパ イルプロセス中に、GCCの各種演算補助用ルーチンやコンパイルされた標準テンプレートが入力コードとリンクされる。次に、コンパイルプロセスに関与する プログラムの状況からコンパイルプロセスの「性質」を定義する。コンパイルプロセスが、そのプロセス実行中以下いずれかの状況に当てはまれば、そのコンパ イルプロセスは「適確」（Eligible）であると定義する。
コ ンパイルプロセスの外（上記のプロセス1.に当てはまる高水準コード生成処理や2.のプリプロセス処理）で使用するプログラムがたとえプロプライエタリ だったとしても、そのプロセスは適確である。しかし、コンパイルプロセス中にGCCと共にGPL非互換なソフトウェアを使用した場合、コンパイルプロセス 中にGCCやGCCのランタイムライブラリ、またはその他GCCの頒布物のソースコードを利用した場合、そのプロセスは適確ではない。この定義のもと、仮 に全てのターゲットコードを生 成するコンパイルプロセスが適確ならば、GCCのランタイムライブラリと入力ソースコードをリンクすることで生成される任意のターゲットコードは任意の許 諾条件のもと「普及」すること（例: コンパイラからターゲットコードを生成（generate）することや、ターゲットコードを複製することなど）を許可する。また入力ソースコードの頒布条 件が一貫性を維持できるならば、ターゲットコードの「伝達」（例: 頒布）も任意の許諾条件で許可される。これがGCCのランタイムライブラリ例外の規定である。 例 えば、GCCと高水準コードジェネレータ（プロセス1.で利用）やプリプロセッサを利用し、GPL非互換なソースコードをコンパイルしようとした場合、た とえ両ユーティリティがプロプライエタリだったとしても、「コンパイルプロセス」の外で両者を利用するだけなので、GCCのランタイムライブラリ例外によ る、任意の「ターゲットコード」のランタイムライブラリとのリンク許可が与えられる。また「ターゲットコード」が生成完了してから、プロプライエタリなア センブラでアセンブル、プロプライエタリなリンケージエディタを利用して各種ライブラリ（この中にGPL非互換なライブラリが含まれていても構わない）と 適確なコンパイルプロセスで生成したターゲットコードとをリンクすることも、ターゲットコードが任意の許諾条件を許可するから、可能となる。伝達する場合 は、入力ソースコードの許諾条件、かつリンクプロセスでリンクしたライブラリ（GCCのランタイムライブラリ、また第1項で定義した「システムライブラ リ」に当てはまるものを除く）の許諾条件などとの一貫性が保てなくなる場合は許可されないが、そうでなければ伝達も可能となる。インラインアセンブラ等で入力コード中にアセンブラを書き込んだ際、コンパイルプロセスではそのアセンブラ部分の一部コードは処理されない場合もある。このような場合でもその入力コードは「中間（表現）言語を除く、人間が作成可能な高水準コード」であるから、コンパイルプロセスに投入しても適確である。ただし、そのインラインアセンブラが、プログラマが手書きしたものではなく、例えばコンパイルプロセス処理中にプロプライエタリなツールなど機械が生成した場合はこの限りではない。また本セクション冒頭で述べたとおり、「GCCのランタイムライブラリにリンクしない場合はGPLに従う必要がない」というのは、正確には「GCCのランタイムライブラリにリンクしない、かつGCCのコンパイルプロセスが適確である場合、入力ソースコードと出力バイナリはGPLに従う必要はない。」と修正される。 しかし、例えば、ターゲットコードではなく、コンパイラ中間表現を直接出力するようGCCを改変して使用した場合はどうなるか。その場合は、3のプロセスが完了した時点では、「コンパイルプロセス」は終了していないことになる。 従ってこの後に、プロプライエタリなツールを利用して3.のプロセス終了後のデータを操作した場合、「コンパイルプロセス」はもはや適確ではない。よって 以後のコードは全てGPLに従わなければならないし、入力ソースコードがプロプライエタリならば、伝達は完全に禁止される。またコンパイルプロセス中に GPL非互換なプログラムを割り込ませる場合もそのコンパイルプロセスは適確ではない。 なぜコンパイラ中間表現のみをターゲットコードから差別しているのか。GCCは各種言語サポートやコンパイルの最適化を 図る処理などを「コンパイルプロセス」に組み込むことができる「プラグイン・アーキテクチャー」を採用している。このことはGCCの拡張性を向上させたの は間違いないが、同時に例えば、コンパイルプロセスに割り込んで内部の低水準コンパイルデータ構造のみを取り出すようなプラグインを作ることも可能とな る。このようなプラグインを作成すること自体は問題ないが、GCCと直接結合せずとも、はたまたGCCのソースコードを参照せずとも、コードの最適化等を 行うことができるようになる。仮にそのような有益なプラグインがプロプライエタリなどGPL非互換なソフトウェアならば、それらがコピーレフトの保護にお かれることもなく、GCCの開発の外側でのみし か利用できない。このことを回避することがその主旨である。また本例外条項にも注意書きされているが、「サードパーティ・ソフトウェアがGCCのコピーレ フトの影響を受けないとの解釈に本例外条項を利用してはならない」。原則GCCとそのランタイムライブラリのコードの利用やリンクなどで結合するプログラ ムはGPLに従わなければならない。ただし、「コンパイルプロセスが適確ならば」GPLv3の義務を一部緩める。本項はこのことを主張しているだけに過ぎない。 まとめると、GCCのコンパイルプロセスに関与せずかつGCCのコンパイラ中間表現を操作しない、その他直接間接問わずコンパイラ中間表現のデータを利用しない条件で「プロプライエタリなプログラム・ビルド・ソフトウェアやツールチェーン」とGCCを同時に使用し、プロプライエタリ・ソフトウェアを作成、その際GCCのランタイムライブラリに静的・動的問わずリンクしたとしても、プロプライエタリ・ソフトウェア自体はGPLに従う必要は全くない。 C++（ 注意すべきこととして、ランタイムライブラリ単独ではGPLで 保護される作品であるから、ランタイムライブラリを伝達した場合はやはり、GPLの義務を負う。例えば第6項、GPLで保護された「オブジェクトコード」 形式作品の伝達時の義務は、「対応するソース」の伝達を強制するものである。後ほど述べるとおり、これにかかるコストはライセンシーによってはかなりの負 担となるケースがあることも留意しておきたい。そこで、共有ライブラリのメカニズムを利用し実体ライブラリを頒布しないという手段を採りたいと考えるだろ う。共有ライブラリとしてプログラムに動的リンクした場合は、実体ライブラリはそのプログラムに添えて伝達せずとも、受領者は受領者のマシンでライブラリ を入手すればプログラムを実行できる。しかし必ずしもそれが適切とは限らない。「GCCのランタイムライブラリ」はGPLv3第1項の規定から、「主要コ ンポーネント（この場合、コンパイラたるGCC）に付属するシステムライブラリ」とみなせるOSもある程度存在する。例えばLinuxディストリビューションでは、libgccなどGCCのランタイムライブラリをGPLのもとパッケージとしてGCC本体からばらして頒布している場合もある[175]。OSがこのようなLinuxディストリビューションと同等の条件を満たす場合は、GCCのランタイムライブラリにリンクしたプログラムを単独で頒布しても問題ないだろう。ところが、Microsoft WindowsオペレーティングシステムはGCCをそもそもインストールしていない環境のほうが圧倒的に多い。なぜならGCCはOSの主要コンポーネントではないからである。よってMicrosoft Windowsオペレーティングシステムにおいて「GCCのランタイムライブラリ」はシステムライブラリではない。こ れにより、GCCのランタイムライブラリを同梱せねばならず、「オブジェクトコード」形式のGPLv3な作品を伝達するのであるから、ランタイムライブラ リのソースコードを「対応するソース」に含める必要がある。このようなOS向けに共有ライブラリのメカニズムを利用して実体ライブラリを頒布しないという ことは、殊の外注意を要する。このようなOS向けのGCCのバリエーションでは、システムライブラリ（例えば、Windowsならば 開発委託興 味深い例として、GPLのソフトウェアを修正し、新たな機能を追加するよう受託したものを、商業的な対価を受け取り顧客に納入する場合、少なくともそのソ フトウェアがGPLv3で保護されるものである場合については、受託企業は改変部分を含めたソースコードを開示する必要はない、というものがある[176][177]。 これはGPLソフトウェアの頒布形態の一つと見なせる。まず、GPLv3で保護された作品たるソフトウェアを原著作者から受領した企業が発注側として、受 託企業に「伝達」する。伝達行為は後ほど説明するとおり第6項において「対応するソース」も受領者たる受託側に「伝達」しなければならない（改変を受託企 業に行わせるので当然ではあるが）。受託側は「対応するソース」に改変を加えたのち、今度は逆に受託企業をライセンサー、発注企業をライセンシーとして発 注側に「伝達」する。よって第6項の「対応するソース」の開示義務（や第10項第3段落の「特許非係争義務」）を負うことになるはずである。しかし、委託 契約は第2項第2段落の第2文以降に該当する。即ち「ライセンシーの改変要求（ソースコードレベルでの改変要求などを含む）や機能追加要求（ソースコード レベルでの改変要求でなくてもよい）に従って、保護された作品を作成、実行する第三者は、ライセンシーの管理監督下において、専らライセンシーのためにそ れらを実施しなければならない。ただしライセンシーの関係の範囲外ではライセンシーの作品の複製を彼らに禁ずる。」という契約形態になるからである[注釈 30]。この条件に当てはまる場合はGPLv3の伝達時の義務が例外的に免ぜられる。従って受託企業は発注企業から要求された改変部分のソースコードを一切開示する必要はない。ちなみに納品が頒布に相当しないとの解釈はGPLv2の条文で明記されていない[注釈 31]。 その他、ソフトウェアを受け取った顧客が「それを再頒布し ない」限り、ソースコードを受託側と発注側以外に対し、非公開にすることには全く問題ない。また、発注企業が社内のみで利用する限り、ソースコードは、た とえそれを改変したとしても、非公開で問題ない（「ライセンシーによる組織内での私的な改変による利用」となるからである）[177]。 ここまでの説明では、受託側が発注側に著作権を譲渡しない場合を想定している。そうでないならば、受託側はそのソフトウェアのコントロールはできなくなる （GPL以外で再ライセンスされることもあり得る）。GPLなソフトウェアを複数のソフトウェアと組み合わせて発注側に納入する場合もほぼ同様だが、 GPLと矛盾するライセンスに従うソフトウェアはGPLの条項により、当然組み合わせることはできない。以上は受託開発におけるライセンスの考え方であるが、受託開発の契約はこれとは別に定められるので注意が必要である。 技術的保護手段回避を禁ずる法への対抗措置第3項は主にDRMをはじめとする技術的保護手段を目的としたGPLv3プログラムを作成した場合、当該プログラムの保護手段を第三者が解除する自由を認める条項である。
ちなみにLGPLv3はGPLv3を参照しつつ第7項の追加的許可条項を認めたライセンスであるので、本質的には「GPLv3そのもの」であるが、第3項の規定は全て免除されている。 忠実な複製の伝達受領したプログラムのソースコードに対し、その未改変の完全な複製を以下[注釈 32]に示す条件を遵守した上で再伝達してもよい（第4項第1段落[186]）。
以上の条件に従う限り、複製を有償無償問わず伝達できる。また複製に対し有償サポートや有償での保証（warranty protection）を提供してもよい（第4項第2段落[187]）。 条件1.は、「再伝達者は受領したプログラムのコピーライトを有していない」旨、下流受領者に通知させる。条件2.は第7項第3段落などに規定されている「追加的非許可条項」（"non-permissive additional terms"） を再伝達者は勝手に削除できないということを示している。具体的な条項の内容は追加的許可条項（additional permissions）ともに第7項にて説明される。条件3.は無保証性告知（ただし、その内、保証に関する追加的非許可条項は条件2.に従う）、条件 4.は本ライセンスの完全な複製の添付を定めている。 本項第2段落は伝達が有償無償を問われないことを示し、レッドハットなどGPLv3ソフトウェアを販売する企業が、サブスクリプションサービスなどを事業として成立させることを可能にしている[187]。第6項のオブジェクトコード形式の作品伝達とは異なり、伝達の手段は条文で問うていない。物理的媒体またネットワークを通じてなどあらゆる伝達が認められる[188]。GPLv3な作品を直接頒布していないが、機器に組み込み、頒布に係る実費を請求するような形は、GPLv3の条項のもと何ら問題は無く、これも伝達に当たる。ただし、その組み込んだ作品の形式を問わず「対応するソース」の伝達義務が発生するのは後述の通り。 改変版ソースの伝達第4項で規定した「保護された作品の未改変ソースの伝達」の条件に対し、第5項では改変した場合について、「ソースコード」形式（第1項参照）での伝達の際に課せられる条件を述べている。 ライセンシーは、本プログラムを基にした作品（第0項参照）、または本プログラムから作成するための「改変点」（"modifications"）を、第4項の規定に従ってソースコード形式で伝達、もしくは再伝達できる。その際、以下4つの小項a)～d)全てを遵守しなければならない（第5項第1段落[189]）。
「改変点」は「改変されたバージョン」（modified version、第0項）とはいえないまでも、「本プログラムを基にした作品」のパッチなど元の作品に対する非常に小さい差分が含まれることを（SFLCは）示唆している。従って小項c)により、本プログラムを基にした作品のパッチもGPLv3に従う必要がある[189]。「本プログラムを基にした作品」ではないと識別される場合のパッチには第5項第2段落の条項が適用できる余地が残されている。蛇足だが、第5項では「ソースコード」形式のパッチを取り扱っているので、「オブジェクトコード」形式のパッチ（い わゆる「バイナリパッチ」であるが、「オブジェクトコード」が単なるバイナリデータだけを意味しないと第1項で述べた）である場合は第6項の規定に従う。 小項b)は、第4項第1段落に対応する規定である。ただし、第7項の追加的許諾条項すべてを対象としており（対して、第4項第1段落では追加的非許可条項のみ対象）、その追加的条項の保全は規定されていない（第7項により、ライセンシーは適宜追加的許可条 項を削除できるからである）。さらに無保証性の告知の保全も要求されていない。これは、第7項の各規定に従い、ライセンシーのコピーライトを主張できる部 分には、許可、非許可問わずすべての追加的条項が適用可能であること、そして可能ならばライセンシーが保証を行うことを考慮しているためである（その保証 の形態は、通常は無保証であるが、特定のライセンシーの保証を追加する形で提供する。無保証性が消えるわけではない点に注意せよ[190]）。よってこのことをもってして、「この条件は、上記第4項における『告知をすべてそのまま保全』するための条項を改変する。」（八田真行訳）と言っている[190]。小項c)は、改変を包含した作品全体がGPLv3に従うことを要求している。その際、作品のパッケージ方法などに関わらず、たとえ作品が巧妙に細分化（artful subdivision）されていようが[45]、作品全体にGPLv3が適用される[190]。ただしその際その作品全体に課せられているマルチライセンスが無効化されることがあってはならない[191]。 小項d)は、改変後の作品が対話的UIを持つ場合、適切な法的事項を告知できるよう、ライセンシーはそのような機能を追加しなければならないとしている。 ただし受領した時点で作品に対話的UIが付いているが、法的事項を告知していない（告知機能がない、告知機能があっても法的事項を告知していない等）場合 は、わざわざ改変してまで適切な法的事項を告知する必要はないと規定している[191]。 セクション"集積物の別の部分と見なされるパッチ"で言及したが、第5項第2段落は集積物（aggregate）について定義している。保護された作品と、それに対し独立した他の別の作品を、同一の記録媒体または伝達時に使用する媒体上に集めたもの（編集物、compilation）のうち、以下3つの条件全てを満たす場合、「集積物」（aggregate）という[191]。
この時、GPLv3で保護された作品を集積物に含めたとしても、その「集積物の他の部分」に本ライセンスが適用されることはない[191]。「保護された作品を含む集積物の全体」は「保護される作品全体」とは異なるのである。適用例は前述の通り。 ソース以外の形式における伝達こ こまでで「ソースコード」形式の伝達の条件を述べた。第6項では主に「ソースコード」以外の形式における伝達の条件を述べている。ライセンシーは第4項、 第5項双方の規定に従い、保護された作品を「オブジェクトコード」形式で伝達することができる。ただし、本ライセンスの規定に従い、「オブジェクトコー ド」形式の保護された作品に「対応するソース」（ただし機械可読であるもの。「対応するソース」は第1項で定義した）を次に述べる5つの方法のうちいずれ かで伝達しなければならない（第6項第1段落[192]）。
小項a)は、オブジェクトコードを、例えばルーターなどの物理的製品に組み込んで伝達する場合や光学メディアなどの物理的媒体に格納する、もしくは組み込んで伝達する場合は、対応するソースを耐久性のある物理的媒体で必ず伝達しなければならないとの規定である[193]。小項b)は小項a)と同一のオブジェクトコードの伝達方法の場合であり、対応するソースを受け取る方法を記載した文書を添付する規定である[193]。対応するソースの伝達方法自体は、(1)小項a)と同じく物理媒体を利用、ただし伝達に係る合理的な実費を請求可[194]もしくは(2)ネットワークによる無償提供[194]である。請求権を持つものは、オブジェクトコードを保有するもの全て（すなわち「受領者」）である。従って本ライセンスを許諾するしないに関わらず（すなわちライセンシーか否かに関わらず） 対応するソースを「請求する権利」を得る。しかし、オブジェクトコードを持たないものは一切対応するソースを「請求する権利」はない（作品を所持していな いのだから、改変などを行使しようとする必要性が無いともいえる）。しかし、結果としてそのようなものでも、対応するソースを受け取ったものが第4項もし くは第5項の方法でソースコードを頒布できるので、それを無条件に頒布すれば第三者が受け取る可能性もある[195]。またオブジェクトコードの再伝達は（仮にライセンシーがGPLv3違反になり、第8項でライセンス終了にならない限り）禁止されないから、ライセンシーがオブジェクトコードを任意の者に伝達することは制限されない[195]。 小項c)は小項b)と対応関係にあり、オブジェクトコードを伝達し、対応するソースを提供する文書をそれに添付する規定である。対応するソースは小項b) と同じく、オブジェクトコードと一緒に伝達しなくてもよい。ただし本小項は条件があり、ライセンシーが上流伝達者からオブジェクトコードを受領した手段が 小項b)の場合に合致し、非定常的かつ非商業的に（すなわち継続的でもなく、かつ事業としてでもなく）対応するソースを伝達する場合に限り認められる[195]。 要するに小項b)で受領したオブジェクトコードと申出書を受け取ったものが両方を忠実に複製し、下流の受領者に渡すケースを想定している。小項b)、c) は理論的には、オブジェクトコードを受け取った受領者から対応するソースの請求が来なければ、その作品は非公開になってしまうということもあり得る[195]。 さて、「非定常的」という用語であるが、この小項に対応するGPLv2第3節第1段落小節c)では伝達を選択できる条件として単に「非商業的」となってい る。例えば商業的ではないが定常的な二次伝達者の例として、小項b)に従ってオブジェクトコードと申出書を受け取り、ウェブサイトなどで継続的に両者の複 製を頒布するケースが挙げられる。このサイトから両複製を受け取った受領者は小項b)の伝達を行ったもともとの一次伝達者に対応するソースを請求できる。 しかし、これを継続的に行えば、受領者の数は極めて多くなり、一次伝達者の請求に対応する業務が増大する一方、中間の二次伝達者は対応するソースの請求を 受けることなく、一次伝達者にただ乗りす る形になる。このようなネットワークの発達に伴う不均衡を防止するため、「非定常的」という条件が加えられたのである。従って保護された作品がGPLv3 である場合は、二次伝達者は小項b)を選択し自身が一次伝達者になるか、もしくは小項c)以外の選択肢を選べばよい。ところで卸売業者や流通業者、「一般的な意味でのディストリビューター」[注釈 33]は、改変、普及行為を一切行わず、単に上流からコードを受領してそのまま忠実に下流業者に譲渡するだけなので、第9項により本第6項の規定を受けない[198]。 さらにSFLCによると、一次伝達者がライセンス違反を犯し、ライセンスで保護される作品を伝達できなくなった（第8項）場合、二次伝達者が対応するソー スの伝達義務を負うようになるのではないか、と勘違いしがちではあるが、そうではないとのことである。つまるところ、実際には小項c)は対応するソースの 伝達義務を負うのではなく、「対応するソースを提供する一次伝達者を紹介する義務」を負う[199]。小項d)はオブジェクトコードをサーバから有償無償問わずダウンロードできるようにした場合、対応するソースもダウンロードできるようにすることを規定している。ただし、オブジェクトコードにアクセスさせる際に費用を徴収している場合は、それ以上請求してはならない[196]。対応するソースのホスティングについては、条文の通り運営者、実体サーバは問わない。またそのサーバがどのような運用が成されていても、ライセンシーは対応するソースのホスティングが停止されないように努力するなど、対応するソースの提供を維持しなければならない[注釈 34]。小項e)はP2Pでオブジェクトコード転送を行う場合、対応するソースを得ることのできる小項d)に対応する場所を、まだその場所を知らないピア（ノード）に無償で通知しなければならない[197]。 そもそもオブジェクトコードとその対応するソースを両方ともP2P伝送する場合は、小項d)（両者を類似の方法で伝送）に相当するので、わざわざこの条項 を規定する理由が無いように思える。この条項を設けた理由は第2次議論用草稿が提出された際に同時に提出された、"Opinion on BitTorrent Propagation"（「BitTorrentの普及行為に関する意見」）[200]で 述べられている。P2Pはその技術的特性からファイルの頒布開始ノードがどこであるかをユーザーが知ることは不可能ではないにしろ、きわめて困難である。 よって確実に頒布しようと考えるならば、（ファイルサイズの増加そして必要伝送時間の増加につながるが）オブジェクトコードとその対応するソースを同一のアーカイブに格納して伝送することになるだろう。しかし、たとえそのような対策を講じたとしても、ユーザーの需要の大小等に関連し、ファイルによってはあまりP2P ネットワーク上に伝播（シーディング、seeding）されないこともある。また頒布開始ノードが十分なシーディングの時間を待たずネットワークを切断すれば、場合によってはピアでシードが完成せず不完全なファイルになってしまう可能性もある。P2P伝送はファイルのビット毎、ブロック毎の伝送や授受には適しているといえるが、「完全なファイルの頒布手段」としてはあまり適切ではない方法であるとの意見が同文書には記載されている。この指摘を受けて小項 e)が設けられた。 さて対応するソースには、システムライブラリなどは含まれないと第1項で述べた。これとはまた別に、オブジェクトコードの分離可能な部分（separable portion）で、システムライブラリとしてそのソースコードが対応するソースから除外（be excluded from）されている場合、分離可能なオブジェクトコードの部分は、オブジェクトコードの作品伝達に含める必要は無い（第6項第2段落[199]）。システムライブラリは、（要約すると、）OSの一部からは除外されるがOSに付属するライブラリで、ランタイムもしくは標準インターフェースの実装であると述べた。これらはオブジェクトコード形式でOSに付属しているもしくはソースコードが公開されているものが多い。従って「対応するソース」の対象としたりオブジェクトコードを伝達する必要性は薄いといえる。ただ注意しておくべきこととして、「分離可能」という文言がある。GPLv3第6項第1段落、第2段落は、概ねGPLv2第3節に相当するとSFLCは述べているが[201]、そこで述べられていたGPLv2のシステムライブラリの判別基準は、いわゆる作品を静的リンクするか否かという側面で定めている。
「そのコンポーネント自体が実行形式に付随するのでは無い限り」（unless that component itself accompanies the executable）というのは、SFLCによると実際には「そのコンポーネント自体がそれらライブラリを含んでいる実行形式に静的にリンクしない限り」（unless that component itself statically linked executable containing those libraries）ということを意味する。これに対しGPLv3は、どのような形式で分離可能か何も述べておらず、リンク形式の判断などといった前提すらない。SFLCより助言を受けたIPAは「GNU GPLv3 逐条解説書」で
との解釈を述べている[201]。この考え方は、LGPLv2.1第6節小節bまたはLGPLv3第4項小項d)-1) での「共有ライブラリの判断基準」とは異なる。かなり大雑把に述べると、システムライブラリはランタイム、共有ライブラリは「標準ではないインタフェース （cf. 第1項の「標準インターフェース」も参照）の提供」という役割の相違があり、この点を考慮すれば判断基準が分かれるのは自明ではある。以上のリンクが GPLの二次的著作物であるか否かの解釈はFSF（SFLC）もリンクの動的・静的関わらず二次的著作物であると考えている。しかし、その他のFLOSSコミュニティは独自の見解を述べており、解釈は分かれている。また二次的著作物か否かを判断するのは「法廷」であるとの見解もある（セクション"リンクと派生物"参照）。 第3段落から第6段落は、「ユーザ製品」（"User Product"）と定義される製品にGPLv3で保護されるオブジェクトコード形式の作品を組み込んだ場合の伝達に対する条件を規定している。この条件は反TiVo化条項（anti-tivoization clause）と呼称される。ユーザ製品とは、次のいずれか一方を指す（第6項第3段落[202]）。
概ね軍事用などではない民生用機器の内、消費者の家庭で使用するものに対象を絞っている。しかし、実際はそれだけとは限らない。コンシューマ製品に該当するかどうかの判断において、個々のユーザーがどのような方法で使用するかは考慮されず、製品の典型的または一般的な使用方法に基づいて判断される。このように使用される形態を通常使用されると条項内で呼称している（第6項第3段落）。よって業務用を謳っていても「ユーザ製品」に該当する場合もある。例えばどう見ても個人用途ではない製品を家庭内で使用した場合はコンシューマ製品に該当しない。しかしある製品が業務用や 工業用など、非家庭向け用途がある場合でも、「通常使用」の観点で家庭内での用途などが1つ以上存在する場合には、コンシューマ製品に該当する。ある製品 がコンシューマ製品に該当するかどうか疑義がある場合は、極力コンシューマ製品に該当すると見なす（第6項第3段落）。FSFはユーザ製品ではない例とし て物理的電子投票機を挙げている[203]。機器にオブジェクトコードを実務上組み込めるか否か別として、かなり特異な例ではあるが、薬事法で定義される医療機器の内、家庭用医療機器（米国でいう、Home medical equipment）はユーザ製品に該当する。しかし、それを除いた医療機器で医師などの専門家の補助なしには使用できないものは、家庭での用途は全く考慮されていないのであるから、ユーザ製品ではないのは確実である[202]。 続いてそのユーザ製品の改変の鍵となるものを定義する。ユーザ製品の「インストール用情報」（Installation Information）とは、ユーザ製品に組み込まれている、保護された作品の対応するソースを、改変して作成した改変バージョンを、当該ユーザ製品にインストールし実行するた めに必要とされる手法、手順、認証キー及びその他の情報の全てをいう。その情報は、改変されたオブジェクトコードの継続的な動作が、改変が為されたということによってのみ拒否されたり妨害されることが決してないことを保証するのに十分なものでなければならない（第6項第4段落[204]）。そのようなインストール用情報には、「改変等を遠隔で検知するような認証機構」の解除方法も含まれる[205]。ソフトウェアに何らかの制限を加えるハードウェアがたとえ存在したとしても、そのソフトウェアがGPLv3で保護されるならば、ハードウェアを所持するユーザーは何の問題も無く改変後のソフトウェアを動作できることをライセンシーに保証させる条項である。「改変されたオブジェクトコードの継続的な動作が（中略）拒否されたり妨害されることが決してないことを保証」とあるので、実際にはハードウェアが継続的に動作することを保証しなければならないわけではなく、GPLv3で保護される作品を改変した二次的著作物がそのハードウェアで継続的に動作することを保証しなければならない、と規定している[206]。後述の第6段落の内容から判断して、製品ユーザーがソフトウェアを改変して動作させることは自由にするが、メーカーはそれによって起こりうる事態、事故は一切関知しないということになる。インストール用情報は機器により様々なものが想定されるが、概念的には、ライセンシーたるメーカーが自由に改変バージョンを動作できるのに、受領者たるユーザーが一切できない場合、メーカー側で保持する情報がインストール用情報に該当する。例えば、ある企業Aが認証済みソフトウェアを作成し、企業Bのハードウェアは企業Aの認証済みソフトウェアでしか動作しない場合、当該ソフトウェア がGPLv3で保護される作品ならば、企業Aはハードウェア受領者にその認証キーを差し出すこととなる[207]。ちなみにSFLCによると、場合によっては、インストール用情報を得ても専門的知識や設備が無ければユーザーがうまくその情報を利用できないケースも想定されるが、それを何らかの形でメーカーが補填する義務などないと述べている[206]。またあくまで情報であって、その情報を利用するのに必要なユーティリティ、ツールまでもメーカーが用意してやる義務も無い。例えばインストール用情報として、機器のプロテクト解除を行うソースコードを提供した場合、そのコードを実際に機器にインストールするにはクロスコンパイラ等でビルドする必要がある。しかしクロスコンパイラをメーカー側で用意してやる義務は無い。どのようなクロスコンパイラが必要であるか、どこでそれを入手できるか、などの情報を記載するのみに留めておいてよい[204]。また「認証キー」についてであるが、「改変されたバージョンを動作させるのに必要な」認証キーであるから、例えば、正規の認証キー自体ではなく、改変版の動作を行うだけのキー（例: PKIの適切な自己署名証明書や それに類似するキー）を別個作成するなどして頒布、もしくはその作成方法を「インストール用情報」に記載するだけでもよいと解釈される。また作品の改変バージョンを動作させるのに必要なハードウェアの認証キーなどが、各ハードウェア固有でありすべて異なっているならば、ハードウェアの購入者、受領者各人が請求した場合に応じて、その受領者のハードウェアのみに対応するキーを受領者各人に差し出すだけでよい。他のハードウェアのキーすべてまで一括に公開する必要などない[208]。 保護される作品たるオブジェクトコードを、ユーザ製品に組み込む、またはユーザ製品に付属する、またはユーザ製品で使用するためのもの（例えばGPLv3ソフトウェアを含むインストール用物理的媒体）として伝達し、かつそのユーザ製品の所有及び使用にかかる権利を永久に、または一定期間譲渡する取引の一部として行われる場合は、取引の（法的）類型に関わらず、本第6項に基づいて伝達される対応するソースは、インストール用情報と共に伝達されなければならな い。ただし、ライセンシーやいかなる第三者も改変されたオブジェクトコードをそのユーザ製品にインストールすることができない場合は適用されない。一例を 挙げると、作品がROMに格納されている場合改変しようがないので本項は適用されない（第6項第5段落[209]）。伝達者は改変部分を含む「対応するソース」を本第6項第1段落に従って伝達しなければならないが、同時にインストール用情報も伝達すべしとの規定である。受領できる対象者は、ユーザ製品の所有権を永久、もしくは有期で譲渡されるものに限られる。ユーザ製品を購入、譲渡されたエンドユーザーは これに該当する。また「対応するソース」の伝達義務を負う者は、「保護された作品に改変を加えたオブジェクトコード形式の作品」を伝達するもの全てであった（本項第1段落）が、「インストール用情報」を伝達する義務を負うものは、「オブジェクトコードを伝達するもの」のうち、永久もしくは有期でユーザ製品を譲渡するものが対象となる。例えばユーザ製品のメーカー、ユーザ製品のレンタル業者はその対象となり、ユーザ製品を最終消費者に売りさばく小売店は入らない。しかし、オブジェクトコードとインストール用情報を同時に添付することになるので、実質的にその対象となるのはメーカーである[210]。 さて、対応するソースとインストール用情報を手に入れた受領者が実際にユーザ製品に組み込んだ時点でのユーザーに対するメーカーの免責を規定する。インストール用情報の提供に関する条件には、受領者が改変もしくはインストールした作品、またはその作品が改変もしくはインストールされたユーザ製品に対して、 保守サービス、保証、アップデートを提供し続けるという条件は含まれない。一例を挙げると、改変によってネットワークの運用に重大かつ有害な影響をもたらす場合、もしくはネットワーク上での通信に関する規約またはプロトコルに違反するような場合には、ネットワークへのアクセスを拒絶することは何ら問題ない（第6項第6段落[211]）。メーカーはユーザーの改変によるハードウェアの保証は必要ないとの規定だが、インストール用情報をユーザーに提供することで、何らかの法律に違反する行為を助長したり、幇助することにつながる可能性もある。例に挙げたネットワークへの影響は一例に過ぎず、ユーザ製品の用途によっては改変版ソフトウェアの利用によって、危険行為や極端な例では死亡事故につながる可能性もある。 さらなる注意点として、SFLCによれば、それぞれの国の法律の規制を遵守するために組み込みソフトウェアの改変を禁止するような場合では、本条項の履行を強制することはないと述べている[210]。例えば、携帯電話端末などのユーザ製品で、電波を用いて組み込みソフトウェアのアップデート情報が送信され、機器により自動的にソフトウェアのアップデート処理が実行される場合がある。この場合メーカー側は改変の自由が確保されている。しかし、日本の携帯電話自体は、電波法ならびその施行規則により、技術基準適合証明を受けることになっている。このため改変版ソフトウェアの導入により、改造を行うと再度証明を受ける必要があり、再証明を受けず使用すると電波法違反となる[212]。インストール用情報を提供することによりこのような違法行為を助長することになる、と想定したうえで、インストール用情報を提供する必要性の有無を考えると、このような場合は必ずしも必要とはいえないのではないかと述べている。これとは対照的に携帯情報端末やいわゆるスマートフォンの 一部は、もとよりユーザーに改変版ソフトウェアのインストールを部分的に許容している。このような場合はハードウェアによる制限を何らかの形で課すことに よって、改変の自由におけるユーザー間での差別を生む（例えば、ハードウェアメーカーから認証を受けたアプリケーション業者がソフトウェアを自由に改変で きる一方、一般ユーザーは一切改変できない[注釈 36]）。道義的な問題でしかないが、仮にそのユーザ製品に組み込んだソフトウェアがGPLv3で保護されているならば、メーカーはユーザーからインストール用情報 の提供を迫られるだろう。ユーザ製品にGPLv3ソフトウェアを組み込むメーカーは、法的な制限を考慮する必要がある[213]。 最後に本第6項で述べた対応するソースとインストール用情報のファイルフォーマットを規定する。本第6項に基づく対応するソースの伝達及びインストール用情報の提供は、文書化され一般に公開されておりかつソースコード形式で一般に利用可能な何らかの実装方法を有する、フォーマットにより提供されなければならない。このような場合、アーカイブの圧縮展開、読み込み、または複製に特別なパスワードや鍵などのキーを必要としてはならない（第6項第7段落[211]）。FLOSSの実装を持つフォーマットとなるので、対応するソース、インストール情報である中身はテキストファイルでなければならないと考えがちだが、PDF、RTF、DOC、はたまたDOCXはFLOSS実装があるので[注釈 37]問題ない。ただし、その文書が「『ソースコード形式』で一般に利用可能」でなければならないので、例えば、そのPDFなどにコピー禁止を施したり、ソースコードをスクリーンショット等の画像で貼り付けるなどといった「改変を加えるに当たって好ましくない」形式は許されない（第1項）。またその中身を圧縮したアーカイブもFLOSS実装があるものでなければならない。ZIP（Info-ZIP参照）、LHA[214]、7zは問題ない。しかし、DGCAなどは、2011年時点で、プロプライエタリな実装しか存在しないので、このようなフォーマット形式を使用してはならない。いずれにせよ受領者が中身を取り出す上でFLOSSな実装のみに依存し、パスワード等を掛けていない場合は問題ない。 追加的条項第7項は、GPLとの両立性を向上させることを主な目的として、ライセンスを補足する追加的条項[注釈 6]を課すことができると述べている。それは追加的許可条項（additional permissive termsまたはadditional permissions）と追加的非許可条項（non-permissive additional terms）と定義される。 「追加的許可条項」（Additional permissions）とは、本ライセンスが課す条項に例外を設けることにより、本ライセンスの条項を補足するものと定義する。追加的許可条項が本プロ グラムの全体に適用される場合、準拠法の下で有効とされる限り、追加的許可条項は本ライセンスに含まれているもの（本ライセンスと一体のもの）と見なされ なければならない。追加的許可条項が本プログラムの一部分にのみ適用される場合は、その部分のみに関しては課される追加的許可条項に基づいて別途利用可能 であるが、本プログラム全体については、追加的許可条項の内容如何に関わらず、本ライセンスが適用される（第7項第1段落[215]）。 結果として追加的許可条項は、GPLv3で課される条件を一部緩和することになる。このような例は、GPLv3なソフトウェアがGPLと両立しないライセ ンスで頒布されるライブラリとリンクしたい場合は、そのGPLv3なソフトウェアに「当該ライブラリのリンクを許諾する」という例外条項をライセンスに明記する[216]。この例外条項が追加的許可条項の一例である（そもそも追加的許可条項は従来慣習的に用いられていた例外条項の一般化に等しい[22]）。GPLv3で保護されるGNU WgetはOpenSSLとリンクするため実際に例外条項を定めている。また既に何度も述べてきたが、LGPLv2.1そしてLGPLv3は共にあらゆるライセンスのソフトウェアのリンクを許諾する条項、すなわち追加的許可条項を持つライセンスであると見なせる（LGPLv3はさらに内部的にGPLv3を参照しているので条文全体が追加的許可条項であると見なせる）。 保護された作品を伝達する場合（第4項、第5項、第6項参照）、ライセンシーは追加的許可条項のいかなる条項についても、その作品の全体または一部を削除で きる（追加的許可条項は、所定の改変がなされた場合はその追加的許可条項自体を削除するように規定することすらもできる）。ライセンシーは、ライセンシー が保護された作品に加えた部分であって、ライセンシーがコピーライトを持つ、もしくは与えることができる（許諾できる）部分について、追加的許可条項を定めることができる（第7項第2段落[217]）。 一般的に、コピーライト保持者（著作権者）がコピーライト（著作権）を主張できる部分にしか許諾条件を定めることはできない。このことによりライセンシー がコピーライトを主張できる部分のみに対しては新たに追加的許可条項を定めることができる。また当然ライセンサーは全ての許諾の変更・削除ができる。しか し、GPLv3では、任意の追加的許可条項についてはライセンシーなら誰でも削除できると本段落で規定している。 本ライセンスの他の条項に関わらず、保護された作品にライセンシーが加えた部分については（当該部分のコピーライト保持者が認める場合）、本ライセンスの条項に加え、以下の条項のいずれかを追加することができる（第7項第3段落[218]）。
これらは結果としてGPLv3で規定される条件よりも厳しい要求を課すので、「追加的非許可条項」（non-permissive additional terms）と呼ばれる。小項a)は、SFLCによると特定国家の準拠法によって無保証性や免責が認められない場合があるため規定された[217]。小項b)はSFLCによるとMPLやその一部派生ライセンスが課す法的な義務や作成者の表示に関する条項（MPLv1.1 "3.5. Required Notices."など）[220]と両立できるようにするものである。これによりMPLでライセンスされたソフトウェアを（個々のコードの著作権者の許諾を得ることもなく）GPLv3で再ライセンスできる[218]。小項c)は虚偽記載の禁止事項であり、故意では無い記載ミスはフェアユースで救済すべきとも考えられるが、同時にこのような制限を設けることにも合理的で異論は無いため規定されている[22]。小項d)も同様の規定をFLOSSライセンスで採用しているものが多数存在する。小項e)も小項c)と同じく、商標のフェアユースは認められてしかるべきであるが、合理的であるため規定されている[22]。小項f)はApache License v2.0 "9. Accepting Warranty or Additional Liability."[221]に規定されている免責条項との両立性を確保する条項である[61]。 このほかにもApache License v2.0はGPLv2と両立しない条項があり、前述の小項e)のような商標の取り扱い（"6. Trademarks"）、「特許停止条項」（"3. Grant of Patent License."）が当てはまる。特許停止条項とGPLv3で対応する条項が第10項第3段落で述べる「特許非係争条項」条項である。これら3つの改訂 点を取り入れたため、GPLv3で保護された作品はApache License v2.0で許諾されるソフトウェアを取り込み、GPLv3で再ライセンスできる、しかしこれは一方的であり逆は不可能である[222]。 本項第3段落で規定した以外の追加的非許可条項を定めることは許されず、それらは全て本ライセンス第10項の「さらなる権利制限」（"further restrictions"） とみなされる。ライセンシーが受領した本プログラムまたはその一部に、本ライセンスに加えてさらなる権利制限が適用される旨が記載されている場合、ライセ ンシーはそれらを（無許可で）削除することができる。さらなる権利制限を含むライセンス文書が本ライセンスに基づく再許諾または伝達行為を認めている場合 は、再許諾または伝達においてそのさらなる権利制限を存続させないことを条件として、ライセンシーはそのライセンス文書の条項が適用されている部分を本ライセンスで保護された作品に追加することができる（第7項第4段落[223]）。のちほど述べるとおり第10項の「さらなる権利制限」はライセンスを自動的に終了させる（第8項）。これにより作品伝達ができなくなってしまうので、「さらなる権利制限に相当する追加的非許可条項」をコピーライト保持者以外が例外的に削除できるようにしている。 以上のように本項では、GPL以外のフリーソフトウェアライセンス、 オープンソースソフトウェアライセンスとの両立性を考慮した一種の妥協点を条項化したものであるといえる。本項に記載されている許可・非許可条項を中心に 別のフリーソフトウェアライセンス、オープンソースソフトウェアライセンスを策定することでGPLv3と完全な両立性のあるライセンスを作成できる。もち ろんソースコードを開示しない、または開示してもフリーな利用を許さない独占的ライセンスはこのようなことを考慮しても無駄であり、（マルチライセンシングを除き）両立することは決してない（セクション"両立性とマルチライセンス"を参照）。 第7項の第5段落では、追加的条項の記載箇所（ソースファイル内に直接記載またはその他参照できる場所の記載）、第6段落では追加的条項のフォーマット（独立したライセンス文書形式または本ライセンスの例外規定として記述。形式に関係なくどちらでも適用される）を規定している。 終了第8項では、前述した保護された作品の改変、普及（伝達含む）や後述のパテントライセンスなどGPLv3で許諾された権利が行使できなくなる、すなわちライ センシーがライセンス違反を行ってからそのライセンスの終了を迎えるまでを規定している。GPLv3はGPLv2と同じくライセンス違反による自動終了の形態を採用している（その他のライセンスでは、著作権者による個別終了方式を採用しているものもある）。しかし、GPLv2とは異なり幾つか特例を設けて違反者の負担軽減を図っている。 本ライセンスで明示的に定められている場合を除いて、保護された作品を普及または改変してはならない。そのような規定以外に保護された作品を普及または改変しようとする企て（attempt）はすべて無効であり、そのような企てをした場合は、本ライセンスに基づくライセンシーの権利（この権利には第11項第3段落に基づいて許諾された「パテントライセンス」（"patent license"）も含まれる）は自動的に終了する（automatically terminate）ものとする（第8項第1段落[224]）。このようにしてライセンスが自動的に終了した場合、作品の改変や再伝達などをコピーライト保持者（著作権者）の許諾なく行使すれば著作権侵害となる（第9項）。ちなみに第9項で定められる、ライセンス受諾の不要な行為（例: 本プログラムの実行）は引き続き許可される。終了の条件に、ライセンスに従わない改変行為等の企て、とあるので、ライセンス違反未遂であっても終了に追い込まれる可能性もある。 前述の規定はかなり厳しいように思えるが、GPLv2も全く同じ規定である。しかし、GPLv3では第8項第2段落以降で、ある期間内に違反者がライセンス違反にある状態を解消した場合の救済措置を規定している。考慮不足に起因する不用意な違反の救済を目的としている[225]。 （第1段落に対して）しかしながら、本ライセンスに違反する行為のすべてが中止された場合、特定のコピーライト保持者から違反者に供与されたライセンスは、
（第8項第2段落[225]）。 ここで注意すべきなのは、違反したライセンシーの許諾終了に対し、保護された作品の「ライセンサー」が包括的な違反告知を行うのではなく、（巨大なソフト ウェアだと多数に上るはずだが）個々の「コピーライト保持者」（著作権者）が違反者に働きかけることになる点である。著作権を主張できるのは著作権者のみ であるから、当然といえる。違反者が(a), (b)どちらの裁定を下されるかは、ライセンス違反行為を中止してからの、コピーライト保持者が違反事実を違反者に告知する日に因るところとなる。このこ とから、コピーライト保持者はライセンシーの違反行為を直接的または間接的に察知しなければならない。違反者が違反行為を中止して60日以内にコピーライ ト保持者から違反の合理的手段による事実の告知を受けた場合、違反者は暫定的なライセンス回復を受けた後、最終的には、明示的、確定的にライセンスを終了 させられる。違反者が違反行為を中止して60日を越えてから、コピーライト保持者から違反の合理的手段による事実を告知された、または、60日たってから も一切告知を受けていない場合、違反者はライセンスを恒久的に回復させられる。通常、ライセンス違反により、ライセンスを停止させられた場合、個々の著作 権者と再度交渉して合意を得れば、個々の著作権者が著作権を主張する部分のみライセンスを回復できるが、それが膨大な数にのぼるケースもある。そのような 事態に陥るケースに比べて、本段落の条項は容易に回復できる手段を提供している[225]。 （第2段落に追加して）さらに、あるコピーライト保持者が違反者に対して合理的な手段で違反の事実を告知した場合において、それが本ライセンスの違反（ここで はコピーライト保持者のいかなる作品に関して違反したかを問わず）に関するそのコピーライト保持者からの最初の告知であり、かつその告知を違反者が受領し たあと、30日以内に違反を是正した場合は、そのコピーライト保持者から違反者に供与されたライセンスは、恒久的に回復するものとする（第8項第3段落[226]）。 ライセンス違反が、該当するコピーライト保持者のGPLv3で保護される全ての作品のライセンス違反を勘定してなお、初回の場合はこのような特例が適用さ れる。この段落も第2段落と同じく、個々のコピーライト保持者毎に違反者に下される決定が変わってくるので、作品のコピーライト保持の区分けによって、あ る部分では初回の違反で、別の部分は初回ではないというケースもある。初回ではない、また初回であってもコピーライト保持者からの違反告知から30日を越 えて違反が是正されなかった場合、第2段落の条項による裁定に移る。 本項に基づいてライセンシーの権利が消滅した場合でも、本ライセンス に基づいてそのライセンシーから複製物、または権利を受領、または承継した者に対する許諾は、消滅しないものとする。ライセンシーの権利が消滅し、恒久的 に回復されないこととなった場合、同一のライセンス対象に対する新たなライセンスを本第10項に基づいて再度受領することは許されない（第8項第4段落[227]）。よって違反者とは対照的に、その下流受領者においては、引き続きライセンスが有効となり、違反者がコピーライトを持つ改変点すらも含めて、 作品の改変、普及、パテントライセンスなどの各種GPLv3の権利が下流ライセンシーに保証される。この規定は第2項第3段落のサブライセンスの否定や第 10項第1段落のライセンサーからの直接許諾規定から判断して妥当といえる。しかし、このままでは同じ第10項第1段落の規定によりプログラムの複製を受 領すれば、一度ライセンスを終了させられたものですら、ライセンスを再度得ることになってしまうので、「一度ライセンスを終了させられたものは、たとえ本 プログラムを受領したとしても、そのライセンスは二度と得ることはできない」というペナルティを課している。 複製の受領の為の行為とその行使における許諾の不要本プログラムの受領またはその実行については、本ライセンスの承諾を必要としない。peer-to-peer 伝送を使用して本プログラムを受領することに伴って生ずる保護された作品の付随的普及についても、同様に承諾を必要としない。しかしながら、それら行為を 除き、ライセンシーに対して、保護された作品の普及または改変を許諾するものは、本ライセンスのみであり、このこと以外は認められない。これらの行為は、 本ライセンスを承諾しない限り、コピーライトを侵害することとなる。したがって、保護された作品を改変または普及することにより、ライセンシーは当該行為 を行うために本ライセンスを承諾する旨、意思表示したことになる（第9項[169]）。 プログラムの実行は普及行為ではなかった（第0項第6段落）。このことを鑑みプログラムを実行するのにライセンスを承諾する必要はないと第2項第1段落で 規定した事項を再度述べている。極端な例、第8項でライセンスを終了させられたとしてもプログラムの実行は許可される。また、受領も同様であり、ライセン ス違反者ですらもプログラムを受領できる。ただし、このままでは、次の第10項第1段落の規定により、ライセンス違反者だろうが何だろうが全ての受領者は ライセンス許諾を得ることになってしまう。これを防止するためそのプログラムのライセンスに以前違反し、かつ（明示的かつ確定的に）終了させられたものは 二度とそのライセンスの許諾を得ることはないと第8項第4段落に規定した。また第6項第1段落小項e)でオブジェクトコードの伝達に利用できると規定した P2P伝送においては、その技術的性質により、作品を受領したものは、同時に作品を他者に送信可能な状態に置いている。これは普及行為なので、通常はライセンスの承諾なく行使できないが、このための例外を設けており、許可を得る必要はない[200]。これ以外の、保護された作品の普及、改変をコピーライト保持者の許可無く行う行為は全てコピーライト保持者のコピーライトを侵害する（著作権者の著作権を侵害する）故、仮にこれら行為を行ったということは、GPLv3という契約書を承諾したという意思表示に等しい、と規定している。すなわちこれら行為を無許可で行った場合、ライセンシーは民法第526条に従って、GPLv3という契約書に沿った契約を締結したと解釈できる[228]。セクション"ライセンスと契約にまつわる問題"でGPLは契約ではなくライセンスであると述べたが、大陸法では両者を区別できない。従ってこのような法体系を持つ法のもと、GPLを契約と見なすことも可能であり、この第9項にその承諾規定が記載されている（日本の民法は 大陸法を法体系に持っているものの、GPLが契約と見なせるかは判例などの法的根拠がないため不明である）。ところで、前述の通り「改変」にライセンスの 承諾が必要とあった。普及行為の定義（第0項第6段落）で述べたような、「私的な改変か否かの区別」はここではなされていない。「組織内部の私的改変」は 第0項第6段落によると普及ではなく、また伝達でもない。この行為が許諾されるか否か、第2項の「基本的な許諾」など、その他の条項などに定められていな い。組織内部であるか否かに関わらず、改変はこの第9項第4文にて許可されるので、無許可で行使した場合、そのことがGPLv3を改変者たるライセンシー が承諾したとの意思表示になり、GPLv3という契約の成立と解される[229]。よって組織内部での改変を行うライセンシーはGPLv3の義務を免除されたわけではない[229]ということに注意すべきである。例えば第10項第3段落の「特許非係争義務」が免ぜられることはない[229][228]。例を述べる。ある組織が受領したGPLv3プログラムをその組織内部で私的に改変して利用していたが、自組織の持つ特許がそのプログラムに勝手に組み込まれていたことにある日気づいたとしても、パテントクレーム侵害を訴訟の 手段で解決することは許されない。仮にそのような訴訟を起こした場合、第10項第3段落により、第8項第1段落の「ライセンス終了」の規定に該当する。ラ イセンス終了後は、当該組織は第8項第4段落の規定から、以後その保護された作品を受け取ってGPLv3の許諾を得ることは一切できなくなる。ライセンス 終了時点で使用しているGPLv3プログラムに関しては、それも「利用を停止すべき」という解釈と「引き続き利用できる」という解釈の二通り存在する[228]。前者は第8項のterminateを民法第545条 1.の「直接効果を持つ解除」と解釈した場合である。この場合、解除の遡及的効果によって単なる私的な改変であってもそれはライセンス無効下において、著作権者からの許可を得ることなき改変であったと遡及的に解釈されるから、ライセンスを終了させられた組織は逆にそのプログラムの個々の著作権者から、著作権侵害で反訴、逆提訴される可能性すらもある。後者は民法第620条に記載されている通り、「解除は、将来に向かってのみその効力を生ずる」となるので、もう既になされた行為までその違反性を問われることはないとする解釈である。 下流の受領者への自動的許諾第10項は主に受領者（recipient）に対する許諾を規定している。 保護された作品の受領者は、ライセンシーがその保護された作品を伝達するごとに、オリジナルのライセンサーから、本ライセンスに基づいてその作品を実行、改変、及び普及する許諾を自動的に得るものとする。なお、ライセンシーは、第三者に本ライセンスの規定を遵守させる義務を負わない（第10項第1段落[230]）。 この規定により、受領者は、直接作品を受領したライセンシーからではなく、オリジナルのライセンサー（原著作者）から直接GPLv3を受諾したことにな り、その許諾は誰かに許可を得ることなく、作品を受領した瞬間に受け取る。このことを根拠として、第2項第3段落のサブライセンスの否定、第8項第4段落 の下流受領者のライセンス継続の確保、が成立する。またこれを濫用することにより、既に第8項によりライセンスを終了させられたものですら再許諾を許すの で、これを防止する規定（違反者の再許諾禁止、第8項第4段落）も存在する。 第2段落は、受領者たる組織が企業組織再編などにより第三者に保護された作品を移転した場合、どのような解釈がなされるかを規定する。 「企業体取引」（"entity transaction"。企業間主体取引など）とは、事業譲渡、会社分割、または合併に関する取引を いう。企業体取引の結果として保護された作品の「普及」が生じた場合、その保護された作品を受領した当事者は、譲渡当事者が前段落（第10項第1段落）の 条項に基づいて保有していた、または保有し与え得た許諾に係るすべてを承継するものとする。また、譲渡当事者が保護された作品の対応するソースを保有して いた場合、または合理的な努力により入手できる場合、受領の当事者は、その対応するソースを保有する権利もまた承継するものとする（第10項第2段落[231]）。企業組織再編の手続きは各種法律に従う必要があり、日本の場合会社法が当てはまる。「企業体取引」の定義に含まれている事業譲渡（transferring control of an organization）は会社法第467条、同第468条等により定められている（詳細はウィキブックス "事業の譲渡等（会社法第467条～第470条）"を参照）。事業譲渡により事業譲渡会社は事業譲受会社に「一定の営業目的のため組織化され、有機的一体として機能する財産を譲渡」する（記事"事業譲渡#事業の意義" を参照）。GPLv3で保護された作品が、当該財産に含まれていた場合、このことにより全く別の第三者組織に対して作品を複製し譲渡することになる。これ は、事業譲渡会社をGPLv3に従うライセンシーと見て、その作品をコピーライト保持者の許可無く「普及」（そのうちの「複製」。第0項第6段落より） し、事業譲受会社はその作品を受領する、という作品の「伝達」（convey。もとよりこの語は日本語で「譲渡」とも訳される）の一形態であるに過ぎない（第0項第7段落）[注釈 38]。ここまでは既に述べた条項からすぐさま解釈できることである[231]。 この第2段落は、企業組織再編の結果として普及行為が発生した場合、事業譲受会社が事業譲渡会社の本ライセンスの許諾一切を承継すると規定している。すな わち、この条項に従って事業譲受会社は、事業譲渡会社からGPLv3のライセンシーとしての立場を引き継ぐということを規定しているのである。従って事業 譲受会社はあたかも事業譲渡会社の立場で例えば第6項の「対応するソース」を上流伝達者に請求することもできる。なおたとえ企業組織再編が発生しても普及 を伴わないものであれば、本項の対象外となる。会社法で規定される会社分割（会社法第757条～第766条）、合併（会社法第748条～第756条）について、少なくとも日本において、両者は包括承継であり、事業譲受会社が事業譲渡会社の法律関係をそのまま承継するため、ライセンシーとしての立場もそれと同じである[232]。その際本項の規定は不要である。 第10項第3段落では、「さらなる権利制限」の禁止と「特許非係争義務」というライセンスの終了とも関連する重要な事項について述べている。 ライセンシーは本ライセンスに基づいて許諾され、または確認された権利の行使に対して、本ライセンスが規定する以上の「さらなる権利制限」（further restrictions）を課してはならない。例えば、ライセンシーは本ライセンスに基づく権利の行使に対してライセンス料、ロイヤルティその他の対価を課してはならない（第10項第3段落第1文[233]）。 第7項第3段落で規定した追加的非許可条項に含まれない権利制限は全て「さらなる権利制限」となり、いずれもライセンス違反となる。ところで、その一例と して「ライセンス料、ロイヤルティその他の対価」を徴収してはならないと書かれている。一見これは第4項第2段落、第6項第1段落小項b),d)その他と 矛盾する内容に思える。しかし実は、本項は「本ライセンスの下でライセンシーに認められている権利行使」に対する課金を禁じているだけに過ぎない。「ソー スコードの改変」などといったライセンシーに対しGPLv3で許諾されている改変行為に課金すること、GPLv3ソフトウェアを他のコンピュータにコピー した際に追加のライセンス料金を請求すること（「普及」行為への課金）、物理的マシン単位もしくは仮想機械、 インスタンス単位でのソフトウェア利用へ課金すること（「普及」行為への課金やGPL承諾不要のプログラム実行への課金）などはいずれも、本来GPL違反 にならない限り自由に行使してよいと定めているはずの行為に、不必要な制限を加えているので「さらなる権利制限」なのである。従ってこれらの行為に対する 課金を禁ずる本項は、「伝達行為の課金を許可した」各項とは矛盾していない[234]。 （第10項第3段落第1文より続き）また、ライセンシーは「そのプログラム」（"the Program"）の全体またはその一部の作成、使用、販売、販売の申出または輸入が特許を侵害することを理由として、訴訟（交差請求及び反訴を含む）を提起してはならない（第10項第3段落第2文[235]）。この規定を一般には「特許非係争義務」（Non assertion of patent clause, NAP. 特許不係争条項）と呼ぶ。非係争の対象となる作品は「そのプログラム」（"the Program"）、 すなわち上流から受領したプログラム自体である（受領していないプログラムは無関係である）。また特許を持つ受領者は誰を訴えることができないのかについ てであるが、それは条文中に明文化されていない。ただ本項の主旨から考えて少なくともそれには「下流の受領者」が含まれているのは間違いなく、仮に上流か ら受領した時点で自身の特許を侵害していることを察知し、それを知っておきながら故意に下流に伝達して、下流の受領者を訴える、などといった不道徳な行為 を是正する働きがあるといえる。では、上流の伝達者や、特許を侵害するような改変点を組み込んだ当事者はいったいどうなるのかは、条文から明確な解釈はで きない（提訴することでライセンス違反となるかは、誰を提訴できないかが明確化されていないため不明である。また、条文に書かれていないのであるから、全 てのひとを対象としている、と考えるのも妥当といえる）[235]。ちなみにセクション"複製の受領の為の行為とその行使における許諾の不要" で少し述べたとおり、この義務はGPLv3の許諾が必要な行為（作品の改変、普及。第9項）を行使する、しないに限らずライセンシーが負うこととなるの で、単なるプログラムの実行や組織内部での私的な改変を行っているだけでもその対象となっている。よって例えばプログラム実行時に自組織の特許侵害に気づ いても訴訟は問題解決の手段として採用できない。これは自組織の持つ特許が自分たちの与り知らないところでGPLv3プログラムに混入していたとしても、 全くもって問題を解決することはできない、という企業組織にとってはかなり頭痛の種となる条項である。次の第11項も特許権不行使を定めたものであるが、 これは個人、団体、組織、企業など特許を持つ人物が積極的な改変を行った場合を想定しており（多くの企業によるコントリビューションから成るGCCな どはそのようなプロジェクトの例）、特許を有効活用する目的で、譲り渡すことを規定している。そのような場合はある程度自組織で特許権をコントロールでき る可能性が高い。しかし、本項で対象となる特許は全てであり、あらゆる特許に関して訴訟による解決の放棄を迫っており、これも実質的な特許権不行使、特許 開放にあたる[235]。改訂プロセスでもこの条項はかなりの論争があったとされるが、企業が個人ユーザーを法廷に訴えるという脅迫行為をやめさせる目的で、FSFは一切妥協しなかった[22][235]。 特許GPLv3 では、以前のバージョンには存在しなかった特許に関する取り扱いが明文化されており、前述の第10項第3段落の「特許非係争義務」だけではなく、第11項 でGPLv3で保護された作品に加えられた特許や第三者の特許の取り扱いを規定している。この条項によりGPLv3プログラムを受領するものはその不当な 特許攻撃から概ね守られることとなる。 「貢献者」(contributor)とは、本許諾書の下で「本プログラム」、あるいは「プログラムを基にした作品」を使用出来るコピーライトを保持するものとする。このようにしてライセンスされた作品を貢献者による「貢献者バージョン」(contributor version)と呼ぶ（第11項第1段落[236]）。 保護された作品（「本プログラム」と「プログラムを基にした作品」）の貢献者に該当するのは、保護された作品の個々のコピーライト保持者である。まず、 「本プログラム」のオリジナル開発者、原著作者で本プログラムをGPLv3で利用することを許諾したライセンサーが当てはまる。上流の伝達者から受領し GPLv3のもと改変、それを再度伝達したものは、コピーライトを主張できる部分を持つ、すなわち改変点についてのコピーライト保持者となり、貢献者であ る。対照的に、上流の伝達者から受領した保護された作品に改変を一切加えず下流に横流ししただけの伝達者は、コピーライトを主張できる部分がないので、そ の作品に関しては貢献者ではない。貢献者バージョンとは貢献者のコピーライトを主張できる部分を持つ作品のバリエーションのことで、その作品全体を指す （コピーライトを主張できる部分に限定されるのではなく作品全体である）[236]。貢献者バージョンは、保護される作品の対象よりも範囲が狭い。この二つの用語は、MPLのある条項で定義されているものに類似している（1.2. "Contributor Version"）[236]。ここまでの定義ではほとんど「改変した者」や「改変バージョン」との違いが見当たらないが、以降の段落で規定されるとおり、貢献者は特許を保持していることが、一般の改変者とは違う点である。 ある貢献者の「必須パテントクレーム」(essential patent claims) とは、取得済み、あるいは今後取得する予定があり、その貢献者が現在所有ないし「支配」（"control"）していると言える特許のうち、貢献者バー ジョンに対して、本ライセンスで許可されているような作成や利用、販売といった何らかの形の行為を行うことにより侵害される可能性があるパテントクレームの すべてと定義する。ただし、貢献者バージョンをさらに改変した結果としてのみ初めて侵害されるようなクレームは含まれない。この定義において、「支配」に は本ライセンスが課す条件と整合的なやり方で特許の再許諾（サブライセンス）を認める権利も含まれる（第11項第2段落[237]）。「必須パテントクレーム」は、日本の特許法では、第七十条「特許発明の技術的範囲」[238]に属する請求項（クレーム）の一つの類型となる[239]が、それだけとは限らないことが条項から読み取れる（必須特許範囲、essential patent claimsと同じ用語になっているが、八田真行がそのように訳していないのはこのため）[240]。特許権侵害とは、「他者の特許権を無断で利用し業をなすことである」[241][242]。通常、特許権侵害はパテントクレーム（特許クレーム、特許請求項）の直接侵害や請求項の文言侵害、間接侵害（寄与侵害、Contributory patent infringement）、均等論の法理下における侵害など多岐に渡る（記事"特許権侵害訴訟"なども参照。この点をもって、ソフトウェア特許な どに否定的な人物・団体からは激しく非難されている）。本段落ではGPLv3で許諾される行為を貢献者バージョンに対し行使することで特許権侵害にあたる 請求項、パテントクレーム全てを、作品毎に「必須パテントクレーム」と定義している。必須パテントクレームには前述の条件に一致しかつ貢献者が現時点で保 持しているもの、または将来取得予定のものも含まれる。また貢献者自身が保持していないがサブライセンスにより貢献者が授与されているパテントクレームも 含まれる。しかし重要な例外があり、「貢献者バージョンをさらに改変した結果としてのみ初めて侵害されるようなクレームは含まれない。」という規定があ る。よってある貢献者が上流の貢献者から作品を受領した時点、もしくはそれに貢献者自身で改 変を加えて、その貢献者自身が保有する「特許を構成する要件」（これを「構成要件」と一般には定義される。侵害のケースで変化するが、「特許発明の技術的 範囲」として具体的にパテントクレームに列挙される「請求項」という箇条書きの文言に合致する要件を備えている場合、文言侵害に当たる。この場合、箇条書 きの文言に合致する要件が「構成要件」である）を備えた場合、両作品が必須パテントクレームに該当する可能性があるが、下流の貢献者の改変の時点で初めてパテントクレームに抵触した場合、そのようなクレームは「必須パテントクレーム」ではない。必須パテントクレームに含まれる、含まれないケースを考察するため以下のような例を採り挙げる[243][244]。 各伝達過程にある作品とパテントクレームに抵触する可能性のある構成要素を定義する。
作品が伝達する流れは次の通りである。伝達過程はUC->PH->DRと考える。原著作者たるライセンサーからGPLv3のもと「本プログラム」を受け取ったUCは、構成要素C1を組み込んで「本プログラムを基にした作品」Wucに改変する。そしてUCはWucをPHに伝達する。同様にPHはWucに構成要素C2を組み込んで「本プログラムを基にした作品」Wphに改変し、DRに伝達する。DRは構成要素C3を組み込んで「本プログラムを基にした作品」Wdrに改変する。各作品に対し「コピーライト」を及ぼす関係から、各人物それぞれの「貢献者バージョン」（すなわちコピーライトを及ぼす部分を持つ全体としての作品）は以下となる（○: 貢献者バージョン ×: 貢献者バージョンではない）。
また伝達の過程にある各作品が備えるパテントクレームの構成要素は以下となる（○: 備えている ×: 備えていない）。
この時、PHの持つパテントクレームの構成要件を次のように定義する。
上 記の条件の下、PHのパテントクレームに抵触するケース、並びにPHに対する「必須パテントクレーム」に該当するしないを考察する。特許権を侵害するケー スは多岐に渡るので、考察を容易にするため、文言侵害のみを考える。この場合は、構成要件が少なくとも一つでも欠ければパテントクレームに抵触しないこと になる（権利一体の原則）。
さて、このようなケースに対しGPLv3は下流の必須パテントクレームに対する特許権侵害を免責する条項を規定している。 各 貢献者はライセンシーに対して、貢献者バージョンの内容の作成、利用、譲渡、譲渡の申し出、または輸入、並びに実行、改変、または普及を行う場合に必要と なる必須パテントクレームを対象とする、非排他的かつロイヤルティフリー（無償）の全世界で有効なパテントライセンスを授与する（第11項第3段落[245]）。いいかえると、ある特許を持つ貢献者は、仮にその下流の受領者が必須パテントクレームに抵触した場合でも特許権を行使することは許されない。よって前述の例で特許に関する事象をまとめると、
1. および2.は至極合理的な結果であり、1.については、自ら持つ特許を混入しておきながら、下流受領者を特許で脅迫するような暴挙をライセンスで封じるこ とになる。2.については、特許権保持者に与り知らず無断で特許を組み込むことは特許権侵害行為であるのは当然である。奇妙な結果となるのは3.である。 PHが受領した時点で既にPHの特許が侵害されているが、それをPHが発見したしないに全く関わらず、PHの責任で下流のDRに伝達することは、下流のDR（DRがその作品を伝達した場合は、さらに受領した下流の受領者も）に対し特許権を行使しないという責務を負うと解釈される。この3.の結果は特許権不行使を規定するその他のライセンス（例:IPL）と比べるとかなり異質である[246]。また、必須パテントクレームであるか否かを考慮せず、PHの特許権を侵害するケースすべてに対し、実際にPHがこれを解決する手段に「訴訟」を選ぶことは注意を要する。構成要件がR2またはR3い ずれの場合においても、PHが特許権侵害でDRを提訴した場合、第10項第3段落により、第8項第1段落のライセンス終了条件が発動、PHのライセンス終 了につながる。（このためPHがライセンサーの保護された作品に改変を加えて伝達した事実から、ライセンサーにより著作権の遡及的な侵害で逆に提訴される 可能性がある、というのはともかくとして、）このような場合、必須パテントクレームであるか否かで状況が一変する。まず、PHはライセンス終了によりライ センスで許諾された権利一切を喪失するが、一方下流のDRは第8項第4段落の規定により、ライセンスで許諾される権利は引き続き保護される。従って未だ もって「必須パテントクレーム」を成すパテントライセンスがPHから授与されていることになる。これにより、PHのパテントクレームの構成要件がR3ならば、DRは裁判において、この事実が抗弁となる可能性が高い。一方、必須パテントクレームでなければ、パテントライセンスは授与されないから、PHのパテントクレームの構成要件がR2ならば、DRは前述のような抗弁はできない[245]。 ま とめると、GPLv3で保護されるソフトウェア開発プロジェクトに参加する人物、団体、企業などは、仮に彼らが保有する特許構成要素をそのソフトウェアに 組み込んだ場合、もしくは既に組み込まれているが自らの責任で伝達した場合は、下流の受領者に対し、部分的に開放することになる。もしそれを避けたけれ ば、彼ら自らの手でソフトウェアに特許構成要素を組み込まないようにすることになる。 ここまでは、特許保有者がGPLv3で保護される作品に改変を加えたり、直接の伝達者となるケースであった。今度はGPLv3の直接の貢献者や伝達者ではない、ライセンスの埒外に位置する第三者、外部の契約者の保有する特許についての取り扱いを規定する。 セクション"バージョン3"で述べたとおり、GPLv3への改訂プロセス中にマイクロソフトとノベルが特許契約を締結したとの報道が舞い込んできた[54]。両者がSECへ提出した資料[50]や両社のプレスリリース[51][52][53]によると、Microsoft WindowsとSUSE Linux Enterprise Serverの相互運用性を高めるとの名目で互いにロイヤルティーを支払い、その見返りに互いの（互いの顧客も含む）特許権侵害を見逃す、すなわちパテントクロスライセンス（特許相互許諾）を付与するという契約を締結したとされる。このマイクロソフト-ノ ベル間の特許ライセンス契約は、GPLのライセンス埒外にいるマイクロソフトと、GPLのライセンシーであるノベルが、その他多くのGPLのライセンシー を差し置いて、自分たちのみが特許攻撃を回避、ライセンシーを不当に差別する不公平な特許契約であるといえる。以下の段落では、その他のライセンシー、受 領者を不当に差別するような特許契約を締結させないようにすること、そして特定のライセンシーが締結した場合の対抗措置が定められている。 以下の3つの段落において「パテントライセンス」（patent license、特許ライセンス、特許許諾）とは、名称に関わらず、特許権を行使しないという明示的な契約[注釈 39]または誓約（commitment、コミットメント）（ある特許の明示的な実施許可、または特許権侵害訴訟を提起しないことに合意する非係争条項等）のすべてをいう。そのようなパテントライセンスをある当事者に「授与する」（grant）とは、相手方当事者に対して特許権を行使しないという契約締結または誓約を指す（第11項第4段落[247]）。前段落で既に使用していた用語「パテントライセンス」を再度定義しなおしている。これは特許権不行使を述べた契約、メモランダムなど、名前によらず特許権不行使を述べているものは全て該当する。また特許権侵害訴訟の不行使を要求する特許非係争条項（Non assertion of patent clause, NAP）も含まれる。パテントライセンスを授与するとは、該当特許の権利不行使を意味する。よって「特許ライセンス契約」を締結する場合も本段落の対象となる。 保護された作品が「パテントライセンスに依存していることを知りながら」（"knowingly relying on a patent license"） 伝達する場合において、保護された作品の「対応するソース」が公衆が利用可能なネットワークサーバまたは他の容易にアクセス可能な手段を通じて、無料かつ 本ライセンスに基づいて複製可能ではない場合、ライセンシーは、以下の3つのいずれかの措置を取らなければならない。
こ こで「パテントライセンスに依存していることを知りながら」とは、ある国においてパテントライセンスなくして保護された作品を伝達、またはライセンシーの 下流の受領者が保護された作品を利用すると、その国における特定の特許権を侵害することに繋がるということ、及びその特許権が有効であると信ずるべき合理 的理由が少なくとも一つ以上あること、以上のケースいずれについて、ライセンシーが実際に知っていることを指す（第11項第5段落[248]）。「パテントライセンスに依存していることを（実際に）知りながら」というケースは具体的には、
など、侵害を示す有効な事実を知っている場合が当てはまるとされる[248]。調査のコストに比し、このようなことを「知っている」とされる受領者はかなり限定される。またクロスライセンス契 約に基づく特許権を侵害していた場合は、「基本特許」が包括的で広範囲なものとなる場合が多く、侵害の事実を「知る」人物はさらに限定される。一般的に は、例えばある特許を侵害しているとされる著作物を受領したものが、特許被侵害者から直接、間接問わず働きかけられ、その事実を「知った」場合が最も多い と想定される[注釈 40]。講ずる措置(1)は、本段落のもともとの大前提となっている条件であり、この措置を実施することで、少なくとも受領者はGPLv3に従って改変できる故、理論上は特許権侵害を回避できる。もし対応するソースを開示伝達しなければ、「侵害事実を知っている」ライセンシー以外は特許攻撃を受けてしまう。措置(2)は、下流の受領者に特許攻撃の危険をはらむ物を伝達しておきながら、自らは回避しようとし、受領者を保護しないという不作為に 対し、そのような行為を直接やめさせる措置である。措置(3)は全ての受領者を特許権保護下におくことで、全ての受領者への特許攻撃を回避する措置であ る。いずれもライセンシーの実施コストが大きい、もしくは全く実現しない可能性が高いが、相対的に措置(1)は講じ易いとみられる[248]。 ある一対一の（単一の, single） 取引や協定に基づき、あるいはそれに関連しライセンシーが保護された作品の伝達、または伝達によって引き起こされる普及を行う場合、保護された作品を受領 した一部の当事者に対して、保護された作品の特定の複製の利用、普及、改変、または伝達する権限を持つパテントライセンスを授与するならば、ライセンシー が授与したそのパテントライセンスは保護された作品や「保護された作品を基にした作品」の全ての受領者にまで自動的に拡大されるものとする（第11項第6段落[249]）。受領者の行為如何に関わらず、ある特定のライセンシーが締結した全てのパテントライセンスが全受 領者に自動拡大されるというのが本段落の内容である。ある組織が別の組織（やその顧客）のみを対象に、自組織の持つ特許侵害を特別に赦すのであるならば、 そのような契約を締結していない人物、団体、企業などにも譲歩してしかるべきであるというのが本旨である。仮に特許侵害訴訟を受けた受領者は本規定を抗弁 にできる可能性が高い[249]。 あるパテントライセンスが「差別的」（discriminatory） であるとは、本ライセンスの下で明確に認められた一つかそれ以上の権利を、パテントライセンスがカバーする範囲内に含めなかったり、そうした権利の行使を 禁じたり、あるいは権利不行使を条件として課すようなものである場合を指す。本ライセンスのライセンシーを一方の当事者とし、ソフトウェアの頒布をなりわ いとする第三者との間で、ライセンシーは第三者に対し、保護された作品を伝達する活動の程度に基づいて対価を支払う一方、その第三者は、ライセンシーから 保護された作品を受領したすべての当事者に対して、
という「差別的」なパテントライセンス、またはそれに類似する協定を結んでいる場合、ライセンシーは保護された作品を伝達することはできない。ただし、ライセンシーがそのような協定を締結したり、パテントライセンスを授与されたのが2007年3月28日より以前である場合は本節の例外とする（第11項第7段落[250]）。 特許攻撃から回避できるようなパテントライセンスを授与し、残りのGPLv3プログラム受領者を特許攻撃に晒したまま「差別」するような不公平な遣り口に 対し、そのような誘惑に陥ってしまったライセンシーの権利を剥奪する措置を加えるのが本項第7段落の主旨である。本項第6段落ではそのような差別的パテン トライセンスを自発的に結ばせないことを期待しそれを無効化するアプローチを取ったが、本段落は、差別的特許契約を締結したライセンシーからGPLの権利 一切を積極的に剥奪する。差別的特許契約の締結対象である第三者は「ソフトウェアの頒布をなりわいとする第三者」、すなわちソフトウェアを頒布（販売な ど）するまたはソフトウェア専業である人物、企業、団体、組織などに限られる。このことからソフトウェアを一切取り扱わない人物、企業、団体、組織（例: ハードウェア専業企業、ITとは別業種の企業）などは対象外となる。また(b)で「保護された作品を含む特定の作品」とあるが、「本第三者」はソフトウェ ア専業に限っていないので、例えばハードウェア製品に保護された作品を組み込むケースも該当する。注意すべきこととして、条件(a), (b)は共に特定（specific）の製品を対象としていることから、製品が特定されていないパテントライセンス（例えば、クロスライセンス契約は前述の通り、包括的な技術提携など、特定の製品に限定しないものがある）は本規定の対象ではないとSFLCは述べている[250]。最終文の既得権条項の期限日は、本条項が初めて導入された第3次議論用草稿の公表日当日（2007年3月28日 EDT）である[49][64]。本条項導入のきっかけとなったマイクロソフトとノベルの行いは目溢しを受けたが、その後ノベルに倣って同様の契約を結んだものは対象となる（例: Xandros[251][252]）。 第8段落は以下の通りである。 本ライセンスのいかなる条項や記述は、準拠法国の特許法において、黙示的ライセンスやその他認められ得る特許侵害に対する防御手段を否定しまたは制限する意図と解釈してはならない（第11項第8段落[250]）。特許に対し暗黙的立場であったGPLv2は、GPLv3の本項を反対解釈したものではない、ということを改めて主張している。即ち「GPLv3のソフトウェアであれば特許は制限される」という事実に対し、「GPLv3のソフトウェアでなければ（→GPLv2のソフトウェアならば）特許は制限されない」というのは誤解である。GPLv2第7節でもその第1段落、第3段落で特許権行使による他者の自由の不当な制限を（直接的ではないにしろ）禁じている。 他者の自由を明け渡してはならない本ライセンスの条件と矛盾する何らかの条件（裁判所の命令や 契約・協定など、その他）がライセンシーに課されたとしても、ライセンシーが本ライセンスの条件を免れることにはならない。ライセンシーが保護された作品 を、本ライセンスが課す義務と他の関連した義務の両方を同時に満たすような形で伝達できないのであれば、結果としてライセンシーがそれを伝達することは完 全に不可能ということになる。例えばライセンシーが、自身で「本プログラム」を伝達した人々がさらに行う伝達するその行為に対して、彼らからロイヤルティ を徴収するような義務を負う条項に同意していた場合、ライセンシーがその条項と本ライセンスの両方を満たす唯一の方法は、「本プログラム」の伝達を完全に 停止することである（第12項[253]）。いわゆる「自由か然らずんば死を」条項[22]である。例として挙げられているのは、GPLv3で許諾された「本プログラム」を利用するもの（下流の受領者）から、利用料 金としてロイヤルティを徴収するような別の契約を（著作権者であるライセンサーなどと）締結することである。このようなロイヤルティの徴収は、第10項第 3段落からライセンス違反となるのは既に述べた。よってこのようなGPLv3と矛盾する契約を締結した後、ライセンス違反とならないようにするためには 「本プログラム」の伝達を中止する他ない。本項はこのことの再確認である。本項の題目にある「他者の自由を明け渡してはならない」（No Surrender of Others' Freedom）の「他者」とはライセンシーに対する下流の受領者のことを指している。ライセンシーが下流の受領者にプログラムを伝達しつつも、他方フリーソフトウェアの自由（改変やプログラム実行の自由など）を不当に制限する契約を受領者に強要することを禁じているのである[253]。第11項で述べた「差別的特許契約」（差別的パテントライセンス）も契約の対象とならない他多数の受領者の「自由を（特許侵害訴訟で）明け渡す」ことになるので、本項で制限対象となる契約の一つである[254]。その他GPLと矛盾する契約の最たるものが、改変の如何に関わらずソースコードの伝達を禁止する秘密保持契約（Non disclosure agreement, NDA）である[253][255][256]。ただし、一律NDAならばGPLで禁止されるわけではなく、例えば、以下どちらかをGPLv3のライセンシーに強要するNDAはいずれも締結しても構わない[257]。
上記の契約のどちらかが有効な期間中、いずれもGPLv3で保護された作品は外部に伝達されるこ とがない。あくまでGPLは再頒布の許可を下流の受領者に与えるのであって、「開発時点での非開示を禁ずる」ものではない。ゆえに、上記両契約において顧 客は、そのソフトウェアの性質を考え、自組織の外部に複製もしくはその私的な改変を伝達せず、秘匿すると想定される。ただ、あくまで想定であって、それを禁止する手段はGPLに従う以上存在しない。 余談ではあるが、本項と対応するGPLv2の節は第7節である。しかし「第7節の規定の一部が無効もしくは強制（エンフォース）不可能という場合は残りの部分が適用される」といういわゆる限定的分離条項 (limited severability clause)が消滅している。第1次議論用草稿趣旨説明書によると、この条項があると裁判においてライセンスの一部分が確実に認められる可能性は高まる が、同時にライセンス全てが認められなくなってしまう。よってむしろこの条項を削ったほうが、法廷にてライセンス全部を認めてもらえる、ということを期待 して削ったとのことである[22]（ただ逆に全部却下されるという危険性も増大した）[258]。 GNU Affero 一般公衆利用許諾書との利用本ライセンスのいかなる他の条項に関わらず、ライセンシーは保護された作品をGNU Affero 一般公衆利用許諾書バージョン3に基づいて許諾された作品とリンクまたは結合して単一の結合された作品とすること、及びその結果として作成された作品を伝達することができる。本ライセンスの条項は、その結合された作品全体における、保護された作品の部分に対しては引き続き適用されるが、結合された作品それ自体としては、GNU Affero 一般公衆利用許諾書の特定の条件、すなわちネットワーク上の相互作用（やり取り、インタラクション、interaction）に関する第13項も適用される（第13項[259]）。 AGPLはいずれのバージョンもGPLv3と原則両立しない。AGPLv3では"13. Remote Network Interaction"（「第13項 リモートネットワーク上の相互作用」）という規定があり、要約すると「ネットワーク相互作用を通じて保護された作品にアクセスするユーザーに、対応するソースを伝達しなければならない」[B]ということを規定している。一方、GPLv3ではウェブアプリケーションとして使用しかつそのオブジェクトコードを伝達しない場合（第0項第7段落では、「コンピュータネットワーク越しにユーザとやりとりするだけで、コピーの転送を伴わない場合」と規定していた[注釈 41]）は、GPLv3の義務（例えば、第6項: 対応するソースの伝達の規定）に従う必要はなかった。よってAGPLv3第13項はGPLv3で「規定されていない追加的非許可条項」すなわち「さらなる権利制限」に相当するため両立しないライセンスなのである。このような非互換性を回避する目的のもと、GPLv3第13項でAGPLv3の作品とGPLv3の作品のリンクや結 合を意図的に許可している。とは言え相互再ライセンスは許可されないので、AGPLv3とGPLv3が完全に両立するわけではないから、両者のソースコードを混合して頒布することは出来ない（バイナリコードならば問題ないが）という点には注意すべきである[260]。結合された作品は全体として（GPLv3のコード部分も含めて）"Remote Network Interaction"条項に従う必要がある。個々のコピーライト保持部分はそれぞれ、GPLv3、AGPLv3で保護されたままとなる。 "Remote Network Interaction"条項が実際に適用されるか否かは、「ネットワーク上の相互作用」の有り無しに係ってくる。ネットワーク上の相互作用を提供するソフトウェアは、CMSが 一例として挙げられる。ネットワーク上の相互作用でこれらにアクセスするユーザーに対し、CMSがGPLv2でリリースされている場合は改変バージョンの対応するソースを公開する必要はない。GPLv3ならば、仮に他のAGPLv3ソフトウェアと結合、リンクしている場合は両ソフトウェア全体として、改変バージョンの対応するソースを伝達することになる（そうでなければ、対応するソースを伝達する必要はない）。AGPLv3ならばいかなる場合でも改変バージョンの対応するソースを伝達することになる。一方、GPLv3プログラムを組み込んで、GPLv3で保護されるSSHサーバを作成、さらにAGPLv3でリリースされるCMSと連携するため両者を「結合」した場合（技術的に詳しくないユーザーの為にユーザビリティを向上する目的で、ブラウザによるフロントエンド・インタフェースを設置することは一般的である）、果たしてSSHサーバ部分まで対応するソースを公開する必要があるか、というのはよくあるケースである。SFLCによるとCMS部分はAGPLv3に従って対応するソースを伝達する必要があるのは当然だが、SSH部分は専らユーザー同士のインタラクティブなインタフェースを提供しているわけではないので、"Remote Network Interaction"条項には当てはまらない[260]。よってSSH部分については伝達する必要はないと述べている。 ちなみに、条文の文字を実際に読むなり、diffコマンドで両条文テキストに行差分をかけて見ただけでも分かるとおり、第13項を除けばAGPLv3はGPLv3の完全な複製であることが理解できる。前文の一部やライセンス名称の違いなどの瑣末な点、条項の外に書かれているソースコードのネットワークインタラクティブな伝達の方法を勧める旨の規定ぐらいしか相違点が存在しないほどである。またAGPLv3第13項にGPLv3第13項の裏返しとなる規定が（当然ながら）なされている[B]。 B AGPLv3の非公式日本語訳が存在しないため、第13項のみ、以下あくまで非公式に翻訳したものを参考までに記載する。用語の定義はAGPLv3第0項、その他条項に定義されているが、一字一句GPLv3と同じなので省略する（例えば、「本ライセンス」はAGPLv3を指すなど）。
本ライセンスの改訂されたバージョンフリーソフトウェア財団は、改訂された、あるいは新しいバージョンの GNU 一般公衆利用許諾書を折りに触れて発行することができる。そのような新バージョンは、その精神においては現在のバージョンと似たものになるだろうが、細部については新たな問題や懸念を解決すべく異なるものになる可能性もある（第14項第1段落[262]）。GPLは前文で「条文の完全な複製と頒布は許可するが変更は不可」としているため、本段落の規定も考慮すると、GPLの新しいバージョンは常にライセンス条文の著作権者であるFSFから発行される。 それぞれのバージョンには、見分けがつくようなバージョン番号が振られている。本プログラムに、ある特定のバージョン番号が振られたGNU 一般公衆利用許諾書「か、またはそれ以降のバージョンのいずれか（or any later version）」が適用されると指定されていた場合、ライセンシーは指定された番号のバージョンか、またはそれ以降にフリーソフトウェア財団によって発行されたバージョンのどちらの利用条件に従うかを選ぶことができる。本プログラムが本ライセンスのバージョン番号を指定していなかった場合には、ライセンシーはフリーソフトウェア財団がそれまでに発行したバージョンの中からどれを選択しても構わない（第14項第2段落[263]）。 ライセンスがリリースされた時期によらず、適切な指定があればライセンシーがライセンスのバージョンを特定バージョン番号以降で任意に選べる。将来新しいライセンスが発行された場合、それを自動的に選択するような方法（any later version）も採用できる。バージョン指定がなければ任意のバージョンを指定できる。ライセンサーが特定のライセンスバージョンを指定する場合、ライセンシーもそれに従う必要がある。そしてそのような場合は自動的にバージョンアップされない。詳しくはセクション"両立性とマルチライセンス"を参照せよ。 本プログラムにおいて、GNU 一般公衆利用許諾書の将来のバージョンのうちどれが適用され得るかは代理人が決定できる、と指定されていた場合、その代理人が、あるバージョンを受諾すると述べた公的な声明は、ライセンシーに対し、そのプログラムに関してそのバージョンのGNU GPLを選ぶことを永続的かつ正式に許可するのと等しい（第14項第3段落[264]）。このような「代理人」の例はFLOSS開発プロジェクトの指導者、リーダーである。プログラムの個々の著作権者がライセンスを指定できるのは、著作権法の要請するところだが、一方GPLは両立しないライセンスとの混合を許さない（GPLv2とGPLv3が両立しないのは前述した）ので、代理人が一括してバージョンを決定できるようにしたほうが都合がよい。またこれにより特定のバージョンのみをピンポイントで選択できる利点がある（any later version方式ではこのようなことはできない）。注意すべき部分は、次の文言「将来のバージョンのうちどれが適用され得るか（can be used）」である。代理人がバージョンを変更しないことも許されている。 本ライセンスの以後のバージョンでは、ライセンシーに追加的な（additional）な、または従来とは異なる形式の許可条項（permissions）が与える可能性がある。しかし、著作権者やコピーライトを保持するものに対し、ライセンシーが以後のバージョンに従うことを選んだ結果として、追加的な義務が課せられることはない（第14項第4段落[265]）。 将来のバージョンに自動的にアップグレードした場合、そのバージョンで初めて導入される「追加的許可条項」やその他異なる扱いの許諾などは、適用されず破棄されるということを定めている。例えばGPLv2とGPLv3の相違点を考える。大きな違いは特許の取り扱いであった。GPLv3のパテントライセンス付与は極めて強力な権利であるが、"GPLv2 or (at your option) any later version"で頒布したプログラムのライセンサーが、許諾時点でこのようなことを想定していないのは容易に想像できる。そのようなことがライセンサーの許可なく執行されることはないという規定である[61][266]。さて、ライセンシーは前述したそのプログラムをGPLv2ではなくGPLv3で伝達することは可能である。ここで仮にライセンシーが下流の受領者に伝達した場合、ライセンシーはその受領者に対して、ライセンシーの持つ特許のパテントライセンスを付与している。ライセンシーが"GPLv2 or (at your option) any later version"というライセンサーの許諾からGPLv3に一本化しているのだから、ライセンシーは下流の受領者に完全な形のGPLv3で許諾しているのである。その他反TiVo化条項（第6項第3段落～第7段落）によるインストール用情報の請求もライセンサーには請求できないが、プログラムを組み込んだユーザ製品を伝達すれば、逆に 下流の受領者からインストール用情報の提供がライセンシーに求められる。ライセンシーの得られる権利は少なくなるが、与える権利は変化がないという当然の帰結である。本段落では明文化はされていないが、ライセンシーが特定のバージョンに一本化することなく、"any later version"を表明していた場合は、同様の規定となる[267]。 無保証性保証の否認第15項では、準拠法国における強行法規によって保証が義務づけられている場合（ただしそれが「準拠法の下で認められる限りにおいて」）、および当事者間で書面による合意を締結した場合を除き、GPLv3プログラムの性能や品質の保証をコピーライト保持者やその他当事者は一切行わない旨述べている。「これと異なる書面による定めがなされる場合を除き」（"EXCEPT WHEN OTHERWISE STATED IN WRITING"）というのは、第4項第1段落、セクション"忠実な複製の伝達" で説明した条件3.に当てはまる追加的非許可条項としての保証の告知が存在する場合を想定している。条件3.に相当する告知は、第4項第1段落の条件2. に従って当該告知を保全しなければならないため本項の対象外となる。またプログラムの品質や性能に関するリスクはすべてライセンシーに帰属する。プログラムに瑕疵があると判明した場合、ライセンシーはすべての保守、修補、修正にかかる必要なコスト、費用を負わなければならない。ライセンサー、伝達者は（ライセンシーの用途を予測できないから）一切その責任を負わない[268]。余談だが第15項、第16項の条文が全て大文字なのは、統一商事法典2‐316条において、黙示の保証を排除する場合はそれを目立つように記載すべき、と定められているためである[269]。 責任の限定第16項では、準拠法国における強行法規によって賠償責任が義務づけられている場合（ただしそれが「準拠法の下で認められる限りにおいて」）、および当事者間で書面による合意をした場合を除き、GPLv3プログラムの瑕疵に起因して生じた損害について、コピーライト保持者やプログラムを改変した者、保護された作品を伝達した者といった当事者は一切賠償責任を負わない。たとえ、そのような瑕疵をそのような当事者に事前に通知していても同じであり、彼らが補修する義務はない[270]。 補足事項第17項では、第15項、第16項に対する補足事項を述べている。準拠法国の強行法規等により第15項、第16項の規定が覆された場合、民事上の責任の絶対的な放棄に最も近い法、すなわちコピーライト保持者や伝達者等が負担する責任の最も軽い法が、裁判官によって選択・適用されるべきであると述べている。ただし、コピーライト保持者や伝達者等が本プログラムを有償で譲渡し、それに伴い保証や賠償責任を負担することを合意している場合は、本項の例外とする。プログラムの有償譲渡（販売）は、保証、賠償責任も込みで成されることが多いからであるとみられる[271]。 論争マイクロソフト2001年、マイクロソフトのCEO、スティーブ・バルマーは、Linuxを「知的財産権の意味において、触れるもの全てにくっつく癌である」と呼んだ[272]。マイクロソフトがGPLを嫌う理由は「取り込み、拡張して、抹殺する」という独占的ベンダーの試みにGPLが抵抗するためであるとマイクロソフトの批判者らは主張する[273]。マイクロソフトは、以前、GPLでライセンスされたコードを含む製品である、Microsoft Windows Services for UNIXを販売（のちWindowsのEULAに従う者には無償ダウンロード可に）していたこともある[274]。マイクロソフトのGPLに対する攻撃に対抗するため、幾人かの著名なフリーソフトウェア開発者とフリーソフトウェアの代弁者たちはライセンスを支持する旨の共同声明を発表した[275][276]。しかしながら、この声明から7年以上たった、2009年7月、マイクロソフト自身が、GPLのもと本体が約20,000行程度となるLinuxカーネルのドライバコードをリリースした[277][278]。ただし、提供されたコードの一部に相当するLinux用のHyper-Vドライバコードが、GPLのもとライセンスされているオープンソース・コンポーネントを利用しており、当初プロプライエタリなバイナリ部分と静的リンクしていた。後者はGPLソフトウェアに対するライセンス違反である[279][280][281]。 また、これ以外にも、同社が提供するソフトウェアに意図せずGPLで保護されたコードが混入するケースもあった[282]。 「ウイルス」性マイクロソフトのシニア・バイス・プレジデント、クレイグ・マンディは、GPLはプログラム全体を譲渡することしか許諾せず、これは、プログラマに、GPLと両立しないライセンスのライブラリとリンクするプログラムを譲渡することを許諾しないことを意味する故、GPLは「ウイルス的(viral)である」と評した[283]。 この所謂「ウイルス的」効果とは、組み合わせることを考えているソフトウェアの、複数のライセンスのうち一つが変更されないならば、そのような状況下で、異なる別のライセンスで許諾されるソフトウェアと組み合わせることができないことを指す。ライセンスのいずれか一つは理論上変更することはできるけれども、「ウイルス的」なる考えの筋書きによれば、GPLは事実上撤回することはできない（なぜなら、GPLソフトウェアには通常極めて多くの貢献者(contributors)の存在があるが、彼らの幾人かはこの決定をおそらく拒絶するだろう）。他方、他のソフトウェアのライセンスは実際には可能なのである。リチャード・ストールマンの見解によると、「ウイルス」というメタファーは誤りであり、また不親切な物言いである。GPLのもとリリースされるソフトウェアは、他のソフトウェアを、決して「攻撃」したり「感染」などしない。むしろ、GPLで保護されるソフトウェアは、オリヅルランのようなものである、と述べている。だれかが、GPLで保護されたソフトウェアのコード断片を持ち帰り、どこかよそへそれを組み込んだならば、GPLで保護されるソフトウェアもまた、そのどこかで成長するのである[284][285][286]。このようにGPLのような二次的著作物にも適用を強制するという強い制約を持つライセンスは、独占的なソフトウェアを開発する企業や、他のライセンスを支持するソフトウェア開発者から批判されることがある。コピーレフトの考え方を支持する人々は、これは自由を守るために必要なことだと主張する。一方、二次的著作物へ の制限が少ないBSDスタイル・ライセンスを支持する人々はまた別の考え方を持っている。GPLの支持者が「フリーソフトウェアの自由が二次的著作物でも 保護されることを、フリーソフトウェア自身が保証すべき」と確信する一方、そうでない人々は「フリーソフトウェアはその再頒布にあたって利用者に最大限の自由を与えるべきだ」と主張する。後者の考え方は、例えばBSDライセンスのように敢えて「ソフトウェアの自由を捨て去る」ことも可能という、ソフトウェア利用者の自由意志、選択の自由を述べている。 商用化への障害FreeBSDプロジェクトは、「GPLソフトウェアを公開しない、そして誤ってGPLソフトウェアを利用してしまったケースなどにより、これらの行為がソフトウェア企業の価値を下げたいと考えている巨大企業の格好の餌食になっている。言い換えれば、GPLは、潜在的に経済的利益の全体を低下させ、また寡占的行為を助長するゆえ、マーケティングの武器として利用されるのに、とてもふさわしい。」と主張し、GPLは「ソフトウェアの商用化やその利益を生み出そうと考えている人々にとって現実の問題として本当に邪魔になっている」と主張している[287]。同じくFreeBSDの開発者としても有名で、Beerwareライセンスの著作者でもある、ポール＝ヘニング・カンプは、"GNU license"を「ジョーク」であると見なしている。その理由は彼が気付く限りこのライセンスには曖昧な記述が存在するからだと述べている[288]。 二次的著作物セクション"リンクと派生物"の通り、GPLで保護されたコードに由来する二次的著作物はGPLでなければならない、と明白に要求されているが、GPLのライブラリに動的にリンクしたプログラムが、二次的著作物と見なせるかどうかは、議論が分かれている。これに対しFSFとその他の人々の見解が異なることが新たな論争の種となっている。この点に関し、著作権法が二次的著作物をどう定義するかが問題になると述べたが、著作権の支分権の具体的内容についての問題が提起されている。アメリカ合衆国著作権法第101条によれば、著作物の改変・翻案を例にあげたうえで「既存の著作物を基礎とする」ことが二次的著作物の要素となっているため、動的リンクの場合でも既存の著作物を基礎としているのかが問題となり得る。これに対し、日本国著作権法第二条によれば、二次的著作物は原著作物の「翻案」を要素としているため、GPLのライブラリとGPLでないプログラムが動的にリンクするプログラムを作って頒布したところで、二次的著作物を作成したことにはならず、プログラムを実行したときに必然的に生じるメモリへの複製の段階で初めて問題になるに過ぎない。しかし、日本国著作権法ではプログラムを実行することそれ自体（これを使用権という）は著作権の支分権としては認められていない。 ちなみにGPLv3では"derivative work"という語が姿を消し、代わりに「改変されたバージョン」や「元プログラムに基づく作品」となっている。これらは「二次的著作物」を指している[A]。 ま た、アメリカ合衆国著作権法においても、日本国著作権法においても、原著作物の著作権者は、二次的著作物に対して著作権行使をすることができるのは当然の 前提なのだが、ソフトウェアが著作権の対象となるように法制度が確立する前は、改変したプログラムに対する権利範囲等が不明確であったこともあり、法の建 前を前提として議論がされていない側面がある。 いずれにせよ、当該著作物が二次的著作物であるかの判断は、ライセンス如何の問題ではなく、最終的には法廷が個々の著作物毎に判断することとなる。しかし、現時点では明確な線引きを行った著作権法上の条文や判例は存在せず、その他法源となるものもない。ガルーブ対任天堂訴訟においても二次的著作物の範囲が明確に定められなかったのは前述の通りである。 条項の複雑さGPLが持つ制約とは全く別の問題として、一部の批判者らは、GPL前文のイデオロギー的な響きが嫌だとか、ライセンスが長過ぎて分かりにくいと愚痴をこぼす。いりもしない利用者の自由を贔屓するあまりソフトウェア・ビジネスモデルを 制限し過ぎており、もっとましな「落とし所」もあるはずだ、という者もいる。この「落とし所」には、ソースやバイナリの複製 (reproduction)を認めないが、個人や会社での使用で修正の自由を認めるようなライセンス群を含むことがある。こういった変種の一つには、 Open Public License (OPL)[289]がある。これら批判の原因は、GPLの条文が一見理解しにくいがために起こる誤解によるところもある。しかし、このGPLの手の込んだ条項は一見理解に困難を要するが、これによりコピーレフトが創出され、著作権法の枠組みを徹底してハックしている点も忘れてはならない。 よくある誤解GPLの条文そのものや、その要求、許可する事項（義務、権利）については、GPLに賛同している者ですらも誤解していることがあり、そのことがGPLの議論に関し混乱を招く原因のひとつともなっている。既に解説済みの項目も多いが、改めて述べる。
脚注注釈
出典
参考文献
関連項目外部リンクライセンス原文非公式日本語翻訳版
IPAによる翻訳、解説文書
GNUプロジェクトによる文書
GPLv3の策定に関する公開協議
日本
GPLv3への移行とその影響GPLv3を支持するフリーソフトウェアコミュニティは積極的にGPLv3への移行や採用を推し進めているが、反面これに異を唱えるオープンソース組織や営利企業も少なくない。
過去のライセンスEmacs General Public License
過去のGPL
LGPLGPL支持者の文書
ガイド
その他議論
準拠法に対するGPLの法的解釈
判例
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
.svg){kind=logo}
Portal di Ensiklopedia Dunia
