「Red HatがオープンソースなJavaの実装を計画」記事へのコメント

既存のプロジェクトとの関係は？

[tuneo (2938)]

Java VM [kaffe.org]やクラスライブラリ [gnu.org]のプロジェクトはすでにあるんだけど、それらとの関係はどうなるのだろう。

Re:既存のプロジェクトとの関係は？

[tuneo (2938)]

自己レス＆まとめレスでごめんなさいです。

・まず、GNU ClasspathプロジェクトのURLですが、ご指摘のとおり間違えてました。

・そういえばJava互換言語(wコンパイラもgcjがありましたね。すっかり失念してました。

・KaffeがJava VMじゃないというのは、ご指摘のとおりです。プロジェクトのWebページにも「Sunのお墨付き

RedHatが新たにクリーンルーム開発をする理由

[Anonymous Coward]

たぶん着目するべきは「新たにゼロから開発する」点よりも「クリーンルームで」という点でしょうね。

つまりコードを最初から完全に管理することにより、SCO みたいなトコロからゴタゴタ言われる危険性を回避するという意味もあるんじゃないですかね。

gcj/Kaffe/GNU classpathなどがそういう問題を現実に持っているというわけではありませんが、可能性を排除したいためのある種究極の選択を行った、と。

Re:RedHatが新たにクリーンルーム開発をする理由

[G7 (3009)]

>SCO みたいなトコロからゴタゴタ言われる危険性を回避する

もしそうだとすると、OpenSourceモノとして公開すると、その「価値」が半減しちゃいますね。
他人の血が入ってきた瞬間に、それが汚染済みであることを恐れないとならないので。

＃「少なくとも自分とこで書いたオリジナルの分は安全だ」という主張は勿論可能だが、OpenSourceの実質的旨みは無くなっちゃう…

オフトピ：
あれ？SuperWaba [superwaba.com.br]ってブラジル(だよね)に引越したですか？

クリーンルームの徹底

[Anonymous Coward]

いえ、公開したあと他所・他者からコードを提供してもらう時に、そのコードの正当性を厳密に判断していけば良いかと。

もちろん、そのコードが「あるクローズドな製品のコード」であるかどうかなんて、その製品のコードを見ることができる一部の人以外には判断のしようもありません。しかし、提供者（＝そのコードの由来に関して責任を負う人）を常に明確にしておけば、もしもの時の対処も可能になります。

＃ もっとも SCO みたいに問題個所を明確にせず文句だけ言う相手には無力ですけ