禁止したいForkの一例はMSのJavaとか。
MS JVMを選んだユーザの気持ちとしてはForkかどうかはどうでもよくて、「 互換かどうか」だけが重要だったのではないでしょうか。 そして、「非互換な互換品」MSJVMはSunとしては嬉しくなかったでしょうし、 できるものなら禁止したかったでしょう。 で、たまたまライセンス上可能だったから禁止したと。
でも、同じことはIntel x86プロセッサにも言えませんか。 IntelはAMD(あるいはTransmeta)の「互換品」は禁止したかったんじゃないかと思います。 けど、できなかった。
想像力は大切。ありすぎるのも困るけど、
ええ、困ってます。 ですから、貧しい私に想像力を適用した結果を具体的に示してくださると助かります。
Mr.orz(「Mr.」と「さん」を同時につけるのは変ですよね)
この点、わたくしは、「ＧＰＬというのはヌケの多い隙だらけの契約」と読んでます
この点、私は「GPLは契約ではない。著作権行使方法の宣言である」と読んでます。 日本でもアメリカでも誰からも文句が出ない形でGPLを契約として成立させるのは無理があるような気がします。 そういう意味では「契約としてヌケ」があっても障害ではないと思っています。
言語処理とかTEXのようなフォーマット言語だと、ユーザからすると「一度書 いた資産が将来もそのまま使えるか」がとでも重要（企業にとっては、市場 規模を決めるファクタ）。しかも、「version-upによって過去の資産が使え なくなってしまった」というのは「私が明日バスに轢かれる可能性」よりは るかに高いものであって、経営上きちんと予測して対処すべき責任（予測し て対策を練らなければ重過失）と考えます。
まだ分かりません。ソフトウェアは自発的には進化しないので、 ここでの「過去の資産が使えなくなる」ような「version-up」とは誰かが行うものなのですよね。 原著作者が行うのであれば、たとえ互換性がなくてもそれは自分の責任であり、 それは少なくとも原著者にとっては「合理的な非互換」であったと考えます。
他者が行うのであれば、
原著者にできるのは、 a)どのような改変が誰によって行われたかを明示すること、 b)再配布を行う時には、修正したものもオープンソースとして開示すること、 を要求することなどであり、それはLPPL 1.3でも、GPLでも可能である、 と思います。LPPL1.3では第６項と第１０項がそれを述 べており、GPL2では第２項がそれに当たると思います。
メンテナの交代が明示されているぶん、LPPLの方がこの点ではわかりやすいとは思いますが、 GPLだから重大の問題が発生する(企業責任が問われる)ほどのことはないと思います。
むしろ、LPPLが(まだ)「OSI認証」でないことによる、 「本当にオープンソースと呼んでもよいの、問題はないの」という不安、 GPLコンパチかどうか(まだ)確認されていないことによる、 「GPLソフトウェアとリンクしてもよいのか」という不安(特に後者)があるので、 私だったら現時点ではLPPL 1.3は薦めません。
ところで、GPLのヌケである「ソースとバイナリの価格づけの関係」というのは、 第１項の
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よりも「地位をあげる」ということは、原著作者になにか新しい権利を付与したいのでしょうか。 強すぎる権利は全体の自由を減らすのではないかと懸念しますが、 これはまた別の機会に話しましょう。
個人的には、forkは仕方ないことだし、起こり得ることで、その可能性をことさら恐れるに足らないほど低いと言う必要は無いと思います。開発者中心の世界ではむしろ適度な競争になって良いことでもあるでしょう。ただ、企業の方針としてフォークを避けたいと考えることも妥当ですし、それに対する説得力のある反論は、「フォークは滅多に起こらない」ではなく、「フォークしてもメリットがありますよ」の線なんじゃないかとの印象を持ちました。
私の言いたかったことは「互換品の登場は禁止できない」でしたが、 「フォークは滅多に起こらない」って言ってますね、確かに。
フォークのメリットと言えば「フォークが起きても競争が促進されるのでメリットがある」というところでしょうか。 特にオープンソースの場合、改良の融通ができるのでより速い速度の進歩が可能ですし。