GNU General Public License

「GPL」はこの項目へ転送されています。その他の用法については「GPL (曖昧さ回避)」をご覧ください。

この記事には複数の問題があります。改善やノートページでの議論にご協力ください。 独自研究が含まれているおそれがあります。（2012年1月） あまり重要でない事項が過剰に含まれているおそれがあり、整理が求められています。（2012年1月）

GNU General Public License

GNU GPLv3のロゴ
作者	フリーソフトウェア財団
バージョン	3
公開元	フリーソフトウェア財団
リリース日	2007年6月29日 (17年前) (2007-06-29)[1]
DFSGとの適合性	Yes[2]
FSFの承認	Yes[3]
OSIの承認	Yes[4]
コピーレフト	Yes[3][5]
異種ライセンスコード からのリンク	No[注釈 1]
ウェブサイト	GNU一般公衆ライセンス
テンプレートを表示

GNU一般公衆ライセンス（GNU General Public License、GNU GPLまたは、単にGPL) とは、GNUプロジェクトのためにリチャード・ストールマンにより作成されたフリーソフトウェアライセンスである。八田真行の日本語訳ではGNU 一般公衆利用許諾書と呼んでいる^[6]。現在、GNU公式サイト日本語ページではGNU一般公衆ライセンスと表記されている^[7]。

GPLは、プログラム（日本国著作権法ではプログラムの著作物）の複製物を所持している者に対し、概ね以下のことを許諾するライセンスである。

1. プログラムの実行^{[注釈 2]}
2. プログラムの動作を調べ、それを改変すること（ソースコードへのアクセスは、その前提になる）
3. 複製物の再頒布
4. プログラムを改良し、改良を公衆にリリースする権利（ソースコードへのアクセスは、その前提になる）

GPLは二次的著作物についても上記4点の権利を保護しようとする。この仕組みはコピーレフトと呼ばれ、GPLでライセンスされた著作物は、その二次的著作物に関してもGPLでライセンスされなければならない。これはBSDライセンスをはじめとするパーミッシブ・ライセンスが、二次的著作物を独占的なものとして再頒布することを許しているのとは対照的である。GPLはコピーレフトのソフトウェアライセンスとしては初めてのものであり、そのもっとも代表的なものである^[8]。

GPLはフリーソフトウェア財団 (以下FSFと略称) によって公開され、その管理が行われている。GPLでライセンスされている傑出したフリーソフトウェアのプログラムには、LinuxカーネルやGNUコンパイラコレクション (GCC) がある。

FSFが公開、管理する他のライセンスには、GNU Lesser General Public License (GNU LGPL)、GNU Free Documentation License (GNU FDL、またはGFDL) そしてGNU Affero General Public Licenseバージョン3 (GNU AGPLv3) がある。

ストールマンは、ソフトウェアに対する自由とは何かという問題を提起し、そのひとつの答えを提示した。GPLは、「自由なソフトウェア」を、有償・無償に関係なく、頒布できるようにした、という単純な意味だけでなく、「ソフトウェアは自由であるべき」という思想が存在することを一般に認知させたという意味において極めて重要な意義がある。

GPLにより付与される強力なコピーレフトはGNU/Linuxの成功にとって重要な役割を果たしているとも言われる。なぜなら、コミュニティに全く還元しようとしないソフトウェア企業にただ搾取されるのではなく、著作物が世界全体に貢献し、自由であり続けるという確証をGPLはプログラマに与えたからである^[9]。

GPL誕生以前、Emacsの頒布条件となっていたライセンスが生まれたきっかけは、ジェームズ・ゴスリンが作成し、当初自由な利用が認められていたGosling Emacsのコードに突如ゴスリンが独占的な許諾条件を附してしまったことが契機となっている^[10][11]。この許諾条件の変更の影響により、ストールマンは自身のEmacsのコードを書き換えなければならなくなった。

またGPL、GNUプロジェクトの誕生について、次のような逸話もある。 当時、ストールマンはMIT人工知能研究所でSymbolics社製のLISPマシンで動くソフトウェアを開発していたが、ストールマンが作りSymbolics社に対して提供したパブリックドメイン版であるソースコードの改変版について、同社が著作権を根拠にソースコードを開示しなかったことに腹を立てGPLを考案したといわれる^[12]。いずれにせよ、これ以降いかにしてソースコードの自由な利用を保証するかということにストールマンは腐心するようになる。

GPLは1989年にリチャード・ストールマンによって、GNUプロジェクトのソフトウェアの配布を目的に作られた。オリジナルのGPLは、初期のGNU Emacs、GNUデバッガそしてGNU Cコンパイラの配布に利用していた類似のライセンスを基に、それらを組み合わせたものをベースとしている^[13][10]。前記3つのライセンスは、現在のGPLと似たような条文を含んでいる。しかし、それらは各プログラム固有のライセンスであり、似通っているとはいえ、互いの互換性は全くなかった^[14]。ストールマンの目標は、いかなるプロジェクトでも使用可能で、それゆえ多くのプロジェクトがコードを共有することを可能にさせる単一の汎用的なライセンスを作り出すことだった。

GPLは幾度か改訂されており、1991年にはバージョン2がリリースされている。バージョン3がリリースされるまで、それに従うこと15年間、FLOSSコミュニティの幾人かは、GPLでライセンスされているプログラムを、ライセンスの意図に反し、搾取する事につながる抜け道 (loopholes; 抜け穴、ループホール) に対し懸念を抱くようになった^[15]。これらの懸念の中には、TiVo化（Tivoization。GPLでライセンスされたプログラムが含まれているにも関わらず、改変版ソフトウェアの稼動を拒絶するハードウェアについての問題）、Webインタフェースの裏側に隠れ公開されることのない改変版GPLソフトウェアの利用、AGPLバージョン1と同等の互換性問題、GNU/Linuxコミュニティと敵対するための武器として特許を行使する企てと見なされる、マイクロソフトとGNU/Linuxディストリビュータとの特許契約などがある。

ウィキニュースに関連記事があります。

• Free Software Foundation releases first draft of GPLv3
• フリーソフトウェア財団がGPLv3の最初の草案を発表

FSFならびにFLOSSコミュニティは、これら懸念に対し真剣に取り組むべく、バージョン3への改訂作業を始めた^[16][17]。2005年後半、FSFは、GPLバージョン3 (GPLv3) の策定に関するアナウンスを行った^[18]。2005年の時点でGPLは様々なFLOSSプロジェクトのソフトウェアに採用されていたこともあり、FSFが単独で改訂することにより起こりえる問題を回避するため、改訂プロセスは公開で行うことが同時に発表された^[18]。2006年1月16日、GPLv3の最初の議論用草稿 (discussion draft) が公開され^[19]、公開協議プロセスを開始した。当初公開協議は9ヶ月から15ヶ月を想定していたが、終わってみると、4つの草稿公開に延べ18ヶ月にまで要した。公式のGPLv3は2007年6月29日、FSFにより発表された。GPLv3は、リチャード・ストールマンにより起草され、エベン・モグレンならびにSoftware Freedom Law Center (SLFC) による法的助言を受けている^[20]。

公開協議プロセスは、FSFを調整役、SFLC・Free Software Foundation Europe (FSFE)^[21]その他フリーソフトウェア開発組織による支援のもと進められた。この間、gplv3.fsf.org^[22]というウェブポータルサイトが立ち上げられ、ここを経由し多くの一般からのコメントが集められた^[23]。このポータルサイトは、策定プロセスのために開発されたstet^[24]というソフトウェア上で稼働している。これらコメントは、およそ130名ほどから成る4つの協議グループ (committee)^[25]に渡された。この130名はFSFの目標に対しそれを支持する人物並びにそれと対立する人物双方が含まれている。これら協議グループは一般から提示されたコメントを精査し、新しいライセンスがどうあるべきか決定するため、ストールマンにその要約を回付した。

公開協議プロセスを経て、初回の草稿には962ものコメントが提出された^[26]。終わってみると、延べ2,636ものコメントが提出されていた^[27][28][23]。

初版の草稿公開ののち、GPLv2とGPLv3の非公式な差分（但し、これはdiff出力による行単位ごとの単純な差分）が、FLOSSコミュニティ向け法律サイトGroklawにより公開された^[29]。

2006年7月27日、GPLv3の討議用第2次草稿^[30]が、LGPL第3版 (GNU LGPLv3) の初版草稿とともに公開された^[31]。初稿と第2稿の差分は、FSF^[32]とFSFE^[33]からそれぞれ提示されている。第2稿ではDRMに対抗する明確な目標が取り入れられている^[34]。

第3稿は2007年3月28日に公開された^[35][36]。この草稿は、かの物議を醸したマイクロソフトとノベルが締結したような特許相互ライセンス (patent cross-license)^{[37][38][39][40][41]}を排除する意図を持つ文言を含んでおり^[28][42]、反TiVo化条項 (anti-tivoization clauses) はユーザ製品 (User Product)・コンシューマ製品 (Consumer Product) といった一般家庭で使用される製品に限定する旨定めている^[28][43]。また、公開協議開始時点で削除が予告されていた地理的 (頒布) 制限 (Geographical Limitations)^[44]の項については、明白に削除されている。

最終稿となった第4の議論草稿^[45][46]は2007年5月31日に公開された。この草稿では、Apache Licenseとの組み合わせを可能にする条項が導入された他、外部契約者 (contractor) の役割を明確化し、マイクロソフト–ノベル間の契約のような明白な問題を回避する例外条項を加えている。この最後の例外条項は、第11項^{[注釈 3]}第7段落に次のように記載されている（条文は正式公開版と同一である）。

You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license [...]

これは、そのような契約を将来に渡って無効化することを目的としている。また本ライセンスは、マイクロソフトが、あるGPLv3ソフトウェアを利用するノベルの顧客に許諾したような特許契約（特許ライセンス、特許許諾、パテントライセンス）を、まさにそのGPLv3ソフトウェアを利用するユーザーすべてにまで（ユーザーの行為如何に全く関わらず）自動的に拡大適用することを意味する。ただし、マイクロソフトが法的にGPLv3ソフトウェアの伝達者 (conveyor; 譲渡者) でもない限り、それは不可能である^[47][48]。これはある種、特許契約に対しそれを他者に無制限に提供してしまうことから、ポイズンピルのような働きを持つとの意見もある^[49]。ただし本条項導入の直接の契機となった、ノベルの行為そのものに対しては、本項第7段落最後に例外を設け、既得権条項（英語版）を適用している^[50][51]。

バージョン1は、1989年2月にリリースされた^[52]。ソフトウェア頒布者が自由を制限する手段の主に2つから、フリーソフトウェアの定義たる自由を守る働きを、このライセンスは持っていた。

第一の手段は、頒布者がバイナリ（実行ファイル）のみを公開することである。バイナリを受け取っても人間は基本的に読んだり改変したりすることができない。これを防ぐため、GPLv1では、いかなるベンダーもバイナリを頒布するならば、ソースコードも利用できるようにしなければならないとしている^{[注釈 4]}。

第二の手段は、ライセンスに追加の制限を加えることである。直接でなくても、別の制限があるソフトウェアを組み合わせて頒布すれば、制限は2つの集合の和になる。すなわち、受け入れられない制限が加えられたことに等しい。これを避けるため、改変版も、GPLv1の下で頒布されなければならないと、GPLv1では規定している^{[注釈 5]}。このため、GPLv1よりも厳しいライセンスで頒布されるソフトウェアを組み合わせることはできない。ただし、GPLv1よりもパーミッシブ・ライセンスで保護されるソフトウェアと組み合わせて頒布することが可能である。なぜなら、組み合わせによって全体を通して頒布に係るライセンス条項に変化はないからである。

バージョン2は、1991年6月にリリースされた^[53]。 リチャード・ストールマンによれば、GPLv2で最大の変更は第7節、彼に言わせると、パトリック・ヘンリーの名文句「自由か然らずんば死を」("Liberty or Death") の一節である^[54]。他の利用者の自由を尊重するような方法で、GPLで保護されたソフトウェアの頒布が妨げられる場合（たとえば、法的規制によりソフトウェアをバイナリ形式でしか頒布できないとき）、この節に従えば、頒布は一切できない。GPLv3でも同様の条項が存在し、幾分簡素化されたうえ主旨が明確になっている。これは、フリーソフトウェア開発者や、フリーソフトウェアを単に使用する者から金を脅し取ろうと特許を行使する企業の企みをすこしでも減らすことを見込んでいる。

1990年までには、現存するプロプライエタリなライブラリと本質的には同等な機能を持つCライブラリや、その他のソフトウェア・ライブラリに対しては、制限の緩いライセンスのほうが戦略的に有効なことが明らかになってきた^[55]。1991年6月にGPL第2版がリリースされた際、Library General Public License (LGPL) が、初版にもかかわらずGPLと相補的なことを示すため第2版として同時に導入された。GNUの思想における位置づけを反映させるため、Lesser General Public Licenseと名を変え、1999年、LGPL2.1がリリースされた。

バージョン3は、2007年6月にリリースされた^[1]。GPLv3は、ソフトウェア（プログラム・ライブラリなど）を含む著作物に対し、著作者・著作権者やライセンス受諾者^[A]の権利や、プログラムの受領者のためにライセンス許諾者が与える権利、またソフトウェアの自由と衝突する法や法的権利（DRM、特許の利用、他者を差別するような特許ライセンスの排除）などに関する基本理念を以前のバージョンより明文化している。

ストールマンによると、もっとも重要な改訂点は、ソフトウェア特許、他のフリーソフトウェア・ライセンスとの両立性(compatibility; 互換性)、「ソースコード」とは何を指すのかの定義^[A]、ソフトウェアの改変に関するハードウェアの制限（英語版）(TiVo化)そしてデジタル著作権管理 (Digital Rights Management, DRM) との関連がある^[20][56]。その他の改訂点は、国際化^[A]、ライセンス違反時の対処手段そして可能ならば著作権者により追加的条項（additional terms^{[注釈 6]}）を与える手段に関連している。

他、注目に値する改訂点としては、GPLv3で保護された著作物の著作権者が、パッチなどを提供しそれに改変を加えた貢献者 (contributor) に対し、ある種の条件または要求を課すことを許諾する条項が加えられている。これらに加えて、新しく導入された要件の一つには、時折Affero条項 (Affero clause、Affero節) とも呼ばれるが、Software as a Service (SaaS) のようなASPモデルによるGPLの条項を回避しようとする試み(ASP loophole; ASPの抜け道^[57])に対し、これを封じようと意図しているものも含まれる。この条項が追加された結果、GNU Affero General Public Licenseバージョン3 (GNU AGPLv3) が作成されている。GPLv3とAGPLv3は互いに両立はしないが、リンクや結合のみを認める相補的な条項を共に持っている。

また、GPLv3で許諾されるソフトウェアは、米国のDMCAや日本の著作権法、不正競争防止法が規定している「技術的制限手段」（技術的保護手段、例: DRM）の「解除」を認める条項が追加されている^[58]（詳細はセクション"技術的保護手段回避を禁ずる法への対抗措置"を参照）。

「GPLが適用された著作物の複製を受け取る全ての者」（Recipients; 受領者）は、GPLの条項と条件 (terms and conditions; 利用条件) を遵守しなければならない。利用条件を遵守するライセンシー（the licensee; 被許諾者、ライセンシー^{[注釈 7]}）は著作物を改変する許諾を与えられるのと同時に著作物または二次的著作 (派生 derivative) 物の複製と頒布を許諾される。ライセンシーは、このようなサービスを提供するのに料金を課してもよいし、また無料で行ってもよい。この後者の許諾は、GPLと商用再頒布禁止のソフトウェアライセンスとの相違点である。FSFは、フリーソフトウェアは商用利用を制限するべきではないと主張している^[59]。また、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項によると、事前コンパイルされたバイナリとして頒布されるプログラムは次のいずれかを満たさなければならない。

1. ソースコードの複製の直接の添付
2. 事前コンパイルされたバイナリと同一の手段でソースコードを頒布するという書面での提案の添付
3. GPLのもと、事前コンパイルされたバイナリを受け取った場合に得た何かを、ソースコードを提供する旨の文書で提示

また、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^[60]で述べられている通り、フェアユースにworld-wide principle; 世界的な原則、統一見解などない）。再頒布のような、通常著作権法で制限される権利をある人物が行使しようと考える場合、その人物はGPLの条項をただ従う必要がある。逆に、GPLの条項を遵守せず（例えば、ソースコードを開示しない）著作物の複製を頒布すると、著作権法に基づき著作権者から頒布の差止め等で提訴される可能性がある。

コピーレフトは、著作権法を本来の使用目的と正反対の目的を実現するために利用する。すなわち制限を課す代わりに、コピーレフトは、権利がのちに消失しないような方法で、他者への権利を許諾する^{[注釈 8]}。コピーレフトはまた、ライセンシーに対し再頒布の権利を無制限に許諾するのではなく、コピーレフトが主張する点において発見されるのは法律上の任意の欠陥であるべきことを保証している。

コピーレフトライセンスで保護されるプログラムを頒布する多くの者は、ソースコードと共に実行ファイルを添付する。コピーレフトを満たす別の方法は、要求に応じて（CDのような）物理媒体を用いてソースコードを提供するという文書を提示することである。また事実としてコピーレフトライセンスで保護されるプログラムの多くは、インターネット上で頒布されており、ソースコードはFTPまたはHTTPなどを用いてソースコードを遣り取りできるようにしているものが多い。インターネット上での頒布は本ライセンスを満たしている。

コピーレフトが適用されるのは、ある人物がプログラムを再頒布しようと求める場合にのみである。改変したソフトウェアを他の誰にも頒布しない限り、改変箇所を公開しなければならない如何なる義務も免ぜられ、その改変版を私的な物とすることは許される。また、コピーレフトはソフトウェア自身のみに適用されるのであって、ソフトウェアの出力 (outputs, アウトプット) には適用されないことには注意しておきたい（ただし、そのアウトプット自身がプログラム自体の二次的著作物ではない場合）。例えば 、GPLで保護されたコンテンツ管理システム ("Contents Management Systems"; CMS) に対しその改変した派生版を動作させる一般ウェブポータル（ブログソフトウェアなど）は、その出力自体はプログラム自体の派生物ではないから、土台としたソフトウェアならびにその改変部分を頒布する必要はない。反例は、GPLで保護されたソフトウェア"GNU bison"である。この構文解析器の出力は、その派生物の一部をまさに含んでおり、そのため、この事実に対しGNU bisonにより許諾される特殊な例外条項 (a special exception) が仮に存在しないならば、出力結果はGPLで保護される派生物となっていたであろう^[61]。最新のGNU bisonでは、事実として、出力コードのヘッダにAs a special exception...という特殊例外条項が記述されている^[62]。

なお（GPLに従う著作物に限ったことではないが）、コピーレフトのもとで公開された著作物の著作権は、前述の通り譲渡しなければ個々のコードの著作権者が保有している。従ってコピーレフトを無視した再頒布に対して、頒布の差止めやコピーレフト違反是正（エンフォースメント）を求める権利があるのはプログラムの著作権者だけであり、一般のライセンシーにはない^[63]。ただ、大規模なFLOSS開発プロジェクトは一般的にワールドワイドであり、開発者の居住国が多岐に渡るため、多かれ少なかれ差異がある各国の著作権法にプロジェクト全体で合致させるのは困難を要す。このため一部のFLOSSプロジェクトでは各著作権者に代わり、コードの著作権を一括してプロジェクト（またはそれを統括する団体・法人組織）が引き受ける場合もある。GNUプロジェクトは、コードの受け入れに関し、米国著作権法の庇護を享受するため、ライセンス如何に関わらず、寄贈されたコードの著作権を原著作者より明示的にFSFに譲渡する場合にのみ受け入れている^[64]。CMSのPloneならびにPlone財団(Plone Foundation)も似たような形式を採用している。

FSFによると、「GPLは改変版、もしくは改変版の一部のリリースを要求することは述べていない。改変版を一切公開せず、改変を加えることや、私的に利用することは自由である。」と主張している^[65][66][67]。しかしながら、仮にある人物がGPLでライセンスされたオブジェクトを公開するならば、ライブラリリンクに関する問題が提起される。すなわち、もし、プロプライエタリなプログラムがGPLなライブラリを使用するならば、そのプロプライエタリなプログラムは（一般にプロプライエタリソフトウェアはソースコードが自由な許諾の下利用できない為）GPLに違反する、はたまたそうではないのか、という問題がある。

この重要な論点は、非GPLソフトウェアがライセンス的、すなわち著作権法的に、GPLなライブラリに静的リンクまたは動的リンク可能であるか否かという問題に行き着く。この問題に関して、異なるいくつかの見解が存在する。GPLのもとリリースされるコードの二次的著作物が全て、それら自身もまた、GPLに従わなければならないとの要求は明白である。しかし、GPLなライブラリを使用する、そして、GPLなソフトウェアをより巨大なパッケージと組み合わせる (bundle, バンドルする)（概ね静的リンクによりバイナリを混合する場合などを想定すればよい）点に関しては、曖昧さが惹起する。これは究極的には、GPLそれ自体 (per se, in itself) とは無関係の問題であるが、著作権法が二次的著作物をどう定義するかということと関連した問題である。この議論に関して、次のようないくつかの異なる見解が存在する。

GPLのライセンス条文自体の著作権を保持する法人組織でもあり、GPLでライセンスされる著名なソフトウェア製品を多数提供しているFSFは、動的リンクされたライブラリを利用する実行ファイルは、実際には二次的著作物である、と強く主張している。しかしながら、このことは、お互いを「結合する」(連携する、communicate) だけの分離された別個のプログラムには適用されないとしている^{[68][注釈 9]}。

FSFはまた、コピーレフトという点で、GPLとはほぼ同一であるが、「ライブラリ利用」という目的のために、リンクの許諾を追加的に与える、LGPLというライセンスも作成した。

リチャード・ストールマンとFSFは、プロプライエタリな世界と比較し、より豊富なツールを提供することによりフリーソフトウェアな世界を護持することを目的として、ライブラリ作者に対し、GPLの下でのライブラリのライセンシングを明確に促している。これは、ソースコードを公開しないならば、プロプライエタリ・プログラムがGPLで保護されたライブラリを一切使用できないようにすることを狙っている^[69]。

FSFは、プラグインの呼び出し方法についてはまた別であると認識している。もし、プラグインが動的リンクにより呼び出され、関数呼び出しをGPLプログラムに提供するならば、その時には、プラグインは、概ね二次的著作物であると見なされる^[70]。

静的リンクは二次的著作物を生じるが、他方、GPLコードに動的リンクされた実行ファイルが二次的著作物であると考慮されるべきか否かははっきりしないとする意見もある。詳細は (Weak copyleft) を参照せよ（ライセンス感染#相互運用性も参考になるかもしれない）。Linuxカーネルの著作権者リーナス・トーバルズは、状況により、動的リンクは派生物を生じ得るとの見解に同意する場合と同意しない場合があるとしている^[71]。

ノベルの弁護士は、動的リンクが二次的著作物でないのは「もっともらしい」が「断言」はできないとし、善意による動的リンクの証拠として、プロプライエタリなLinuxカーネルドライバの存在に見てとれる、と文書にて記載している^[72]。

ガルーブ対任天堂（英語版）訴訟において、アメリカ合衆国第9連邦巡回区控訴裁判所（英語版）は、二次的著作物を「『形式』または永続性」を所持するものと定義し、「当件における侵害された著作物が、ある形式で著作権の適用された著作物の一部と協働しなければならない」と言い渡した^[73]。しかし、特にこの対立を解決する明白な法廷判断は出ていない。

Linux Journal誌の記事によれば、IP法の専門家でOSIの法務顧問 (General counsel) も務めるローレンス・ローゼンは、リンクの動的・静的を含む種別は、ある種のソフトウェアが二次的著作物であるか否かについての問題とは概ね関係がない、すなわち、そのソフトウェアが、クライアントソフトウェアとライブラリ、またはそれら個別とのインタフェースが意図されているか否かについての問題のほうがより重要である、と主張している^[74]。彼は、「新規のプログラムが二次的著作物であるか否かの主な指標は、原著作物のプログラムのソースコードが、『複製と添付(コピーアンドペースト)』する意図をもって利用され、新たなプログラムを作成する任意の手段において、改変、翻案またはその他の変更を加えたか否かに係っている。もしそうでないならば、私はその新規のプログラムは二次的著作物ではないと主張するだろう」と述べる^[74]。また、彼はこの記事の中で、ソフトウェアの組み合わせ・バンドリング、リンクのメカニズムなど、その他関連する多くの指摘意図を挙げている。さらに、彼は、彼の弁護士事務所のウェブサイト^[75]にて、このような「市場原理」的要素はライブラリリンクの原理といった技術的な要素よりも重要であると主張している。

プラグインまたはモジュール（例えば、フリーなドライバ"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でも同じであり、条項の文面は多少異なっているが^{[注釈 10]}、上記と同様の内容が、以下となる（詳しくはセクション"改変版ソースの伝達"を参照）。

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に対し、それらに提供されていたプロプライエタリと想定されるプラグイン、テーマ（英語版）、スキンなどは、両プロジェクトサイドにて議論が巻き起こる共に、非難されるようになってしまった^{[76][77][78][79][80]}。

一方、Linuxカーネルではこのような結合の状況分析を行うことなく、カーネルの著作権の影響範囲とユーザ空間プログラムが派生物ではないことをライセンステキスト冒頭^[81]で述べている^{[注釈 11]}。

  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ソフトウェアとは別の著作物」とみなされる可能性も含んでいる。これは、前述の通り、

• 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.^[82]

に規定されている。即ちGPLソフトウェアを含む「集積物 (aggregate) の他の部分」と認められれば、GPLに反しない、言い換えればGPLよりパーミッシブ・ライセンスでパッチを公開しても良い^{[注釈 12]}。例えばパッチが単なる修正ではなく、単体で再利用可能な全く別種の機能強化と見なされればそれは集積物の別の部分と規定でき、そのパッチのみに対しGPLと矛盾せずかつGPL以外のライセンス（BSDライセンスやzlib Licenseなど）を適用する事も可能である。一例をあげると、MySQLは、「リンク例外条項付きGPLv2」と商用ライセンスとでデュアルライセンシングされている。これに対しGoogleはMySQL向けのパッチをBSDライセンスで提供していた^[83]。このパッチはオリジナルのMySQLに由来しないコードのため、GPLで保護されたMySQLの「集積物とは別の部分」となる。BSDライセンスは独占的なライセンスであろうとも両立するので、結果的にこのパッチは、MySQLをGPLで利用するライセンシーと共に商用ライセンスで利用する者も適用可能である^[84][85]。また同時にそのパッチからサブルーチンのみを取り出し、BSDライセンスされたソフトウェアにも同様のルーチンを導入する事も可能となる^[85]。

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.

^[86][87]

このように、FSFは「ライブラリ」と「その他のプログラム」とを、次の2つの観点双方を用いて線引きしている。

1. データ・情報交換に係る「複雑さ」(complexity) と「親密さ」(intimacy) (「セマンティクス^{[要曖昧さ回避]}」)
2. セマンティクスだけではなくメカニズム（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; 配布) は許されている^[88]。GPL FAQ^[89]によると、仮に改変する場合は、別の名前とし、「GNU」について言及せず、フリーソフトウェア財団から許諾を得ている場合を除いて改変版ライセンスからGPLの前文 (Preamble) を削除した場合に限り、GPLの改変版を利用して新たなライセンスを作成しても良い。そのようにして作成された派生ライセンスに対し、FSFは一切の法的異議申し立てを行うことはないが、そういったライセンスは一般にGPLと両立しない (互換性が無い、incompatible) ので、FSFは推奨していない 。

前述のとおり、GPLの条文自体は著作権で管理されており、その保持者はFSFである。しかしながら、FSFはGPLのもとリリースされた著作物の著作権は保持しない。これも前述したが、例外は、著作権者が明示的にFSFに著作権を譲渡した場合である。ただし、そのような事例はGNUプロジェクトに属するプログラムや寄贈されたプログラムを除いてあまりない。ライセンス違反が発生した場合、個々の著作権者のみが、訴訟を起こす権限を持つ^[63]。

FSFは、FSFの許可なくGPLの前文 (Preamble) を含めた、派生ライセンスを使用しない限り、GPLに基づいた新しいライセンスを作成することを許可する。しかしながら、このようなライセンスはGPLと両立しない (incompatible) 場合があるので、作成しないほうがよい^[89]。またそれは、明らかにライセンスの氾濫を生じさせる。翻訳も翻案権の行使であるため、ライセンスの翻訳は原則認められないが、その翻訳が非公式であることを明記し、FSFの求めに応じて翻訳をアップデートできるならば翻訳を許可される^[90]。

その他、GNUプロジェクトにより作成されたライセンスには、GNU Lesser General Public License、GNU Free Documentation Licenseが含まれる。

あるオープンソースソフトウェアでライセンス上考慮すべき点があるなどして、またはもっと極端な例では、GPLの思想的な面に反発があるなどして、GPLと両立性^{[注釈 13]}を欠くようなライセンスを著作物に敢えて採用するケースがあるかもしれない。しかし、GPLを採用するフリーソフトウェア、オープンソースソフトウェアが多数存在するため（セクション"採用実績"を参照）、現実問題としてそのような行為はコードの再利用性を著しく欠く結果につながる（記事"ライセンスの氾濫"を参照）。このため、自身の採用するライセンスをGPLと非互換にしないよう、GPLとのライセンス両立性を考慮することは重要である。

著作物全体として影響を受けるライセンスの持つ制限の組み合わせにより、GPLが許諾する事項を越えるいかなる追加的制限が課されない限り、他のライセンスで許諾されたコードは、GPLで許諾されたプログラムと衝突することなく組み合わせることも可能である^[91]。また二次的著作物の観点として、互換性のあるフリーソフトウェアライセンス/オープンソースソフトウェアライセンスで許諾されるコードを組み合わせる場合は、原則コードの組み合わせ全体に、そのコピーレフト性が最も強くなるライセンスの影響を受ける^{[注釈 14]}。GPLの正規の条項に加えて、追加的な制限や許諾を適用することができる組み合わせは以下の通りである。

1. 異なるバージョンのGPLのもとライセンスされるコードを組み合わせたいと考える場合は、より古いバージョンのGPLのコードに"any later version" statement (「任意の以後のバージョン」という表明文) が認められているのならば許可される^[92]
2. LGPLのもとライセンスされるコードは、そのコードのライセンス如何に関わらず（独占的なコードでさえも）、いかなるその他のコードともリンク可能である^[93][94]。組み合わせた全体の著作物がGPLv2またはGPLv3でライセンスされる場合において、LGPLv2でライセンスされたコードに"any later version" statementが存在しない場合はコードを当該ライセンスで再ライセンスすることができる^[95]。

上述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)）が存在する為である。一般的に、ソフトウェアのライセンスを非互換なライセンスに変更する場合は、コードの全著作権者からライセンス変更の同意を取り付けなければならない^[96]。LinuxカーネルのライセンスはGPLv2単独であり、Ruby処理系のような特殊な規定を持っているわけではないので、仮に変更する場合はそうせざるを得ない^[96]。GNUプロジェクトはこのような事態に陥ることを回避するため、前述の通り著作権者からコードの著作権をFSFに譲渡するよう勧め、またソフトウェアのライセンスほぼ全てに"any later version"表明文を付したGPLを適用している。

FSFは、GPLと両立するフリーソフトウェアライセンスのリストを維持管理している^[97][98][99]。そのようなライセンスは、もっとも広く利用されている、オリジナルのMIT/X license、（現行の3条項形式の）BSDライセンスそしてArtistic License 2.0などを対象としている^[100]。

デイヴィッド・A・ウィーラー（英語版）は、GPLと非互換なライセンスを利用すると、他者のフリーソフトウェア/オープンソースソフトウェアプロジェクトへの参加や、コードの貢献を困難にするため、フリー/オープンソース開発者はGPL互換なライセンスのみ採用するよう強く主張し続けている^{[101][注釈 15]}。

特筆すべきライセンス非互換の例として、旧サン・マイクロシステムズのZFSが、GPLでライセンスされたLinuxカーネルに組み込めないというものが挙げられる。なぜなら、ZFSはGPL非互換なライセンス、CDDLで許諾されているからである。これに加え、ZFSは特許で保護されており、ZFSの機能を持つソフトウェアをサンとは独立にGPLのもと実装し頒布しようとしたとしても、それでもなおサン（現在はオラクル）の許諾が必要となると予想される^[102]。

他の一部のフリーソフトウェア・プログラムは、複数のライセンスによりデュアルライセンスされているものがある。その中にはライセンスの一つにGPLが選択されていることもよくあり、「デュアルライセンスはもっと広まる」と独立ソフトウェア・コンサルタントのテッド・ロシュ (Ted Roche) は指摘している^[103]。この方法だと、GPLを適用しないまま二次的著作物を頒布することを認めることができる。これは、二次的著作物に有償の商用ライセンスを適用することも可能にする。MySQLなどはまさにこの例に当てはまる特筆すべき例である。

一般的にプロプライエタリソフトウェアはGPLソフトウェアと組み合わせることはできない。しかしこのような場合でも、マルチライセンスを利用することでGPLソフトウェアを組み合わせることも可能となる。

GPLのもとで頒布するとともに、静的リンクなどを使用する場合やそうではなく動的リンクを使用する場合においても^{[注釈 16]}、パッケージにプロプライエタリなコードを組み合わせたいと望む企業のため、二次的著作物を独占的な条件・ライセンスで頒布・販売可能にする商用ライセンスを同時に提供するマルチライセンシング・ビジネスモデルが多く存在する。このようなビジネスモデルを採用する企業と採用したソフトウェアには、Oracle社（MySQL AB社のMySQL）、Digia（英語版）^[104]社(旧Trolltech社のQtフレームワーク^[105] )、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,”でリリースされていれば両立する^[92]。

GPLはフリーあるいはオープンソースソフトウェア用のライセンスとして圧倒的な人気がある。 きわめて大きいソフトウェア・アーカイブをもつMetalab（英語版）の1997年の調査では、約半数をGPLのソフトウェアが占めていた^[101]。 2001年の調査では、Red Hat Linux 7.1 に使われているソースコードの 50%がGPLでライセンスされている^[106]。 2006年1月の時点で、SourceForge.netにホスティングされているプロジェクトの約68%が、2007年8月の時点で、Freshmeatに掲載されている43,442のフリーソフトウェア・プロジェクトのうち65%近くが保護されるライセンスとしてGPLを使用している^[107]（両サイトを運営しているのはLinuxとGPLに造詣の深い企業Geeknet社である）。

Black Duck Software社により管理される"Open Source License Resource Center"によると、フリーソフトウェア/オープンソースライセンスでリリースされたソフトウェアパッケージ全体の約60%がGPLをライセンスに採用していると示されている^[8]。

コンピュータ・プログラムの代わりにテキスト文書、またはより一般的にはあらゆる種類のメディア全てにGPLを採用することは可能である。ただしその条件は、それらメディアが「ソースコード」（その定義としては、「それ自身を変更することを可能にさせる著作物の好ましい形態」）を構成できるか明らかである必要がある^[108]。マニュアルや教科書は、FSF自身はGNU Free Documentation License (GFDL)の利用を代わりに薦めるが、この目的において前述の要件を形成できる媒体である^[109]。しかしながら、FSFの勧告にも関わらず、Debian開発者らは（2006年に採択された決議に基づき）、彼らのプロジェクトにおける文書をGPLのもとライセンスする勧告を出した。なぜなら、プログラム・メディア双方の著作物における「ソースコード」という概念に対し、GFDLにはGPLの条項と非互換な取り扱いが存在するからである。すなわちGFDLのもとライセンスされたテキストはGPLで保護されるソフトウェアに組み込めないというのである^[110]。詳細については、記事"Debianフリーソフトウェアガイドライン#GFDL"を参照せよ。また、フリーソフトウェア用のマニュアルなどの作成に貢献している組織、FLOSS Manuals（英語版） Foundationは、2007年に、本組織のテキストにGFDLの採用を忌避しGPLの採用を決定した^[111]。

仮にGPLがフォントのライセンスに採用された場合、このようなフォントにより形成されるあらゆる文書、画像、PDFは、これまたGPLの条項に従って配布する必要があるかもしれない。このケースは、著作権法がフォントの書体 (appearance of fonts, typeface) には及ばない国々（アメリカ合衆国とカナダのような国）では問題とならない。日本の場合も同じく、フォントの書体は意匠権を持ち、意匠法により管掌されると同時に、独創性と美的特性のない書体に著作権はないとの考えは現状一般的である。しかし、フォントヒンティング・テクノロジーなどのフォントファイル内に存在するプログラムコードは（それが「プログラム」である^[112]から、）猶も著作権法で保護され得るとの主張もある（詳細は記事"知的財産権#その他の権利" "タイプフェース"を参照）。また、セクション"リンクと派生物"で述べたことと同様に、フォント埋め込みは文書がフォントと「リンク」していると見なされる^{[注釈 17]}ので、事態をより複雑にさせる。FSFはこの想定外の事態に対し、GPLでフォントをライセンスする際には著作権者は「例外条項」を設けるべきと勧告している^[113][114]。

GPLは契約ではなくライセンスとして設計されている^[115][116]。コモン・ローの法的な権限の及ぶ範囲において、契約は契約法により支配されるが、他方ライセンスは著作権法のもと行使されるため、ライセンスと契約の法的な区別はいくらか重要である。しかしながら、大陸法のような契約とライセンスの相違点がない多くの法体系ではこの区別は意味を成さない^[117]。

また、GPLなソフトウェアを受け取ったライセンシーはどの国の著作権法に従うかであるが、これは著作権やライセンスの一般論として定められており、すなわち著作権の準拠法は著作物の利用のあった国の法体系である（これを属地主義という）。よってGPLなソフトウェアを受け取ったライセンシーはその居住する国の著作権法のもと当該ソフトウェアを利用することとなる。

GPLの条項や条件に同意しない（"do not agree to"）、またはそれらを受け入れない（"do no accept"）人々は、著作権法のもと、GPLでライセンスされたソフトウェアまたはその二次的著作物 (派生物) を複製または頒布する許諾を得ることはない（GPLv2第5節、GPLv3第9項）。しかしながら、もし彼らがGPLで保護されたプログラムを再頒布しないならば、彼らは猶も彼らの組織内でそのソフトウェアを好きなように使用しても構わない。そして、プログラムの利用により作成された著作物（生成されたプログラムもこの中に当てはまる）はこのライセンスの影響範囲に含めることを要求されない。

アリソン・ランダルは、ライセンスとしてのGPLv3はその支持者を不必要に混乱させており、同一の条件や法的効力を維持しつつ、簡略化すべきだと主張した^[118]。

日本の独立行政法人、情報処理推進機構がSoftware Freedom Law Centerの協力の下作成した「GNU GPLv3 逐条解説書」^[119]によると、GPLが契約かライセンスかの論争は、GPLがエンフォーシブル（enforceable）か否かという問題と同値であると結論付けられている^[120]。すなわち、ライセンス違反が発生し、解決が法廷に持ち込まれた場合、GPLソフトウェアの作者に認められる要求が著作権侵害による違反者の頒布差止請求や損害賠償請求に留まるのか、はたまた、ライセンスをエンフォース（強制）し、ソースコードの開示にまで持っていけるのか、といった議論は、GPLが契約か否かという問題に帰着する。大陸法ではGPLを契約と見なせるので（とりわけGPLv2の第2節、GPLv3の第9項は申込と承諾の意思表示であると解釈できる）、仮に法廷に持ち込まれた場合、大陸法の法体系では、差止請求だけに留まらずソースコードの開示まで請求できるとの解釈が述べられている。ただし実際にそのような法的な判断、すなわち判決を下すのは裁判所と裁判官であり、状況によってはGPLが対象とする法的範囲が著作権法よりもさらに小さなものだと見なされ、ライセンサーの権利不行使を宣言するものである、民法の権利濫用の禁止や禁反言を始めとする信義則を述べているだけにすぎないという判決が下される可能性すらもある。

また、契約をもってライセンスを制限することも理論上は可能であるため、GPLでの再頒布時の権限を契約を持って押さえ込むことも可能である。ただしそれが有効と認めた判例は未だもってない。

2002年、MySQL ABは著作権侵害ならびに商標権侵害でProgress NuSphere社^[121][122]をアメリカ合衆国マサチューセッツ連邦地方裁判所（英語版）に提訴した。伝えられる所では、NuSphereは、MySQLのGPLで保護されるコードを自社のGeminiテーブル型モジュール^[123]に静的リンクしたが、GPLの条項に従わず、Geminiのソースコードを一切公開しなかった。このためMySQLの著作権を侵害していたとされる^{[124][125][126]}。2002年2月27日、パティ・サリス（英語版）判事の予備審問ののち、当事者らは和解協議に入り、最終的に事実上合意に至った^[127]。審問終了後、FSFは「サリス判事は、GNU GPLが強制力と束縛力を持つライセンスであることが分かったことを表明した」とのコメントを発表した^[128][129]。

2003年8月、SCOグループは、「GPLに法的な有効性などない」と本気で考え、彼らはSCO UnixからLinuxカーネルへと不正に複製されたと疑わしいソースコードの断片を法廷で取り上げるつもりだと主張した。彼らは、当時GNU/Linuxディストリビューションを頒布しており、またそのディストリビューション、Caldera OpenLinuxディストリビューションに含まれていたその他GPLで保護されたコードも頒布していたため、これは問題のある行動であり、しかも、GPLの条項に従うことを除いてそのような問題行動をとる法的な権利などほとんど有って無いに等しかった。

ドイツのネットワーク機器メーカーSitecomは、GPLの条項に違反して、netfilter/iptables（英語版）^{[注釈 18]}プロジェクトのGPLで保護されたソフトウェアを頒布していたが、彼らは頒布停止を拒絶した。この後、事態は法廷に持ち込まれ、2004年4月、ミュンヘン地方裁判所はnetfilter/iptablesプロジェクトの訴えに対し、Sitecomドイツ法人の製品に対する予備的差止命令（英語版）（仮処分差止命令）を認める決定を下した。2004年7月、ドイツの法廷は、この差止命令がSitecomへの判決になると確定し、結審した^[130]。法廷で認められたのは次の内容である。

Defendant has infringed on the copyright of plaintiff by offering the software 'netfilter/iptables' for download and by advertising its distribution, without adhering to the license conditions of the GPL. Said actions would only be permissible if defendant had a license grant [...] This is independent of the questions whether the licensing conditions of the GPL have been effectively agreed upon between plaintiff and defendant or not. If the GPL were not agreed upon by the parties, defendant would notwithstanding lack the necessary rights to copy, distribute, and make the software 'netfilter/iptables' publicly available.

参考訳:

被告は、ソフトウェア'netfilter/iptables'をダウンロードできる状態にし、その頒布物を宣伝したが、GPLのライセンス条件を遵守しなかったため、原告の著作権を侵害した。仮に被告がライセンスの許諾を受けている場合を除いて、当該行為は許されない。(中略) このことは、原告と被告との間で、GPLのライセンス条件に事実上合意したか否かという問題とは別である。仮に原告・被告の当事者がGPLに同意しなければ、にもかかわらず、被告は当該ソフトウェア'netfilter/iptables'を複製、頒布そして公開するのに必要な権利を失っていただろう。

netfilter/iptablesの開発者でその著作権を持つもののひとりでもある、ハラルト・ヴェルテは、ドイツにあるFLOSS関連の法的係争を扱う組織、ifrOSS（英語版）の共同設立者、ティル・イェーガー(Till Jaeger)に自身の法的代理人を要請した。この判決文は当時FSFの顧問だったエベン・モグレンが以前予想した通りの内容を反映していた。これは、GPLの条項違反が著作権侵害に与える影響を法廷が初めて認めた重要な判決だった。

2005年5月、ダニエル・ウォレス (Daniel Wallace) は「GPLは価格を零にしようとする違法な企て、すなわち価格固定（英語版）やダンピングである」と主張し、FSFをアメリカ合衆国インディアナ南部連邦地方裁判所（英語版）に提訴した。2006年3月、ウォレスはGPLが反トラスト法に違反する行為を促すとの正当な主張を法廷で証明することができなかったため、原告申立ては棄却された。「GPLは、自由競争、コンピュータ・オペレーティングシステム・ソフトウェアの頒布、消費者が直接得られる利点を阻害するというより、むしろ促進している」と、法廷は言い渡した^[131]。その後、ウォレスは、不服申立の控訴状も却下され、FSFへの訴訟費用の支払いを命じられた。

2005年9月8日、ソウル中央地方法院 (서울중앙지방법원, Seoul Central District Court, ソウル中央地方裁判所) は、GPLでライセンスされた著作物から派生した二次的著作物を企業秘密^{[注釈 19]}とする契約事項に対し、GPLは本件と関連なしとの判決を下した^[132][133]。判決主文の英文抄訳より事件のあらましを述べると、係争にあがった著作物は、GPLv2で保護されたソフトウェアVTun（英語版）である。被告の一人はVTunをベースとした二次的著作物であるソフトウェアを、原告である企業に雇用されている間作成した。彼が原告企業を退社後、そのソフトウェアのソースコードを個人的に複製しており、そのバグ修正を行ったうえ、そのソフトウェアを利用した商用サービスをもう一人の被告と立ち上げた^{[注釈 20]}。これに対し、原告はそのサービスが自社の企業秘密の漏洩であると主張した。 被告らは、GPLを遵守して著作物を頒布する限りは、企業秘密を維持することなど不可能であるので、守秘義務違反ではないと主張した。ソウル地裁はこの主張の法的根拠を認めず、「ライセンス如何にかかわらず、企業秘密の漏洩により公平な競争者に対抗し不公平な利益を得ることを守秘義務で縛ることは妥当である。また企業秘密は特許とは別であり、技術的である必要は無い（1998年大韓民国大法院判決による）。」と述べた。

2006年9月6日、gpl-violations.orgプロジェクトは、D-Link Germany GmbH（Dリンクのドイツ法人）を提訴し、これに勝訴した。原告は、被告が販売する（即ちこれ自体「対価を取って頒布する」ことであり、なんら問題ない）NAS機器に、Linuxカーネルの一部を利用していたが、GPLに違反した使用であり、著作権侵害である、と主張した^[134]。この判決^[135][136]により、GPLの有効性、法的拘束力がドイツの法廷で支持されたという判例が与えられたことになった。

2007年後半より、BusyBoxの開発者ならびにSoftware Freedom Law Center(SFLC)は、組み込みシステムに利用するBusyBoxの頒布者からGPLを遵守する旨の言質を得ることや、GPLを遵守しないものを提訴する計画に乗り出した。これら一連の訴訟は、アメリカ合衆国において、GPLの責務に対する強制力を法廷で争った初の機会であると述べられている。

2008年12月11日、FSFはシスコシステムズを提訴した^[137]。被告はそのLinksys部門にて、原告のFSFがGPLでライセンスした著作物である、

• GNU Core Utilities
• GNU Readline
• GNU Parted
• GNU Wget
• GNUコンパイラコレクション
• GNU Binutils
• GNUデバッガ

ソフトウェアパッケージを、Linksysの次に述べる製品のファームウェアにGNU/Linuxの形で組み込んで、対価を取って頒布、すなわち販売していたが、GPLの条項に違反していたためFSFの著作権を侵害している、と原告のFSFは主張した。該当する製品は、Linksysの有名な無線LANルーターWRT54Gやその他DSLモデム、ケーブルモデム、NAS機器、VoIPゲートウェイ、VPN機器そしてホームシアター、メディアプレーヤー機器などその他多くの機器にも及ぶ^[138]。

FSFがシスコを提訴するまでの6年間、FSFはシスコに何度も申立を行ったが、シスコは、「われわれは、（GPLで保護されたプログラムの全てのソースコードならびにその改変箇所を含む完全な複製を提供しなかったというGPLの）条項違反についての問題を修正する予定もしくは修正中である」と主張した。しかし、FSFはその後もより多くの製品から新たな違反が発覚したとの報告を受け、Linksysと多くの会談をとり行うこととなった。しかし、結局実りは少なかった。FSFのブログでは、この過程を「5年間にも及ぶモグラ叩きゲーム」("five-years-running game of Whack-a-Mole") と評している^[139][138]。この6年間の過程を経て、FSFは遂に本件を法廷に持ち込むことを決意した。

その後シスコは本訴訟の和解のテーブルに着き、6ヵ月後、

• GPLのコンプライアンス遵守を保証することを目的とした「Linksysに対するフリーソフトウェアの監査役 (Free Software Director) を任命すること」
• 「GPLに基づき、FSFの著作物である当該プログラムを組み込んだLinksys製品を、対価を払って受領、すなわち購入した以前の顧客 (つまりGPLのライセンシーまたは受領者) に、当該顧客のGPL上の権利を保証する旨の通知を行うこと」
• FSFのプログラムのソースコードを、シスコのウェブサイト上で自由に利用可能な状態にする(アップロードする)こと^[140]
• FSFへの金銭的支払いを行うこと

以上の和解内容に合意した^[141]。

2001年、マイクロソフトのCEO、スティーブ・バルマーは、Linuxを「知的財産権の意味において、触れるもの全てにくっつく癌である」と呼んだ^[142]。マイクロソフトがGPLを嫌う理由は「取り込み、拡張して、抹殺する」という独占的ベンダーの試みにGPLが抵抗するためであるとマイクロソフトの批判者らは主張する^[143]。

マイクロソフトは、以前、GPLでライセンスされたコードを含む製品である、Microsoft Windows Services for UNIXを販売（のちWindowsのEULAに従う者には無償ダウンロード可に）していたこともある^[144]。マイクロソフトのGPLに対する攻撃に対抗するため、幾人かの著名なフリーソフトウェア開発者とフリーソフトウェアの代弁者たちはライセンスを支持する旨の共同声明を発表した^[145][146]。しかしながら、この声明から7年以上たった、2009年7月、マイクロソフト自身が、GPLのもと本体が約20,000行程度となるLinuxカーネルのドライバコードをリリースした^[147][148]。ただし、提供されたコードの一部に相当するLinux用のHyper-Vドライバコードが、GPLのもとライセンスされているオープンソース・コンポーネントを利用しており、当初プロプライエタリなバイナリ部分と静的リンクしていた。後者はGPLソフトウェアに対するライセンス違反である^{[149][150][151]}。

また、これ以外にも、同社が提供するソフトウェアに意図せずGPLで保護されたコードが混入するケースもあった^[152]。

マイクロソフトのシニア・バイス・プレジデント、クレイグ・マンディは、GPLはプログラム全体を譲渡することしか許諾せず、これは、プログラマに、GPLと両立しないライセンスのライブラリとリンクするプログラムを譲渡することを許諾しないことを意味する故、GPLは「ウイルス的(viral)である」と評した^[153]。

このいわゆる「ウイルス的」効果とは、組み合わせることを考えているソフトウェアの、複数のライセンスのうち一つが変更されないならば、そのような状況下で、異なる別のライセンスで許諾されるソフトウェアと組み合わせることができないことを指す。ライセンスのいずれか一つは理論上変更することはできるけれども、「ウイルス的」なる考えの筋書きによれば、GPLは事実上撤回することはできない（なぜなら、GPLソフトウェアには通常極めて多くの貢献者(contributors)の存在があるが、彼らの幾人かはこの決定をおそらく拒絶するだろう）。他方、他のソフトウェアのライセンスは実際には可能なのである。

リチャード・ストールマンの見解によると、「ウイルス」というメタファーは誤りであり、また不親切な物言いである。GPLのもとリリースされるソフトウェアは、他のソフトウェアを、決して「攻撃」したり「感染」などしない。むしろ、GPLで保護されるソフトウェアは、オリヅルランのようなものである、と述べている。だれかが、GPLで保護されたソフトウェアのコード断片を持ち帰り、どこかよそへそれを組み込んだならば、GPLで保護されるソフトウェアもまた、そのどこかで成長するのである^{[154][155][156]}。このようにGPLのような二次的著作物にも適用を強制するという強い制約を持つライセンスは、独占的なソフトウェアを開発する企業や、他のライセンスを支持するソフトウェア開発者から批判されることがある。コピーレフトの考え方を支持する人々は、これは自由を守るために必要なことだと主張する。一方、二次的著作物への制限が少ないBSDスタイル・ライセンスを支持する人々はまた別の考え方を持っている。GPLの支持者が「フリーソフトウェアの自由が二次的著作物でも保護されることを、フリーソフトウェア自身が保証すべき」と確信する一方、そうでない人々は「フリーソフトウェアはその再頒布にあたって利用者に最大限の自由を与えるべきだ」と主張する。後者の考え方は、例えばBSDライセンスのように敢えて「ソフトウェアの自由を捨て去る」ことも可能という、ソフトウェア利用者の自由意志、選択の自由を述べている。

態度を鮮明にしている幾人かの有名なLinuxカーネル開発者は、マスメディアに対しコメントを出し、GPLv3の議論用の初稿ならびに第2稿の一部に反対する旨の声名を発表した^[157]。リーナス・トーバルズは、GPLv3の反DRM条項により、GPLv3でライセンスされたソフトウェアがDRMを利用したコンピュータ・セキュリティのメカニズムを享受できなくなるとして、LinuxカーネルのGPLv3への移行には明確に反対している^[158]。リチャード・ストールマンは、2007年初めにもこの動きは収束すると期待していた^{[注釈 21]}。

第3稿に関しては、（反TiVo化条項がいくらか緩められたため）トーバルズは「満足している」と語っていた^[160]が、最終稿が提出された後のコメントでは、GPLv3はGPLv2と比べ（両者のデュアルライセンスが可能か考慮に入れた上、コードの全著作者からライセンス移行の合意を得るという途方も無い手間を掛けたとしても^[96]）移行するメリットはないとトーバルズは述べた^[161][162]。

おおむね、これらの議論は本質的には全く同じ視点に立ってはいるが、主にソフトウェアのコードの自由を重視するオープンソース陣営と、それのみではなくソフトウェアを利用するユーザーの自由の最大化を目的とするフリーソフトウェア陣営の考え方の違いが浮き彫りになったに過ぎない。ソフトウェアの自由な利用のためには、GPLv3にはソフトウェアの範疇に留まらず、広く働きかけることを厭わ（いとわ）ないとする後者の考え方が色濃く出ている^{[疑問点 – ノート]}。

FreeBSDプロジェクトは、「GPLソフトウェアを公開しない、そして誤ってGPLソフトウェアを利用してしまったケースなどにより、これらの行為がソフトウェア企業の価値を下げたいと考えている巨大企業の格好の餌食になっている。言い換えれば、GPLは、潜在的に経済的利益の全体を低下させ、また寡占的行為を助長するゆえ、マーケティングの武器として利用されるのに、とてもふさわしい。」と主張し、GPLは「ソフトウェアの商用化やその利益を生み出そうと考えている人々にとって現実の問題として本当に邪魔になっている」と主張している^[163]。

FreeBSDの開発者で、Beerware（英語版）ライセンスの著作者でもある、ポール＝ヘニング・カンプ（英語版）は、"GNUライセンス"を「ジョーク」であると見なしている。その理由は彼が気付く限りこのライセンスには曖昧な記述が存在するからだと述べている^[164]。実際にFreeBSDでは、2014年1月にリリースした10.0-RELEASEより、OSの標準コンパイラをGNU GCCからClang/LLVMに切り替えている^[165]。

セクション"リンクと派生物"の通り、GPLで保護されたコードに由来する二次的著作物はGPLでなければならない、と明白に要求されているが、GPLのライブラリに動的にリンクしたプログラムが、二次的著作物と見なせるかどうかは、議論が分かれている。これに対しFSFとその他の人々の見解が異なることが新たな論争の種となっている。この点に関し、著作権法が二次的著作物をどう定義するかが問題になると述べたが、著作権の支分権の具体的内容についての問題が提起されている。アメリカ合衆国著作権法を収録した合衆国法典第17編の第101条 (各種用語の定義) によれば、著作物の改変・翻案を例にあげたうえで「既存の著作物を基礎とする」ことが二次的著作物の要素となっているため、動的リンクの場合でも既存の著作物を基礎としているのかが問題となり得る。これに対し、日本国著作権法第二条によれば、二次的著作物は原著作物の「翻案」を要素としているため、GPLのライブラリとGPLでないプログラムが動的にリンクするプログラムを作って頒布したところで、二次的著作物を作成したことにはならず、プログラムを実行したときに必然的に生じるメモリへの複製の段階で初めて問題になるに過ぎない。しかし、日本国著作権法ではプログラムを実行することそれ自体（これを使用権という）は著作権の支分権としては認められていない。 ちなみにGPLv3では"derivative work"という語が姿を消し、代わりに「改変されたバージョン」や「元プログラムに基づく作品」となっている。これらは「二次的著作物」を指している^[A]。

また、アメリカ合衆国著作権法においても、日本国著作権法においても、原著作物の著作権者は、二次的著作物に対して著作権行使をすることができるのは当然の前提なのだが、ソフトウェアが著作権の対象となるように法制度が確立する前は、改変したプログラムに対する権利範囲等が不明確であったこともあり、法の建前を前提として議論がされていない側面がある。

いずれにせよ、当該著作物が二次的著作物であるかの判断は、ライセンス如何の問題ではなく、最終的には法廷が個々の著作物毎に判断することとなる。しかし、現時点では明確な線引きを行った著作権法上の条文や判例は存在せず、その他法源となるものもない。ガルーブ対任天堂（英語版）訴訟においても二次的著作物の範囲が明確に定められなかったのは前述の通りである。

GPLが持つ制約とは全く別の問題として、一部の批判者らは、GPL前文のイデオロギー的な響きが嫌だとか、ライセンスが長過ぎて分かりにくいと愚痴をこぼす。この「落とし所」には、ソースやバイナリの複製 (reproduction) を認めないが、個人や会社での使用で修正の自由を認めるようなライセンス群を含むことがある。こういった変種の一つには、 Open Public License (OPL)^[166]がある。これら批判の原因は、GPLの条文が一見理解しにくいがために起こる誤解によるところもある。しかし、このGPLの手の込んだ条項は一見理解に困難を伴うが、これによりコピーレフトが創出され、著作権法の枠組みを徹底してハックしている点も忘れてはならない。

GPLの条文そのものや、その要求、許可する事項（義務、権利）については、GPLに賛同している者ですらも誤解していることがあり、そのことがGPLの議論に関し混乱を招く原因のひとつともなっている。既に解説済みの項目も多いが、改めて述べる。

GPLなソースコードを改変・修正した場合、ソースコードを公開しなければならない

GPLで保護された著作物の修正や、GPLの影響が及ぶコードを新しい著作物で利用するとき、修正者であるライセンシー、またはライセンシーの組織内のみで私的に利用されるだけならば、ソースコードの公開は要求されない。組織内のみでの使用であれば、二次的著作物のソースコードを公開する義務が発生しないため、機密性の重要視される研究開発部門や顧客管理部門で使用されるパソコンやサーバーのほか、インフラシステムや軍事・防衛分野などでも広く用いられている。

課金が許されていない

GPLで保護された著作物の複製を販売^[167][168]したり、ダウンロードに課金^[169][170]したりすることをGPLはわざわざ許可している（セクション"利用条件"を参照）。頒布の手間にかかるコストは無視できないためこのことは都合がよい。また頒布の手段に拠ってGPLの下での購入者やベンダーの権利、責任に変更が生じることはない。実のところ、非商用の頒布だけを認めるライセンスは、自動的にGPLと矛盾する。

ソースコードは無償で頒布しなければならない

GPLが要求することは、ソースコードを入手する機会を保証することである。たとえば、ソースコードが記録されたCD-ROMを実費を請求する形で郵送しても一向にかまわない。GPLv3では第4項第2段落で「『プログラム』の『伝達』行為に対する課金」と定めている。ただ、「ライセンス料、ロイヤルティその他の対価」を徴収することは、「さらなる権利制限」になるので注意が必要である（セクション"下流の受領者への自動的許諾"を参照）。

GPLのツールを使って開発したソフトウェアはGPLでなければならない

GPLでなければならないのは、GPLのソースコードを含んでいたり、GPLのライブラリをリンクや結合するときのみに限る。独占的なソフトウェアをGCCでコンパイルして頒布することは、許可されている。ただし、libgccなど、GCCの各種ランタイムライブラリはGPLに関するライセンスの影響を受けることもある。プロプライエタリなソフトウェアとの動的リンクを可能とするため、GCCの各種ランタイムライブラリは例外条項が付帯したGPLとなっている^[171]。

GPLソフトウェアは改造して公開することは不自由なくできる

GPLは著作権を規定するライセンスであり、商標権・意匠権やその他の法的な権利や義務には効力が及ばない。また、フォークや独自パッチ適用バージョンを「改変前とまったく同一の名前のソフトウェア」として公開し、もともとの原著作者のソフトウェアと一見して区別できない場合には、著作権法上の問題が発生する。GPLソフトウェアから派生したプロプライエタリソフトウェアのバイナリパッケージやソースコードを秘密保持契約に反する形で漏洩させると、不正競争防止法に抵触し、処罰される可能性がある。デジタルコンテンツのコピーガードを無効化したり、不正アクセス行為に使用することを主目的としたソフトウェアの作成や公開も法律により固く禁じられている。セキュリティ上の脆弱性に関する情報を権利者に無断で外部に公開する行為も不正アクセス禁止法違反となる場合がある。

出典は列挙するだけでなく、脚注などを用いてどの記述の情報源であるかを明記してください。 記事の信頼性向上にご協力をお願いいたします。（2022年4月）

• 江端俊昭、稲葉清高、岩切美和、上山浩、川上桂子、瀬戸邦雄、八田真行、松田久夫、松本美信、八木稔浩、柳沢茂樹 (2010年5月26日). “GNU GPLv3 逐条解説書”. IPA. 2011年4月21日閲覧。なおこの文献はあくまでもSFLCならびにIPA両者の見解であり、実際の係争事例に対するGPLについての明確な法廷判断が存在するわけではない。
• SOFTIC オープンソースソフトウェアライセンスの最新動向に関する調査研究委員会委員 (2007年11月16日). “オープンソースソフトウェアライセンスの最新動向に関する調査報告書 平成19年11月16日”. SOFTIC. 2011年4月29日閲覧。
• Free Software Foundation. “GNU 一般公衆利用許諾書 バージョン3（非公式日本語訳）”. SourceForge.JP. 2011年4月23日閲覧。

ポータル FLOSS

英語版ウィキブックスに本記事に関連した解説書・教科書があります。

FLOSSライセンス

• The GNU General Public License (原文)
• GNU General Public License v3.0（テキストファイル形式）
• GNU General Public License v1.0 – FSFによりすでに廃止済。
• GNU General Public License v2.0 – FSFによりすでに廃止済であるが、Linux・GNUのパッケージを含む多くのソフトウェアプロジェクトで未だに使用されている。

• GNU 一般公衆利用許諾書 バージョン3 (GPLv3) (GitHub)
• GNU 一般公衆利用許諾契約書 バージョン2 (GitHub) (非公式日本語訳)

表 話 編 歴 FLOSSライセンス
オープンソース
コピーレフト (自由ソフトウェア)	GPL LGPL AGPL Common Development and Distribution License Common Public License 1.0 MPL 2.0	Portal:FLOSS
非コピーレフト (自由ソフトウェア)	Apache License, 2.0 Artistic License 2.0 BSDライセンス Eclipse Public License MIT License イリノイ大学/NCSAオープンソースライセンス

表 話 編 歴 GNUプロジェクト
歴史	GNU宣言 GNUプロジェクト フリーソフトウェア財団 フリーソフトウェアの定義 フリーソフトウェアの歴史（英語版）
GNUライセンス	GNU General Public License GNU Lesser General Public License GNU Affero General Public License GNU Free Documentation License GPLリンク例外 GPLフォント例外
ソフトウェア	GNU 派生 Hurd Linux-libre GNOME Gnuzilla IceCat Gnash Bash GCC Electric Emacs glibc Gnulib Coreutils GNUstep Autotools Bazaar LilyPond 一覧
代表者	アレシャンドリ・オリヴァ ベンジャミン・マコ・ヒル（英語版） ブラッドリー・M・クーン エベン・モグレン フェデリコ・ハインツ ゲオルク・C・F・グレーフェ レオナルド・H・タワー・ジュニア（英語版） ロイク・ダシャリー（英語版） リカルド・ガリ（英語版） リチャード・ストールマン ロバート・J・シャッセル（英語版） ジョン・サリバン
その他	GNU/Linux名称論争 Revolution OS The Cathedral and the Bazaar BadVista Defective by Design
カテゴリ

表 話 編 歴 フリーソフトウェア財団
人物	リチャード・ストールマン（代表） ウィリアム・ジョン・サリバン
GNUプロジェクト	GNU General Public License GNU Lesser General Public License GNU Affero General Public License GNAT Modified General Public License GNU Free Documentation License
他のプロジェクト	Free Software Directory FSFフリーソフトウェア賞 BadVista Defective by Design
姉妹組織	FSF Europe FSF Latin America FSF India プログラミング自由連盟
関連項目	自由ソフトウェア フリーソフトウェア運動 自由ソフトウェアの定義 自由ソフトウェアライセンス フリーソフトウェア財団対シスコシステムズ事件 Linuxディストリビューションの比較
カテゴリ