Matzにっき

_ [TV]サンダーバード

日曜に録画したサンダーバードを息子を保育園につれていく前に一緒に見る。

私は4歳くらいのときにサンダーバードに夢中だったそうなのだが、息子も感動してみていた。 娘たちはさっぱり興味がないようなので、こういうところに男女差が出るのか。 別にとりたてて男らしく育てたつもりはないのだが。

_ [本]CODE

4891003383 とある野望のために『4891003383』を購入する。 『CODE』といっても4881359932じゃなくて、Petzoldの。 もちろん、Creative Commonsは面白い考えだし、Lessig教授にも注目してはいるんだけど。

知らなかったけどPetzoldって人はWindows関係の本をたくさん出している人なのね。 で、『CODE』での説明は...うーん、私の好きなタイプじゃないなあ。 まあ、このような本が本当に必要な人に伝われば、私が好きかどうかは関係ないんだけど。

_ [Palm]ケース破損

ずっと ベルトにさげたケースにVisor Edgeを入れて便利に使ってきたのだが、先日とうとう破損してしまった。 で、しかたがないのでEdgeをかばんに入れているとそれはそれは不自由だ。 やはりいつも持っているということに意義があるのだなあ。

とうことで、明日東京に行った時にでもさっそく新しいのを購入しよう。 田舎ではそんなものはなかなか売っていないのだ。

_ チケット確保

来週の「オープンソース政策についての討論会」と７月のOSCONのチケットが確保できた。 席が取れないかも、とちょっと焦った。 こんどはもうちょっと早く行動を開始しよう。

_ [Ruby]BlockとProcとMethod

以前に

1.8.0では以下のいずれかになるのでは。

1. BlockとProcは親子ではない。BlockとProcとMethodがある。生成方法が異なる
2. Blockが残り、ProcはMethodとunifyされる。実装が大変。
3. BlockはProcに戻る。無名関数オブジェクトはMethodにunify。実装が大変。

などと書いたが、その後改めて検討した結果ProcのMethodのUnifyは無理であることが判明。 となると(2)や(3)は採用できない。

そこで原点に帰って考え直してみた。

元々の動機は「ブロック引数で得られる『ブロックオブジェクト』とlambdaで得られる『手続きオブジェクト』は違うものではないか」という疑問に対する対応だ。

実際このふたつは違うもので、異なる挙動が要求されている(仮に前者をBlock、後者をProcと呼ぶ)。

• Blockは引数チェックがゆるい。breakやnextが例外になる
• Procは引数チェックが厳しい。breakやnextは実行の中断

それが理由でこのふたつのオブジェクトを異なるクラスに分離しようと考えたのだ。 ところが、実際にCVS版でBlockとProcを分離したところ、

• このふたつは似過ぎていてユーザへの説明や使い分けが難しい

という注文が付いた。困った。

そこでしばらく考えたところ、なにもこの2種類のオブジェクトのクラスを分ける必要はないことに気がついた。

仮にlambdaの定義が

def lambda(&block)
  Proc.new{|*args|
    # 引数の数チェック
    begin
      block.call(*args)
    rescue LocalJumpError => e
      case e.reason
      when :break, :next, :return
        return e.exit_value
      end
      raise e
    end
  }
end

のようなものだったら、別に同じクラスで挙動が違うことは十分に説明できるだろう。 実際にはこのような形では実装しないし、arityの調整も行わなくちゃいけないけど、 あくまでも概念としては。

ということは、非互換の素であるBlockというクラスの導入も不要だし、 新しいクラスについての説明も、その使い分けも不要だ。

ということで、これをもって長らく悩んできた「Block/Proc問題」は解決ということにしよう。

あとは、20日午後5時(日本時間)を予定しているpreview3のリリースまで、きちんと準備していくだけだな。

_ [OSS]オープンソース裁判

ライセンスの話をしているとオープンソースに関する裁判についても話題になることが多い。

法律の素人の私がえらそうなことを言ってはいけないのかもしれないけど、 日常生活以上に裁判を心配する必要はないだろうと考えている。 また、裁判に関してライセンスはさほど役に立たないとも考えている。

オープンソースソフトウェアに関連して裁判が起きたケースはまだまだ少ないけれど、 考えられるパターンは以下のいくつかに大別できるように思う。

1. ソースコードの不正流用
2. ソフトウェア瑕疵に伴う損害賠償
3. 商標問題(MySQLとかUNIXとか)
4. 特許、トレードシークレットの不正使用(SCOのケース)

他のパターンがあるだろうか。

さて、これらを見てみると、(1)だけは開発者が訴えるケースで、残りが訴えられるケースだ。 訴えるケースについては後で考察しよう。

残りについてだが、まず(3)と(4)に関してはライセンスは全く関係ない。 よってライセンスをどのように選んでも避けようがない。 曖昧な「気をつけようね」以上の対応策はない。

それから(2)の損害賠償だが、多くのライセンスには無保証の文言が含まれているし、 たとえ含まれていなかったとしても、すべての情報が公開され、無償で提供されているソフトウェアについて 損害賠償が行える契約が締結されていると見なすことは困難だと思われる。 はっきりとしたことは専門家に聞かないといけないけど。

となると、ライセンスをどう選んでも訴えられることに関してはさほど差がないのではないだろうか。

最後に(1)の自分が訴える方だが、これは開発者の自発的なアクションなので好きに選んだらよい。 しかし、裁判という手段に訴えるよりは、ライセンス違反を広く公言して圧力をかける方が効果的ではないか、 という気がしている。

まとめ

• ライセンスの選択と訴えられることには実はあまり関係がない。
• 訴えられることをあまり心配するのは無駄。
• 裁判についてあまり心配しすぎることはFUD的要素を持つ(だからやめよう)。
• でも、最終的な判断は専門家に聞かないと(だれか相談に乗ってくれないかな)。