今日は出雲支部の支部大会ということで、出雲訪問。
ずっと外回りばかりで、そろそろ松江に出たいんですが。 えーと、スケジュールを確認すると、来週は松江ですか。
先週は1.8の準備で忙しかったし、結婚披露宴の裏方などのせいか、 かなり疲れてしまい、うちに帰ると寝入ってしまった。
まあ、昼寝も安息日にふさわしい活動のひとつだそうだが。
先日のシュマイザー訴訟の件ひとつとっても、 どの報道を読むかによって、印象がまるで違う。
たとえば、NIKKEI NET。
モンサント、遺伝子組み換え作物特許訴訟で勝訴
【ワシントン＝吉田透】米農業バイオ大手モンサントが、同社開発の遺伝子組み換え作物の特許を侵害されたとしてカナダ農家を相手取って訴訟していた問題で、カナダ最高裁は21日、モンサント側の主張を支持する判決を下した。
<中略>
特許の有効性を巡り係争していたのは、モンサントが開発した除草剤耐性を持つ遺伝子組み換えナタネ。カナダ・サスカチワン州の農家が同社に特許使用料を支払わずに組み換えナタネを栽培していたとして、1997年に訴えていた。
モンサントが勝訴した点と、 「同社に特許使用料を支払わずに組み替えナタネを栽培していた」という内容からは、 シュマイザーさんの主張はまるで読み取れない。
一方、HotWiredの記事は、 もっとシュマイザーさんに同情的だ。
遺伝子組み替え訴訟：カナダ農家、最高裁でもモンサント社に敗訴
Kristen Philipkoski2004年5月21日 9:44am PT カナダ最高裁判所は21日(米国時間)、農業ビジネス大手の米モンサント社が、自社が特許を保有する遺伝子組み替えカノーラ[食用油をとる菜種の一種]の種を自分の畑に蒔いたとされる農家に対して起こした訴訟で、原告側の訴えを認める判決を僅差で下した。
<中略>
敗訴したものの、シュマイザー氏は個人的には勝利だと述べている。最高裁が今回、同氏は種から利益を得ていないという判断もあわせて下したからだという。シュマイザー氏は、訴訟費用と種から得た利益としてモンサント社から20万ドルを請求されていたが、これを払う必要はない。
「真実はいつもひとつ」なのかもしれないが、それに手が届くとは限らない。 あるいは「いつもひとつ」ではないのかもしれない。
特許が実におかしなものに思える理由はこういうことじゃないでしょうか。つまり、特許を取った人がやったことや特許そのものを見ることで、それと同じアイディアを模倣した場合、模倣行為に制限がかかったり、お金を請求されたりする。これはまだ分かります。でも、何も見てないのに、真似しようともしてないのに、やったら似たようなアイディアになってしまった、それだけで訴えられる場合があります。そして、こうやって現実に裁判で負けちゃったりするわけです。
見ないで同じものが出来てしまうのであれば、最初の発明者が公開してようがしてまいが関係ないわけで、特許権が及ぶのはまさに不合理ですね。
確かにソフトウェア開発者としては同意できる意見だ。でもって、私の立場からは
逆に言えば、「アイディアを故意に盗んだことが証明できなければ、特許による独占権を発動できない」ことにすれば、特許もそう悪いものではないのかな？
にも同意したい。
でも、権利者の立場から言えば、「それでは盗用して偽装した人による侵害から保護されない」ということになるような気もする。ならば、
くらいならどうだろう。後者は弁理士の仕事を阻害しそうだが、 特許という権利が有効に働くためにはそれくらい必要な気がする。 現在弁理士の方には国家公務員になっていただくということで(いいのか、それで)。
誰がコードを導入したかの責任をとるプロセスを明確に文書化するというお話。
FSFがコードのコントリビューションに文書を要求するので面倒だと思っていたのだが、 とうとうLinuxもそうなってしまった、ということか。 オープンソースソフトウェアが社会的に重要なプレイヤーになるにしたがって責任も増すということなのだろう。 嬉しくないが、受容しなければならない変化なのだろうか。
とはいえ、Linuxだけでなくすべてのオープンソースソフトウェアにそのようなプロセスが必要、 という話になるとかなりイヤだな。Rubyとか権利関係が(とくに著作者人格権に関して)怪しい部分があるものな。
以前の牧歌的な開発が懐かしい。
nisさんからツッコミをいただいた。
特許は無料で検索できませんか？ 特許庁や、US Patent Officeで。
でも、実際に専門家の話を聞くと、無料の検索では十分に見つからないので、きちんと調べようと思うと、結局それなりのコストをかけて弁理士なり知財部門なりに依頼する必要があるようです。たとえ、相当のコストをかけて専門家に依頼しても、たとえば「Rubyのどこかが既存の特許に抵触していないかどうか」という調査が可能かどうか自信がありません。
どうすれば産業や社会に貢献する発明を促せるか、というところから出来たのが発明者の権利を守るための特許法ですよね。そういうルールとインセンティブの構造を作ったうえで、みんなで競争して知恵を出そうと、やってきているのに、「ルールがあるなんて知らなかった、前例があるなんて知らなかった」がまかり通るのでは困りませんか？
私は特許の理念まで否定するものではありません。理想は素晴らしいと思います。
ですから、別に「前例があるなんて知らなかった」と言いたいわけじゃないんです。ただ、「訴えられない確信を得るためのコストが高すぎる」ということです。大企業ならそのコストを負担できるかもしれませんが、個人には無理です。 テクノロジーは個人にパワーを与えているのに、 法制度や経済情勢はますますビッグプレイヤー(大企業とか先進国とか)にだけ有利になっていくのは不合理に感じます。
そもそも既存技術、技術トレンド、他社の研究動向、特許申請状況を把握していないような技術者が、発明ができるようには思えません。
だったら良かったんですが、実際にはソフトウェアの分野では「特許申請状況を把握していないような技術者」が開発したものが、(結果的に発明になってしまって)他社の特許と衝突するケースがしばしばあります。
それは、
誰もが思いつくような発明に独占権を与えてしまうことがあるということが問題であって（FATファイルシステムとか）、発明登録制度自体に根元的な問題があるようには思えません。
ということで、 おっしゃる通り根源的な問題ではないのかもしれませんが、
という現状は、特許の理想を達成するよりも、他者の妨害(ひいては人類全体の進歩の阻害)に向かっているのではないかと思います。
また、知財部門を持ち、それなりに調査を行っているはずの企業間でも特許紛争が絶えないことを見ると、 すでに現在、特許申請状況を把握することは誰にも不可能になりつつあるのではないかと感じます。 膨大な数の特許それぞれのクレームの全容(しかもそれらは拡大解釈されうる)を把握し、 自分のプロダクトがそれら全てを侵害していないことを確認することは、確かに困難を極めそうです。 いや、はっきり言って無理でしょう。
もし仮に既存の特許の全容を把握することが不可能なのであれば、すべての開発者(発明者)は、 まだ見ぬ特許権者から訴えられないように祈るよりほか手段がなく、 それは特許の理念からかけはなれたものになるのではないでしょうか。
現状の制度の下でそういう事態を避けるためには、 特許検索の分野で大胆な改革を行うことしか思い付かないのですが。 それでも十分ではないかもしれませんけど。
「誰でも思い付くような特許」が認められてしまうことそのものが、 既存の全ての特許、また公知の全ての知識を検索することが現実的でないことの証拠のような気がします。
子供を起こして、学校に送り出す。 上の娘は中学生で手がかからないが、 小学生はなかなか手がかかる。
長男は今日学校でやりたくないことがあると言ってぐずったあげく、 集団登校に参加できなかった。なんとかなだめて学校に連れていく。 次女は次女で忘れ物をしているので、それを届けに再び学校に。 なんでこんなに手がかかるんだ。
昼食が終わったころ、会社から電話。 ちょっと話し合いが必要なことがあるようだ。 しょうがないので、赤ん坊を連れてオフィスへ。
打ち合わせを終えてうちに帰ったら、すっかり疲れきっていて、 赤ん坊と一緒にうたた寝してしまう。
慌てて夕食を作り、食後に全員を連れて妻に面会。 今日もまた慌ただしい一日であった。
むかしから「なんでもできる人になりたい」と思ってきていて、 ようやく「プログラマの偉い人」くらいにはなれたんだが、 今回の経験で「主夫もできるプログラマ」にランクアップしたかも。
一言に「未踏の人」といってもさまざまなわけだが、 その辺を分析していて面白い。
まず「そもそもなぜ未踏ソフトウェア事業に応募しようと思ったのか?」という点についてだが、これについては人それぞれの意見が出た。
...
ただ多くの開発者に共通するのが「自分が欲しいソフトを作る」という点。
...
「ソフト開発に必要なスキルはどこで身につけたか?」という質問に対しても、浜田氏や登氏など「開発の過程やそれ以前の段階(研究・趣味などを通じて)で独学で身につけた」という答えが一般的で、平林氏のように「元々職業プログラマだった」というのはむしろ少数派。
ま、いろんな人がいるのが面白いところだし、それができている点が「未踏」の最大の成功点だと思っている。
未踏のメリットとしてあげられた
未踏のメリットとして開発者の多くが挙げたのが「開発者同士の交流」。未踏ソフトウェア事業では各開発者が自らの成果を発表する合同の中間報告会や、発表会が開かれることが多いが、その席上において他の開発者の報告を聞いたり、その後の懇親会等で開発者同士が交流したりという中で、いろいろと有益なアイデアを得られることが多いという。
というのはよくわかる気がする。未踏に選ばれるような人間はどこかしら似たようなところがあるので、 交流することで有益なアイディアが出てくることってのはよくありそうだ。 もっとも、未踏でなくても、学会やオープンソースコミュニティでもそのようなことは起きるので、 これが「最大のメリット」とされちゃうとちょっと（だいぶ？）さみしい気がする。
できることなら「他の人は本気にしてくれなかったアイディアに投資してくれる」ということを メリットとしてあげてほしかったなあ。
しかし、デメリットとしてあげられた点はちょっと意外だった。
一方で問題点として挙がったのが、まず「期間が短い」割に「すぐ商品化できるものを求める」という点。渡辺氏は「未踏ソフトウェア事業は開発期間が短く、そこで作ったものをそのまま世に出せるところまで持って行くのが難しいため、未踏の期間が終わるとせっかくの技術が埋もれてしまう」と述べ、今後は「ポスト未踏」が必要だと語った。
期間が短いのはわからないでもない。未踏はスタートアップを支援する仕組みなので、 継続的な開発には向かない点があるのは確かだ。意外なのは「すぐ商品化できるものを求める」こと。 私は初年度の未踏だったせいか、そんな雰囲気は余り感じなかった。 まああれからＩＰＡの独立法人化もあったし、やや方向性に変化があったのだろうか。
未踏の仕組みは「すぐ商品化できるもの」の育成には向かないと思うのだが。
「ポスト未踏」が必要か、というとよくわからない。私の中の未踏のイメージでは、 ちょっと違うもののような気がする。ま、おんなじ未踏でもビジネス色の強いＰＭやプロジェクトも多いし、 逆にオープンソース風味のプロジェクトも多い。前者と後者では感じかたも違うかも。
個人的には前者と後者できっちり分けちゃった方が良いと思うけどね。 前者は「未来ベンチャー支援」みたいな方向で、 後者は「技術発掘(or 技術者発掘)」を目指すということで。
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が動いていたりして。
さて、第三者にはどうでもいい話は置いといて、 インタビューを読むと彼が速度と信頼性についてきちんと考えていることがわかる。 ちゃんと測定、ちゃんとテスト。これにまさるツールはない。
いや、老後のことを考えると子供がいて、 その子が面倒を見てくれるというのが理想ではあるが、 それを理由に結婚したり出産する人はあまりいないような気がする。
それを考えると、この文章の説得力が急に下がる気がするのはなぜだろうか。
いや、子供はかわいいけどね。
RubyGemsの原作者(というか発案者)でもあるRyan Leavengoodがまとめた Google Summer of Codeに(Ruby関連で)参加する人へのアドバイス。
他の応募(未踏とか)でもある程度あてはまりそう。
小迫さんにとって不快なことをしてしまったようだ。
先日私はRuby 1.9に鬼車5.7.0をマージした。 これは別に企むところがあったわけではなくて、 5.xでしか提供されてない機能が欲しくなったのと、 今後実装するM17N機能の実装に5.xのAPIの方が都合が良かったから(UTF-16も処理できるし)。
で、この場合、Rubyは単なる鬼車の利用者なので、 鬼車のライセンスはBSDライクだし、利用する前に 相談するとか許諾を求めるとかは考えてなかった。
で、今後、Rubyの都合で鬼車本体に手を入れてもらう方が (我々にとって)都合が良いようなことがあったら、 その時点で相談しようと思っていたのだった。
だから決して「拒否のメールを受けることが僅かでも損になると思った」などということはない。小迫さんが我々の都合に合わせたくなければ(そして、そう思われるなら、それはもっともな拒否だと思う)、我々の方で勝手に追随するまでのことだから。
不快な思いをされたのであれば、その点については謝罪したい。
とはいえ、
これから私にできることは何もありませんので、今後何も起こりません。従って、この件について私にメール、コメント等を送らないでください。返事をしませんので。
ということなので、取りつく島はないのかも。
JRubyチームに引き続き、Eval PhoenixもRubiniusの開発のために雇用された(半分だけど)、という話。
Rubyがいろいろな人の生活を変えていくのは、驚きである。 ちょっと恐い気もする。
Rubyを使ったウィルス、なのかな。危険度は低いらしい。
っていうか、Windowsで/usr/local/binとかあるのってどういう状況？ Cygwin?
RubyスレッドでMapReduceを実現した話。 あまりRubyのスレッドをいじめないでください。
Ruby 1.8までのスレッドはスタックを毎回まるごとコピーしているので コンテキストスイッチのコストがめちゃめちゃ高い。 「動く」とか「使える」とかは言えるけど、間違っても「性能が良くなる」なんてことは言えない。
でも、1.9(YARV)で落ちるってのはなんでだろう？ ネーティブスレッドのスタック領域を使いきったかな？
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である。性能はどうだろう。 現時点ではあんまり期待できないかな。将来に期待か。
作業中。とりあえずstring.cは終わった。