«前の日(05-24) 最新 次の日(05-26)» 追記

Matzにっき


2003年05月25日

_ [教会]出雲訪問

今日は出雲支部の支部大会ということで、出雲訪問。

ずっと外回りばかりで、そろそろ松江に出たいんですが。 えーと、スケジュールを確認すると、来週は松江ですか。

先週は1.8の準備で忙しかったし、結婚披露宴の裏方などのせいか、 かなり疲れてしまい、うちに帰ると寝入ってしまった。

まあ、昼寝も安息日にふさわしい活動のひとつだそうだが。


2004年05月25日

_ 報道の表現

先日のシュマイザー訴訟の件ひとつとっても、 どの報道を読むかによって、印象がまるで違う。

たとえば、NIKKEI NET

モンサント、遺伝子組み換え作物特許訴訟で勝訴

【ワシントン=吉田透】米農業バイオ大手モンサントが、同社開発の遺伝子組み換え作物の特許を侵害されたとしてカナダ農家を相手取って訴訟していた問題で、カナダ最高裁は21日、モンサント側の主張を支持する判決を下した。

<中略>

特許の有効性を巡り係争していたのは、モンサントが開発した除草剤耐性を持つ遺伝子組み換えナタネ。カナダ・サスカチワン州の農家が同社に特許使用料を支払わずに組み換えナタネを栽培していたとして、1997年に訴えていた。

モンサントが勝訴した点と、 「同社に特許使用料を支払わずに組み替えナタネを栽培していた」という内容からは、 シュマイザーさんの主張はまるで読み取れない。

一方、HotWiredの記事は、 もっとシュマイザーさんに同情的だ。

遺伝子組み替え訴訟:カナダ農家、最高裁でもモンサント社に敗訴
Kristen Philipkoski

2004年5月21日 9:44am PT  カナダ最高裁判所は21日(米国時間)、農業ビジネス大手の米モンサント社が、自社が特許を保有する遺伝子組み替えカノーラ[食用油をとる菜種の一種]の種を自分の畑に蒔いたとされる農家に対して起こした訴訟で、原告側の訴えを認める判決を僅差で下した。

<中略>

敗訴したものの、シュマイザー氏は個人的には勝利だと述べている。最高裁が今回、同氏は種から利益を得ていないという判断もあわせて下したからだという。シュマイザー氏は、訴訟費用と種から得た利益としてモンサント社から20万ドルを請求されていたが、これを払う必要はない。

「真実はいつもひとつ」なのかもしれないが、それに手が届くとは限らない。 あるいは「いつもひとつ」ではないのかもしれない。

_ [特許]特許の不条理

まったくですな

特許が実におかしなものに思える理由はこういうことじゃないでしょうか。つまり、特許を取った人がやったことや特許そのものを見ることで、それと同じアイディアを模倣した場合、模倣行為に制限がかかったり、お金を請求されたりする。これはまだ分かります。でも、何も見てないのに、真似しようともしてないのに、やったら似たようなアイディアになってしまった、それだけで訴えられる場合があります。そして、こうやって現実に裁判で負けちゃったりするわけです。

見ないで同じものが出来てしまうのであれば、最初の発明者が公開してようがしてまいが関係ないわけで、特許権が及ぶのはまさに不合理ですね。

確かにソフトウェア開発者としては同意できる意見だ。でもって、私の立場からは

逆に言えば、「アイディアを故意に盗んだことが証明できなければ、特許による独占権を発動できない」ことにすれば、特許もそう悪いものではないのかな?

にも同意したい。

でも、権利者の立場から言えば、「それでは盗用して偽装した人による侵害から保護されない」ということになるような気もする。ならば、

  • 公示(or 秘密の開示)される前に同様の発明を行ったことが証明できれば、 その人に対しては独占権を行使できない
  • 公示された特許への総合的な検索手段を無料で提供する

くらいならどうだろう。後者は弁理士の仕事を阻害しそうだが、 特許という権利が有効に働くためにはそれくらい必要な気がする。 現在弁理士の方には国家公務員になっていただくということで(いいのか、それで)。

_ [OSS]疑念払拭へ、Linuxの開発プロセス変更

誰がコードを導入したかの責任をとるプロセスを明確に文書化するというお話。

FSFがコードのコントリビューションに文書を要求するので面倒だと思っていたのだが、 とうとうLinuxもそうなってしまった、ということか。 オープンソースソフトウェアが社会的に重要なプレイヤーになるにしたがって責任も増すということなのだろう。 嬉しくないが、受容しなければならない変化なのだろうか。

とはいえ、Linuxだけでなくすべてのオープンソースソフトウェアにそのようなプロセスが必要、 という話になるとかなりイヤだな。Rubyとか権利関係が(とくに著作者人格権に関して)怪しい部分があるものな。

以前の牧歌的な開発が懐かしい。

_ [特許]特許の問題

nisさんからツッコミをいただいた。

特許は無料で検索できませんか? 特許庁や、US Patent Officeで。

でも、実際に専門家の話を聞くと、無料の検索では十分に見つからないので、きちんと調べようと思うと、結局それなりのコストをかけて弁理士なり知財部門なりに依頼する必要があるようです。たとえ、相当のコストをかけて専門家に依頼しても、たとえば「Rubyのどこかが既存の特許に抵触していないかどうか」という調査が可能かどうか自信がありません。

どうすれば産業や社会に貢献する発明を促せるか、というところから出来たのが発明者の権利を守るための特許法ですよね。そういうルールとインセンティブの構造を作ったうえで、みんなで競争して知恵を出そうと、やってきているのに、「ルールがあるなんて知らなかった、前例があるなんて知らなかった」がまかり通るのでは困りませんか?

私は特許の理念まで否定するものではありません。理想は素晴らしいと思います。

ですから、別に「前例があるなんて知らなかった」と言いたいわけじゃないんです。ただ、「訴えられない確信を得るためのコストが高すぎる」ということです。大企業ならそのコストを負担できるかもしれませんが、個人には無理です。 テクノロジーは個人にパワーを与えているのに、 法制度や経済情勢はますますビッグプレイヤー(大企業とか先進国とか)にだけ有利になっていくのは不合理に感じます。

そもそも既存技術、技術トレンド、他社の研究動向、特許申請状況を把握していないような技術者が、発明ができるようには思えません。

だったら良かったんですが、実際にはソフトウェアの分野では「特許申請状況を把握していないような技術者」が開発したものが、(結果的に発明になってしまって)他社の特許と衝突するケースがしばしばあります。

それは、

誰もが思いつくような発明に独占権を与えてしまうことがあるということが問題であって(FATファイルシステムとか)、発明登録制度自体に根元的な問題があるようには思えません。

ということで、 おっしゃる通り根源的な問題ではないのかもしれませんが、

  • 相当なコストをかけないと衝突しているかどうか十分に調査できない
  • 偶然衝突してしまった時に発生する不幸が大きい
  • 誰でも思い付くような発明に独占権が与えられることがたびたびあるが、それらを無効化するにも相当のコストがかかる

という現状は、特許の理想を達成するよりも、他者の妨害(ひいては人類全体の進歩の阻害)に向かっているのではないかと思います。

また、知財部門を持ち、それなりに調査を行っているはずの企業間でも特許紛争が絶えないことを見ると、 すでに現在、特許申請状況を把握することは誰にも不可能になりつつあるのではないかと感じます。 膨大な数の特許それぞれのクレームの全容(しかもそれらは拡大解釈されうる)を把握し、 自分のプロダクトがそれら全てを侵害していないことを確認することは、確かに困難を極めそうです。 いや、はっきり言って無理でしょう。

もし仮に既存の特許の全容を把握することが不可能なのであれば、すべての開発者(発明者)は、 まだ見ぬ特許権者から訴えられないように祈るよりほか手段がなく、 それは特許の理念からかけはなれたものになるのではないでしょうか。

現状の制度の下でそういう事態を避けるためには、 特許検索の分野で大胆な改革を行うことしか思い付かないのですが。 それでも十分ではないかもしれませんけど。

「誰でも思い付くような特許」が認められてしまうことそのものが、 既存の全ての特許、また公知の全ての知識を検索することが現実的でないことの証拠のような気がします。


2005年05月25日

_ 主夫3日目

子供を起こして、学校に送り出す。 上の娘は中学生で手がかからないが、 小学生はなかなか手がかかる。

長男は今日学校でやりたくないことがあると言ってぐずったあげく、 集団登校に参加できなかった。なんとかなだめて学校に連れていく。 次女は次女で忘れ物をしているので、それを届けに再び学校に。 なんでこんなに手がかかるんだ。

昼食が終わったころ、会社から電話。 ちょっと話し合いが必要なことがあるようだ。 しょうがないので、赤ん坊を連れてオフィスへ。

打ち合わせを終えてうちに帰ったら、すっかり疲れきっていて、 赤ん坊と一緒にうたた寝してしまう。

慌てて夕食を作り、食後に全員を連れて妻に面会。 今日もまた慌ただしい一日であった。

むかしから「なんでもできる人になりたい」と思ってきていて、 ようやく「プログラマの偉い人」くらいにはなれたんだが、 今回の経験で「主夫もできるプログラマ」にランクアップしたかも。

_ IPAX 2005 - 今語られるスーパークリエータの開発のきっかけ

一言に「未踏の人」といってもさまざまなわけだが、 その辺を分析していて面白い。

まず「そもそもなぜ未踏ソフトウェア事業に応募しようと思ったのか?」という点についてだが、これについては人それぞれの意見が出た。

...

ただ多くの開発者に共通するのが「自分が欲しいソフトを作る」という点。

...

「ソフト開発に必要なスキルはどこで身につけたか?」という質問に対しても、浜田氏や登氏など「開発の過程やそれ以前の段階(研究・趣味などを通じて)で独学で身につけた」という答えが一般的で、平林氏のように「元々職業プログラマだった」というのはむしろ少数派。

ま、いろんな人がいるのが面白いところだし、それができている点が「未踏」の最大の成功点だと思っている。

未踏のメリットとしてあげられた

未踏のメリットとして開発者の多くが挙げたのが「開発者同士の交流」。未踏ソフトウェア事業では各開発者が自らの成果を発表する合同の中間報告会や、発表会が開かれることが多いが、その席上において他の開発者の報告を聞いたり、その後の懇親会等で開発者同士が交流したりという中で、いろいろと有益なアイデアを得られることが多いという。

というのはよくわかる気がする。未踏に選ばれるような人間はどこかしら似たようなところがあるので、 交流することで有益なアイディアが出てくることってのはよくありそうだ。 もっとも、未踏でなくても、学会やオープンソースコミュニティでもそのようなことは起きるので、 これが「最大のメリット」とされちゃうとちょっと(だいぶ?)さみしい気がする。

できることなら「他の人は本気にしてくれなかったアイディアに投資してくれる」ということを メリットとしてあげてほしかったなあ。

しかし、デメリットとしてあげられた点はちょっと意外だった。

一方で問題点として挙がったのが、まず「期間が短い」割に「すぐ商品化できるものを求める」という点。渡辺氏は「未踏ソフトウェア事業は開発期間が短く、そこで作ったものをそのまま世に出せるところまで持って行くのが難しいため、未踏の期間が終わるとせっかくの技術が埋もれてしまう」と述べ、今後は「ポスト未踏」が必要だと語った。

期間が短いのはわからないでもない。未踏はスタートアップを支援する仕組みなので、 継続的な開発には向かない点があるのは確かだ。意外なのは「すぐ商品化できるものを求める」こと。 私は初年度の未踏だったせいか、そんな雰囲気は余り感じなかった。 まああれからIPAの独立法人化もあったし、やや方向性に変化があったのだろうか。

未踏の仕組みは「すぐ商品化できるもの」の育成には向かないと思うのだが。

「ポスト未踏」が必要か、というとよくわからない。私の中の未踏のイメージでは、 ちょっと違うもののような気がする。ま、おんなじ未踏でもビジネス色の強いPMやプロジェクトも多いし、 逆にオープンソース風味のプロジェクトも多い。前者と後者では感じかたも違うかも。

個人的には前者と後者できっちり分けちゃった方が良いと思うけどね。 前者は「未来ベンチャー支援」みたいな方向で、 後者は「技術発掘(or 技術者発掘)」を目指すということで。


2006年05月25日

_ [Ruby] Zed on Ruby, Rails, Mongrel, and More - O'Reilly Ruby

Rubyによる高速WebサーバーMogrelの開発者、Zed Shaw へのインタビュー。

個人的に一番感銘を受けたのは、実はインタビュアーであるPat Eylerの経歴

Pat Eyler is an Infrastructure Engineer for the LDS Church by profession, a Ruby geek by choice, and a writer by night. He enjoys reading, cooking, spending time with his family, and helping to build the Ruby community.

同じ教会の人だとは知ってたけど、フルタイムで教会職員をしているとは知らなかった。 実は、教会公式サイトでもRubyが動いていたりして。

さて、第三者にはどうでもいい話は置いといて、 インタビューを読むと彼が速度と信頼性についてきちんと考えていることがわかる。 ちゃんと測定、ちゃんとテスト。これにまさるツールはない。

_ 子ども・家族にかけるお金を考える(第10回)

いや、老後のことを考えると子供がいて、 その子が面倒を見てくれるというのが理想ではあるが、 それを理由に結婚したり出産する人はあまりいないような気がする。

それを考えると、この文章の説得力が急に下がる気がするのはなぜだろうか。

いや、子供はかわいいけどね。

_ Summer of Code Advice For Ruby Central Applications

RubyGemsの原作者(というか発案者)でもあるRyan Leavengoodがまとめた Google Summer of Codeに(Ruby関連で)参加する人へのアドバイス。

  1. Rails関連のプロジェクトで応募しない。今回のホストはRubyCentrailであって、RailsCentralではない。また、「人手が足りないところ」という点ではRubyの方がたくさんある。
  2. オリジナルであれ。人まねは採用されない。
  3. 成果物を具体的に。なにをするのか曖昧な応募が多すぎる。
  4. コミュニティで知られるように。ruby-talkで見たことのある人ならそれだけで注目される。
  5. Google templateを使わない。つまらない応募になってしまう。
  6. 早めに応募し、必要に応じて応募内容を改定すること。メンターとしてはあんまり言いたくないが、早い方が注目されやすい。50も応募を受けると〆切直前に来たものをずっと早く来たものと同じ集中力でチェックするのは困難だ。メンターも人間だし。
  7. 応募内容を自分でよく再確認した上、他人にも読んでもらうこと。

他の応募(未踏とか)でもある程度あてはまりそう。


2007年05月25日

_ [Ruby] 報國挺身日記 - 5.7.0がマージされた件について

小迫さんにとって不快なことをしてしまったようだ。

先日私はRuby 1.9に鬼車5.7.0をマージした。 これは別に企むところがあったわけではなくて、 5.xでしか提供されてない機能が欲しくなったのと、 今後実装するM17N機能の実装に5.xのAPIの方が都合が良かったから(UTF-16も処理できるし)。

で、この場合、Rubyは単なる鬼車の利用者なので、 鬼車のライセンスはBSDライクだし、利用する前に 相談するとか許諾を求めるとかは考えてなかった。

で、今後、Rubyの都合で鬼車本体に手を入れてもらう方が (我々にとって)都合が良いようなことがあったら、 その時点で相談しようと思っていたのだった。

だから決して「拒否のメールを受けることが僅かでも損になると思った」などということはない。小迫さんが我々の都合に合わせたくなければ(そして、そう思われるなら、それはもっともな拒否だと思う)、我々の方で勝手に追随するまでのことだから。

不快な思いをされたのであれば、その点については謝罪したい。

とはいえ、

これから私にできることは何もありませんので、今後何も起こりません。従って、この件について私にメール、コメント等を送らないでください。返事をしませんので。

ということなので、取りつく島はないのかも。

_ [Ruby] InfoQ: Evan Phoenix hired to work on Rubinius

JRubyチームに引き続き、Eval PhoenixもRubiniusの開発のために雇用された(半分だけど)、という話。

Rubyがいろいろな人の生活を変えていくのは、驚きである。 ちょっと恐い気もする。

_ [Ruby] Ruby.Badbunny - Symantec.com

Rubyを使ったウィルス、なのかな。危険度は低いらしい。

っていうか、Windowsで/usr/local/binとかあるのってどういう状況? Cygwin?

_ [Ruby] rubyneko - RubyでえせMapReduceもどきを作ってみた。

RubyスレッドでMapReduceを実現した話。 あまりRubyのスレッドをいじめないでください。

Ruby 1.8までのスレッドはスタックを毎回まるごとコピーしているので コンテキストスイッチのコストがめちゃめちゃ高い。 「動く」とか「使える」とかは言えるけど、間違っても「性能が良くなる」なんてことは言えない。

でも、1.9(YARV)で落ちるってのはなんでだろう? ネーティブスレッドのスタック領域を使いきったかな?

_ [Ruby] RubyForge: The Omnibus Concurrency Library

ActorをRubyで実現するライブラリ。 ActorってのはScala風なんだろうか。まだ調べてないけど。

利用例はこんな感じになる。

require 'concurrent/actors'
include Concurrent::Actors

RequestGreeting = Struct.new :reply_to
Greeting = Struct.new :value

# spawning a new actor
oracle = Actor.spawn do
  greeting = "Hello"
  loop do
    # guarded receive (does case-like matching via #===)
    Actor.receive do |f|
      f.when Greeting do |m|
        greeting = m.value.dup.freeze
      end
      # callback part 1
      f.when RequestGreeting do |m|
        m.reply_to << Greeting[greeting]
      end
    end
  end
end

# sending a message to an actor
oracle << Greeting["Howdy"]

# getting a reference to the current actor
current = Actor.current

# callback part 2
oracle << RequestGreeting[current]
Actor.receive do |f|
  f.when Greeting do |m|
    puts "#{ m.value }, Bill!"
  end
end

結構、気持ちのいいAPIである。性能はどうだろう。 現時点ではあんまり期待できないかな。将来に期待か。

_ [Ruby] M17N化

作業中。とりあえずstring.cは終わった。


«前の日(05-24) 最新 次の日(05-26)» 追記