動的リンクとGPL 61
不思議な解釈 部門より
Kichiji 曰く，"すこし前の話になるが、日経Linuxのページに Hard Hat Linux を販売する米 Monta Vista Software副社長の Commune氏のインタビュー記事が掲載されていた。
この中で発せられたGPLと知的所有権の保護に関する質問に対して、同氏は「この問題は既に解決し、GPLのルールに従いながら知的所有権を保護することは可能」としている。"
"それに続く記者の補足コメントでは
同社ではGPLのライブラリは動的にリンク，LGPLのライブラリは静的にリンクするという方法で，ソース・コードの公開義務を回避している
とあるのだが… え!? そうなの? そんなGPL解釈初めて聞いたぞ。ちなみに、同じ日経LinuxのQ&Aのページには
「GPLライブラリを利用したプログラムは，静的リンクであれ動的リンクであれGPLで配布しなければなりません。」
とあるし、また、LGPLの前文には
"When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom."
としっかり書かれているのだが…
時おり法的解釈にあいまいさが残る可能性を指摘されることもあるオープンソースライセンスの数々だが、それにしても最近、原文を読めば明白なこの手の勘違い(FUDのための意図的と思われる物も含めて)多すぎるのではないだろうか。"
つぅか、Montavistaの取った方策は全然回避になってない気がするんだけど…
倫理的問題と法的問題。 (スコア:4, すばらしい洞察)
この種の問題は, 倫理上の問題 と 法的問題に分けて考える必要があると思います。
今回の例で言うと, 「倫理上の問題」とは, MontaVista社の行動がGNUの精神に反しているのかどうか, Linuxコミュニティの成果を搾取していないかどうかということです。一方, 「法的問題」とは, 同社の行動がGPLに対する契約違反であるか否かということです。これを踏まえた上で, 次のような場合に分けて考えたいと思います。
・倫理上の問題はなく, 法的問題も無い場合
この場合は当然, 何も問題が無いので, 議論の必要もありません。
・倫理上の問題は無いが, 法的問題はある場合
GPLはGNUの精神に基いて作られているので, これはありえないでしょう。もしこのようなことがあったとしても, "被害者"がいないので, 問題となることはありません。
・倫理上の問題はあるが, 法的問題は無い場合
これは, GNUの方針に背くことが明らかな行動であっても, GPLにはその行動を禁止する条文が見つからないことを意味します。この場合が一番問題なわけでして, GPL生成物を搾取しようとする者を阻止できないことになります。このような場合が実際に存在するとすれば, GPLは不完全なライセンスであるといわれても仕方が無いでしょう。
・倫理上の問題, 法的問題, 共にある場合
この場合は比較的簡単です。どの行為がGPL違反かを指摘し, 改善を求めればよいだけです。改善しようとしない場合は法的措置をとるべきでしょう。
いずれにせよ, 今後GPLが一般に認められるためには, 違反者(と思われる者)に対する裁判を数多く経ていく必要があると思います。GNU側が勝訴すれば, GPLの法的文書としての信頼性が増すわけですし, 敗訴すれば, 敗因となったGPLの穴の部分を埋めるべく改訂を行うことにより, より良いGPLを作ることが出来るからです。
…もちろん, 裁判になるような問題が発生しないのが一番ですが。
Re:fj.os.linux でも (スコア:3, 参考になる)
その議論の展開としては、
「著作権的にはダイナミックリンクにおいて ライセンスの影響が及ぶと考えるのは無理」
といった意見が大勢を占めておちついていたかと。 なにぶん著作権って書籍をベースに考え出されたもの なので、それでソフトウェアを論じると限界があります。 現行の著作権法ではその限界のカバーのために追加で 例外を規定かけてるしのいでるわけだけど、ソフト ウェアのこのジャンルについてはそういった条項は無い。
「ダイナミックリンク」って、web のリファレンスと 同じで単に名前の参照でしかないので、各自の手元に ライブラリが存在していて、それを名前で参照する 場合、著作権的にはそれを制限するような要素は ありません。あえて書籍にあてはめるなら、日本語で 文書を書くのに、特定の辞書の権利者からその辞書に のっている単語の解説の使用許諾を得るなんて話は ないよってこと。ライブラリと同梱で配布するなら、 著作権の根幹たる複製権の範囲になるけどね。
著作権とライセンスは別物で、ライセンスは契約なので 強力ってことになるんだけど、あまりにむちゃな権利 要求するライセンスは無効でしょうし、あと、 ソフトウェアの場合、ライセンスが及ぶ理由は、 結局「それの著作権があるから」であり、ダイナミック リンクの場合、ライセンスを適応しようにも、本当に そのライセンス対象のライブラリを使うのかどうかは 断定しきれず、著作権が及ぶとはいいきれないわけ。
GPLの効果を本当に認めようとすると極論では一般的な ソフトウェアのライセンスの及ぶ範囲を現行の著作権 より強力にする必要があって、たとえばとあるOS上で 動くプログラムは、そのOSのAPI使ってるから、OSの 著作権者の権利が及んでくるとかそういった話に なってくる。GNUはFAQでプロセス呼び出しかどうかを 境界線としていってるけど、それってあんたらが決める 話なの？ってつっこみもできちゃう。
ソフト作ってる人たちの倫理的には(自分たちが ライセンス商売する上でも)なんとなくGPLはまもった ほうがよさそうだってことになると思うけど、 その法的根拠は、裁判になって、著作権法に例外と しての条項がつけくわわったり、ソフトウェアに関する 権利を規定する新しい法律ができたりしないかぎり 固まらないんではないかな。
もともと、Copyleft って、ソフトウェアの ライセンスの概念を否定するってのが根底である にもかかわらず、そのための武器としての GPL は ソフトウェアのライセンスに依存してるわけで、 その矛盾がふきでてきてるともいえるかもねん。
Linux 上でのクローズドなソフトの利用 (スコア:2, 参考になる)
「リンクとはみなさないので問題ない」
と発言していたと記憶しています。(どなたか、発言記録のリンクとかご存知ないでしょうか?)
しかし、ライブラリの使用に関しては、明らかにリンクなわけだし、なによりも、ヘッダファイルは静的にコードにインポートされるので、GPLなライブラリはGPLなソフトウェアにしか使えないという見解があったと記憶しています。
unix依存な考え方 (スコア:2, すばらしい洞察)
これって、JavaOSやSqueakOS(^^;では、意味を成さない考え方ですよね。
プロセス(の壁)って概念がない世界だから、そのOSで実行させたアプリ(アプリという概念もまたアレだがさておき)らの全てが
「1つの実行イメージ」ってことになっちゃう。
いつも議論されるここらへんの話って、技術的にUnix＋αの世界だけを前提としているような
気がしてならん(=心配な)のだけど…どう？
動的リンクといっても技術的に色々な段階(?)のものがあるわけですよね。
Classの動的Loadをサポートしてる言語やOSだと、当初は未知だったInterfaceやImplementationをLoadできちゃうし、
evalみたいなことが出来るならば未知の機能を呼ぶことも出来る。
そういう緩やかな結合はどうするんだろう？
緩やかな結合にGPL伝染を阻止する効果があるならば、
動的結合を使いまくることでGPL逃れをするという寒い戦略が取れるわけで、
伝染するかどうかが「最適化(笑)」の問題に堕ちてしまうという、
すり替え状況が生じ得てしまう。
逆にGPL伝染を阻止する効果が無いとすると、
どこまでを結合と見なすかという問題が生じ、分散ObjectやSuperSwikiの立場が無くなる(ちょっと違うが(^^;)。
少なくとも、線引きがどこに存在するか？ってのを、新技術が登場するたび(笑)に
改訂していかないとならないってのは、ちと困るんじゃないかな。
#というか、LispやSmalltalkなんて劇古じゃん…
…と思ってるんですが、間違ってますか？
ところでFREE(自由)至上主義立場だと、「どっちにせよ全部FREEになるなら儲けモノ」
という解釈もありえそうで、なかなか恐い(^^;
高級になったらどうすんだ(っけ)？ (スコア:2, すばらしい洞察)
#「ソケットは?」と「GPL ソフトへの依存と共同著作の概念」を多重継承したいんだが。
ソケットやWrapperと言われればLinuxerは(ぉ)ピンと来るのかも知れませんが、
もっと高級な世界になったら、どう考えればいいんでしたっけ？
ラッパーが継承や委譲になり、
ソケットが分散Objectになったら、です。
そうするとソースの字面はだいぶ替わる(直接的な結合であるかのように見える)ようになると思うんですが、
「ソースを」縛るライセンスであるGPLと、
ソースの見た目と実際の足回りの構造がどんどん乖離(抽象化ともいう)してく世界
ってのは、うまく合うもんなんでしょうか？
Re:Linux 上でのクローズドなソフトの利用 (スコア:2, 興味深い)
そういう問題が起こる理由は単純で、「リンクする」とは何なのか定義しないからですよ。
ただ、私もこれを定義しろといわれたら悩みます。というのは、例えば以下のような問題点があるためです。
少なくとも、「リンク」というのは相当泥くさい作業です。そのようなものとライセンスのような多くのアプリケーションをカバーする高尚なものとでは本質的に互いに相容れないものなんですけどねぇ。
Re:Linux 上でのクローズドなソフトの利用 (スコア:2, 興味深い)
おっしゃる通りです。ですから、ここでとるべき正しい対応は、「リンク」という泥くさい作業をうまく回避することです。
商用ライセンスでは、この問題を避けて通るのは非常に困難です。SunのライセンスもMicrosoftのライセンスも、もっとも気を使ってあるのはこの部分です。GPLは、泥くさいものをかわすことが難しいという背景を知らないままに作られてしまったのでしょう。
BSD-styleライセンスは、こういう泥くさい話を全然持ち出していませんね。
Re:Linux 上でのクローズドなソフトの利用 (スコア:2, 参考になる)
一方後者の「プラグイン ライセンス」というのは Perl のArtistic/GPL の選択 とか、Qt の QPL/GPL の選択のような デュアルライセンスがそれにあたるのではないでしょうか?
Re:規格を介せば (スコア:2)
APIというよりもAPIを定義しているヘッダーファイルには著作権があります。
だから互換のライブラリを書いた時に、ヘッダーファイルもスクラッチで書かなきゃならないんですが、結果的にそっくりなヘッダーファイルになったら．．．．．という問題があるんじゃないかと。
Re:著作権って、別々に配布するものに (スコア:2)
「使用」ということですが, この場合, ライブラリを「使用」するのは誰でしょうか？ 言い換えると, もしGPLなライブラリを使用するプログラムが非GPLだった場合, ライセンス違反として責められるべきなのは誰なのでしょうか？
もちろん, 普通に考えればライブラリを「使用」しているのは, 正に文字通り, これを使用している「プログラム」なわけですが, だからといってプログラムをGPL違反に問うわけには行きません。違反の責めを負うのは, あくまで人間である必要があります。
それでは, どの人間がGPL違反に問われるのでしょうか？ (GPLなライブラリを用いるにも関わらず)非GPLなプログラムを配布している人でしょうか？ 静的リンクの場合は明らかにそうです。配布プログラムの中にGPL生成物が含まれているにも関わらず, それを非GPLとして配布することはGPL違反だからです。しかし, 動的リンクの場合はどうでしょう？ 配布物の中にはGPLの生成物は含まれていないはずです。また, 配布の過程においてライブラリを使用することなどありえません。したがって, このプログラムの頒布者がGPL違反に問われることは無いと思われます。
ここまで考えると, GPLなライブラリを使用する人間は一人しかいません。例のプログラム手に入れてを利用(実行)する人です。しかし, この人をGPL違反に問うわけにはいきません。「GNU GENERAL PUBLIC LICENSE 」には,
と書かかれており, プログラムを実行する行為は一切制限していないからです。
以上のように考えると, GPLなライブラリを動的に使用するプログラムをGPL以外のライセンスで配布することはGPL違反にならないような気がするんですけど, どうでしょうか？ 反論お待ちしております。
Re:規格を介せば (スコア:2)
で、実際の所 (スコア:2)
私も (^^;;;;;
で、結論の一つに
「ところで今配布されているディストリビューションに含まれているGPLなライブラリってあるのか？全部LGPLではないか？」
というのがあったような気がするんですが．．．．GPLなライブラリってあるんでしょうか？
＃fj.os.linuxでこの議論が始まるまでは、全部LGPLだと思ってたっす (^_^;;
Re:GPL ソフトへの依存と共同著作の概念 (スコア:2)
つーか、それなら BSD でいいじゃんと思うのですが、なぜ Linux ？
やはりマーケティング上の都合なんだろーか。
Linux を知っている技術者からは否定的な評価をされるリスクが大きいと思うんですが。
そんなものはどうでもいいのかな？
Re:ヘッダファイルには著作権はない (スコア:2)
gccのSunOS4.x用では、make時に、SunOS標準ライブラリのヘッダファイルを処理している部分があるんですが、それはヘッダファイルの著作権の問題でこういう処理をしなければならない羽目になっている、という話を聞いたことがあるもんで。
実際、ヘッダーファイルに(C)が書かれてたと思います。
Re:ついでにこれも高級化(かな? (スコア:2)
へ？コンパイル時はオリジナルも互換品も関係なしに、普通のクラスとして見るからエラーにはならないですよ。
packageがinportしてるのと違ってればコンパイルできんけどさ。
packageも同じにした互換クラスに入れ換えると、JavaVMの方で「コンパイル時とバージョンが違うよ」って警告が出ますけど、VMの設定で回避できます。
つまりオリジナルの親クラスがバージョンアップして「別のバイナリ(ってJavaの場合変な言い方だけど)」になっても、それを呼び出しているクラスや継承しているクラスは、再コンパイルなしでそのまま動作します。
ということは (スコア:2)
ということはKDEで動作するアプリはGPLにしなきゃならないってことですねぇ。
GNOMEだとGPLにしなくてもOKなのかな？．．．．なんか面白いな。
後は、GDBMとGNU readlineを避ければ大丈夫なわけね。
とはいえ、LGPLなはずのライブラリにこの２つか混じっていたりする可能性はないだろうな(笑)。
Re:で、実際の所 (スコア:2)
勘違いかもしれないけどね (^-^;;;;
glibcをGPLと思ってる人がいて、LGPLだから問題ない、で終わったやつを勘違いしたかな？
Re:著作権って、別々に配布するものに (スコア:2)
「精神を尊重すべき」ということに関しては, 同意します。少なくとも私がGPL生成物を使う時は, GPLの精神を尊重します。おそらく/.の皆さんも尊重しているかとおもいます。
しかし, この精神を尊重しない人間が現れたらどうなるでしょうか？ 私は, 少なくとも現在のGPLでは, これを阻止することは出来ないと考えています。理由は ( #28) の投稿で指摘したとおりです。
とは言うものの, 私はGPLに詳しいわけでもなければ, 法律に詳しいわけでもありません。「GPLなライブラリを動的にリンクして使う非GPLプログラム」がGPL違反であることを 説明できる方がいらっしゃいましたら, 是非ご説明いただきたいと思います。
Re:ヘッダファイルには著作権はない (スコア:2)
「APIには著作権はない」
けど
「ヘッダーファイルには著作権がある」
わけでしょ？
私が心配したのは
「同じAPIを記述したヘッダーファイルは著作権違反になるかどうか？」
です。
結論としては「著作権違反にならない」わけですね。
ソケットは? (スコア:1)
連携して処理させるのはGPLのソース公開の義務があるのかどうか。
GPL＜～Socket～＞Closed
動的リンキングの一種になるかもしれないが、こうすれば、GPLで書いた関数のラッパープログラムだけ
公開するだけでいいのでしょうか?
ちょっと気になっています。
.::.:... .::....: .::...:: .::.:.:: .::..:.: .:::..:.
I 1 2 B H4[keR. :-)
GPL ソフトへの依存と共同著作の概念 (スコア:1)
よく理解できていませんし、彼の会社の主張でもありませんが、 GPL ソフトに依存していなければ、共同著作物の概念で縛る GPL には抵触しないという主張がありました。
動的リンクの相手が選択可能なソフトの場合、そのいずれかが GPL だったときにも、GPL でなくてはならないのか？というような問いだったかと。
wraper を介して逃げるという方法はありますが、OS Kernel でやることではないでしょうに。
fj.os.linux でも (スコア:1)
最近 fj.os.linux でも同じようなことを議論していたような気がします。あまりにもスレッドが大きくなりすぎて追い切れませんでしたが。
リンクを作りたかったけど、最近もやっているanonymous nntp(?)っていうのかな、Webから購読投稿が可能なサイトの場所がわからなかったので、、、パス
Re:fj.os.linux でも (スコア:1)
Re:著作権って、別々に配布するものに (スコア:1)
この手の議論をする場合は、著作権と使用許諾（ライセンス）を区別して行う必要があります。
より詳しい話は、きっと詳しい人が書いてくれると思いますが、GPLなライブラリを使用するプログラムは、それが動的であれ静的であれ GPL なライブラリを使用するわけですから、当然 GPL でなければなりません。
もちろん、GPLが現行法上有効ならばの話ですけど。
Re:GPL ソフトへの依存と共同著作の概念 (スコア:1)
>OS Kernel でやることではないでしょうに。
…よく判らないんですが、そういう問題なんですか？
OSじゃヤルことじゃなく、一方アプリとかだといい、んですか？
ふと、「OS以外にゃGPLが全然流行らない世界」という
嫌なパラレルワールドを想像してしまった。
＜おふとぴ＞
OSと、あとは「速度優先なのでWrapperなんか書くとまずい」ようなソフトと。
＜／おふとぴ＞
＜おふとぴ２＞
OSとアプリと(Inter)netとが区別できないようなオッサンも未だに居るが、
そういう人から見ればInternet全体がGPL伝染の対象となる、と思えるんだろうか？(笑)
＜／おふとぴ２＞
Re:Linux 上でのクローズドなソフトの利用 (スコア:1)
>カーネルモジュール
>「リンクとはみなさないので問題ない」
カーネルモジュールって、単に、
「実装形態の違う、もう1つの動的ロード体系」
に過ぎないと思うのだが、気のせい？
Linusがなんと言おうと (スコア:1, 参考になる)
Re:Linux 上でのクローズドなソフトの利用 (スコア:1)
誰が定義{すべきな|できる}んですか？
GPLソフトを入手した人(GPLの読者)でないことは確かでしょうが、
GPLの作者なのか、それともGPLを適用するソフトの作者なのか、は
ちと悩んでしまう。
前者だとすると時代(笑)と共に改訂をしまくらないとならんのが非現実的なような気がするし、
後者だとするとライセンスにプラグインを許すってのはStallmanノリ(笑)に似合わないし。
Re:Linusがなんと言おうと (スコア:1)
このあたりからも、GPLが対称的(最初の作者も含むあらゆる人間に特権を与えない)ライセンスだというの実感するきがします。
Re:著作権って、別々に配布するものに (スコア:1)
GPLの有効性や適用範囲に関して実際に法定で争われた事ってどれぐらいあるんでしょうか?
すこしまえにフランス(かどこだったか)でそういう裁判があったという噂を耳にした覚えがあるのですが、すごくいい加減な記憶です。(すんません。)
また、例えばアメリカで「有効だ」という判例が出たとしても、日本など他の国で法定に登ったときは他国の判例というのは参考にならないものなのでしょうか?
だれか詳しい人教えて下さい!
規格を介せば (スコア:1)
動的リンク先のライブラリに関してもその関数名だけ用意したスタブOnlyのライブラリを作っておいて、これを動的リンクしてできたバイナリを配布し、実行には元になったライブラリと等価なAPIを持ったライブラリが必要、とすることで問題が回避できたりしないのかな？
Linuxの動的モジュールに関しても、そういうAPIがある、という前提でドライバを組めばGPLにする必要性があるとは言い切れないと思うんだけど。
それともAPIの名前そのものが著作権の範疇に入るからだめなんでしょうか？
-- By Grabthar's Hammer!
Re:|は? (スコア:1)
Re:規格を介せば (スコア:1)
規約には著作権が認められません。
また創作性の無いものにも著作権は認められません。
それはさておき、(他の人が既に指摘しているとおり)使用許諾と著作権は、無関係ではないにせよ、パラレルですね。
from もなか
Re:で、実際の所 (スコア:1)
そんな話になってたっけ。
とりあえず2つあげときます。
GNU readline(GPL)
Qt(GPL/QPL)
-- Che Che - Bye Bye
ついでにこれも高級化(かな? (スコア:1)
ヘッダーなるものが存在するかどうかも、ある種の言語のありように依存した問題すね。
あ。「そんなこと考えてどうなるってんだ？」と思われる方がいるかも知れませんが、
別にGPLはLinuxだのUnixだの(そしてC)のモノってわけじゃないんで、
あーゆーのと全然毛色の違う世界にも通用するものであって欲しいという願望が有るもんでして、考えたくなっていたりします。
閑話休題。実際どうなんだろうなあ？
動的な言語ならヘッダー的な情報をいっさい与えられずとも戦える(笑)だろうし。ObjectiveCだとどうなるんだっけ？
Delphi/Kylixの言語はCみたいにHeader相当の情報を別ファイルにすることは可能だし。
Javaだと別ファイルにするのは無理っすよね。APIの伝達手段という意味でHeaderに敢えて似たものを探すとすれば
それは継承の親ClassまたはInterface(のソース)かなと思いますが、
Javaってコンパイル結果のファイルに含まれる情報が一般的なCとかのソレより多い(よね：というかCが今時ウブなくらいに情報少ないんだけどさ)から、ソース無くてもバイナリだけで「継承」することが出来ちゃう。
Headerの出番なし。あれれ？なんか変だな…
#これはdelphiも同じ。
てゆーかむしろ、Java(やC++)みたいな強型言語(ってのか)だと、字面互換なだけの偽物を書いちゃったら同名の別Classとして互換性が否定されてコンパイルエラーになっちゃうし(笑)。
つまり、Cだと偽物のソース(Header)および偽物のバイナリでも通るけど、Javaだと本物のソースまたは本物のバイナリが必要であり、かつ両方は要らない、と。
#だよね？javaは俺まだ浅いんで…
なんか、C以外を考えると、凄くワケワカな世界にいっちゃうような気がする…。
それは困るなあ…
蛇足だけどついでに言えば、実行ファイル(とライブラリファイルの差)という概念も怪しげだしね。
javaだとmainあればいいし、rubyとかだとargv[0]と自身の名が一致してればmainだ(暴論)し…。
java初めて見たとき膝をたたいたんだけど、実行ファイルとlibraryファイルの差ってのが無いのね。
#個人的にはjava方式が好き
オブジェクト指向(正確にはクラス指向(笑))的に考えれ (スコア:1)
兄弟クラスであるhogeとGPL_softの間には、問題となるような繋がりは無いと思われます。
どちらもPipeableのPipeToNext(Pipeable)メソッドやPipeToPrev(Pipeable)メソッドや、ReadメソッドやWriteメソッドを「使って」、未知の隣人と対話しているに過ぎません。
むしろ問題が有(り得)るのは、hogeとPipeableの関係や、
GPL_softとPipeableの関係、じゃないでしょうか？
待てよ？Class間の依存関係はGPL的にどうなるかっていう問題はココまで色々出てきたが、一方Instanace間の依存関係はどうすりゃいいんだ？
Bridge Pattern(?)を使って未知(のClass)のInstanceを接続した瞬間にGPL汚染が生じる、ってのは、あまりにも変だし(笑)。
Re:Linux 上でのクローズドなソフトの利用 (スコア:1)
>後者の「プラグイン ライセンス」というのは Perl のArtistic/GPL の選択 とか、Qt の QPL/GPL の選択のような デュアルライセンス
ちょっと違うと思います。
デュアルはGPLとかの個別のライセンスの「外」で多態(笑)をしてるのであって、
一方俺が書いたプラグインってのは、個別ライセンス(ここではGPL)の「内」で多態するみたいな感じです。
GPLの文章自体はFREEじゃない(変更の自由とかが他者に無いっすよね)というGPL以上に厳しいものであるのにも関わらず、
そのGPL自体が他のライブラリへの動的リンク(爆笑)を内包するってのは、
変だろうな、と思ったってのが前述です。
Re:GPL/FSFのFAQはあてにならない (スコア:1)
ライセンスを読むときは制定者の意図を読め、とかいう人が結構いるけど:-P、
むしろ逆で、ライセンスこそ字面をそのまんま解釈せんといかんと思う。
どうせ効力が有るのは字面だけなんだしさ。
意図を十分込めてないライセンスがあったとしたら、それは
なんらかの障害があったのでそうせざるを得なかったか、
単に制定者が阿呆だったか(笑)のどっちかでしょう。
で、どっちにせよ有効なのは出来あがった文面だけ。
意図は歴史学(?)の問題に過ぎない。
GPLって、それこそStallmanとかの意図(理想)をそのまんま込めちゃったら
ライセンスとして成り立たないんじゃないですかね。
知らないけどきっと、法的に「ライセンス」というものの
本分つーか能力限界は、どっか一定のレベルが存在するわけですよね。
だから、それに見合うように、理想の草案を「剪定する」必要があったのじゃないかと。
で、理想のほうは、制定者が*別途*書いた宣伝文のほうに
(言論の自由に基づき)しっかり書いてある、と(笑)。
温度差が出来るのは、当然かと。
そもそもGPL自体が、裏技だよね。
Closeする権利しかどうせ想定してなかったんであろう著作権を逆手にとって
(逆手に取れたのは他でもなく、取られる隙が法律の中に存在したからでしょう)
Openする権利を記述したんだから。
かなり離れ業やってるよね。
#勿論、裏技=悪い、ということではなく。
Re:で、実際の所 (スコア:1)
もひとつ。
GDBM
Re:Linux 上でのクローズドなソフトの利用 (スコア:1)
>> 多態(笑)をしてるのであって、
>> 一方俺が書いたプラグインってのは、
>> 個別ライセンス(ここではGPL)の「内」
>> で多態するみたいな感じです。
(改行付加)
なるほど。基本的にはGPLであるが、Netscape Inc. や Trolltech に特権を認めていた MPL や QPL Ver.1 なんかがこれにあたるのでしょうか?
たしかにこれだとソトールマンは認めない気が… ちなみに、これらのライセンスはGNUのフリーソフトウェアのライセンス解説ページでは、GPL非互換のフリーソフトウェアライセンス(GPL-Incompatible, Free Software Licenses )と分類されているようです。
Re:Linux 上でのクローズドなソフトの利用 (スコア:1)
問題がなくなるというのは違いますか?
「内」とはいいがたいかな。
Various Licenses and Comments about ThemのQPLの項より
-- Che Che - Bye Bye
Re:で、実際の所 (スコア:1, 参考になる)
glibc-2.2.3まではGPLなコード(libio)が含まれてます.
ただし、
As a special exception, if you link the code in this file with
files compiled with a GNU compiler to produce an executable,
that does not cause the resulting executable to be covered by
the GNU General Public License. This exception does not
however invalidate any other reasons why the executable file
might be covered by the GNU General Public License.
という例外条項がついているので、gccを使う限りでは、
glibcをLGPLとみなせただけです.Kylixなんかを使う場合
にはこの例外条項が適用されないのでglibc2.2.3とは
static linkすると商業版でもＧＰＬが適用されちまい
ます.
glibc 2.2.4ではライセンスが変更されてLGPLになったので
この問題は解決されてます.
Re:で、実際の所 (スコア:1)
なってるものをあげておきます。
ElectricFence FreeWnn-devel VFlib apmd apt
binutils console-tools dev86 e2fsprogs egcs-c++
esound flex gdbm gnome-games gpm
guile isapnptools kakasi kudzu-devel libPropList
libjconv librep libstdc++ libtool libwnn6
namazu pciutils-devel popt procps readline
rpm slang
fooとfoo-develの双方があるものはfoo-develは記述していません。
意外とあるかな。
-- Che Che - Bye Bye
Re:著作権って、別々に配布するものに (スコア:1, 興味深い)
Re:で、実際の所 (スコア:1)
gettextもお忘れなく。ただし、libintlは次のリリースからLGPLになるみたい。
実装がなければダメなんでない？ (スコア:1)
というのであれば、GPLライセンスが有効になるのでは？
（動的でも静的でもライセンスの範疇に入るのだから）
すると、GPLライセンス回避の為にBSDライセンスでライブラリを書き直す、なんて事も起こりうるのか。
＃もっとも、ほとんどのライブラリはLGPLだから関係ないと思うけど。
# mishimaは本田透先生を熱烈に応援しています
著作権って、別々に配布するものに (スコア:0)
GPLのライブラリを利用していようと、
動的リンクならば、そのプログラム自体には
ライブラリのコードが含まれずに配布できるわけです。
ライブラリという著作物を引用していないわけですから、
そのプログラムの配布を著作権で縛れるのでしょうか？
Re:著作権って、別々に配布するものに (スコア:0)
また、バイナリ（製品）となってたソフトウェア（ここではソフトAとします）が、特定のライブラリを利用するようになったものについても同じような話が出てきます。例えばソフトAがGPLなライブラリを動的リンクした場合、メモリ上で1つの実行イメージになったり、他のGPLなソフトウェアとタイミングを取った（レスポンスや実行結果に依存する）連携を行う場合は、そのソフトAはGPLで公開されるべきである、となります。 これらのことは、FAQかなにかに明記してあったかと。
Re:fj.os.linux でも (スコア:0)
ライセンス的な縛りを現状でばっちりいれるなら、 GPL不適合なソフトウェアとリンクすることを あらゆる局面で全面的に禁止してしまえばOK。 現状は、GPL が規定してる制限が及ぶのは配布する 時だけなので、エンドユーザがなにをしようと関係 ないってのが、こういった現象がおこる背景にある わけです。
もっとも、これ禁止しちゃうと、それこそどこが フリーやねんって話になるから、禁止することは ありえないと思う
Re:著作権って、別々に配布するものに (スコア:0)