softic question D-3-1

1.自社開発プログラムを GPL プログラムと結合または連係動作させる場合、自社開発プログラムに GPL を適用しなければならない(GPL が伝搬する)範囲をどのように判断すればよいでしょうか。

1 GPL のライセンス条件を遵守しなければならない理由 とは?

GPL プログラムは、プログラムの著作物であり、著作権法で保護されています。著作権法上、著作物を複製や改変等をする権利は、著作権者(開発者等)だけに与えられています(著作権法21 条乃至 28 条)。著作権法で定める著作権の制限を除き、著作権者の許諾を得ることなく、無断で著作物を複製または改変(著作者人格権の侵害)ないし翻案(著作財産権の侵害)をした場合には、著作権の侵害に該当し、損害賠償の対象となるとともに(民法 709 条)、場合によっては刑事罰の対象ともなります(著作権法 113 条 1 項 2 号)。
★そこで、著作権者以外が、著作物を複製や改変、翻案等をする場合には、著作権者の許諾を受ける必要があります。許諾を受けたとしても、著作権者が著作物の利用を許諾する際に一定の条件(利用料の支払、再販売の禁止等)を付けることもあります。この条件がいわゆる利用許諾条件であり、GPL も利用許諾条件の一つです。すなわち、GPL 等のオープンソースは、著作権を放棄するのではなく、自由な利用の促進等の目的のために一定の条件を付しており、著作権法上、原作品を翻案した二次的著作物に該当するプログラムについては、利用者が GPL プログラムを利用する条件に違反すると、ライセンス条件を充たさないために著作権の不行使(ライセンス)が消滅し、利用者は無権原な者となり、当該 OSS を利用する行為が著作権侵害となります。

2 GPL が契約かライセンスかによって伝搬性の判断が異なるか ?

GPL が契約220なのかライセンス221なのかについては、両方の考え方がありますが、GPL プログラムの伝搬性を判断する場面においては、いずれの説を採ったとしても、結果的に自社開発プログラムに GPL が伝搬する判断基準を考えるときには、実務上は有意な差異がないものと考えられますので、GPL の趣旨にしたがい、FSF(Free Software Foundation)の FAQ222に基づいて伝搬性を判断するアプローチの方が、GPL プログラムを利用する企業にとって安全であると考えます223。この点に関して、詳しくは本書「D-4-1 GPL の法的性質」を参照してください。

3.GPL 伝搬性の判断基準は?

(1)静的リンク
同一の実行ファイルに含まれる場合(プログラムが実行される前の段階で同一ファイルになっている場合)、すなわち静的リンクは伝搬します。
(2)動的リンク
同一の実行ファイルに含まれないけれども、共有アドレス空間内でモジュールがリンクされて実行するよう設計されている場合(共有ライブラリ)およびモジュールの動的リンクは、伝搬します229。
(3)コマンド起動、パイプ、ソケット
同一の実行ファイルに含まれず、共有アドレス空間内でリンクされることなく、プログラム間で通信する場合、プログラム間の通信のメカニズム(構造)および通信のセマンティクス(どのような種類の情報が交換されるか)を分析して、個別具体的に判断することになります。コマンド起動(fork、exec など)、パイプ、ソケットは原則として別個のプログラム間の通信にすぎず、原則として伝搬しませんが、通信の態様が密接である場合には伝搬することがあります。また、プラグイン(Plug-in)は、通信の態様が密接である場合は伝搬することがあります。

4 伝搬しない実装方法は?

GPL プログラムと自社開発プログラムを組み合わせる場合、次の条件をすべて満たす利用態様であれば、GPL プログラムが自社開発プログラムに伝搬しないと考えられます。
① 自社開発プログラムは、独自開発したコードであって、GPL のコードを複製または翻案(GPL のコードに依拠して実質的に類似)していない。
② それぞれのプログラムは、分離可能で、メモリ空間(プロセス空間)を共有しない230。
③ 標準インターフースを介して通信をおこなう。
④ コミュニケーションのメカニズムについては、静的にも動的にもリンクしない通信方法(パイプ・ソケット、プロセス間通信、プラグイン、コマンド起動)を選択する 。
⑤ 自社開発プログラムと GPL プログラムの間で相互交換される情報は、関数やパラメータのタイプや数の定義 (ほとんどが非著作物) である(セマンティクスが親密でない)。
⑥ 相互依存性が低い(自社開発プログラムの有無が GPL のコード動作の正否に影響しない)
231。
以下、なぜこのように考えるかについて、解説していきます。

5.伝搬性判断基準の根拠は?

(1)この FAQ が採る解釈基準
①GPLv2 が適用されるプログラムを基礎とした作品(work based on the Program)とは、米国著作権法 101 条に規定されている派生物ないし二次的著作物(derivative work undercopyright law)と同一の意義であるものと考えられますが、この FAQ では、翻案、二次的著作物ないし派生物に関する著作権法の解釈に加えて、GPL のライセンス文言を重視して考えます。
②同一の課題については、GPLv2 と GPLv3 を統一的に解釈します。FSF の解釈としては、バージョンによらず基本的な考え方は変わらないという建前をとっていますから、GPLv2についても GPLv3 についての現時点の考え方に従って解釈されるでしょう。
③FSF(Free Software Foundation)が著作権者であるか否かにかかわらず、FSF の公式見解や FAQ を尊重して、ライセンサーの合理的意思を解釈します。著作物の利用許諾においては、ライセンス条件を決定する権利は著作権者が持っています。しかし、FSF が著作権者である場合はもちろん、FSF が著作権者でない場合であっても、FAQ やその他の FSFの見解が、裁判においても参酌されて、ライセンス条件の解釈に影響すると考えられます
から、事実上これらに従って考えておくことが安全であると思われます。すなわち、企業が避けるべきリスクについて、OSS コミュニティとの係争事件の予防に重点を置くならば、FSF が採用する見解寄りでライセンス条件を解釈することが安全でしょう。

(2)単一の一個のプログラム
FSF の FAQ によると、「単なる集合物(collective works)」と「結合(combining)」との区別について、次のように述べています232。

Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL–if you can’t, or won’t, do that, you may not combine them.
二つのモジュールを結合するとは、それらを一緒に接続しそれらが単一のより大規模なプログラムを形成することを意味する。もし、いずれかの部分が GPL でカバーされていれば、結合物全体も GPL の下でリリースされねばならない。もし、あなたがそうできないとかしたくないなら、あなたは結合してはならない。

If the modules are included in the same executable file, they are definitely combined in one program.
モジュールが同じ実行ファイルに含まれている場合、それらは、言うまでもなく一つのプログラムに結合されている。

すなわち、2つのプログラムを結合して1つの大きなプログラムにする場合、一方が GPL なら全体も GPL にしなければなりませんが、同じ実行ファイルに含まれているなら単一のプログラムであるとしているので、GPL が伝搬しているといえます。したがって、静的リンクは、プログラム実行前のコンパイルまたはリンクされた段階で1つのものとなりますから、複数のプログラムが実行前の段階で結合していることは明らかであって、伝搬するものと考えられます234著作権法の解釈としても、GPL プログラムを複製し、自社開発プログラムと一体化して、一個プログラムとして合体してしまえば、複製物または著作権が及ぶ派生物(derivative works,
翻案して作成した二次的著作物)になる可能性が高いでしょう

(3)メモリ空間の共有
動的リンクおよび共有ライブラリは、プログラム実行時に共有メモリ空間上で、プログラムが実行される仕組みです。この点について GPLv3 第1条は、次のとおり、共有アドレス空間上で実行されるもの(動的リンクおよび共有ライブラリ)の場合、サブプログラムのソースコードを提供する必要があると規定しており、GPL が伝搬すると考えられます235

The “Corresponding Source” includes (中略)the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
コレスポンディング・ソース(提供を要求されるソースコード)には、サブプログラムと作品のその他の部分との間に親密なデータ交換またはコントロールフロー等により、作品が特定的に必要とするよう設計された共有ライブラリやダイナミックリンク・サブプログラムを含む。

f modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
もし、モジュールが共有アドレス空間でリンクされるなら、それはそれらのモジュールを1つのプログラムに結合していることを意味するのはほとんど確実である。

さらに、FAQ は、次のように規定しています236

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.
カバーされる作品と、別の分離・独立した作品(性質上カバーされた作品の拡張物ではなく、一個のより大きなプログラムとなるよう合体されていないもの)の編集物が一つのストレージまたは頒布媒体上にある場合、―もし、その編集物及び結果としての著作権が当該編集物のユーザのアクセス又は法的権利を当該独立した作品の許容する限度を超えて制限するために用いられてないなら、―「集合物」と称する。カバーされた作品を集合物に入れたとしても、本ライセンスを当該集合物の他の部分に適用させるものではない。

したがって、動的リンクは GPL が伝搬すると考えられます237。さらに、メモリ空間の共有については、GPLv3 の 5 条に次のような記述があります238。自社開発プログラムに GPL が適用されないように設計するためには、メモリ空間を共有しないことが一つの要件になるでしょう。

なお、FAQ には次のとおり規定されており、メイン関数を使うだけでは伝搬しないものと考えられます239。

If the program dynamically links plug-ins, but the communication between them is limited to invoking the `main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.
プログラムがプラグインと動的にリンクされていますが、それらの間のコミュニケーションはいくつかのオプションと共にプラグインのメイン関数を呼び出して返値を待つだけという場合は、限界事例でしょう。

(4)標準インターフェース
GPLv3 において、「標準インターフェース(Standard Interface)」とは、標準化団体として認知された組織によって定義された公式な標準か、ある特定のプログラミング言語向けに指定されたインターフェースの場合には、その言語を利用する開発者の間で広く使われているインターフェースのことを指すと定義されています。
自社開発プログラムを GPL プログラムと連係動作させるときに、標準インターフェースを介したというだけでは、伝搬しないとは判断できず、自由なプログラムと自由ではないプログラムとがそれぞれ独立を保った形で通信(communicate)し、それらが事実上単一のプログラムとなってしまうような方法で結合されていないことを確認する必要があります240。当該自社開発プログラムのみが動作可能なように特殊なインターフェースを作成して、自社開発プログラムをGPL プログラムと連係動作させる場合、全体として分離不能な一個のプログラムであると判断される可能性が高くなります241。

(5)コミュニケーションのメカニズム
コミュニケーションのメカニズムに関して、FAQ は、次のように規定しています242。

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).
私たちは、適切な基準はコミュニケーションのメカニズム(exec、パイプ、rpc、共有アドレス空間でのファンクションコール)とコミュニケーションのセマンティクス(どのような種類の情報が相互交換されるか)の両方によると考えている。

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.
これ(共有アドレス空間内のモジュールのリンク)と逆に、パイプ、ソケット及びコマンド引数は通常2つの別個のプログラム間で使われる通信手段である。よって、これらが通信のために使われるとき、モジュールは通常別個のプログラムである。

Plug-in もプログラムですが、GPL や FAQ において原則的には許されるというような記述はありません。FSF の FAQ によれば、“If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs・・・”と記載されており、プラグインを呼び出すために forkと exec を用いる場合は、GPL が伝搬しないということは明確に記載されています243。これによれば、自社開発プログラムから Fork コマンドによってプロセスの枠を作成し、別個のメモリ空間に存在する GPL プログラムを exec コマンドによって起動し、自社開発プログラムの処理はexec された GPL プログラムの処理結果に依存しないで、独立に処理可能である場合、この2つは別個のプログラムであって、伝搬しないと考えられます。
したがって、パイプ、ソケットおよびコマンドライン引数の場合は、原則として、自社開発プログラムは GPL プログラムとは別個のプログラムであり、伝搬しないものと考えられます。ただし、セマンティクスが親密である場合には伝搬するとされているので、注意を要します。

(6)セマンティクス
別個のプログラムが何のやり取りもしなければ伝搬することはありませんが、情報のやり取りをする場合には、原則として別のプログラムだとしても、その関係が密接になるために伝搬の対象に含まれるようになります。ただし、GPLv3 や FAQ などの関連文書は、一義的に明確な規定はしていません。FAQ の「コミュニケーションのメカニズム(exec、パイプ、rpc、共有アドレス空間でのファンクションコール)とコミュニケーションのセマンティクス(どのような種類の情報が相互交換されるか)の両方による」との記述があり、かつ、「複雑な内部データ構造を交換し、コミュニケーションの Semantics が親密である場合」という記述があります2

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.
しかし、複雑な内部データ構造を交換し、コミュニケーションのセマンティクス(Semantics)が親密である場合は、それらも2つの部分がより大規模なプログラムに結合されているという基準になり得ます。

コミュニケーションのメカニズムとセマンティクスが、伝搬性を判断する上で重要な要因であるものの、データ(構造)やコントロールフローが如何に複雑、密接、意味的に関連付けられているか否かについては、程度問題であって、裁判例もなく、GPL の条文や FSF の FAQ もどの程度かについて判断基準を提示していません。したがって、プログラム間のやり取りをできる限
り単純で少なくするほど安全であるとしかいえません。

(7)相互依存性
外観上一個の著作物で、2つのプログラムが一体不可分の有機的関係を持って結合した形態で、表現を分離抽出して論じられないもの(個別に利用することができないプログラム)は、全体として一個の著作物であると判断され、原著作物(GPL プログラムの著作権)と結合した自社開発プログラム全体が二次的著作物となる可能性があります245。
自社開発プログラムと GPL プログラムが相互に依存しており、結合した相手方のプログラムを特定的に必要とする場合には、GPL が自社開発プログラムに適用されるものと解釈される可能性が高いでしょう。この点について、GPLv3 第 1 条には、次のとおり規定されています246。

Corresponding Source includes ・・・dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
Corresponding Source(すなわち提供を要求されるソースコード)には、サブプログラムと作品のその他の部分との間に親密なデータ交換またはコントロールフロー等により、作品が特定的に必要とするよう設計されたダイナミックリンク・サブプログラムを含む。

さらに、GPL3 second draft footnote 20 によれば、容易に代替できるサブプログラムライブラリなどのソースは、Corresponding Source に含まれないとされており、代替可能なサブプログラムライブラリなどは、GPL プログラムと結合されていても直ちに伝搬するわけではないと考えられます。
したがって、自社開発プログラムから Fork コマンドによってプロセスの枠を作成し、別個のメモリ空間に存在する OSS を exec コマンドによって起動し、自社開発プログラムの処理は execされたプログラムの処理結果に依存しないで、独立に処理可能である場合、この 2 つは別個のプログラムであって、伝搬しないと考えられます。

5.API を介した連携動作 とは?

API とは、あるコンピュータプログラムの機能や管理するデータなどを、外部の他のプログラムから呼び出してプログラム同士を繋ぎ、その機能を利用するための手順やデータ形式などを定めたインターフースです。API は、仕様を定めたドキュメントという意味で使われることもありますが、ここでは仕様を実現するプログラムという意味で用います。
API を介して GPL プログラムを動作させる場合であっても、GPL プログラムを配布する以上は、著作物の利用になります。したがって、Linux kernel 以外の OSS プログラムについては、それぞれのプロラムの著作権者のライセンス条件によって伝搬性の判断が異なる可能性があり、自社開発プログラムに GPL が適用されない旨を明示的に表示していない場合には、GPL のライセンス条件に基づいて、GPL プログラムと連携動作する自社開発プログラムへの伝搬性を検討する必要があります。
API を介して、自社開発プログラムを GPL プログラムと連携動作させる場合、通常、メモリ空間は論理的に GPL プログラムとは異なるユーザ空間に存在しているものと考えられますが、通信のメカニズムやセマンティクスを分析して、上記の基準に沿って伝搬性を判断することになります。

6.Linux システムコールとは?

API のうち、特に、OS(Linux kernel)の機能をアプリケーションから呼び出してタスク(kernel に対して指示した処理)を実行するために使用される機構のことをシステムコール(System Call)といいます247。
Linux においては、Linux kernel の創作者である Linus Torvalds 氏によって、Linux の著作権は、通常のシステムコールによってカーネルのサービスを使用するユーザ・プログラムには及ばないと宣言しているため248、Linux 上で動作する自社開発プログラム(アプリケーション)が、kernel とは別のアドレス空間から、通常のシステムコールで kernel を利用する場合、その
アプリケーションに GPL が適用されない(伝搬しない)とされています249。

カーネルモジュールに関する GPLv2 の README ファイル冒頭の 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”. Also note that the GPL below is copyrighted
by the Free Software Foundation, but the instance of code that it refers to (the linux kernel) is copyrighted by me and others who actually wrote it. Linus Torvalds

法律的には、上記の NOTE は、GPL の適用を除外する例外条項(GPLv3 の「追加的許可条項」)ではなく、派生物に関する Linus Torvalds 氏の解釈ですから、伝搬しないという結論が裁判所に確実に採用されるという保証はありませんけれども、著作権者である contributors から特段の異議がない状態が継続していますので、Linux kernel の通常の用法としてコミュニティ
の多数派に許容されているものと推定されます。