動的リンク時のGPLライセンス
あるプログラムAはGPLライセンスではないとします。
そして「A用に作られた」プラグインBはGPLであるプログラムCを使用するため、GPLライセンスであるとします。
なお、両プログラムAとプラグインBの作者は同じですが、プログラムAとプラグインBは(同じサイト上ではあるものの)同時配布されるわけではないとします。
原文ではないものの、WikiにGPLに関しての説明があります。
http://ja.wikipedia.org/wiki/GNU_General_Public_License
この中で、動的リンク時の問題にも触れられています。
私が読んだ限りでは「明文化されているわけでも、法的に明らかでもないが、動的リンクをするプログラムにもGPLが派生すると言うような習慣になっている。」と見受けられます。
もし「プログラムAがプラグインBを前提としている」場合は、プログラムAはGPLであるべきである思っています。
しかし「プログラムAはプラグインBがなかったとしても正常に動作するものであって、プラグインBが提供する機能以外は正常に使え、かつそれ以外の機能というものが存在している」場合はどうなるのでしょうか？
極端な話「Windows上で動くWindows拡張用DLLがGPLライセンスのとき、WindowsはGPLライセンスであるべきなのか？」といわれたら、そうではないと思います。
しかしながら「Windowsが、Windows上で動くGPLライセンスのWindows拡張用DLLの使用を前提としている」のなら、WindowsはGPLであるべきだと思います。
要するに派生関係によってライセンスが変わるので、
「Bの上でAが動く」なら「AはGPL」
「Aの上でBが動く」なら「AはGPLではない」
と解釈しています。
＜質問１＞プログラムAとプラグインBが同じ作者によるものであっても、「Aの上でBが動く」なら「AはGPLではない」という論理は正しいといえるのでしょうか？
＜質問２＞仮にプログラムAがプラグインBの影響でGPLになったとした場合、その他のプラグインEはGPLであるべきということになってしまうのでしょうか？
以上、よろしくお願いします。
投稿日時 - 2007-10-20 19:21:45
質問者が選んだベストアンサー
えと、とりあえず、
RubyインタプリタそのものはGPLとRuby'sライセンスのデュアルライセンスです。
正規表現の関数が収められている regex.c/regex.h の扱いに注意する必要はありますが(これらは LGPLのみ)、
それに関しても鬼車を組み込むことで(Ruby本体に数行の修正が必要です)、
GPLから解放されることは可能です。
LICENSE.txtというファイルに(英語で)書かれてますのでどうぞ。
実際、RPGツクールxp(ちょっとタイトル違うかも)というアプリケーションは
そのようにしてRubyインタプリタ(の改造版)を組み込んだものですが、
ソースは公開されておらず(したがってGPLにしたがってはいない)、
クローズドなものです。
>>ですので BSDライセンスで配布されているものであれば、
>>non-free ということはないのではないでしょうか。
>
>とすると、BSDなプログラムAに対してGPLなプラグインBを作成＆公開でき
>る可能性があるとお考えなのでしょうか？
>BSDにすると感染が止まるというのも何か不思議な感じがしますが、もし>これが可能ならば朗報なのですが。
こっちはディスコミュニケーションが発生している気配ありありなので
ちと時間をおきます。
とりあえずBSDにすると感染が止まるとという表現の意味するところが
よく読み取れませんので即答はしません(できません)。
一応最終的な目標をおききしますが、
・Rubyインタプリタを組み込んだアプリを作りたい
・アプリのユーザーが自由にプラグインを作れるような仕掛けにしておきたい
・プラグインの作者に対してGPL縛り(特にソースコードの公開)を押し付けたくはない
ということでよろしいですか?
投稿日時 - 2007-10-25 01:46:45
> Ruby・・・GPLから解放されることは可能です。
なるほど、non-GPLedにできるのですね。
選択の一つとしてありえますね。
非常に参考になります。
> こっちはディスコミュニケーションが・・・
ぼんやりとしたイメージで書き込んだので、混乱させて申し訳ないです。
------------------------------------
目標は
（１）プログラムAを公開したい
（２）プラグインEの作者に対してGPL縛り(特にソースコードの公開)を押し付けたくはない
（３）Rubyを使ったプラグインBを提供したい(Rubyを使ったプログラムAのスクリプト制御などの機能を提供するため。たのプラグインEはこの機能は使わない。)
以上の３つの目的を両立させたい。
-------------------------------------
そこで私は当初、Dynamic Link＆別配布されるとはいえ、GPLなプラグインBを提供することで、プログラムAにGPLが感染すると思っていました。そしてAに感染するとプラグインEにも感染するはずで、それを危惧していたわけです。つまり「B->A->EというGPLの伝搬」が起こると誤解していました。
しかし、よくよく考えれば、プログラムA用に後から”プラグインBが提供されるのであって、プログラムAのライセンスがGPL化されることはあり得ません。考え方が逆で「non-freeなプログラムAに対してGPLedなプラグインBを提供できない。」が正解でした。つまり「Bを提供するためには、AをBSD（など）にすればよい」ということになりました。
ここでさらに私が誤解して「B->A->EというGPLの伝搬」が起こると思っていたのに「AをBSDにしたことで止まった」と思ってしまったわけです。実際にはプラグインEがBの機能を使用しない限り、Aにのみ依存しているので、感染しなくなったにすぎません。
またプラグインBの機能をつかったRubyスクリプト(or Rubyプラグイン)はインタープリタに対する入力であるので、GPL化しません。
http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
結局、上記の目標を達成するには、以下の打開策が考えられます。
(１)Rubyのnon-GPLed化
(２)Aのnon-copyleftなGPL適合ライセンス化
打開策１も２もどちらもそれなりに容易にできそうな気がします。
よって、問題は解決されました！
長いこと質問にお付き合いいただいてありがとうございました。
#数日以内に回答を締め切らせていただきます。
投稿日時 - 2007-10-26 19:06:55
このQ&Aは役に立ちましたか?
0人が「このQ&Aが役に立った」と投票しています
回答（3）
> (ひとつ誤解があるようですが、Aが非GPLで、BがGPLという状況です。
> どちらでも同じようなものですが、話の展開で混乱を招く恐れがありますので。)
あ、すみません。
ちょっと読み違えてました。
> 若干気になるのは「non-freeというのはどういう意味なのか？」ですが、
> もし「GPL適合なライセンスではない」ということならBSDかなにかでAが公開されてたらいいということになるのでしょうか？
> あえてnon-GPLedではなくnon-freeと書いているのか・・。
えー、彼らのいうFree Softwareではないということだと思います。
このFree Softwareとはなんじゃいという話になるのですが、
これまた彼らの言を借りれば、四つの「自由」が保証されているソフトウェアです。
Richard Stallman インタビュー - GNUな生活
http://d.hatena.ne.jp/akirashibata/20051223
| Freedom 0 は、自分の好きなようにソフトウェアを使う自由。
| Freedom 1 は、そのソースコードを読んで、自分の好きなように変更する自由。 | Freedom 2 は、好きなようにそのソフトをコピーして配布する自由。
| そしてFreedom 3は、自分の変更したバージョンを配布することが出来る自由。
GPLはこれらの自由を保証するものですが、
GPL以外にもこのようなライセンスはあるので
nonGPLed ではなく、non-freeという表記をしているのだと思います。
ですので BSDライセンスで配布されているものであれば、
non-free ということはないのではないでしょうか。
>どちらにせよ、ややこしそうですので、GPLなプログラムCは使わないよう努力することにします。
> (無理ならプラグインBのリリースをやめる。)
何かの理由でGPLの要求する項目をクリアできないのであれば、
使うのは避けたほうが良いでしょうね。
もしプログラムCの作者にコンタクトが取れるなら、
自分に対して別途配布規定を定めてもらうという手段がとれなくもありませんが。
投稿日時 - 2007-10-23 17:43:25
>もしプログラムCの作者にコンタクトが・・・・
実はプログラムCというのはRubyのインタプリタです。
RubyはGPLedなライブラリを多数使用している様なので、
おそらくは無理ではないかと思います。
> 何かの理由でGPLの要求する項目をクリアできないのであれば、
プログラムAを公開したいと考えているのですが、GPLだと(もし運良く作ってくださる人が現れたとして)プラグイン製作者にソースコードの開示を強制してしまうことになります。それは避けれるなら避けたいなぁと思った次第でして。それでも全然かまわないという人はいるでしょうが、そうでない人も多いと思いますし。
またRuby以外の言語でもかまわないのですが、どうせならRubyを使ってみたかったのです。
>ですので BSDライセンスで配布されているものであれば、
>non-free ということはないのではないでしょうか。
とすると、BSDなプログラムAに対してGPLなプラグインBを作成＆公開できる可能性があるとお考えなのでしょうか？
BSDにすると感染が止まるというのも何か不思議な感じがしますが、もしこれが可能ならば朗報なのですが。
ちょっと、このあたり、もう少し調べてみます。
投稿日時 - 2007-10-24 21:19:23
質問1について。
FSFの見解についてはFAQにあるそのままだと思います。
http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF
http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins
#日本語訳が存在しているかどうかは知りません
GNU GPLライセンスのソフトウェアAと、非GPLのプラグインBとを
「同一の配布パッケージ」として配布することは少なくともできないでしょう(配布パッケージのライセンスを(互換性のあるライセンスを含めた)GPLにも
できないし、非GPLにもできないので)。
質問の例では同時に配布するものではないということなので、このパターンでは
ないと思われますが、プラグインBがなくてもソフトウェアAが動作しうるのであれば
Bのような非GPLのプラグインを「別途配布」することに関しては
ソフトウェアAの作者がそのプラグインを作る場合もOKだと思います。
ただ、プラグインBがない状態での動作を「機能制限」と見るのなら
ちょっと危ないかもしれませんね。
質問2の方は想定している状況が良くわかりません。
ある人が開発・配布している非GPLソフトウェア用のプラグインを
別の人がGPL下で「作成した場合に」その非GPLソフトウェアが自動的に
GPLで配布しなければならないとかとお考えですか?
なお以上はわたしの意見ですので、どこかでコンセンサスが取れたとか
統一見解として存在しているものではないことをお断りしておきます。
ところで、Wikipdeiaの略称として'Wiki'を使うのは止めてほしい今日この頃。
投稿日時 - 2007-10-21 11:31:53
回答ありがとうございます。
>質問1について。
>FSFの見解についてはFAQにあるそのままだと思います。
(ひとつ誤解があるようですが、Aが非GPLで、BがGPLという状況です。どちらでも同じようなものですが、話の展開で混乱を招く恐れがありますので。)
URL大変参考になりました。
付帯事項をつければプラグインBをA用にリリースできるということみたいですね。
しかし、今回の場合BがGPLとなったのは別のプログラムCを使用するからであって、Cにその様な付帯事項が付いているかどうかがカギになりそうです。
そうでない場合は、GPLに法的に反すると（少なくとも）FSFは主張しているようですね。
若干気になるのは「non-freeというのはどういう意味なのか？」ですが、もし「GPL適合なライセンスではない」ということならBSDかなにかでAが公開されてたらいいということになるのでしょうか？
あえてnon-GPLedではなくnon-freeと書いているのか・・。
どちらにせよ、ややこしそうですので、GPLなプログラムCは使わないよう努力することにします。
(無理ならプラグインBのリリースをやめる。)
----------------------------------------------------
質問２に関してはGPLなプラグインBが出現することを想定して、プログラムAをGPLにした場合、その他のプラグインEはGPLであるべきか？という意味ですが、考えてみれば当然ですね。FAQにも、まさにどんぴしゃなものがありました。
http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
投稿日時 - 2007-10-23 16:42:09
