アカウント名:
パスワード:
>GPL汚染とかを嫌う他社が、 >SolarisならではのAPI(よく知りませんが、きっと色々あるのですよね？)を使った製品を >出したがらなくなる
カーネルやライブラリにGPLが適用されていたとしても、 それを使ったプログラムにGPLを適用する必要はありません。 「ふつー」の会社/プロジェクトならば
>それって今回の話(下層であるOSがGPLであり、その上に乗せるソフトが非自由)とは逆の状況ですよね。 >そのまま参考になるんでしょうか？
そのまま適用できます。 あるGPL非互換なコードAとGPLなコードBがあったとして、 Aのソースコード公開義務が発生するのは、 Aをコンパイルした部分とBをコンパイルした部分が同一のメモリ空間に 配置されるかどうかで決まります [gnu.org]。 上層/下層という関係は、GPL条文には登場しません。
>あれ？GPLソフト(この場合は将来のSolaris)「に」依存するソフトを書く場合、 >それこそ例外条項を設けない限り、
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生unstable -- あるハッカー
GPL嫌いの「世間の多数派」が… (スコア:2, すばらしい洞察)
GPL汚染とかを嫌う他社が、
SolarisならではのAPI(よく知りませんが、きっと色々あるのですよね？)を使った製品を
出したがらなくなる
…なんてな未来が生じたりは、しないんでしょうか？
個人的にはGPLみたいな乱暴な(^^;考え方＆実装(としてのライセンスそのもの)は好きですが、
実際に自分がそれの影響(たとえばGPL汚染)に晒されるときに度胸を要するって感覚もわかるし、
嫌ってる奴らはやっぱり世間に結構居るようなので、
他社による周辺ソフトや周辺ハードの「広がり」が(更に)鈍ってし
Re:GPL嫌いの「世間の多数派」が… (スコア:1, 参考になる)
カーネルやライブラリにGPLが適用されていたとしても、 それを使ったプログラムにGPLを適用する必要はありません。 「ふつー」の会社/プロジェクトならば
Re:GPL嫌いの「世間の多数派」が… (スコア:1)
ええと。上記リンク先FAQに書かれてる状況設定は、
「フリーではないライブラリを利用するフリーソフトウェアを書いている」
ということですが、
それって今回の話(下層であるOSがGPLであり、その上に乗せるソフトが非自由)とは逆の状況ですよね。
そのまま参考になるんでしょうか？
>カーネルやライブラリにGPLが適用されていたとしても、それを使ったプログラムにGPLを適用する必要はありません。
あれ？GPLソフト(この場合は将来のSolaris)「に」依存するソフトを書く場合、
それこそ例外条項を設けない限り、GPL汚染を食らうわけですよね？
Re:GPL嫌いの「世間の多数派」が… (スコア:1)
http://www.gnu.org/licenses/gpl-faq.ja.html#TOCPortProgramToGL
Re:GPL嫌いの「世間の多数派」が… (スコア:1)
あのー。そのリンク先もまた、「すっぴんのGPL」なライブラリの上に乗せるソフトの話には
なっていないように読めるのですが。 LGPLとか例外条項つきとか書いてますね。
「一部のライブラリはGNU GPLのみの下で公開されていますので、
そういったライブラリを使いたいならばあなたはGPLと矛盾しないライセンスを自分のソフトウェアに
適用しなければなりません。しかし通常そういったライブラリはより特殊な用途向けのものであることが
多いので、単なるポーティングでそういったライブラリを利用しようと思うことはまずないでしょう。」
という記述なら有りますが、これは、(ある観点から見ての)希望的観測、でしかないですよね。
実際に目の前にすっぴんのGPLのライブラリが有ったらどうなるんだ、という話ではないです。
＃というか、こういう無責任(笑)な文面が本家のFAQに書いてあるあたりが、なんとも牧歌的というか…
で、「API」という表現をしたわけでして、汎用なインターフェース(POSIXとかが該当するでしょうか)にのみ依存
してるソフトなら話は別かも知れない(「知れない」というのは俺がよく理解してないというだけの意味ですが)
けども、Solaris独自APIのぶんについては、ライセンスが素のGPLならば、それを使うソフトは汚染を免れない、
ですよねえ？っていう話です。
で、Solarisならではの独特な機能(?)を使ったソフトやハードなら、独自APIとの縁も有ろうよ、と思ったわけで。
>リンク先FAQの下の方を読んだ方がよろしいかと。
んー。読みましたが、上記の通り…ですよね？
＃更に下まで読めなんてのは勘弁ですよ。せっかくのアンカータグのname属性なのですから。
「一般的に言えば、答えはノーです。」という記述なら有りますが、その下:-)に、
「個々のケースという意味では、答えはあなたが使いたいライブラリとそのライセンスに依ります。」という記述が続いているわけです。
で、「素のGPL」に依れば、汚染されますよね？
----
Linuxは、すったもんだの末、例外条項があるぞということになっている…のでしたっけか？
で、今回はLinuxの話ではないわけでして。
Sunも例外条項を「とーぜん」つけてくるはずだ、という話が別途あるのでしたら、それはそれでしょうけども。
Re:GPL嫌いの「世間の多数派」が… (スコア:0)
そのまま適用できます。 あるGPL非互換なコードAとGPLなコードBがあったとして、 Aのソースコード公開義務が発生するのは、 Aをコンパイルした部分とBをコンパイルした部分が同一のメモリ空間に 配置されるかどうかで決まります [gnu.org]。 上層/下層という関係は、GPL条文には登場しません。
Re:GPL嫌いの「世間の多数派」が… (スコア:1)
そんなことはリンク先のどこにも書いてないわけだが
例えばMS-DOSやuClinuxなどの全プロセスが同一メモリ空間に配置さえるOS上のプロセスはどうなるの？
一方（仮想記憶付きOSでは通常別メモリ空間に配置される）別プロセスであっても「しかしコミュニケーションのセマンティクスが親密であったり、複雑な 内部データ構造を交換したりする場合は、それらも二つの部分がより大規模な プログラムに結合されていると考える基準となりうるでしょう。 」
とほのめかしている。
実際には「これは法的 な質問であり、究極的には裁判官が決めることです。」としか言わず、断定を避けてる。
linuxに限っていれば、「システムコールを経由したユーザプログラムはカーネルのGPL派生物にならない」
と限定 [linux.no]してるので問題ないけど
Re:GPL嫌いの「世間の多数派」が… (スコア:1)
別の人も書いてますが、「同一のメモリ空間」という技術的に詳細すぎ＆実装依存すぎな概念を
こんなところに持ち出すのは、本来不適切な筈です。
さもないと、「UnixLikeなOS以外ではGPL汚染が発動しない」という滑稽な事態が起きかねない。
実装に小手先の変化をつけるだけで汚染を遮断できちゃう可能性が有るってことなのですから。
それは全くもってRMSの望むところではないでしょう…
余談：
Javaみたいに「メモリ空間」なんて概念が意味を成さない世界では、どうすんでしょうか？
そうそう。JavaOSだとどうするんでしょう？
あえて言えばJava(OS)では「メモリ空間」は最下層(Cで書かれるマイクロカーネル)以外は全部地続きです…
あとScript言語みたいなソースから直結ばりばりなインタプリタ言語だとどう？
＃最近めっきり、FREEソフトはJavaやRubyみたいな高級言語でしか作らなくなったのでG7
結局のところ、GPLにおける「リンク」って概念って、ザルってわけではないにせよ、どこか的外れだと思います。
まあ的外れだからといってザル(=無視可能)というわけではないとは思いますが、だからこそ今度は感染暴走が怖い…
かといってRMSの精神(笑)は尊重したいから、有効に機能はして欲しい…
つまり按配が良くないんですよね、現状のGPLって。
>少なくともカーネルやバンドルされているライブラリがGPL化されるだけならば、
>第三者が作ったユーザモードプログラムやデバイスドライバは GPL が定めるソースコード公開義務の適用例外の範疇に入ります。
別の人も書いてますが、それは特例を設けた場合だけの話で、
素のGPLはそんな風になっていませんよねえ？？
＃「(論理的に)依存」するかどうかどうか、で決まるもんだとばっかり思って(好意的に解釈して)たのでG7
＃まあ俺の解釈はどうでもいいんですが、上記の貴方の解釈もまた変なのでは？