«前の日記(2004-07-12) 最新 次の日記(2004-07-14)» 編集

Matzにっき


2004-07-13 [長年日記]

_ [OSS]「オープンソースによる互換性の問題」へのコメント

とおりすがりさん

禁止したいForkの一例はMSのJavaとか。

MS JVMを選んだユーザの気持ちとしてはForkかどうかはどうでもよくて、「 互換かどうか」だけが重要だったのではないでしょうか。 そして、「非互換な互換品」MSJVMはSunとしては嬉しくなかったでしょうし、 できるものなら禁止したかったでしょう。 で、たまたまライセンス上可能だったから禁止したと。

でも、同じことはIntel x86プロセッサにも言えませんか。 IntelはAMD(あるいはTransmeta)の「互換品」は禁止したかったんじゃないかと思います。 けど、できなかった。


オープンソース化失敗企業勤務さん

想像力は大切。ありすぎるのも困るけど、

ええ、困ってます。 ですから、貧しい私に想像力を適用した結果を具体的に示してくださると助かります。


Mr.orz(「Mr.」と「さん」を同時につけるのは変ですよね)

この点、わたくしは、「GPLというのはヌケの多い隙だらけの契約」と読んでます

この点、私は「GPLは契約ではない。著作権行使方法の宣言である」と読んでます。 日本でもアメリカでも誰からも文句が出ない形でGPLを契約として成立させるのは無理があるような気がします。 そういう意味では「契約としてヌケ」があっても障害ではないと思っています。

言語処理とかTEXのようなフォーマット言語だと、ユーザからすると「一度書 いた資産が将来もそのまま使えるか」がとでも重要(企業にとっては、市場 規模を決めるファクタ)。しかも、「version-upによって過去の資産が使え なくなってしまった」というのは「私が明日バスに轢かれる可能性」よりは るかに高いものであって、経営上きちんと予測して対処すべき責任(予測し て対策を練らなければ重過失)と考えます。

まだ分かりません。ソフトウェアは自発的には進化しないので、 ここでの「過去の資産が使えなくなる」ような「version-up」とは誰かが行うものなのですよね。 原著作者が行うのであれば、たとえ互換性がなくてもそれは自分の責任であり、 それは少なくとも原著者にとっては「合理的な非互換」であったと考えます。

他者が行うのであれば、

  • 原著者の承諾を受け、メンテナの交代が起きていれば、新しいメンテナの責任。 原著者は交代した時点でコントロールを失っている。
  • 原著者に無断で行った(その結果、フォークが発生した)のであれば、 それはどうやっても禁止できない行為であり、原著者には責任はない。

原著者にできるのは、 a)どのような改変が誰によって行われたかを明示すること、 b)再配布を行う時には、修正したものもオープンソースとして開示すること、 を要求することなどであり、それはLPPL 1.3でも、GPLでも可能である、 と思います。LPPL1.3では第6項と第10項がそれを述 べており、GPL2では第2項がそれに当たると思います。

メンテナの交代が明示されているぶん、LPPLの方がこの点ではわかりやすいとは思いますが、 GPLだから重大の問題が発生する(企業責任が問われる)ほどのことはないと思います。

むしろ、LPPLが(まだ)「OSI認証」でないことによる、 「本当にオープンソースと呼んでもよいの、問題はないの」という不安、 GPLコンパチかどうか(まだ)確認されていないことによる、 「GPLソフトウェアとリンクしてもよいのか」という不安(特に後者)があるので、 私だったら現時点ではLPPL 1.3は薦めません。

ところで、GPLのヌケである「ソースとバイナリの価格づけの関係」というのは、 第1項の

You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.

という部分でしょうか。 配布方法として磁気テープが一般的であった時代を感じさせる表現ではありますが、 「ヌケ」とまでは思いませんでした。

GPLが現在の状況に合わない点がまったくないとは断言できません。 おそらくはいくつもあることでしょう。 しかし、運用上問題があるほど合わない点にはまだ気がついていません。 ご教示いただけるとさいわいです。

時代に合わないと言えば、刑法なんかも成立が古いだけに変な表現が残ってますよね。

オリジネータの著作権法的な地位をGPLよりは一歩あげ、オリジネータはすべての改変情報を知ることができる、(改変は自由であるものの)正式な改変であるか否かはオリジネータが決定できる、という点で、forkに対するユーザの懸念とオープンソースにより享受できる利益は両立できると考えます。

具体的にどのようなライセンスを考えていらっしゃるのか分かりませんが、 GPLでも上にあげたa)とb)の要求があるので、 全ての改変情報を知ることは可能で、それらの変更を取り込むことも可能だと思います。

わざわざGPLよりも「地位をあげる」ということは、原著作者になにか新しい権利を付与したいのでしょうか。 強すぎる権利は全体の自由を減らすのではないかと懸念しますが、 これはまた別の機会に話しましょう。


shiroさん

個人的には、forkは仕方ないことだし、起こり得ることで、その可能性をことさら恐れるに足らないほど低いと言う必要は無いと思います。開発者中心の世界ではむしろ適度な競争になって良いことでもあるでしょう。ただ、企業の方針としてフォークを避けたいと考えることも妥当ですし、それに対する説得力のある反論は、「フォークは滅多に起こらない」ではなく、「フォークしてもメリットがありますよ」の線なんじゃないかとの印象を持ちました。

私の言いたかったことは「互換品の登場は禁止できない」でしたが、 「フォークは滅多に起こらない」って言ってますね、確かに。

フォークのメリットと言えば「フォークが起きても競争が促進されるのでメリットがある」というところでしょうか。 特にオープンソースの場合、改良の融通ができるのでより速い速度の進歩が可能ですし。

本日のツッコミ(全5件) [ツッコミを入れる]
_ Mr.orz (2004-07-13 13:46)

> GPLのヌケである「ソースとバイナリの価格づけの関係」というのは<br><br>そうです。may charge a fee となっていますので、<br>・バイナリは無償配布<br>・ソースは対価1兆円で配布(ただし最初に1兆円で買った人その他が無償で配るのは許すという条件)<br>でもGPL準拠です。(おそらくこういう屁理屈flameを経て)GPL-FAQでは、バイナリ価格>ソース価格という無理な解釈を示していますが、かような解釈は、GPLの文理上無理があるといわざるを得ません。

_ まつもと (2004-07-13 14:14)

Mr.orz:<br>> ・バイナリは無償配布<br>> ・ソースは対価1兆円で配布(ただし最初に1兆円で買った人その他が無償で配るのは許すという条件)<br>> でもGPL準拠です。<br><br>まあ、確かにそうで、たぶん「reasonable fee」とすべきだったん<br>でしょうね(この点ではArtisticの方が優れている)。<br><br>が、文章の一部に穴があったからと言って契約(あるいは約束)が無<br>効になるわけではないでしょう。

_ AC (2004-07-13 16:25)

ところでJavaをForkして嬉しい点が想像できない。<br>ソースの断片が定義できて(Proc)、yieldがあってeachに渡せたり、<br>evalは……要らないけど、そういうJavaなら欲しいが。<br>それはRubybybyby....(残響音含む<br>VMの互換性が無いだけのJavaは嬉しくないし。<br>だいたいMSJavaVM依存のアプリなんぞ作る開発会社がいることがこの業界の(以下略

_ 通りすがり (2004-07-13 17:56)

まつもとさんのフォークの定義も、そもそものフォークの定義も良くは知らないので、それはフォークじゃないから関係無いと言われてしまいそうなのですが、自分でPerlなCGIを書いてた頃に、mod_perlやJPerlのサポートで苦慮していた事があります。このような事態はまつもとさんのRuby的なオープンソースの世界ではどのように解釈されるのでしょうか?<br>少なくともPerlを開発した人達は、私が苦労する事を望むような事はなかったと思っているのですが、より良いスクリプターになる為の試練を与えてくれたと感謝するべきだったのでしょうか?

_ まつもと (2004-07-13 18:19)

それは「非互換」で、望ましくないことだと思います。<br><br>jperlについては、Larryたちにそれを取り込むように説得するなど、<br>互換性問題を避けるためにできることはあったかもしれないとは思<br>います。 Emacs->NEmacs->Muleのようにフォークしたけど、最終的<br>には取り込まれた例もあるわけですから。

お名前:
E-mail:
コメント:
[]

«前の日記(2004-07-12) 最新 次の日記(2004-07-14)» 編集

track feed Matzにっき Creative Commons License This work is licensed under a Creative Commons License.