2006-03-27

public override …

ロージナ茶会がさり気なく爆弾を投げ込んでいる。特に大項目1が危険である。まず読んでみるべきだ。

ここで提案されている法制度は大胆で、直ちに実現できるものではないように見えて、実は実現性が高いという点に留意すべきだ。フレームワークとしては、権利を短期間化し一方で権利侵害対応を強化した制度との選択制にすることによって、実質的に不要な権利ロックを著作権トランザクションから開放することで、窮屈な著作権制度を打開しようという発想である。著作権者は商業的に有利な制度を選択することになるだろう。

大項目1〜4の全てがひとつの明確な目的に結びついている。それは「権利の明確化」であり「ルール化」の流れを汲むものと言える。で、現状、法律のうちコード化されていない部分について、現実に合わせた解を提示しているのが、特に大項目3、4といったところであろう。

実のところ僕は微妙に茶会に出入りしているので、この案も少し前に茶会でさわりを聞いていたのだけど、上手く考えられているなあと驚いた。

ともあれ、この案を踏まえて、僕としては従来書いてきた路線を継続しておこうかなあと思っている。それは、曖昧な権利主張の無効化、あるいは架空の権利主張の犯罪化（正確には厳罰化）であり、明示規定による公正使用規定の導入であり、サブマリン特許・サブマリン著作権侵害の無効化・犯罪化である。で、この前当日になってあわてて2,3時間でやっつけた奴を使い回そうと思っているのだけど、同じ内容で別の文面をひねるのがめんどいなあ…

というわけで今日は某一橋講堂まで遊びに行く予定。

電子政府が使えない理由、縦割りの弊害？JREの弊害？

JREがバージョンごとに少なからず振る舞いが異なっていて、アップデートにちゃんと対応するのが大変だね、という話。って書くとあんまし面白みが無いので、もう少し。

本件の場合

XML Signature実装って、この電子政府ソリューションが始まった頃はまだまだフロンティアで、とてもバージョン間互換性が期待できたものではなかったように思う。

JREの問題と言える部分があるとしたら、それはsecurity fixを別途リリースするという形にしていないという一点だけであろう（これとは関連するようで関連しない「脆弱なバージョンが残る」問題もあるけど）。そして、それは.NETも（もちろんMonoも）同じである。versioning hellが起こるのはJREだけではない。以前書いた通り、.NET も、期間内件数としてTigerと同程度の変更を加えているのだから、どちらかと言えばSunの方が真摯にアップデートを提供することによって、問題が「隠されていない」のである。

MS.NETのversioning hell

.NET 2.0では1.1でクロスバージョンなアセンブリ生成が出来ないし、1.0でビルドしたアプリケーションの多くが1.xで動作せず、さらにはSecurity Fixと同程度の内容であるべきService Packの適用状態によって動作が変わる¹。protectedがpublicになっただけで動かなくなる。^{2 3}

おそらくその原因は、信頼してはいけないSystem.Runtime.Serialization依存（回避可能）とか、member signaturesの変更（回避不可）とかだろう。これは開発者の問題にすることはできないし、フレームワーク実装者の問題でもない。

side by sideはcoolな提案だったし、僕は嫌いではないが、異なるバージョン間でのdispatchの設計には（少なくとも.NET 2.0までの時点では）失敗した。同一のバージョンを前提としたランタイムの自動選択機能が残った。それはほとんど並列にインストールされたJVMと実質的にあまり違いが無い。exeを直接実行するか、batなりshなり何なりを叩くかの違いだ。

.NETがせめてJava程度にインターフェース指向のフレームワークであったなら、これらの問題の多くが回避できたかもしれないが、interfaceでない型を使わないことは不可能なので、結局はJavaで起こっていることと同レベルの問題は起きていたことだろう。Javaではなく.NETで同じような開発が行われていたら、問題はさらに悲惨なものだったであろう。

Monoの場合

Monoの問題はもっと悲惨である。僕らはAPIの誤差を随時修正してMSに合わせている。可能な場合はMSとのserialization compatibilityを実現する。つまり、シリアライズされたメンバーを見て、同じ構成になるようにフィールド名を書き換える⁴。これによって、むしろそれ以前のMonoとの間で、互換性が失われる⁵。

serialization compatibilityは機械的な作業ではないので、僕はもう諦めた方が良いと思っている。一方でMonoコミュニティにはMS互換原理主義者が少なからずいて、（特に他人の）時間を無駄にするな・させるなという立ち位置の僕とはしばし衝突する。最近はそうでもないか。^{6 7}

結論

…というわけで、strongly-strongly-typedな言語を使うのも良いが、素直にstatic linkedなC(++)を使ったり、インタープリタ言語でコーディングしてしまった方が良い側面も多いだろう。この手のソフトのうち、パフォーマンスが大きな問題になるプログラムがどれほどあるか、という話もある。

別にJavaや.NETのソリューションを否定しているわけではない。GroovyやBooを使えば良い。

何か同じ話を何度も書いているような気がしてきたのでこの辺でsage

そんなことより

僕はmidiomの存在を知って感動している。まだほとんど使っていないのだけど、巷にあるピアノロール系の入力よりはこのグリッド入力の方が使いやすい（気がする）し、数値入力（イベント入力）のバッドノウハウぶりがたまらんです。

まあそんなことを言いながら一方ではReasonｶｺｲｲ!とかゆってるわけですが。

コメント

ladybug — 03/27/2006 13:09:44

以前、他の人が書いていたことの受け売りなんですが、クラスライブラリの設計において private/protected/internal の境界引きというのは、それなりに優秀な千里眼的センスが必要なのでですよね。
なので、internal → protected/public やら protected → public といった変更は、使われだしてから必要性が判明してしまうのは仕方が無いと思ってますし、コンシューマデベロッパーにとっては（互換性うんぬんは別にして）歓迎すべき修正だと思っています。

個人的には、.NET1.1/2.0 のこの線引きがヘタクソだと思える部分が多すぎる感がありますが。

atsushieno — 03/27/2006 16:41:43

はい、APIのスコープを事前に予測しておくというのは難しいというか、期待して良いものではないと思います。↑でもちょっと書きましたが、僕はMicrosoftがこの辺を予測し損ねていたとして「糾弾」するつもりはありません（できません）。

.NET 2.0については、僕には途中で方針を変えて無理に互換性を維持する方向に行ってほしくはなかったなあと思います。その辺で.NET 2.0が退屈なものになってしまったという印象もあります。が、ソースレベルでincompatibleにならないような変更で済ませる努力は認められるべきかな、とは思います。

nazokou — 03/28/2006 09:52:39

爆弾
ベルヌ条約で日本（と言うより加盟国の過半数）が留保している追求権の創設が謳われていますけど、権利の前提が公売市場の存在であることにどの程度留意しているのか見えないのが多少、疑問。「大量複製物への適用（＝権利の消尽原則破棄）に対する足掛かりにしない」と言う確約が得られるのなら、反対ではありませんが。

atsushieno — 03/28/2006 23:44:16

なるほど、確かに芸術著作物を単に既存の著作権法のカバーする範囲で保護される著作物と100%マッピングすることは出来ないでしょうから、取引価額に応じて芸術著作物の取引に相応しい対価請求というかたちにせざるを得ない＝政令等に一任するのは不安である、ということは理解できます。僕が出す範囲ではその辺りも言及しておきます。

dekodeko — 03/29/2006 03:42:03

たしかにJREにまずい部分はあるものの、この例ではJREのパスやレジストリの場所を直接参照しているとの事らしいのでさすがにそこまでJREの責任にするのはかわいそうな気がしますが。

atsushieno — 03/29/2006 04:14:36

「この例」というのがその具体的な一例のことを指されているのだとしたら、それはJREの問題ではないと思います。