概要

GPLの基礎にあるコピーレフトの概念は、改変の自由を重要な目的の一つとしている。 

改変の自由を確保するためには、受領者に対して実行形式のプログラムだけでなく、ソー スコードが提供されることが必要である。ソースコードがなければ、プログラムを改変す ることは実際上不可能だからである。 

そこで、本条は、ソースコードについて詳細な定義を定めている（といっても、ソース コードの定義は、開発現場で通常用いられている範囲と特段違っているわけではない）。 

実務上重要な問題は、オブジェクトコード形式（実行形式）でプログラムを配付した場 合に受領者の要求に応じてソースコードを開示する場合、開示すべき範囲がどのようなも のを含むかということである。本条は、この点に関しても「対応ソース」（Corresponding 

Source）という用語を用いて重要な定義を定めている（第4パラグラフ）。 

3.2. 条文内容

3.2.1. 第1パラグラフ

「ソースコード」とは、「著作物を改変するのに好ましい形式」をいう。やや抽象的な表 現ではあるが、オブジェクトコード形式のプログラムの受領者がプログラムを改変できる ようにするためにソースコードの提供が必要とされているのであるから、この目的からす れば合理的な規定といえる。 

「オブジェクトコード」は、「ソースコード」以外の形式すべてをいうものとして定義さ れている。これも、基本は、一般のソフトウェア開発で用いられる実行形式のコードと同 義と考えてよいであろう。しかし、例えば、書籍に印刷された大量のソースコードは、そ れ自体では「著作物を改変するのに好ましい形式」とはいえないから、この定義からは「オ ブジェクトコード」に当たると解される余地もあることに留意が必要である。 

GPLv2  に お い て は 、ソ ー ス コ ード はʺthe  preferred  form of  the  work  for making  modifications to itʺ （著作物の修正に適した形態）と定義されているが（第3条）、オブジェ クトコードや実行形式の定義はなされていない。これに対し、GPLv3 においては、第 1 条 第1パラグラフでソースコード以外のすべての形態をオブジェクトコードと定義している。

‐ 35 ‐ 

つまり、GPLv2 においては、明白にソースコードともオブジェクトコード（や実行形式）

とも判別の付かないものの配布に関しては、GPLv2 の第 3 条に従う必要があるのかどう かが明白ではなかったが^［33］、GPLv3 においてはその判断が容易になっている。 

例えば、意図的に読みにくく段組みなどを変えたソースコードはʺpreferred formʺとはい えず、オブジェクトコードに当たる^［34］。 

もう少し複雑な例としては、例えば bison などのコンパイラコンパイラの出力を配布す

る場合、GPLv2 においては、これがオブジェクトコードに該当し、GPLv2 第 3 条が適用

されると解するのには若干無理がある。そのため、GPLv2 においては、コンパイラコンパ イラの入力を配布しないことを GPL 違反に問うことは難しいと考えられる。これに対し、

GPLv3 では、ʺpreferred formʺ 以外はすべてオブジェクトコードに当たるから、コンパイ ラコンパイラの出力はオブジェクトコードであり、コンパイラコンパイラへの入力がその 対応ソースということになる。したがって、GPLv3 では、コンパイラコンパイラへの入力 も第6条に基づき配付する義務があるということになり、問題が解決される。 

また、GPL で保護された著作物（プログラムに限らない）を雑誌等の印刷媒体に掲載す るというケースも、典型的にこの条件にあてはまる。GPLv2 においてはこのケースは曖昧 に扱うしかないが（ソースコードを雑誌に掲載したからと言って、それを特に追加定義な しにオブジェクトコードということには無理がある）、プログラムの改変に適した形態とは いえないことが明らかである以上、GPLv3 においてはオブジェクトコードに該当すると解 され、したがって第 6 条の適用を受けることになると考えるのが妥当であろう。 

3.2.2. 第2パラグラフ

「標準インターフェース」（Standard Interface）とは、標準化団体によって策定された公 式の標準規格のインターフェース、または特定のプログラミング言語用のインターフェー スであって、当該言語を利用する開発者の間で広く用いられているものをいう。 

プログラムをオブジェクトコード形式で配付した場合でも、「標準インターフェース」に 当たる部分についてはそのソースコードを開示しなくともよいこととされている（第 1 条 第4パラグラフ）。 

SFLCによれば、「標準インターフェース」における標準規格の例としてはTCP/IPのイン ターフェース、プログラミング言語用インターフェースの例としてはJavaのAPIなどがあ る。 

［33］第3条が適用されない場合は、配布の前に改変を行ったかどうかによって、第1条また は第2条が適用される。 

［34］ディスカッションドラフト第1版解説にその旨記載されている。 

‐ 36 ‐ 

3.2.3. 第3パラグラフ

本パラグラフは、「システムライブラリ」（System Libraries）の定義を定めている。 

プログラムをオブジェクトコード形式で配付した場合でも、「システムライブラリ」に当 たる部分についてはそのソースコードを開示しなくともよいこととされている（第1条第4 パラグラフ）。 

「システムライブラリ」とは、以下の（a）または（b）に当たるプログラムをいう（た だし、全体としての当該著作物そのものは除く）。 

（a）「主要コンポーネント」（Major Component）のパッケージに通常含まれている、主 要コンポーネント以外の著作物 

（b）著作物を主要コンポーネントにおいて利用可能とするためにのみ機能するもの、お よび、標準インターフェースを実装するためにのみ機能するものであって、一般に 公開されているソースコードを用いて実装できるもののすべて。 

上記（b）の「主要コンポーネント」とは、プログラムが動作する特定のオペレーティン グシステムの主要な必須コンポーネント（カーネルやウィンドウシステムなど）、著作物の 生成に用いられるコンパイラ、著作物を実行するために用いられるオブジェクトコードイ ンタプリタをいう。例えばSun Microsystems社の提供するSunOS（同社のOSであるSolaris のカーネル部分の呼称）のようなものがその典型である。この例の場合、SolarisのSunOS 以外の部分（Cライブラリなど）が「システムライブラリ」に該当すると解される。 

また、Linux ディストリビューション中の C ライブラリは、それを使用するプログラム

から見た場合、「主要コンポーネント」に該当すると同時に、「システムライブラリ」にも 該当する（上記（b）に該当）。また、Javaクラスライブラリやlibxlibも「システムライブ ラリ」に該当すると解される。 

「システムライブラリ」に関する例外規定は、もともとプロプライエタリなOS用に開発 されたアプリケーションの配付に関する障碍を取り除くことを目的としたものである。 

プロプライエタリなOS用に開発されたアプリケーションの場合、アプリケーションをコ ンパイルして得られたオブジェクトコードにプロプライエタリなライブラリが静的リンク されていることがある。このような場合、本条第4 パラグラフ第 1 文の原則によれば、プ ロプライエタリなライブラリに対応するソースコードも開示しなければならないことにな る。しかし、プロプライエタリであるためこれは不可能である。そのため、プロプライエ タリなライブラリを静的リンクしたプログラムはGPLで公開できないことになる。 

一方で、こうしたOSは一般に入手・利用が可能であるから、システムライブラリのソー

‐ 37 ‐ 

スコードを公開せずとも、アプリケーションのソースコードさえ開示されれば、プログラ ムの改変も改変後のプログラムを実行することも可能である。 

そこで、システムライブラリのソースコードは開示対象から除かれているのである。 

（b）の標準インターフェースを実装するためにのみ機能するもので、実装用にソースコー ドが公開されているものとしては、JavaのAPIなどがある。 

システムライブラリに該当するか否かを判断するためのフローチャートを以下に示す。 

カーネル、ウィンドウシステム、コンパイラ、

バイトコードインタプリタ等の主要コンポーネ ントのパッケージに通常含まれているか？

Yes

No 著作物を主要コンポーネントにおいて利用

可能とするためにのみ機能するものか？

当該部分は「システムライブラリ」であり 対応ソースの開示は不要

Yes 標準インターフェースの実装で、ソースコー

ドが一般に利用可能か？

当該部分は「システムライブラリ」ではなく、

対応ソースの開示が必要

No

3.2.4. 第4パラグラフ

本パラグラフは、オブジェクトコード形式の著作物における「対応ソース」（Corresponding 

Source）の定義を定めている。ソースコード形式の著作物の対応ソースについては、本条第

6パラグラフで定義されている。 

対象著作物をオブジェクトコード形式で配布した場合、受領者の改変の自由を確保する ためには、通常のソースコードだけでなく、改変後のプログラムをコンパイルやインストー ルして実行するのに必要な情報のすべてが受領者に提供される必要がある。 

そこで、「対応ソース」は、オブジェクトコードを生成し、インストールし、実行するた めに必要なソースコードのすべてをいうものとして定義されている。当該著作物を改変す るために必要なソースコード（これが通常の意味でのソースコードに当たろう）だけでな く、これらの作業を行うのに必要なスクリプトもまた「対応ソース」に含まれる。 

ただし、上記に該当するものであっても、システムライブラリ、汎用ツール又は一般に