GPLについて以前、以下のような質問をしました。

FSFはLindowsに尋ねました、「ソースはどこにある?」

もうちょっと、しっかりとしたソースを探したのですが、ちょっと見つからなかったので、とりあえず、上記ページでは、特定の相手への納品が「頒布」に該当するだろう、ということが書かれています。

このコメントの最後の方に、「もし、特定の相手への提供が頒布に当たらないとしたら」という考察が興味深いです。

「EC-CUBEのライセンスについて」を確認しましたが、「『（特定の相手のみへの）納品』の場合でもソースコードを公開せよ、さもなくばライセンスを買え」とは読み取れませんでした。

私は単に「GPLにしたがえ」と書いてあると読んだのですが、REMsuiminさんは、どういう観点から、配布（特定の相手への納品）の場合でもソースコードを公開せよと読み取ったのでしょうか。

たしかに、「ライセンス選択フローチャート」の部分で、「配布の場合」かつ「ソースコードを公開したくない」場合に「商用ライセンスの購入が必要です」となっているので、この部分はGPLと矛盾するような気もします。ただ、「上記ケースで本当にGPLライセンスの規定に従っているかの判断は裁判所に委ねられます」とも記されているので、幅を持った解釈ができます。

EC-CUBE側としては、改変したプログラムをパッケージやダウンロード販売など、広く流通に乗せることを想定しているのではないでしょうか。

原則論になりますが、GPLの規定がどうあれ、オープンソースのバグに関するリスクを回避する観点から、改変ソースは公開する（ソースに関する責任を顧客側にヘッジする）方が良いと思います。

プログラムの公開方法として一番事例が多く一番簡単なのが「誰でもダウンロード出来るようにする」なので、GPLに基づいてソース公開＝ソースを誰でもダウンロード出来るようにすること、と勘違いされやすいですが正しくは「プログラム(実行ファイル)を持ってる人にソースを公開しなければならない」です。

なので質問のケースでは、納品先に改変したソースを公開する体制があれば良く、相変わらず第3者への公開義務はありません。

あくまでも、体裁をどう整えるか、という話と割り切ればいいんじゃないかと思います。

・顧客との契約形態を、「アプリケーションの開発・販売・配布」ではなく、「役務(サービス)

の提供」とする。

・サイトからのソースのダウンロードは、顧客からの指示によって、（以下は場合によって。

「顧客の会社内で」、「顧客のPCを使って」）行われる作業である。

・改変したソースの所有者は、顧客である。

「契約形態～」については、顧客との相互信頼関係が必要になる話ですので、顧客には、

それなりの事情説明（パッケージを必要とする背景、パッケージベンダの条件など）が

必要にはなりますが。

> ただし、この場合、提供するソフトウェアにも、GPLライセンスを適用する必要があります。

↑上記の一文により、「ソースコードを公開したくない（GPLを適用したくない）のならばライセンスを買え」と言っているように私は解釈しました。

なるほど。

しかし、ソースコードを公開するかどうかは GPL の解釈の仕方によります。GPL を読んで、不特定多数への「頒布」ではないのだからソースコード公開は不要という解釈も成り立ちますから（後述するようにグレーではありますが）、商用ライセンスを購入する必要はないでしょう。

ネットで使うスクリプトなどのように、コンパイルをせずにもともとソースコードが丸見えになっているソフトウェアにおいてはGPLの考え方は馴染まない気がしますが、その辺りはいかがでしょうか。

私は GNU 設立当初から、そのツール群のお世話になっている人間の一人です。

GPL の変遷を見ていると、たぶん、すべてのソースコードを百科事典のような人類の知的財産として共有したいという思いに基づいて記述されているのだと感じます。彼らは、改変を加えた部分にも新たな知的価値を与え、積極的に公開していって欲しいと願っているようです。

対象となるプログラムがバイナリであってもスクリプトであっても、基本的な思想は同じだと思います。

一方で、ソフトウェア開発ビジネスは知識／情報を独占することによって成り立っています。この意味で、GPL を開発ビジネスに導入するのは、とても勇気が要ることです。

法文の解釈は、グレーであればクロと見なした方がリスクが低いというのが王道ですので、あえてリスクを冒してまで GPL を利用するのは勇気が要ります。

もし私が EC-CUBE を利用しなければならない立場でしたら、迷わず商用ライセンスを購入するでしょう。

実際、私が仕事でオープンソースを利用する場合、商用ライセンスがあるものしか採用しません。GPLで仕事をしたことは、一度もありません。

もしGPLを採用して訴えられた場合――訴訟というのはどんなに小さいものでも数百万円オーダーの損失が出ますので、商用ライセンスを購入した方がリスクが低いと考えています。

おそらく、前回の解答自体に間違いがあるのではないかと思います。

http://www.gnu.org/licenses/gpl.html

GPLの原文を見ると、修正を施したプログラムについて書かれている箇所（セクション5）で使われている単語はconveyで意味は「譲渡する」です。従って、「不特定多数に対するものかどうか」は関係ありません。

v2では「copy and distribute」と言う表現が見えますから、v3で誤解のないように改められたものと思われます。

（http://www.itmedia.co.jp/enterprise/articles/0609/01/news011_3.h... でv2の問題についてそのように言及されています。）

v2については次の記述（第8項）がそのまま当てはまるものと思われます。

http://www.itmedia.co.jp/enterprise/articles/0609/01/news011_2.h...

これによると、ソースコードは要求があれば誰にでも公開しなければならないようです。

但し、この項目は「copy and distribute」「convey」しない限り発効しませんから、「プログラムの提供でなくサービスの提供」とする形なら公開の必要はないようです。

http://www.ec-cube.net/license/business.php

上のページで「ASPなら必要がない」と書かれているのはこのため（譲渡が発生しない）からでしょう。

ちなみに、もしもFSFから訴訟がある場合は最初に改善の要求があるらしいです。

前回の質問では、EC-CUBE側の背景を十分理解しない状態で回答しました。

今回の回答「４．」は、領布の定義に抵触しないで解決する方法を提案しました。

結果的に、いずれも質問者の方の意に沿うものではなかったようですね。

その後、GPLの定義などを再度見返してみて、以下のような記述にたどりつきました。

（以下GPLのFAQより）

http://www.gnu.org/licenses/gpl-faq.html#TOCDevelopChangesUnderN...

http://www.gnu.org/licenses/gpl-faq.ja.html#DevelopChangesUnderN...

この中の

「あなたはクライアントに対して自分の改変した点をGPLの下で公開し、

しかしそれらをクライアントがOKと言うまで他の人には公開しないという

ことに合意することもできます。」

という記述が、今回のような場合にあてはまるものと思います。