目次 [ close ]
  1. はじめに
  2. 第2条: ソースコードの改変と配布（最重要条項）
    1. 条件a: 改変箇所の明示
    2. 条件b: コピーレフトの核心
    3. 条件c: インタラクティブな著作権表示
    4. 補足説明: 「単なる集約」は例外
  3. 第3条: バイナリ配布の3つの方法
    1. 方法1: ソースコードを同時配布（最もシンプル）
    2. 方法2: 書面での提供約束（物理媒体向け）
    3. 方法3: 書面の転送（非営利配布のみ）
    4. システムライブラリの例外
  4. 第4条: ライセンス違反時の権利喪失
    1. 結果1: あなたの権利が自動的に消滅
    2. 結果2: 著作権侵害になる
    3. 結果3: 下流の受取人は影響を受けない
    4. 実務での対応
  5. 実務でのチェックリスト
    1. 改変版を配布する前に（第2条）
    2. バイナリを配布する前に（第3条）
    3. ライセンス違反を防ぐために（第4条）
  6. まとめ
    1. 第2条：改変と配布
    2. 第3条：バイナリ配布
    3. 第4条：ライセンス違反

はじめに

第1部では、GPL v2の前文と基本定義、そして逐語的コピーの配布ルールを見てきました。第2部では、いよいよGPL v2の核心部分に入ります。

この記事で扱う内容：

  • 第2条: ソースコードを改変したときのルール（GPL v2の心臓部）
  • 第3条: バイナリ（実行ファイル）を配布するときのルール（実務で最重要）
  • 第4条: ライセンス違反したらどうなるか？

開発者が実際に最もよく直面する「改変したらどうなるのか？」「バイナリ配布時に何が必要なのか？」という疑問に、原文を読み解きながら答えていきます。

第2条: ソースコードの改変と配布（最重要条項）

第1条では「変更を加えないコピー」の配布ルールでしたが、第2条では「改変版」の配布について定めています。これがGPL v2の最も重要な条項です。

原文:

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:

和訳:

あなたは、プログラムまたはその一部のコピーを改変し、それによってプログラムを基にした作品を形成し、そのような改変または作品を上記第1条の条件の下で複製・配布することができます。ただし、以下のすべての条件を満たすことが必要です。

新人君

つまり、改変版も配布できるけど、追加の条件があるってことですね？

ossan

その通り！改変すること自体は自由だけど、それを配布するときには特別なルールが適用されるんだ。

条件a: 改変箇所の明示

原文:

a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

和訳:

a) 改変されたファイルに、あなたがそのファイルを変更したこと、および変更の日付を記した目立つ告知を含めなければなりません。

新人君

これは何のためですか？

ossan

これは「誰が、いつ変更したか」を明確にするためなんだ。

実装例

/*
 * Original work Copyright (C) 2020 Original Author
 * Modified by Your Name on 2024-10-12
 * 
 * Changes:
 * - Added new feature X
 * - Fixed bug in function Y
 */

または：

# Modified by Your Name, 2024-10-12
# Changes: Refactored database connection logic

新人君

これってなぜ重要なんですか？

ossan

いくつか理由があるよ：

  1. 責任の所在: バグが見つかったとき、誰の変更が原因かわかる
  2. オリジナル作者の保護: 改変版の問題が、元の作者のせいにならないようにする
  3. 履歴の追跡: ソフトウェアの進化を追跡できる

新人君

GitのコミットログがあればOKですか？

ossan

良い質問だね！実務的には、Gitのログがあれば「改変の日付」の要件は満たせると考えられているよ。ただし、改変されたファイル自体に何らかの告知を含める方がより安全だね。

条件b: コピーレフトの核心

原文:

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.

和訳:

b) あなたが配布または公開する作品であって、全体または一部がプログラムまたはその一部を含むか、それから派生したものである場合、その作品全体を、本許諾書の条件の下で、すべての第三者に無償で許諾しなければなりません。

新人君

これが有名な「コピーレフト」ですね！でも、ちょっと複雑で…

ossan

そうだね。これはGPL v2の心臓部だから、丁寧に読み解いていこう。

ポイント1: 「作品全体（as a whole）」がGPL v2になる

ossan

ここで重要なのは「as a whole（全体として）」という部分なんだ。

具体例で考えてみよう：

あなたのアプリケーション（10,000行）
  ├─ あなたが書いたコード（9,000行）
  └─ GPL v2ライブラリ（1,000行）

この場合、アプリケーション全体の10,000行がGPL v2で配布されなければならないんだ。

新人君

え！自分が書いた9,000行も全部GPL v2になっちゃうんですか？

ossan

そう、これがGPLの「感染力（viral effect）」と呼ばれる特徴なんだ。GPL v2のコードを少しでも含むと、全体がGPL v2になる。

ポイント2: 「無償で（at no charge）」の意味

新人君

「無償で（at no charge）」って、有料で配布できないってことですか？

ossan

これは誤解されやすいんだけど、実は違うんだ。

「at no charge」は「ライセンス料を請求しない」という意味で、「販売してはいけない」という意味ではないんだよ。

つまり：

  • ✅ ソフトウェア自体を有料で販売してもOK
  • ✅ サポート料金を請求してもOK
  • ✅ CD-ROMの製造・配送料を請求してもOK
  • ❌ ライセンス料（使用許可料）は請求できない
  • ❌ 買った人にはソースコードを提供し、その人も同じ権利を持つ

新人君

じゃあ、Red Hatが有料でLinuxを販売できるのはそういう理由なんですね。

ossan

その通り！Red Hatは「ソフトウェア自体」ではなく、「サポートとサービス」に対して料金を請求しているんだ。

ポイント3: 「すべての第三者（all third parties）」への許諾

原文の該当部分:

to be licensed … to all third parties

ossan

これは「あなたから受け取った人だけでなく、その先の人にも同じ権利がある」という意味なんだ。

連鎖的な権利の継承：

オリジナル作者（GPL v2で公開）
    ↓
あなた（改変してGPL v2で配布）
    ↓
受取人A（さらにGPL v2で配布）
    ↓
受取人B（同じくGPL v2で配布）
    ↓
... 永遠に続く

全員が同じ自由を持つんだ。

条件c: インタラクティブな著作権表示

原文:

c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)

和訳:

c) 改変されたプログラムが、実行時に通常、対話的にコマンドを読み取る場合、最も通常の方法でそのような対話的使用のために起動されたとき、適切な著作権表示と、保証がないことの告知（あるいは、あなたが保証を提供する旨の表示）、ユーザーがこれらの条件の下でプログラムを再配布できる旨、およびユーザーが本許諾書のコピーを閲覧する方法を含む告知を印刷または表示しなければなりません。（例外：プログラム自体が対話的であっても、通常そのような告知を印刷しない場合、プログラムを基にしたあなたの作品は告知を印刷する必要はありません。）

新人君

これは具体的にどういうことですか？

ossan

これは「対話型プログラム」の場合の追加条件だよ。

対話型プログラムの例

$ myprogram
MyProgram version 2.0
Copyright (C) 2024 Your Name
This program comes with ABSOLUTELY NO WARRANTY; for details type 'show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type 'show c' for details.

>

新人君

全部のプログラムでこれを表示しないといけないんですか？

ossan

いや、条件があるよ：

  1. プログラムが「対話的」である
    • コマンドラインツール、シェル、REPLなど
    • ユーザーとやり取りするプログラム
  2. 元のプログラムが告知を表示する
    • 元のプログラムが表示していなければ、あなたも表示しなくていい

つまり、GUIアプリや、バックグラウンドで動くサービスは対象外なんだ。

補足説明: 「単なる集約」は例外

原文（第2条の続き）:

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…

In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

和訳:

これらの要件は、改変された作品全体に適用されます。その作品の識別可能なセクションがプログラムから派生したものでなく、それ自体が独立した別個の作品であると合理的に考えられる場合、それらのセクションを別個の作品として配布する際には、本許諾書およびその条件は適用されません。しかし、同じセクションを、プログラムを基にした作品である全体の一部として配布する場合、全体の配布は本許諾書の条件に従わなければなりません…

さらに、プログラムを基にしていない他の作品を、プログラム（またはプログラムを基にした作品）と、ストレージまたは配布媒体の一巻に単に集約することは、その他の作品を本許諾書の範囲に含めません。

新人君

これは何を言っているんですか？

ossan

これは「単なる集約（mere aggregation）」という重要な例外なんだ。

例外が認められるケース

ケース1: 独立したプログラムの集合

Linux DVD（1枚のディスクに収録）
  ├─ Linux kernel（GPL v2）
  ├─ Bash（GPL v2）
  ├─ プロプライエタリなビデオドライバ（独自ライセンス）
  └─ あなたの商用アプリ（独自ライセンス）

これは「単なる集約」なので、それぞれが独立したライセンスを持てる。

ケース2: 認められない密結合

あなたのアプリケーション
  ├─ main.c（あなたのコード）
  └─ libgpl.a（GPL v2ライブラリと静的リンク）← 密結合

これは「単なる集約」ではなく、一体となった派生作品なので、全体がGPL v2になる。

新人君

その境界線はどこですか？

ossan

これは議論が分かれる部分なんだ。一般的な基準は：

状況派生作品?根拠
静的リンク✅ はい一つの実行ファイルに統合される
動的リンク（密結合）⚠️ 議論が分かれるFSFは派生物とする立場だが、法的には未確定
プロセス間通信❌ いいえ独立したプログラム間のやり取り
同じディスクに保存❌ いいえ物理的に同じ場所にあるだけ
パイプで接続❌ いいえ標準的なインターフェース経由

新人君

動的リンクが「議論が分かれる」ってどういうことですか？

ossan

これは実は法的にグレーゾーンなんだ。 

FSF（Free Software Foundation）の立場:

  • 動的リンクでも派生物を構成する
  • GPL v2が適用される

しかし：

  • 裁判所の確定判断はまだない
  • 企業の法務部門でも解釈が分かれる
  • LGPL（Lesser GPL）が作られたのは、この問題に対処するため

だから実務では：

✅ 安全策：LGPLライブラリを使う、または独自ライセンスのライブラリを使う 
⚠️ リスク承知：動的リンクで使い、法務部門と相談
❌ 危険：静的リンクで使い、ソースを公開しない

第3条: バイナリ配布の3つの方法

さて、ここまではソースコードの改変と配布でした。しかし実務では、バイナリ（実行ファイル）を配布することの方が多いですよね。第3条では、その方法を定めています。

原文（冒頭）:

You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

和訳:

あなたは、上記第1条および第2条の条件の下で、プログラム（または第2条に基づくそれを基にした作品）をオブジェクトコードまたは実行可能形式で複製・配布することができます。ただし、以下のいずれかを行うことも必要です。

新人君

 「オブジェクトコード」と「実行可能形式」って何ですか？

ossan

簡単に言うと：

  • ソースコード: 人間が読める形式（.c、.java、.pyなど）
  • オブジェクトコード: コンパイルされた中間形式（.o、.objなど）
  • 実行可能形式: そのまま実行できる形式（.exe、バイナリなど）

要するに、「ソースコードではない形式」で配布するときのルールだね。

方法1: ソースコードを同時配布（最もシンプル）

原文:

a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange;

和訳:

a) 完全な対応する機械可読のソースコードを添え、そのソースコードは、ソフトウェア交換に通常使用される媒体で、上記第1条および第2条の条件の下で配布されなければなりません。

新人君

これが一番わかりやすいですね。バイナリと一緒にソースコードも配ればいいんですね？

ossan

その通り！これが最もシンプルで確実な方法だよ。

実装例

例1: Webサイトでの配布

ダウンロードページ：
├─ myapp-1.0.bin（バイナリ）
└─ myapp-1.0-src.tar.gz（ソースコード）

例2: パッケージでの配布

Linuxディストリビューション：
├─ myapp-1.0.rpm（バイナリパッケージ）
└─ myapp-1.0.src.rpm（ソースパッケージ）

例3: 組み込み機器

製品パッケージ：
├─ ハードウェア本体
├─ ファームウェア（バイナリ）
└─ CD-ROM or USBメモリ（ソースコード収録）

「完全な対応するソースコード」の意味

新人君

「完全な対応する（complete corresponding）」ソースコードって、具体的に何を含めればいいんですか？

ossan

これは原文で定義されているよ：

原文（第3条の補足）:

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.

和訳:

作品のソースコードとは、それを改変するための好ましい形式を意味します。実行可能な作品の場合、完全なソースコードとは、それが含むすべてのモジュールのすべてのソースコード、加えて関連するインターフェース定義ファイル、加えて実行可能ファイルのコンパイルとインストールを制御するために使用されるスクリプトを意味します。

ossan

つまり、含める必要があるのは：

  1. すべてのソースコード
    • メインプログラムのソース
    • 含まれるすべてのモジュールのソース
    • GPL v2ライブラリのソース
  2. ビルドに必要なもの
    • Makefile、CMakeLists.txt
    • ビルドスクリプト
    • 設定ファイル
  3. インターフェース定義
    • ヘッダーファイル（.h）
    • IDLファイル
    • APIドキュメント
  4. インストール手順
    • インストールスクリプト
    • READMEファイル（ビルド方法の説明）

新人君

じゃあ、受け取った人が「自分でビルドできる状態」にする必要があるんですね。

ossan

その通り！これがGPLの「改変の自由」を保証するために重要なんだ。

方法2: 書面での提供約束（物理媒体向け）

原文:

b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange;

和訳:

b) 少なくとも3年間有効な書面での申し出を添え、いかなる第三者に対しても、ソース配布を物理的に実行するための費用を超えない料金で、対応するソースコードの完全な機械可読のコピーを、ソフトウェア交換に通常使用される媒体で、上記第1条および第2条の条件の下で配布することを約束します。

新人君

これはどういうときに使うんですか？

ossan

これは主に物理的な媒体（CD-ROM、DVDなど）で配布するときに使われるんだ。

使用例

製品パッケージに同梱される書面：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    ソースコード提供のお知らせ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

本製品には GPL v2 ライセンスのソフトウェアが
含まれています。

ソースコードをご希望の方は、以下の宛先まで
ご請求ください。実費（送料・媒体費）のみで
提供いたします。

【申込先】
株式会社○○○○ GPL ソースコード係
〒123-4567 東京都...
Email: gpl-source@example.com

【提供期間】
2024年10月12日から3年間有効
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

重要な条件

条件1: 最低3年間有効

  • 製品販売後、3年間は対応しなければならない
  • 長期的なコミットメントが必要

条件2: 実費のみ請求可能

for a charge no more than your cost of physically performing source distribution

  • CD-ROMの製造費
  • 送料
  • 人件費は含めない

条件3: すべての第三者が対象

to give any third party

  • 製品を直接買った人だけでなく
  • 中古で入手した人も
  • 第三者から譲り受けた人も
  • 全員がソースコードを請求できる

新人君

これってコストがかかりそうですね…

ossan

その通り。だから現代では方法1（ダウンロードで同時配布）が主流になっているんだ。でも、組み込み機器のように物理的な製品の場合は、この方法が今でも使われているよ。

方法3: 書面の転送（非営利配布のみ）

原文:

c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

和訳:

c) 対応するソースコードを配布する申し出に関して、あなたが受け取った情報を添える。（この選択肢は、非商業的配布に限り、かつ、あなたが上記bに従ってそのような申し出と共にオブジェクトコードまたは実行可能形式でプログラムを受け取った場合にのみ許可されます。）

新人君

これはどういう意味ですか？

ossan

これは「又配布」の特例なんだ。

使用シナリオ

メーカーA
  ↓ 製品販売（方法bの書面付き）
エンドユーザーB
  ↓ 友人に無償で譲渡
友人C

この場合、Cさんは：

  • メーカーAが提供した書面を転送すればOK
  • 自分でソースコードを用意する必要はない

重要な制限

  1. 非商業的配布のみ
    • 友人に譲る、コミュニティで共有するなど
    • 販売する場合は使えない
  2. 方法bで受け取った場合のみ
    • 自分も同じ書面を受け取っている必要がある
  3. 書面の内容をそのまま転送
    • メーカーAの連絡先をそのまま渡す
    • 自分で対応する義務はない

新人君

これって、メーカーAに負担がかかりませんか？

ossan

そうなんだ。だからメーカー側は、方法1で最初からソースコードを公開しておく方が、長期的には楽なんだよ。

システムライブラリの例外

原文（第3条の続き）:

However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

和訳:

しかし、特別な例外として、配布されるソースコードは、実行可能ファイルが動作するオペレーティングシステムの主要なコンポーネント（コンパイラ、カーネルなど）と通常配布される（ソースまたはバイナリ形式で）ものを含む必要はありません。ただし、そのコンポーネント自体が実行可能ファイルに付随する場合を除きます。

新人君

これはどういう例外ですか？

ossan

これは「システムライブラリ例外」と呼ばれるものだよ。

例外の対象

あなたのGPL v2アプリが以下を使っている場合、そのソースコードを含める必要はない：

✅ 含めなくてよいもの（システムライブラリ）：

  • libc（標準Cライブラリ）
  • libm（数学ライブラリ）
  • Windowsの標準DLL（kernel32.dll等）
  • OSに標準で含まれるライブラリ

❌ 含める必要があるもの：

  • 自分で同梱した特殊なライブラリ
  • GPL v2のライブラリ
  • サードパーティのライブラリ

新人君

なぜこの例外があるんですか？

ossan

もしこの例外がないと：

  • Linuxカーネル全体のソース
  • libc全体のソース
  • すべてのシステムライブラリのソース

これら全部を含めないといけなくなる。それは非現実的だから、「OSに標準で含まれるもの」は例外としたんだ。

第4条: ライセンス違反時の権利喪失

さて、ここまで配布のルールを見てきました。では、これらのルールを守らなかったらどうなるのでしょうか？それが第4条です。

原文:

You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

和訳:

あなたは、本許諾書で明示的に規定されている場合を除き、プログラムを複製、改変、再許諾、または配布することはできません。それ以外の方法でプログラムを複製、改変、再許諾、または配布しようとする試みは無効であり、本許諾書の下でのあなたの権利を自動的に終了させます。ただし、本許諾書の下であなたからコピーまたは権利を受け取った者は、その者が完全に遵守している限り、そのライセンスは終了しません。

新人君

違反したらどうなるんですか？

ossan

3つの重要な結果があるよ。

結果1: あなたの権利が自動的に消滅

原文の該当部分:

will automatically terminate your rights under this License

ossan

ライセンス違反した瞬間に、自動的にあなたの権利が失われるんだ。

つまり：

  • プログラムを使う権利
  • 配布する権利
  • 改変する権利

これらすべてが即座に失われる。

新人君

「警告してから」ではなく、「即座に」ですか？

ossan

そう、「automatically（自動的に）」と書いてあるね。警告や猶予期間はないんだ。

結果2: 著作権侵害になる

ossan

権利を失った後にプログラムを使い続けると、それは著作権侵害になるんだ。

ライセンスがあるから合法的に使えていたのに、それが失われると：

  • ✅ ライセンス違反前：合法的な使用
  • ❌ ライセンス違反後：著作権侵害

法的な結果：

  • 損害賠償請求の対象
  • 差し止め請求の対象
  • 場合によっては刑事罰の対象

結果3: 下流の受取人は影響を受けない

原文の該当部分:

However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

新人君

これはどういう意味ですか？

ossan

これは「あなたが違反しても、あなたから受け取った人の権利は守られる」という意味なんだ。

図解

オリジナル作者
    ↓
あなた（違反！）← 権利喪失
    ↓
受取人A（遵守している）← 権利は継続
    ↓
受取人B（遵守している）← 権利は継続

ossan

つまり：

  • あなたの権利は失われる
  • でも受取人A、Bは、ルールを守っている限り影響を受けない
  • コミュニティ全体への影響を最小限にする配慮だね

実務での対応

新人君

もし違反してしまったら、どうすればいいんですか？

ossan

GPL v2には「自動復権（automatic reinstatement）」の規定がないから、厳密には：

  1. 著作権者に連絡
    • 違反を認める
    • 是正措置を説明
    • 再許諾をお願いする
  2. 違反を修正
    • ソースコードを公開
    • ライセンス表示を追加
    • 配布を停止（または適切に再開）
  3. 著作権者の判断を待つ
    • 著作権者が新たにライセンスを付与するかどうか
    • 実務的には、誠実に対応すれば多くの場合は解決

新人君

GPL v3ではこれが改善されているんですよね？

ossan

そうなんだ。GPL v3では、初回違反の場合は30日以内に是正すれば自動的に復権できる規定が追加されたんだよ。でもGPL v2にはそれがないから、より慎重な対応が必要なんだ。

実務でのチェックリスト

第2部で学んだ内容を実務に活かすためのチェックリストです。

改変版を配布する前に（第2条）

  • [ ] 改変したファイルに改変日時と改変者を明記したか？
  • [ ] 改変版全体をGPL v2で配布する準備ができているか？
  • [ ] 全ての依存ライブラリがGPL v2互換か確認したか？

バイナリを配布する前に（第3条）

  • [ ] 「完全な対応するソースコード」を準備したか？
    • すべてのソースコード
    • ビルドスクリプト（Makefile等）
    • 依存ライブラリのソース（システムライブラリ除く）
  • [ ] ソースコードからバイナリを再現できるか確認したか？

ライセンス違反を防ぐために（第4条）

  • [ ] GPL v2の条件をチーム全体で理解しているか？
  • [ ] 定期的なライセンス監査を実施しているか？

まとめ

第2部では、GPL v2の最も重要な条項である第2条〜第4条を詳しく見てきました。

重要なポイントをおさらい:

第2条：改変と配布

  • 改変箇所の明示: 誰が、いつ変更したかを記録
  • コピーレフトの核心: 改変版も全体がGPL v2になる
  • 感染力: GPL v2コードを含むと全体に適用される
  • 単なる集約の例外: 独立したプログラムの集合は例外

第3条：バイナリ配布

  • 3つの方法: 同時配布、書面提供、書面転送
  • 完全なソースコード: ビルド・インストールに必要なすべて
  • システムライブラリ例外: OS標準のライブラリは含めなくてよい
  • 実務では同時配布が推奨: 長期的な管理コストが低い

第4条：ライセンス違反

  • 自動的な権利喪失: 違反した瞬間に権利が消滅
  • 著作権侵害に: 権利喪失後の使用は違法
  • 下流は保護される: 受け取った人の権利は継続
  • 復権規定なし: GPL v2には自動復権の仕組みがない

実務での鉄則:

  1. GPL v2コードを使う前に、プロジェクト全体への影響を評価
  2. バイナリ配布時は、必ずソースコードの提供方法を確保
  3. 不明な点は、GPL v2を避けるか、専門家に相談
  4. 「内部使用のみ」なら公開義務なし（SaaSも含む）

この記事は一般的な情報提供を目的としており、法的アドバイスではありません。具体的な法的問題については、専門家にご相談ください。