GPLv2とGPLv3の違いを、実務で重要な論点ごとに整理し、公式情報に基づいて比較します。
概要
| 項目 | GPLv2 | GPLv3 |
|---|---|---|
| 特許の扱い | 明記されていない | 明示的に制限（特許権行使でライセンス喪失など） |
| DRM（著作権保護技術）対策 | 対応なし | 回避を禁止する法律（DMCA等）に対抗する条項あり |
| Tivo化対策（実行改変防止） | 不可 | 改変後のコードを実行できるように義務付け |
| SaaS提供 | 開示義務なし | 同様に開示義務なし（AGPLで補完される） |
| ライセンス違反時の救済 | なし（即時終了） | 是正すれば自動復活（猶予期間あり） |
| 他ライセンスとの互換性 | 狭い（例：Apacheと非互換） | 広い（例：Apache License 2.0と併用可能） |
| 表記の推奨 | GPL-2.0-only / or-later | GPL-3.0-only / or-later |
GPLライセンスについては、こちらの記事でも解説しています。
オープンソースのライセンスの一覧については、こちらの記事で解説しています。
詳細比較：GPLv2とGPLv3の主な違いの解説
以下、GPLv2とGPLv3の主な違いについて、詳しく解説します。
1. 特許に関する保護の違い
- GPLv2：特許に関する明示的な条項がほぼない。
- GPLv3：特許ライセンスを明文化（Section 11）。特許権を主張する企業の再配布を制限可能。
GNU: GPLv3 Section 11 – Patents
https://www.gnu.org/licenses/gpl-3.0.html#section11
2. DRM（デジタル著作権管理）への対応
- GPLv2：DRM技術に対抗する仕組みはない。
- GPLv3：DRMを利用して自由を制限することを禁止（Section 3）。
GNU: Quick Guide to GPLv3
https://www.gnu.org/licenses/quick-guide-gplv3.en.html
3. Tivoization（改変の自由の制限）対策
- GPLv2：ハードウェアで改変コードを動作不可にしても違反になる記載がない。
- GPLv3：改変後のコードを「実行可能」にする方法を提供する義務あり（Section 6）。
GNU: GPLv3 Section 6 – Installation Information
https://www.gnu.org/licenses/gpl-3.0.html#section6
4. SaaS提供時の扱い（クラウド対応）
- 両者共通：ソフトウェアを「配布」しない（SaaS）場合はソースコード開示義務なし。
例）SaaS形式で自社サーバー上で動かすだけなら、GPLの開示義務はない
例）SaaSモデルで、ユーザーはソフトをダウンロードして所有するのではなく、
サーバー上で提供されるサービスとして利用する場合は、配布にはなりません- ソフトウェアのコピーを配布していない
- クライアントにはバイナリもソースも渡していない
- 対策としては、AGPLv3（Affero GPL）が別に用意されている。
AGPLv3では、ネットワーク経由のソフトウェア提供（ASPサービス・SaaS等の提供）にもソースコード提供を適用
GNU: AGPLv3 とは
https://www.gnu.org/licenses/agpl-3.0.html
5. 違反時のライセンス復活（猶予）
- GPLv2：違反＝直ちにライセンス終了、回復には特別な許可が必要。
- GPLv3：違反を是正すれば一定の条件で復活する条項あり（Section 8）。
GPLv3（Section 8）
引用元：https://www.gnu.org/licenses/gpl-3.0.html#section8
本ライセンスの違反をすべてやめた場合、特定の著作権保有者からのライセンスは、(a) 著作権保有者が明示的かつ最終的にライセンスを終了しない限り暫定的に、(b) 停止後 60 日以内に著作権保有者が何らかの合理的な手段で違反を通知しなかった場合、永久的に復活します。
6. 他ライセンスとの互換性
- GPLv2：互換性に関する制約がより厳しい
Apache License 2.0 との併用は不可（特許条項が競合）。 - GPLv3：Apache License 2.0 との互換性あり（FSF公認）。
GPLv2の互換性に関する記述
Apache License 2.0 との互換性に関する記述
7. SPDX識別子（明確なライセンス表記）
- GPLv2：
GPL-2.0-onlyまたはGPL-2.0-or-laterを明記。 - GPLv3：
GPL-3.0-onlyまたはGPL-3.0-or-laterを推奨。
SPDX（公式）ライセンスID一覧
https://spdx.org/licenses/
公式に基づくライセンス表記
Therefore, when you use SPDX license indicators, please use these:
引用元：https://www.gnu.org/licenses/identify-licenses-clearly.en.html
・GPL-2.0-only or GPL-2.0-or-later
・GPL-3.0-only or GPL-3.0-or-later
・LGPL-2.0-only or LGPL-2.0-or-later
・LGPL-2.1-only or LGPL-2.1-or-later
・LGPL-3.0-only or LGPL-3.0-or-later
・AGPL-3.0-only or AGPL-3.0-or-later
・GFDL-1.3-only or GFDL-1.3-or-later
Please do not use the old, ambiguous license indicators, which will be deprecated:
・GPL-2.0
・GPL-3.0
・LGPL-2.0
・LGPL-2.1
・LGPL-3.0
・AGPL-3.0
・GFDL-1.3.
補足
GPLv3 の特許条項（第11条）「特許権」と「特許ライセンス」の扱い
この条項は、GPLv3プログラムの利用に関する「特許権」と「特許ライセンス」の扱いを明確に定めたものです。GPLv2では曖昧だった特許リスクを避けるために追加されています。
概要
貢献者（Contributor）の定義
- 貢献者とは、GPLv3の下でプログラムをライセンスしている著作権者のこと。
- 各貢献者が公開した版は「contributor version（貢献者バージョン）」と呼ばれます。
「必須特許請求範囲」とは
- 貢献者が保有・管理する特許のうち、GPLv3の条件のもとで「contributor version（貢献者バージョン）」を使うときに侵害する可能性がある範囲。
- ただし、「改変によって初めて侵害するようになる特許」は除かれます。
- 「管理」には、その特許をサブライセンスする権利も含まれます。
特許ライセンスの自動付与
- 各貢献者は、受領者（あなた）に対し、
「プログラムを使う・改変する・配布する」ための非独占的・世界的・ロイヤリティフリーな特許ライセンスを自動的に与えます。 - つまり、貢献者の特許を侵害しないように安心して使える、ということです。
特許ライセンスの意味
- 「特許ライセンス」とは、「特許を行使しない」と約束すること。（＝訴えない、侵害と主張しない、の意）
- 名称が異なっても、実質的にその合意があれば特許ライセンスと見なされます。
あなたが特許ライセンスに依拠する場合の義務
あなたが次のような場合には、3つの選択肢のいずれかを取る必要があります。
- 特許ライセンスに依拠して作品を配布し、
そのソースコードを自由にダウンロードできない形で提供しているとき。
何れかを対応する：
- ソースコードを無料で入手できるようにする
- その特許ライセンスの恩恵を放棄する
- 下流の受領者にも同じ特許ライセンスを拡張する
下流への特許ライセンスの自動拡張
- あなたが他者と契約して、特定の相手に特許ライセンスを付与した場合、
そのライセンスは自動的にすべての下流受領者（配布先全員）に拡張されます。
差別的特許ライセンスの禁止
- 一部の人だけを優遇する特許ライセンス（例：ある企業だけ無料）は禁止。
- 特に、あなたが配布活動と引き換えに第三者へ支払いを行い、
その第三者があなたの受領者に特許の免責を与えるような契約（Microsoft-Novell協定のようなもの）は禁止。 - ただし、2007年3月28日以前の契約は例外。
最後の但し書き
- この条項は、法的にあなたが主張できる黙示的ライセンスや侵害防御（特許法上の抗弁）を奪うものではありません。（つまり、あなたの法的権利を制限する意図はない）
実務での選び方（まとめ）
| あなたのプロジェクト | 推奨ライセンス |
|---|---|
| ハードウェア製品（IoT・組込） | GPLv3（Tivo化対策） |
| 古いGPLv2-only資産と併用（例：Linux kernel） | GPLv2-only |
| Apache License と組み合わせたい | GPLv3 |
| ソース非配布（SaaS形式のみ） | GPLv2/3どちらでもOK（ただしAGPLも検討） |
| より明文化されたライセンス管理を望む | GPLv3（条項が明瞭） |
FAQ よくある質問
- GPLv2における「第三者に対して有効な書面によるオファー」とはどういう意味ですか？これは、世界中の誰もがGPLライセンスのプログラムのソースコードを、どんな状況でも入手できるという意味ですか？
-
書面による申し出を通じてソースを提供することを選択した場合、あなたにソースを要求する人は誰でもそれを受け取る権利があります。
GPLでは、ソースコードを添付せずにバイナリを商用配布する場合、後日ソースコードを配布することを書面で申し出る必要があると規定されています。ユーザーがあなたから受け取ったバイナリを非商用目的で再配布する場合、この書面による申し出のコピーを渡す必要があります。つまり、あなたから直接バイナリを入手していない人でも、書面による申し出と共にソースコードのコピーを受け取ることができるということです。
このオファーが第三者に対しても有効であることを要求している理由は、その方法で間接的にバイナリを受け取った人があなたからソース コードを注文できるようにするためです。
引用元：：https://www.gnu.org/licenses/gpl-faq.en.html#WhatDoesGPLStandFor - GPL では、改変したバージョンのソースコードを公開することが義務付けられていますか?
-
GPLは、改変したバージョン、あるいはその一部を公開することを義務付けていません。改変を加えて、それを公開することなく、私的に利用することは自由です。これは組織（企業を含む）にも適用されます。組織は改変したバージョンを作成し、それを組織外に公開することなく、内部で利用することができます。
しかし、何らかの方法で改変したバージョンを一般に公開する場合、GPL に基づいて改変したソース コードをプログラムのユーザーが利用できるようにすることが GPL によって義務付けられます。
したがって、GPL は、変更されたプログラムを特定の方法でリリースすることを許可しますが、他の方法では許可しません。ただし、リリースするかどうかの決定はあなた次第です。
引用元：：https://www.gnu.org/licenses/gpl-faq.en.html#GPLRequireSourcePostedPublic - ある会社がGPLが適用されたプログラムの改変バージョンをウェブサイトで動かしています。GPLはかれらは改変したソースコードを配布しなければならないと言ってますか? (#UnreleasedMods)
-
GPLは誰もが改変したバージョンを作成し、他に配布することなく、使うことを許しています。この会社が行っているのはこの特別な場合です。ですから、この会社が改変したソースコードをリリースする必要はありません。改変されたプログラムがGNUアフェロGPLの条項のもとでライセンスされているときには、この状況は異なります。
この状況を、ユーザがこのウェブサイトを訪れた際にユーザに対して別のGPLプログラムが配信されるような状況(よくJavaScriptで書かれますが、ほかの言語も使われます)と比較してみてください。別のGPLプログラムが配信される状況では、配信されるプログラムのソースコードは、ユーザーに対してGPLの条項の元でリリースされる必要があります。
引用元：https://www.gnu.org/licenses/gpl-faq.html#UnreleasedMods - GPLv2では、改変版を公開する場合は「すべての第三者にライセンスを付与しなければならない」と規定されています。この第三者とは誰でしょうか？
-
第2条では、あなたが配布する改変版は、すべての第三者に対してGPLに基づいてライセンス付与されなければならないと規定されています。「すべての第三者」とは、文字通りすべての人を指しますが、これはあなたが彼らに対して物理的に何かを
引用元：：https://www.gnu.org/licenses/gpl-faq.en.html#WhatDoesGPLStandFor
することを意味するものではありません。彼らがあなたのバージョンに対して、GPLに基づいてあなたからライセンスを付与されていることを意味するだけです。 - GPL で保護されたプログラムに対する変更に対して著作権を主張する必要がありますか?
-
変更内容に対して著作権を主張する必要はありません。ただし、ほとんどの国ではデフォルトで自動的に著作権が主張されるため、著作権を主張したくない場合は、変更内容を明示的にパブリックドメインにする必要があります。
変更に対する著作権を主張するかどうかに関わらず、いずれにしても、変更したバージョン全体を GPL の下でリリースする必要があります (変更したバージョンをリリースする場合)
引用元：：https://www.gnu.org/licenses/gpl-faq.en.html#WhatDoesGPLStandFor - GPL では、あるコードを別のプログラミング言語に翻訳することについて何と言っていますか?
-
著作権法では、著作物の翻訳は改変の一種とみなされます。したがって、GPLが改変版について規定している内容は、翻訳版にも適用されます。翻訳版は元のプログラムの著作権によって保護されます。
元のプログラムがフリーライセンスである場合、そのライセンスは翻訳を許可します。翻訳されたプログラムの使用方法とライセンスは、そのライセンスによって決まります。元のプログラムが特定のバージョンのGNU GPLでライセンスされている場合、翻訳されたプログラムも同じバージョンのGNU GPLで保護される必要があります。
引用元：：https://www.gnu.org/licenses/gpl-faq.en.html#WhatDoesGPLStandFor - プログラムがパブリック ドメイン コードと GPL で保護されたコードを組み合わせた場合、パブリック ドメイン部分を取り出してパブリック ドメイン コードとして使用してもよいですか?
-
どの部分がパブリックドメインなのかを理解し、それを他の部分から分離できれば、それは可能です。コードが開発者によってパブリックドメインに置かれたのであれば、それがどこにあったとしても、それはパブリックドメインです。
引用元：：https://www.gnu.org/licenses/gpl-faq.en.html#WhatDoesGPLStandFor - GPL では、プログラムのコピーを金銭で販売することが許可されていますか?
-
はい、GPLは誰でもそうすることを許可しています。
引用元：：https://www.gnu.org/licenses/gpl-faq.en.html#WhatDoesGPLStandFor
複製を販売する権利はフリーソフトウェアの定義の一部です。特別な状況を除き、価格に制限はありません。（唯一の例外は、バイナリのみのリリースに付随するソースコードの提供を書面で申し出る必要がある場合です。） - GNU GPL のコピーをリポジトリに置くだけで十分ですか?
-
GNU GPLのコピーをリポジトリ内のファイルに置くだけでは、同じリポジトリ内のコードがGNU GPLの下で使用できると明示的に表明するものではありません。そのような記述がなければ、ライセンスの許可が特定のソースファイルに本当に適用されるかどうかは完全には明らかではありません。明示的にそう記述すれば、あらゆる疑問は解消されます。
ライセンスだけを含むファイルで、そのライセンスが他の特定のファイルにも適用されるという記述がない場合、それは他のどこからも呼び出されないサブルーチンだけを含むファイルに似ています。しかし、その類似性は完璧ではありません。弁護士や裁判所は常識的に判断し、コードをそのようにライセンスしたかったからGNU GPLのコピーをそこに置いたに違いないと結論付けるかもしれません。あるいは、そうではないかもしれません。なぜ不確実性を残すのでしょうか？
この声明は各ソースファイルに記載する必要があります。プログラムのREADMEファイルに明確な声明を記載すれば、コードに付随している限り法的には十分ですが、両者は簡単に分離されてしまう可能性があります。コードのライセンスが不確実になるリスクを冒す必要はありません。
これはGNU GPLの具体的な内容とは全く関係ありません。あらゆるフリーライセンスに当てはまります
引用元：：https://www.gnu.org/licenses/gpl-faq.en.html#WhatDoesGPLStandFor - 各ソース ファイルにライセンス通知を入れる必要があるのはなぜですか?
-
コードがライセンスから切り離されてしまうリスクを避けるため、各ソースファイルの冒頭に、そのファイルがどのライセンスに基づいているかを明記する必要があります。リポジトリのREADMEにソースファイルがGNU GPLに基づいていると記載されている場合、誰かがそのファイルを他のプログラムにコピーするとどうなるでしょうか？他の文脈では、ファイルのライセンスが何であるかが分からない可能性があります。別のライセンスが適用されているように見える場合や、ライセンスが全く適用されていないように見える場合（その場合、コードは非フリーになります）があります。
各ソース ファイルの先頭に著作権表示とライセンス表示を追加するのは簡単で、そのような混乱は起こりにくくなります。
これはGNU GPLの具体的な内容とは全く関係ありません。あらゆるフリーライセンスに当てはまります。
引用元：https://www.gnu.org/licenses/gpl-faq.en.html#NoticeInSourceFile - GPLの及ぶプログラムで使うためにプラグインをわたしが書いたとして、わたしのプラグインの配布に際して、わたしが使えるライセンスにはどのような要請がありますか? (#GPLAndPlugins)
-
この質問を、ある「プログラムとそのプラグインが単一の結合されたプログラムと考えられるときと、別々の作品と考えられるときを決定するために(#GPLPlugins)」を読んでください。
もしメインプログラムとプラグインが単一の結合されたプログラムの場合、あなたはそのプラグインをGPLかGPLと両立する自由ソフトウェア・ライセンスでライセンスしなければならず、GPLの条項に従ってソースコードとともに配布する必要があります。そのプラグインと分かれているメインプログラムは、そのプラグインに何の要請もしません。
引用元：https://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins - あるプログラムとそのプラグインが単一の結合されたプログラムと考えられるのはどのようなときですか?(#GPLPlugins)
-
それはプログラムがどのようにプラグインを呼び出すかに依ります。メイン・プログラムがforkやexecでプラグインを呼び出し、複雑なデータ構造を共有することで密接な通信をしたり、複雑なデータ構造をやりとりする場合、単一の結合されたプログラムとなるでしょう。メイン・プログラムが単純なforkやexecを使ってプラグインを呼び出し、密接な通信を確立しないのであれば、プラグインは別のプログラムと言えるでしょう。
もしプログラムがプラグインと動的にリンクされており、お互いにファンクションコールを使ってデータ構造を共有している場合、それらは単一の結合されたプログラムを形成しているとみなされますので、その単一の結合されたプログラムは、メインプログラムとプラグインの両方の拡張部分として扱われなければなりません。もしプログラムがプラグインと動的にリンクされているが、相互の通信はプラグインの ‘main’ 関数をあるオプションで起動しその帰りを待つことだけに限定される場合、これは境界線のケースとなります。共有メモリを使い、複雑なデータ構造で通信することは、動的なリンクとほとんど同等です。
引用元：https://www.gnu.org/licenses/gpl-faq.html#GPLPlugins
公式ドキュメントまとめ
- GNU（公式）GPLv2 本文（英語）
https://www.gnu.org/licenses/gpl-2.0.txt - GNU（公式）GPLv3 本文（英語）
https://www.gnu.org/licenses/gpl-3.0.txt - GNU: GPL FAQ（v2/v3比較・互換性）
https://www.gnu.org/licenses/gpl-faq.en.html
コメント