AGPLライセンスのライブラリを組み込んだメインプログラムと、API通信でメインプログラムと通信するフロントプログラムを作り、エンドユーザがフロントプログラムにのみアクセスできる場合のライセンスの範囲

Question

AGPLライセンスのライブラリを組み込んだメインプログラムがAPサーバー上で動作している場合、
メインプログラムはAGPLライセンスですのでエンドユーザから開示要請があればソースコードを開示する必要があります。
![

しかし、メインプログラムが直接エンドユーザと通信をせず、仲介であるフロントプログラムを作り、
フロントプログラムがAPI通信等でメインプログラムと通信する場合(そして、メインプログラムがエンドユーザから直接アクセスできない場合)、
メインプログラムを利用するユーザーは「フロントプログラム」であり、フロントプログラムはメインプログラムを組み込んでいない為、AGPLライセンスでなくても良いことになり、エンドユーザはフロントプログラム、メインプログラムのソースを開示要請することはできないのではないかと考えています。

API通信でのシステム連携はよくあるものだと思いますが、API通信先がどういうライセンスであるかは通信元が把握できるものではないと考えています。
エンドユーザから問い合わせがある度、その通信先に確認をしなければならないのは現実的ではありません。
もし、エンドユーザがフロントプログラムに対し、メインプログラムのソースを開示してほしいと要請しても、フロントプログラムは開示する義務がないという考えであっていますでしょうか。

Answer 1

まず、はじめに、私は法律の専門家ではありません。
何ら法律的な保証はありませんので、一意見として参考程度にしていただくようお願いします。

AGPL13条には"all users interacting with it remotely through a computer network"とあります。
つまり、ネットワークを介して何かしら利用している全てのユーザーに対して、
AGPLに基づき、ソースを公開しなければなりません。
文言に直接や間接といった言葉は無いため、AGPL部分を間接的に利用していようが、
ネットワークを介している限り、ライセンスは適用されると考えられます。

よって、少なくとも"AGPL LIB"についてはソースを公開する必要があります。
(まったく改変していなければ、オリジナルへのリンクでもいいでしょうけど)

では、メインプログラムとフロントプログラムはどうなるかというと、
この問題は普通のGPLと似た問題になります。
つまり、ネット上にだけ公開ではなく、普通にプログラムをバイナリで配付したときと
同じ考えをする必要があります。
GPLなライブラリをリンクして使用する場合、静的動的を問わず、グレーです。
一般的には、代替のライブラリが存在するか、APIが一般に公開されている物で、
そのAPIのみを使用しているのであれば、GPLに汚染されないと考えられています。
(ただ、これも確実では無い事に注意して下さい。
Wikipediaにあるように、見解は分かれています。)
ただ、AGPLは、実際に動作している環境でライセンス適用となるため、
代替が存在するとは言いにくく、メインプログラムにもAGPLが
適用される可能性が高いと思います。

次にフロントプログラムですが、これも考え方は一緒でいいと思います。
その通信が一般的で、代替が存在するかどうかです。
たとえば、フロンプログラムが一般的なリバースプロキシのような物であった場合は、
AGPLの適用が求められることはないでしょう。
もし、そんな物まで求められたら、AGPLで動作するアプリを
商用の負荷分散装置の下に置くことができなくなってしまいます。
しかし、一般的なHTTP等を使用していても、そのAPIが専用の物で、
メインプログラムとセットとして作られていた物であったら、この解釈は無理かと思います。
なぜなら、フロントプログラムとメインプログラムをセットに
一つのプログラム(著作物)と見なされる可能性が高いからです。
少なくとも、APIについての詳細を一般に公開し、第三者が代替を作れる環境にしなければ、
別のプログラムであるという主張は難しいでしょう。

実際に商用で利用される場合は、専門の法律家に相談することをお勧めします。
ただ、日本では判例がないため、難しい判断になるかも知れません。
(そもそも、日本でGPLが有効かどうかの判例もなかったかと思います)
また、AGPLの精神に基づくならば、すべてのソースを公開することをお勧めします。
たとえ訴訟で勝利したとしても、OSSコミュニティーを敵に回すことになりますので、
会社にとってはマイナスイメージの方が大きくなるでしょう。

Comments

[anonymouskawa]

ありがとうございます。
現段階で私自信がAGPLライセンスのライブラリを使用する計画はありませんが、
他社のAPIサービスを利用して、図で言う「フロントプログラム」を作成した場合、
万が一そのAPIがAGPLライブラリを利用していたらと思うとぞっとする話になるのではと疑問に思ったことと、
もしAPIであれば可という状態であるならば、自分たちのプログラムの構成をAPI通信にすればAGPL汚染は防げるのか？とさらなる疑問が生まれたのが発端です。

業務で開発するのであれば、GPL、AGPLライセンスのライブラリには触らない方が良さそうですね。

Answer 2

通常のインターネットアクセスでも大抵の場合はブラウザ等のクライアントアプリケーションを利用していませんか？そういう意味でAPIアクセスの場合と差はありません。AGPLはネットワークを経由してプログラムの利用があるユーザーに対してソースコードを開示するライセンスです。そのため、どちらの場合でも正規のユーザーであればコードを開示しなければなりません。

ソースコードを開示するのは「正規のユーザー」であり、無作為に開示するわけではありません。詳しくは参考リンクを見てください。

参考: 漢(オトコ)のコンピューター道 - 受託開発とGPL

Comments

[anonymouskawa]

ありがとうございます。参考サイトはすでに確認済みでした。
クライアントアプリケーションに開示の義務はないことも理解しています。そうでなければ、IEを含む全てのインターネットブラウザはソース開示しなければなりません。
しかし、図に記載した通り、「フロントプログラム」がサーバー上のクライアントとなっている場合、フロントプログラムはメインプログラムに対して開示要求ができますが、
エンドユーザがメインプログラム、フロントプログラムに対し開示要求ができるのかという問題になります。
もし、単なる「HTTP通信」でメインとフロントが連携していた場合、ライブラリの読込がない、GPLでは「グレー」とされるものになります。

何が正解かわからない以上、GPL、AGPLの使用は避けたほうが良さそうですね。

[退会済みユーザー]

> フロントプログラムはメインプログラムに対して開示要求ができます
エンドユーザーがメインプログラムに対して開示請求ができるだけで、フロントプログラムは関係ありません。フロントプログラムが許諾するライセンスは、フロントプログラムの開発元がエンドユーザーに利用を許諾する時に決める話です。もし「フロントプログラム」のソースコード開示が必要だとしたら、それこそAGPLv3のサービスを使うとIEのコードを開示しなければならない、みたいな変な話になってしまいませんか？

ところで参考になるかはわかりませんが、任天堂の製品でGPL等のライセンスに関わる部分のソースコードが公開されています。
http://www.nintendo.co.jp/support/oss/

ここでWiiの全てのコードが公開されているか、と言えばそんなことはありません。また、Wii Sport等のゲームソフトのコード全体が公開されているか、というとそれもありません。どんなものが公開されているか、というと、WiiのブラウザにはWebKitが使われているので、WebKitに手を入れた部分が公開されていたり、マリオカート8だとGCCに手を入れたのか、GCCのコードが公開されていたりします。

任天堂製品の場合、利用者からの開示請求に答えるコストを考えるとWebに一般公開した方がコストがかからないので、このような選択をしているのでしょう。が、一般的には「正規の利用許諾を受けたエンドユーザー」のみにソースコードの開示請求に応えれば十分です。