SunによるSolarisのGPL化計画(アイディア段階) 50
ストーリー by Oliver
GPLだからこそビジネスになる 部門より
GPLだからこそビジネスになる 部門より
ozuma 曰く、 "slashdot.orgの記事でも話題になっているが、SunがSolarisをオープンソース化し、ライセンスとしてGPLを適用する計画を考えているという( Infoworldの記事)。これにより、SunのSolaris販売は、RedHatのLinux販売と似たモデルを取ることになるという。Infoworldの記事を読む限りでは、この計画が今すぐ実現されるというわけではないようだ。しかし、もしSolarisがGPLになったとしたら、いったいどんな影響が考えられるだろうか?"
SolarisのGPL化で考えられる影響 (スコア:2, 興味深い)
Re:SolarisのGPL化で考えられる影響 (スコア:0)
Re:SolarisのGPL化で考えられる影響 (スコア:1, 参考になる)
レイヤが違うんですが...
Re:SolarisのGPL化で考えられる影響 (スコア:0)
Re:SolarisのGPL化で考えられる影響 (スコア:0)
http://www.unicode.org/unicode/reports/tr17/
の characters vs glyph を意識してのことです。
glyphのレンダリングをXサーバでやるかクライアントでやるかの
比較であればSTSF vs Xftの話でICUとは無関係です。
今のところICUにglyphやfontを扱うAPIはありません(将来的には?ですが)。
またSTSFはglyphをレンダリングする下準備として
BiDi属性などはPOSIX localeだ
Re:SolarisのGPL化で考えられる影響 (スコア:0)
NFS (スコア:2, 興味深い)
できるのか (スコア:2, 興味深い)
そういうのもクリアになってるのかな?
Re:できるのか (スコア:1)
まさか、Solaris 1.x (SunOS 4.x)系列じゃないですよね。
あれはBSDベースでSysVコードとは縁が薄い..はず。
Re:できるのか (スコア:4, 参考になる)
SunOS 4.x は 4BSD ベースではあるものの、System V からもずいぶん取り入れています。
* ベースとなった 4.3BSD 以前の部分: Ancient UNIX なので SCO free
* Sun が独自に開発した部分: 微妙
* SVR 3 等から取り入れた部分: SCO tainted
な感じかな。
当時 SunOS を書いてた連中は System V のコードを日常的に見てたはずなので、「このコードのここは System V 由来に違いない」などといちゃもんをつけられると、違うということを証明するのは結構めんどくさそう。
Re:できるのか (スコア:1)
どうなるんだろう。。外されたら嫌だな。かなうちなのでWnnとか使えないし。
Re:できるのか (スコア:1)
＞どうなるんだろう。。外されたら嫌だな。かなうちなのでWnnとか使えないし。
RedHat、TurboLinuxなんかと同じだったら、SUNが販売するパッケージにだけ
付けておけばいいんではないですか？
問題は、ATOKのSolaris版を単体販売してもらえるかってことですね。
# タダパッケージのデフォルトは、Wnn・・・・
GPL嫌いの「世間の多数派」が… (スコア:2, すばらしい洞察)
GPL汚染とかを嫌う他社が、
SolarisならではのAPI(よく知りませんが、きっと色々あるのですよね？)を使った製品を
出したがらなくなる
…なんてな未来が生じたりは、しないんでしょうか？
個人的にはGPLみたいな乱暴な(^^;考え方＆実装(としてのライセンスそのもの)は好きですが、
実際に自分がそれの影響(たとえばGPL汚染)に晒されるときに度胸を要するって感覚もわかるし、
嫌ってる奴らはやっぱり世間に結構居るようなので、
他社による周辺ソフトや周辺ハードの「広がり」が(更に)鈍ってしまうかも知れない
という点が心配です。
＃それとも、もう既に、自由ソフトまんせーな人々くらいしかSolarisを相手にしてない、ということでしょうか？
自社技術を世間に晒したいけど、晒すという意味でご同輩の穴二つ(??)になる事を回避しつつタダノリする他人を認める気はない、
という場合にはGPLは有効な武器だと思いますが、
一歩間違えると、仲間(ただしClosedを前提とする連中)を食っちゃう過剰免疫状態に陥りそうで。
＃好きだけど度胸が無いのでG7
いや、そこを覚悟の上でGPLにするっていうなら、一個人として喝采しますけど。
----
あと、Solarisはともかく(藁)として、一方の柱であるところのJavaは、どうなのよ？という点も少し気になります。
稼ぎ頭(というべきなのかな)という意味でもありますし、
外部からのOpen化の要求の圧力が強いという意味では、JavaはSolaris以上でしょうから。
あ。それとも、今となっては、
「Javaは手放したくない。それに比べればSolarisならばまだしも…」
ということなのかなあ？
＃初めて触ったUnixはSunOS4だったのでG7
Re:GPL嫌いの「世間の多数派」が… (スコア:1, 参考になる)
カーネルやライブラリにGPLが適用されていたとしても、 それを使ったプログラムにGPLを適用する必要はありません。 「ふつー」の会社/プロジェクトならば FAQ [gnu.org] くらいちゃんと調べるでしょうから、GPLということが理由となって開発が忌避されることはないと思ってます。
まあそもそも、Solaris向けソフトウェアの絶対数自体が相当少なくなってる気もするわけですが。
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
＃まあ俺の解釈はどうでもいいんですが、上記の貴方の解釈もまた変なのでは？
Solarisのライセンスいじるの (スコア:1, 興味深い)
Re:Solarisのライセンスいじるの (スコア:1)
ひしひしと伝わってくるな。コバルト買ったりして結構頑張ってくれるかと思ってたのに。
それなりにまだ魅力的な技術を持ってるのに、
どんどん自分の価値を落としていくのに歯止めがかからないという感じ。
とりあえず、Solaris/x86がGPLで出たら勉強がてら触ってみたいですが。
Re:Solarisのライセンスいじるの (スコア:0)
FreeBSD5.xの人たちは (スコア:1, 興味深い)
言ってたけど、その手の人たちには、ソースを公開するまでもなく
もう既知の技術なんだろうな、と思う今日この頃。
The Network is the Computer.
未だ、ネットワークとコンピューターはシームレスになってないけど
SUNは夢半ばにして、弱体化の一途をたどっているのが、
アレゲ好きとしては悲しい。。。
Re:FreeBSD5.xの人たちは (スコア:0)
逆に何故いまさら FreeBSD5.x では M:N のモデルなんだろうか。
Re:FreeBSD5.xの人たちは (スコア:1, 参考になる)
5.2.1のデフォルトは1:N。
Re:FreeBSD5.xの人たちは (スコア:0)
だったらSolaris（やLinux）みたいに
Re:FreeBSD5.xの人たちは (スコア:0)
/.JPでもSunの論文だけ読んでSMP実装の強さを理解した気になってたFreeBSD関係の人がいましたね。
Re:FreeBSD5.xの人たちは (スコア:1, 興味深い)
Solarisのカーネルは、「lintクリーン」だって自慢してたから、
きっと、すごく読み易いに違いない。多分。
それはそうと、これで、UNIXの系図を書くとき
SolarisからFreeBSDに線が引かれることになるのかな。
それはそれで、ニンマリするものがあるが。
Re:FreeBSD5.xの人たちは (スコア:1)
この中に SunOS が入るのは、楽しいかも。
FreeBSD: /usr/share/misc/bsd-family-tree
# いつも思うのですが、この図を書くのって大変じゃないのかな。
Re:FreeBSD5.xの人たちは (スコア:0)
まあ、「非GPLなところにコードをパクられない」からこそGPLという選択肢がでてくるんですけど。*BSDを排除するのは副作用で、
Re:FreeBSD5.xの人たちは (スコア:0)
>
>/.JPでもSunの論文だけ読んでSMP実装の強さを理解した気になってたFreeBSD関係の人がいましたね。
以前公開されたSolarisのソースにはNDAの縛りがあったらしいので、
『FreeBSDのカーネル開発者が(Solarisの)ソースを読むべきだ』
とは言えないと思います。
sunはmsと仲良しらしいが (スコア:1, 興味深い)
すぐ思いつくネタとしては... (スコア:0)
とりあえず Debian Solaris、つぎにDebian GNU/SolarisとDebian BSD/Solarisのプロジェクトが立ち上がることでしょう。
＃でも、Debian Solaris/Linuxとか Debian Solaris/kFreeBSDとかは誰もやらないと思う。
Re:すぐ思いつくネタとしては... (スコア:2, おもしろおかしい)
Solarisに汚染されたエンジニアがLinuxやFreeBSD開発をできる様になる。
Re:すぐ思いつくネタとしては... (スコア:0)
# 昔からのkernel-hackerを抱えていても、現場で
# 彼らを生かすのが難しいんだよね。
Re:すぐ思いつくネタとしては... (スコア:0)
考えにくいなぁ…リアリティが感じられないというか。
（Windows系の開発者が、UNIX系の開発で戸惑うというのならまだしも）
まともな開発者なら、どちらも使えるのが当たり前では？
Re:すぐ思いつくネタとしては... (スコア:1)
Re:すぐ思いつくネタとしては... (スコア:1, 参考になる)
決して技術力云々って話ではないと思われ。
Re:すぐ思いつくネタとしては... (スコア:0)
コマンドとか/etcの下とかがSunOS4のころの BSD風に戻ったSolarisならすげー使いたいぞ。
Sun? (スコア:0, 荒らし)
正直、Sunはもう終わってるっしょ
Re:Sun? (スコア:2, 参考になる)
少なくとも現在稼働しているシステムの多さといった、現場レベルでは
まだまだ現役ですよ。
これからSolaris(というかSPARC)でシステムを構築する、というのは
減っているのかどうか…
いくつかのシステム構築に携わってきましたが、最近だと
金がないプロジェクト→Linux
金があるプロジェクト→HP-UX
って感じで…
どっちにもつかないところでSolarisが使われているような気がしてならない
のは私だけでしょうか？
どのOSやハードウェアにしろ、盛者必衰みたいなところはあると思うので、
システムそのものには適度な投資で済ませて、残ったお金で運用するスタッフの
教育とか職場環境にお金をかけてあげて欲しいな、とは常々思うのですが…
Re:Sun? (スコア:0)
HP-UX? (スコア:2, 興味深い)
巷に数多くあるUNIXの参考書の中で商用OSをみてみるとSolarisが非常に多くて、AIXもちょこっとあって、ところがどういうわけかHP-UXの本はほとんど見かけないのですが、なぜなんでしょう…。
というか、この参考書が妙に多いSolarisってのも不思議といえば不思議なのですが…。
ちどりの「ち」きっての「き」…
Re:HP-UX? (スコア:3, 参考になる)
Sunは1台だけ導入する場合でも、販売店が積極的にセールスに来るので、導入台数が少ない所ではSunを選ぶことが多いです。そういう場合には、システム組むSIさんがUNIXのノウハウあまり持ってないし、数台ではメーカーのサポートも期待できないので、市販の参考書が必要になるので多く売られるようになった、のだと思います。
ソースコードがなかった (スコア:0)
GPLだからこそビジネスになる (スコア:0)
GPLだからこそビジネスになる成功例？ (スコア:2, 参考になる)
制約の多いライセンスである GPL ならではのビジネス展開ではないでしょうか。
-----
[オープンソースで利益を上げるには？]
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20031030/1/
-----
Mc.N
そんな少数例だけあげられてもね... (スコア:0)
プロプライエタリ厨必死だな(w (スコア:0)