アカウント名:
パスワード:
>GPL汚染とかを嫌う他社が、 >SolarisならではのAPI(よく知りませんが、きっと色々あるのですよね?)を使った製品を >出したがらなくなる
カーネルやライブラリにGPLが適用されていたとしても、 それを使ったプログラムにGPLを適用する必要はありません。 「ふつー」の会社/プロジェクトならば
>それって今回の話(下層であるOSがGPLであり、その上に乗せるソフトが非自由)とは逆の状況ですよね。 >そのまま参考になるんでしょうか?
そのまま適用できます。 あるGPL非互換なコードAとGPLなコードBがあったとして、 Aのソースコード公開義務が発生するのは、 Aをコンパイルした部分とBをコンパイルした部分が同一のメモリ空間に 配置されるかどうかで決まります [gnu.org]。 上層/下層という関係は、GPL条文には登場しません。
>あれ?GPLソフト(この場合は将来のSolaris)「に」依存するソフトを書く場合、 >それこそ例外条項を設けない限り、GPL汚染を食らうわけですよね?
少なくともカーネルやバンドルされているライブラリがGPL化されるだけならば、 第三者が作ったユーザモードプログラムやデバイスドライバは GPLが定めるソースコード公開義務の適用例外の範疇に入ります。 実際、「A=現状のSolarisカーネル, B=GPLなプログラム」と、その逆の 「A=GPL非互換なプログラム, B=GPLなLinuxカーネル」は、どっちもありですよね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
GPL嫌いの「世間の多数派」が… (スコア:2, すばらしい洞察)
GPL汚染とかを嫌う他社が、
SolarisならではのAPI(よく知りませんが、きっと色々あるのですよね?)を使った製品を
出したがらなくなる
…なんてな未来が生じたりは、しないんでしょうか?
個人的にはGPLみたいな乱暴な(^^;考え方&実装(としてのライセンスそのもの)は好きですが、
実際に自分がそれの影響(たとえばGPL汚染)に晒されるときに度胸を要するって感覚もわかるし、
嫌ってる奴らはやっぱり世間に結構居るようなので、
他社による周辺ソフトや周辺ハードの「広がり」が(更に)鈍ってし
Re:GPL嫌いの「世間の多数派」が… (スコア:1, 参考になる)
カーネルやライブラリにGPLが適用されていたとしても、 それを使ったプログラムにGPLを適用する必要はありません。 「ふつー」の会社/プロジェクトならば
Re:GPL嫌いの「世間の多数派」が… (スコア:1)
ええと。上記リンク先FAQに書かれてる状況設定は、
「フリーではないライブラリを利用するフリーソフトウェアを書いている」
ということですが、
それって今回の話(下層であるOSがGPLであり、その上に乗せるソフトが非自由)とは逆の状況ですよね。
そのまま参考になるんでしょうか?
>カー
Re:GPL嫌いの「世間の多数派」が… (スコア:0)
そのまま適用できます。 あるGPL非互換なコードAとGPLなコードBがあったとして、 Aのソースコード公開義務が発生するのは、 Aをコンパイルした部分とBをコンパイルした部分が同一のメモリ空間に 配置されるかどうかで決まります [gnu.org]。 上層/下層という関係は、GPL条文には登場しません。
少なくともカーネルやバンドルされているライブラリがGPL化されるだけならば、 第三者が作ったユーザモードプログラムやデバイスドライバは GPLが定めるソースコード公開義務の適用例外の範疇に入ります。
実際、「A=現状のSolarisカーネル, B=GPLなプログラム」と、その逆の 「A=GPL非互換なプログラム, B=GPLなLinuxカーネル」は、どっちもありですよね。
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
#まあ俺の解釈はどうでもいいんですが、上記の貴方の解釈もまた変なのでは?