greenteaさんが怒ってらっしゃる。その怒りは理解できないでもない。
「バカが征く」はリンクしにくいんでこっちで要約しよう。 greenteaさんの指摘する問題と、それぞれに対する私の意見は以下の通り。
その通り。しかし、「オープンソースを利用するには、リーグ会員となる必要があります。」 という記述は、 株式会社フォーワンファーストによるものでゼンドのものではない。 ライセンスをはじめとするその他の記述との整合性を考えると、 こっちの記述が間違いである可能性が高い。 つまり株式会社フォーワンファースト(の担当者)の無理解が原因である。
それはそれで困ったものだが、彼らがオープンソースに貢献しようという態度をキャンセルするほどには まずくはないと思う。
それと、この件に関して私はgentlemanというわけではなく、 オープンソースをビジネスとする身として、 住んでいる領域が彼らの領域に近いってだけだと思うなあ。
動的言語について学ぶため、SunがPerl (Larry WallとDan Sugalski)、 Python (Guido van Rossum, Samuele Pedroni, Sean McGrath)、 Groovy (James Strachan)を呼んだというお話。
個人的な注目点。
ま、呼ばれても困るんだけどね。
Eolasの弁護士は正気なのだろうか。
Eolas Technologiesは、ブラウザがWebページに組み込まれたアプリケーションを認識して実行する機能に関して特許を保有しているが、この機能は Viola WWWブラウザを開発した“ペリー”・ペイ-ユアン・ウェイ氏が1993年にデモを行っており、これはEolasの特許が認められる5年以上も前のことだ−− 。コンスタンティン・トレラ弁護士はワシントンDCの米巡回連邦控訴裁で、裁判官を前にこう語った。
と、先行発明について指摘されると、こう反応する。
これに対してEolas側弁護士のマーティン・ルーク氏は、特許は有効だと反論。ウェイ氏のブラウザは後のバージョンでこの機能を捨ててしまい、自分のブラウザで組み込みアプリケーションを実行できる機能のデモは誰にも見せたことはなく、1993年5月のSun Microsystemsのエンジニアとの会合でも披露しなかったと主張した。ウェイ氏が行ったViolaのデモにはインターネットに接続されていないコンピュータが使われており、従ってSun関係者に対し、自分のブラウザでインターネットを介してアプリケーションが実行できる様子を示すことはできなかった、とルーク氏は述べている。
私の理解が正しければ、 特許は「後に捨ててしまった」かどうかは問題ではない。先に発明したかどうかが問題だ。 さらに言えば実装を誰かに見せる必要もない。そのアイディア(あるいはEolasの特許の新規性を失わせるに十分なアイディア)が、先に知られていれば十分無効にできる。
おそらくは「インターネットを介してアプリケーションを実行できる」ことが本質だ、 と主張したいのだろうが、だいぶ無理筋ではないかと。そもそもViolaはWWWブラウザなんだし、 たとえ、そのデモではインターネットを使わなかったとしても、 WWWブラウザであるViolaにプラグイン機能があれば「普通の技術者」は「インターネットを介してアプリケーションを実行できる」ことに気がつくだろう。
それで5億ドルぶんどろうっていうんだから、まったく。
追記:
CNETでも面白い主張が読める。発言者は「Robins, Kaplan, Miller & Ciresiのパートナーで、UCおよびEolasの代理人を務めるMartin Lueck」、つまり上記の「ルーク氏」と同一人物。
Weiが1993年5月に行ったデモは正当な先行技術とは見なされないと述べ、その理由として、このデモがインターネットに未接続のコンピュータ上で行われた点を挙げた。
上でも述べたが、あるデモがスタンドアロンコンピュータで実行されたからと言って、 それをインターネット上に展開することが、「普通の技術者」に思いつかない新規性のある発明であると言う主張には無理がある。ソケット通信は当時でも常識だったし、それについての知識が少しでもあれば、 ループバックデバイス上でローカル実行することとインターネットを介して実行することに本質的な違いはないことにすぐ気がつくはずだ。
さらにLueckは、「Weiのプロジェクトは、詳細が一切公開されず、立ち消えになった。コードの開発に大金をつぎ込みながら、それを利用することも公開することもしないのは権利放棄だ」と述べた。
確かに「権利放棄」であろう、特許的な見地からは。特許申請もしてないだろうし。 だから、Wei氏は5億ドルをマイクロソフトに要求できない。 が、Wei氏が権利を「放棄」したという事実は、Eolasが権利を主張できることを意味しない。
これはたとえWei氏が権利を放棄していようと関係ない。
このルーク(Lueck)氏は正気なのだろうか。
さて、正解はどれだろう？
Dave ThomasがPragmatic Bookshelfから出版するRubyシリーズの著者を募集している。[ruby-talk:123137]
英語圏でも256倍シリーズのような出版ラッシュが到来するのか。
Dave ThomasはPickaxe IIに続く2冊目としてRuby on Railsの本を書いているそうだ。
私自ら英語の本を書く根性はないが、応援したいものだ。
山陰中央新報は、島根県の地方紙だ。うちも取っている。今日は『特集 しまねIT新時代』なる折り込み別冊が入っていた。なんと、Rubyのことも載っている。田舎で開発されている「言語」はものめずらしいらしい。
通信環境生かし活動の輪
コンピュータ言語「Ruby」開発
...
世界に数千あるとされるプログラミング言語の中で、注目を浴びているのが「Ruby(ルビー)」と呼ばれる言語だ。
Rubyはソフトウェア開発などのネットワーク応用通信研究所(松江市学園南二丁目)に勤めるまつもとゆきひろさんが、十年前から開発してきた島根県発の言語といえる。
...
県は、Rubyを生かした産業振興を目指すため十月から、同社と、若者の就業を支援するふるさと島根定住財団ジョブカフェしまねに呼び掛け、県内でRubyを扱う技術者を育成する講習会をスタートさせた。
...
同社の井上浩社長は「Rubyを使おうと言う気運が盛り上がればうれしい」と、島根発の技術を島根の行政機関や企業で使う情報技術の「地産地消」に期待を込める。
さらに「Rubyを使える人が増えれば、県内で仕事や雇用が増え、県外から仕事も取れる」と、県の担当者もRubyを生かした産業振興の可能性に注目する。
「Rubyなら島根県といわれるようにしたい」。関係者が描く将来像だ。将来、多くの技術者を抱える島根にRubyの開発業務が集積する「Rubyの拠点」を目指す。
えーと、島根県は本気なんでしょうか。「情報技術の地産地消」って、いったいなんなんでしょうね。10年前には島根に住んでなかったとか、元々島根県の生まれじゃないとか、そういうことは置いておいて、 まつもとは島根県を応援します。
上記の将来像には、どこからか「取らぬ狸」という声が聞こえてきそうですが。
でも、ここまで目立つと下手に転職とか引っ越しとかできないなあ。島根県から出ていったら、裏切り者とか言われそう。
先日来、ruby-talkでRangeについていろいろと議論されていたことを解消できるめどが立った。
しかし、その完全解決にはひとつ、もしくはふたつメソッドを追加する必要があるのだが、 良い名前が思いつかないのだ。困った。
ひとつめは大小比較で包含関係を判定するRangeクラスのメソッド。 1.8でいうとinclude?に相当するのだが、1.9ではこれは基本的に、 要素として含むかどうかという離散的な包含関係を意味することにした。 ただし、include?とmember?は数だけは例外として大小関係で判定する。
名前の候補としては「encompass?」と「span?」があがっているが、 いまいちピンとこない。便利なメソッドなのでできるだけ短い名前にしたいのだが、
beg <= x <= end
という関係が明確に分かるとありがたい。
もうひとつは、succで作られる列に含まれるかどうかを判定するメソッド。 つまり、このメソッドの名前を仮にfooとしたとすると、
x.foo(beg,end)
は begからendまでsuccを使って順に値を生成した場合、その列にxを含むとき、真を返すというもの。 xを含まない、あるいはsuccを使ってbegからendにたどりつけない場合には偽を返す。
これがあるとinclude?などの包含関係の判定でループを回さなくてもすむので効率が向上する。 効率だけの問題なので、なくてもいいし、直接呼ばれることもないので短い名前である必要もない。 「between?」に近いのだがComparable#between?が大小関係で比較すると決まっているので、 離散的なこちらには別の名前をつけたい。
なにかいい名前はないものか。
娘の視力がまた下がったので、眼科へ。
待ち時間に娘は読書、私はPCを開けていろいろと。 しかし、ふと気がつくとキューに入れただけのはずのメールが配送されている。 知らない間に無線LAN接続していたらしい。FREESPOTか？
ま、ネットが使えるのはありがたいことではあるが。
集会終了後、米子でデボーショナルの衛星中継があるというので 参加しに行った。
クリスマスソングやクリスマスにちなむお話など、 クリスマスらしい気持ちを感じることができた。 今年も他の人にいい気持ちになってもらえるようなことを なにか一つでもしたいものだなあ。
なにがいいかなあ。
もう、ほぼ落ち着いたのだが、やや不満がある。
まあ、4と5は以前の環境ではできていなかったので、贅沢なんだけど。
2はKernel起動時にAPMを指定することで解決。 ACPIの方が温度とかたくさん情報がとれるので(メーター好きには)嬉しいんだけどな。
3はpowsersavedをアンインストールしてみるか。
追記
powersavedが正解。apmdを代わりにインストールしたら、 ネットワークが切れなくなった。gnome-power-managerは APMだとバッテリ状態がわからないみたい。
バッテリアプレットがちゃんと動くからメーターとしては問題ないんだけど。
発展的解消というプレスリリースだが、 まあ、結局はいろいろうまく行かなかったんだろうなあ。
やはりアプリケーションレイヤーでオープンソースというのはチャレンジが大きいのと 関係があるんだろうか。いや、オープンソースじゃなくてもチャレンジは大きいのだが。
アプリケーションレイヤーのように直接のユーザに近ければ近いほど、 いろいろな「注文」を一手に引き受けることになる。 日本のような「出来合いシステム」になじみのない環境では、 「ソフトに自分を合わせる」ということを要求するやり方は 受け入れられるためにかなり強い動機づけが必要になる。
それに比べたら、直接のユーザインタフェースを伴わない ミドルウェア、開発ツール、言語、OSはよっぽど簡単だ。 オープンソースソフトウェアの成功例がこのような分野に多いのは偶然ではないと思う。
とはいえ、アプリケーションレイヤーでの成功例もこれからどんどん出てきてほしいのだが。
(隠れた成功例: ORCA)
ボーイングが787の100億ドルの開発費を削減するために 積極的にアウトソーシングを押し進め、結果として20億ドル余計にかかった という話。
やはりコアな部分はアウトソースしてはいけない、ということだ。
ソフトウェア開発という多くの企業にとってそれなりに重要な部分を 受託開発という形で請け負っている会社の従業員としては 複雑な気持ちである。
が、みんながみんな結局はコア技術は自分のところで開発した方が良い ということに気がついちゃったら(実践できたら)、日本のIT業界は 完全にひっくり返るだろうな。
それでいいのか。いいのか。
で、思い出したのがしばらく前のこの記事。
いや、言ってることが間違いだとは思わない。
「日本には摺り合わせ文化があり，日本独自の文化と商習慣がある。社会基盤が異なる国で生まれた標準をそのまま適用するべきではない」（阿部氏）。
「システム開発において日本のSIベンダーはインドのSEと戦えるのか」という問いに対して「（顧客企業の業務ノウハウに強いなど）日本独自の世界でなら，日本がインドに負けるわけがない」と断言。「シリコン・バレーと同じことをしていたら，日本は他国に勝てるわけがない。逆に，日本独自の世界でなら，他国に負けるわけがない」
それは確かにそうなんだけど、それって「日本的な環境がこれからも維持されたら」とか 「日本だけで十分な市場規模が維持できたら」とか、 「日本の独自文化を維持するためのコストが正当化されるなら」というような、 今となってはいつまで続くかわからない暗黙の前提があるのではないか。 特に最後のが一番怪しい。
幕末期に「近接戦闘なら武士が負けるはずがない」と 言ってるようなもので、明治維新で武士という身分そのものがなくなってしまうような 前提条件がひっくり返りそうな気配が見える時に、 トップがそんな危機感のなさを公言してしまうのは、こちらが空恐ろしさを覚える。