アカウント名:
パスワード:
GPL の dll をクローズドからリンクする場合と、逆にクローズドの dll を GPL コードからリンクする場合、それぞれのライセンスの波及のしかたについてどなたか詳しい方教えていただけないでしょうか?
少なくとも前者に
GPL互換ライブラリをつっこむことが可能なのはソフトウェア配布者だけなのでは?
乗っ取ろうとした人間本人が後付けで GPL ライブラリをつけて配布したとしても、ライセンス違反を問われるのはそいつだけなのだし
GPL プラグインを同梱した二次配布者(==第三者)がライセンス違反に問われると思います。しかしあくまで一次配布者には責任は及びません。
二次配布者が GPL プラグインを同梱して配布することを想定するのであれば、作者はそのソフトウェアのライセンスに GPL 互換ライセンスを採用するべきでしょう。 逆に GPL のプラグインを使
>ライブラリのライセンスに例外がちゃんと記述されてなければ後づけのライブラリ開発者がライセンス違反ですね。
ライブラリ開発者が違反してるライセンスというのはきっと無くて、例外に書き忘れた呼び出し元ソフトがGPLでないと矛盾してるようなライセンスをライブラリに付けてしまった、ということですね。で、この場合のGPLはライセンスとして無効で、そのライブラリがGPLでないものとして(著作権法等に反しない範囲で)勝手に使われても文句言えない?
>で、ふと思ったのですが既存のライブラリが後からGPLになったケースや、ソースコードレベルで複数のOS間で互換性があるがそのうち一部のOSのみがGPLなライブラリを使用するケースでソースコードのみを非GPLなライセンスで配布した場合はGPLはどう適用されるんでしょう?
というわけで前者は勝手に使われるかも。後者は問題の所在がわかりませんでした。すみません。
それは違うでしょう。
GPL でライブラリを配布している人がいたとします。 そのライブラリを非 GPL 互換のソフトウェアにリンクして、一緒に二次配布した人がいた場合、二次配布者は元の配布者に GPL 違反を問われます。
しかし、あるライブラリ単体を配布した人が、配布後にそのライブラリを呼び出すかもしれない全てのソフトウェアのライセンスについて保証をすることは不可能です。既に存在する GPL のライブラリに対して、俺様のライセンスからは利用できないから GPL は無効だ、とは言えないはずです。その GPL ライブラリが GPL ソフトウェ
実行形式が実行されるオペレーティングシステムの主要なコンポーネント (コンパイラやカーネル等)を除いて単体配布できないから、 そういうライブラリやプラグインはGPLで配布できないとか、例外を規定する 必要があるとか、LGPLやRuntime GPLを使うとか、 という提案がされてきたのが、 この話題の主要な流れのひとつであったと思います。 この例外についても、もともと曖昧であった上に、 技術の高度化・多様化でますます訳がわからなくなっている、 という主張も多く見られました。
一方貴方のように、インタフェイス依存にすぎないから 単体配布可能とする主張もいくつかありました。 こちらの方が曖昧な点が少ないし、心情的には支持したいのですが、 各々単体で配布されているソフトを一ヶ所に集めることさえできれば、 ユーザにとっては同じコトになってしまいますね。 仮にそのような行為自体が不当だとしても、防御は困難でしょう。
>実行形式が実行されるオペレーティングシステムの主要なコン >ポーネント (コンパイラやカーネル等)を除いて単体配布できな >いから、そういうライブラリやプラグインはGPLで配布できないとか、
ここの意味がよくわかりませんでした。
>各々単体で配布されているソフトを一ヶ所に集めることさえでき >れば、ユーザにとっては同じコトになってしまいますね。仮にそ >のような行為自体が不当だとしても、防御は困難でしょう。
ライセンスが噛み合わないプラグインや親ソフトを集めて再配布してしまったら、それはふつうに
>ここの意味がよくわかりませんでした。
ここはGPLと他のコメントの部分引用です。リンクは大変なのでご勘弁を。
>それとも再配布をしないエンドユーザーの行為を問題にしているのでしょうか。
その意味で書きました。
例外を除いて、関連するインターフェース定義ファイルのすべてとライブラリのコンパイルやインストールを制御するために使われるスクリプトをも加えたものを含まないといけない、とGPLに書いてあるわけです。 それがないとコンパイルできない、ということのほかに、「このソースの任意の追加や書き換えを許すから、そのかわり出来たものもGPLにしてね」という約束をもとにGPLワールドを単調拡大させていく、というGPLの目的が、ライブラリ等の形態を介することで止まらないようにしていると思われます。 それなのに、単体配布物を集めてコンパイルすればGPLと非GPLを混ぜて使える、ということが知れ渡ったら、そもそもGPLの意味がない、と。
>slashdot のトピックは数日で流れてしまいますので残念ながらこのへんでキリになってしまいそうですが。 議論の蓄積できる場所があればいいのにね・・・
引きずりすぎないからこそ新しい話題に対応できるのも確かですから。 アーカイブは残るので、いつか新しいタレコミの中で、いいタイミングで蒸し返してください。
>普通のDLLをGPLで公開するのはアリなのに
dll なら アリってわけではないと思いますが・・・
ただ、GPL な plugin のみを単体で配布することは可能ではないかと。 plugin が依存するのは親プログラムではなくインターフェイスそのものなのだから。
つまり非GPLなアプリのPluginをGPLで作った場合はどうなるのかということです。 ramsy さんの説明通りなら、動的リンクされる側を先に作ろうが後に作ろうが同一の見解になりますが、FSFの例をあてはめるべきとなると利用するI/F用のDLLが複数あった場合にその中に一つでもGPL
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
dll (スコア:0)
GPL の dll をクローズドからリンクする場合と、逆にクローズドの dll を GPL コードからリンクする場合、それぞれのライセンスの波及のしかたについてどなたか詳しい方教えていただけないでしょうか?
少なくとも前者に
Re:dll (スコア:2, 参考になる)
ただし、DLLを動的ローディングする限りにおいては適用外です。(GPL source codeを使わなくてもAPIで呼び出せるので)
windows においてDLLを使う方法には2種類あって、
# rm -rf ./.
Re:dll (スコア:0)
ダウト。少なくとも FSF はそれもダメだと言ってます。
ほれ [gnu.org]
> .dllをロードするAPIを叩いて自分のコードポイントに取り込む(動的ローディング)
> .dllと対になる.libをリンクし、コードの方でヘッダファイルをインクルードする(静的ローディング)
もしかしたらそういう言葉の定義の仕方もあるのかもしれませんが、
普通はこれらは両方とも動的ローディングと呼びます。
両者を区別する場合、前者は動的バインディング動的ローディング、
後者は静的バインディング動的ローディングといいます。
静的ローディングは、libfoo.a をリンクするような場合を指します。
# 「ローディング」は「リンキング」とも言います。
# 歴史的事情から、注釈ない場合には「ローダ」が「リンカ」と
# 等価なのと同様。
このFSFの例では (スコア:2, 参考になる)
つまり非GPLなアプリのPluginをGPLで作った場合はどうなるのかということです。
ramsy さんの説明通りなら、動的リンクされる側を先に作ろうが後に作ろうが同一の見解になりますが、FSFの例をあてはめるべきとなると利用するI/F用のDLLが複数あった場合にその中に一つでもGPLなものがあると呼び出し元もソース公開の義務を負いかねないという解釈になってしまいますが。
このFSFの例ではプロセスを形成しているメインの機能がGPLライセンスのものであり、その延長上にPluginが位置する事からGPLであるべきと言っているだけでGPLなDLLを動的ローディングする限りにおいては適用外だという解釈は間違っていないと思います。
Re:このFSFの例では (スコア:2, 参考になる)
動作するためにGPLなDLLが必須ならGPLの影響を受けると思いたい。
そうじゃないとあとづけでGPLな互換ライブラリをつっこむだけでGPLで乗っ取れてしまう。
このへんのことちゃんとしておかないとGPLは公序良俗に反するけしからんライセンスと攻撃されてもしかたないんじゃなかろうか
Re:このFSFの例では (スコア:0)
GPL互換ライブラリをつっこむことが可能なのはソフトウェア配布者だけなのでは?
乗っ取ろうとした人間本人が後付けで GPL ライブラリをつけて配布したとしても、ライセンス違反を問われるのはそいつだけなのだし
Re:このFSFの例では (スコア:1)
ライブラリのライセンスに例外がちゃんと記述されてなければ後づけのライブラリ開発者がライセンス違反ですね。
で、ふと思ったのですが既存のライブラリが後からGPLになったケースや、ソースコードレベルで複数のOS間で互換性があるがそのうち一部のOSのみがGPLなライブラリを使用するケースでソースコードのみを非GPLなライセンスで配布した場合はGPLはどう適用されるんでしょう?
Re:このFSFの例では (スコア:0)
第三者がGPLなプラグインを同梱して配布した場合はどうなるのでしょう?
この場合もGPL感染するのならば、
プログラムの作者は配布形態に関するライセンスに注意しなければいけませんね。
Re:このFSFの例では (スコア:0)
GPL プラグインを同梱した二次配布者(==第三者)がライセンス違反に問われると思います。しかしあくまで一次配布者には責任は及びません。
二次配布者が GPL プラグインを同梱して配布することを想定するのであれば、作者はそのソフトウェアのライセンスに GPL 互換ライセンスを採用するべきでしょう。 逆に GPL のプラグインを使
Re:このFSFの例では (スコア:1)
>ライブラリのライセンスに例外がちゃんと記述されてなければ後づけのライブラリ開発者がライセンス違反ですね。
ライブラリ開発者が違反してるライセンスというのはきっと無くて、例外に書き忘れた呼び出し元ソフトがGPLでないと矛盾してるようなライセンスをライブラリに付けてしまった、ということですね。で、この場合のGPLはライセンスとして無効で、そのライブラリがGPLでないものとして(著作権法等に反しない範囲で)勝手に使われても文句言えない?
>で、ふと思ったのですが既存のライブラリが後からGPLになったケースや、ソースコードレベルで複数のOS間で互換性があるがそのうち一部のOSのみがGPLなライブラリを使用するケースでソースコードのみを非GPLなライセンスで配布した場合はGPLはどう適用されるんでしょう?
というわけで前者は勝手に使われるかも。後者は問題の所在がわかりませんでした。すみません。
Re:このFSFの例では (スコア:0)
それは違うでしょう。
GPL でライブラリを配布している人がいたとします。 そのライブラリを非 GPL 互換のソフトウェアにリンクして、一緒に二次配布した人がいた場合、二次配布者は元の配布者に GPL 違反を問われます。
しかし、あるライブラリ単体を配布した人が、配布後にそのライブラリを呼び出すかもしれない全てのソフトウェアのライセンスについて保証をすることは不可能です。既に存在する GPL のライブラリに対して、俺様のライセンスからは利用できないから GPL は無効だ、とは言えないはずです。その GPL ライブラリが GPL ソフトウェ
リンク & GPL おさらい (スコア:1)
実行形式が実行されるオペレーティングシステムの主要なコンポーネント (コンパイラやカーネル等)を除いて単体配布できないから、 そういうライブラリやプラグインはGPLで配布できないとか、例外を規定する 必要があるとか、LGPLやRuntime GPLを使うとか、 という提案がされてきたのが、 この話題の主要な流れのひとつであったと思います。 この例外についても、もともと曖昧であった上に、 技術の高度化・多様化でますます訳がわからなくなっている、 という主張も多く見られました。
一方貴方のように、インタフェイス依存にすぎないから 単体配布可能とする主張もいくつかありました。 こちらの方が曖昧な点が少ないし、心情的には支持したいのですが、 各々単体で配布されているソフトを一ヶ所に集めることさえできれば、 ユーザにとっては同じコトになってしまいますね。 仮にそのような行為自体が不当だとしても、防御は困難でしょう。
Re:リンク & GPL おさらい (スコア:0)
>実行形式が実行されるオペレーティングシステムの主要なコン
>ポーネント (コンパイラやカーネル等)を除いて単体配布できな
>いから、そういうライブラリやプラグインはGPLで配布できないとか、
ここの意味がよくわかりませんでした。
>各々単体で配布されているソフトを一ヶ所に集めることさえでき
>れば、ユーザにとっては同じコトになってしまいますね。仮にそ
>のような行為自体が不当だとしても、防御は困難でしょう。
ライセンスが噛み合わないプラグインや親ソフトを集めて再配布してしまったら、それはふつうに
Re: リンク & GPL おさらい (スコア:1)
>ここの意味がよくわかりませんでした。
ここはGPLと他のコメントの部分引用です。リンクは大変なのでご勘弁を。
>それとも再配布をしないエンドユーザーの行為を問題にしているのでしょうか。
その意味で書きました。
例外を除いて、関連するインターフェース定義ファイルのすべてとライブラリのコンパイルやインストールを制御するために使われるスクリプトをも加えたものを含まないといけない、とGPLに書いてあるわけです。 それがないとコンパイルできない、ということのほかに、「このソースの任意の追加や書き換えを許すから、そのかわり出来たものもGPLにしてね」という約束をもとにGPLワールドを単調拡大させていく、というGPLの目的が、ライブラリ等の形態を介することで止まらないようにしていると思われます。 それなのに、単体配布物を集めてコンパイルすればGPLと非GPLを混ぜて使える、ということが知れ渡ったら、そもそもGPLの意味がない、と。
>slashdot のトピックは数日で流れてしまいますので残念ながらこのへんでキリになってしまいそうですが。 議論の蓄積できる場所があればいいのにね・・・
引きずりすぎないからこそ新しい話題に対応できるのも確かですから。 アーカイブは残るので、いつか新しいタレコミの中で、いいタイミングで蒸し返してください。
書き忘れ (スコア:1)
Re:書き忘れ (スコア:1)
Javaみたいに(に限らないが)、ぜんぶ.classで「対等な」ライブラリファイルが
うじゃうじゃ集まってるだけのものだと、結構悩むんじゃないでしょうかね。
極端な話、それらのうちの「複数の」Classにmainメソッドを持たせて
ユーザーがゲッターロボみたいにどれを今mainとして使うかを好きに選べるなら、
もう主従関係自体が静的に決まらなくなりかねない。
(それに対してDLLやsoだと主従関係自体は動的に決まらず必ずexeが主ですよね)
主従関係や依存関係の定義も、システムの仕組みに依存しますよね。どうするんだGPL?
Re:このFSFの例では (スコア:0)
に動的リンクも単一プログラムとしてみなされると書いてある。
FAQをもっと読んで。
ただ法的にこれが有効なのかは別問題。判例がないから、裁判に
なったら別物と認定されると踏んで動的リンク使うならありだけど。 [gnu.org]
Re:このFSFの例では (スコア:1)
例えば画像を扱うSusie [digitalpad.co.jp]というソフトがありますが、このソフトのPluginとしてGPLライセンスのPluginを作った場合、Susieまでソースを公開の義務が生じるという事になってしまいます。
逆にこのPlugin I/Fを利用するクローズドソースなアプリもありますが、それらもソース公開の義務を負う事になってしまいます。
それこそMSじゃないですがウィルス的なライセンスになってしまいます。
ですからこのFSFの例とは逆のケースではこのまま適用出来ないと考えています。
Re:このFSFの例では (スコア:1)
が、そんなのつけてるソフトやプラグインみたことありません。
いちいち特例で指定する場合、同じ仕様のpluginをサポートしたfugaが出てきても、それで使うことはライセンスされてない、とゆーことになってしまいます
Re:このFSFの例では (スコア:0)
なんでこうなるのでしょう。単にそのようなPluginはGPLの下で配布できないというだけでは?
世の中にはGPLを適用できるものとできないものとがあり、あなたが例に挙げたPluginは後者に属するというだけのことでしょう。
Re:このFSFの例では (スコア:0)
適用しないと入れればいいだけですよね。
Re:このFSFの例では (スコア:1)
適用すべきではないと思いますけど。
その I/F を利用する GPL なアプリとその I/F を利用する GPL な Plugin とセットで出してというようなパターンもありますし。
私の挙げた例とは違いますが、GPL な Windows プログラムが呼び出す Windows API も DLL で実現されているんですけどね。
Re:このFSFの例では (スコア:1, 参考になる)
GPLにはOSとコンパイラのコンポーネントは除外するとある
でしょ。だからGPLなものは原則としてGPLと非互換な
ライセンスのソフトウェアと一体となって動くかたちで配布
してはならないの。
別にGPL なpluginを作ったからといってSusieがGPLになるわけじゃない。だけど、GPLなpluginはOSでもコンパイラでもない
susieという独占的プログラムに依存するのでGPLを満たせない。
だから配布はできないというのに無理がありますか?
Re:このFSFの例では (スコア:1)
Re:このFSFの例では (スコア:1)
すっかり忘れてました。
>だからGPLなものは原則としてGPLと非互換な
>ライセンスのソフトウェアと一体となって動くかたちで配布
>してはならないの。
これは理解してます。
>だけど、GPLなpluginはOSでもコンパイラでもない
>susieという独占的プログラムに依存するのでGPLを満たせない。
>だから配布はできないというのに無理がありますか?
そういえば独占的プログラムに依存するものにGPLを適用出来ないという条項も確かありましたね。
一応その Plugin I/F を利用する GPL なアプリと GPL な Plugin という形で満たす手段はありますが、その場合は組み合わせる人の問題だという事ですか。
納得です。
Re:このFSFの例では (スコア:0)
(LGPLとほとんど変わらないけど。)
Re:このFSFの例では (スコア:1)
利用することが可能ですから依存していないのでは?
依存しているのはインターフェース。
GPL詳しくないんで合ってるか知りませんがこれで逃げれないんですか?
Re:このFSFの例では (スコア:1)
ところで、OSやアプリやプラグインやライブラリの定義もまた(^^;、システムの仕組みに依存しますよね。
というか、Unixの「アプリ」だって、考えてみれば、OSというプログラムの上で動く「プラグイン」なんですよね。
main(笑)を始めとする各種APIの作法に則って作られ(だって則ってないアプリは動かないでしょ?)、
ユーザーが後付けでシステムに追加することが出来て、システムを機能拡張してくれる、「プラグイン」です。
GPLのような興味深い性質を持たされているライセンスが、OSとかライブラリとかいう
状況依存性の強い語(!)で説明される(FSF自身もそう説明してるんだったよね?)のは、
ちょっと残念です。
Re:このFSFの例では (スコア:0)
Susieはアプリケーションなのは確実なのでGPLから
引っ張った際に「主要なコンポーネント」っていうのをはずし
ていました。
>GPLのような興味深い性質を持たされているライセンスが、OSとかライブラリとかいう
>状況依存性の強い語(!)で説明される(FSF自身
Re:このFSFの例では (スコア:0)
この場合どうなるんでしょ?
普通のDLLをGPLで公開するのはアリなのに
拡張子を変更するとGPLにはできないってこと?
Re:このFSFの例では (スコア:1)
Re:このFSFの例では (スコア:0)
>普通のDLLをGPLで公開するのはアリなのに
dll なら アリってわけではないと思いますが・・・
ただ、GPL な plugin のみを単体で配布することは可能ではないかと。 plugin が依存するのは親プログラムではなくインターフェイスそのものなのだから。
Re:このFSFの例では (スコア:1, 興味深い)
ただ特例を設けないといけないと認識している人は いろいろと問題のでるGPLを使わないと思います。
GPLは,動的リンクに関して不完全なライセンス? (スコア:0)
>に動的リンクも単一プログラムとしてみなされると書いてある。
確かにその通りなんですが,これってGPL本文には明記されていないん
ですよね。FAQは単にFSFの主張を述べているだけであって,何ら法的
拘束力を持たない。ですから,
Re:このFSFの例では (スコア:0)
Re:このFSFの例では (スコア:2, おもしろおかしい)
Re:このFSFの例では (スコア:0)
自分が作ったものには著作権があるのでそれを利用する人にライセンスを守ることを要求できますが、他人の著作物にライセンスを守るように要求するというのはそもそも話がおかしいです。
まあ、ネタなのでマジレスしてもしかたない気がしますが(^^;