2006年5月31日水曜日

Ruby on Rails 30分 Hacking

お題はもちろん「キューピー3分クッキング」のもじりです。
次回の情報科学を学んでいる人向けのなんでもセミナーで発表&デモを行う予定です。時間・場所等の詳細は追って紹介します。

「Ruby on Rails 30分 Hacking」

概要
Ruby on RailsはWebアプリケーション開発のためのノウハウが集積されているフレームワーク&ライブラリです。今回は、RailsやWebアプリケーション開発の基礎について説明し、実際にRailsを用いて、30分間で、wikiを実装するデモを行います。ファイル添付機能付き、さらに、AJAXを使ったwikiのdynamic
preview機能などにも挑戦します。

RubyやSQLを使用しますが、これらについて知らなくても、理解の上で支障はないかと思います。
3分~15分くらいの短い時間でも、DBを使った簡単なWebアプリケーションは作れるのですが、それだと、情報系の人を唸らせるところまではいかないと思い、30分にしました。キューピーの10倍です。

キューピー3分クッキングの舞台裏の紹介番組を見たことがありますが、あの番組は本当に生放送で、料理人一人ではなく、実は多数のスタッフの人が、見えないところで、調理、盛りつけ等を手伝っているのです。

それに比べれば、今回は本当に1人でデモをするので、30分なら妥当な線かと。Java+Struts+JSP+JDBCでWebアプリケーションの開発をしようものなら、こんな時間では設定すら終わりません。

既に30分で実装を終わらせることはできるのですが、見ている人にわかりやすいようにデモをするには、もうちょっと練習が必要そう。乞うご期待。

2006年5月30日火曜日

ys: 「 理想と現実の狭間の教育基本法 」

ys: 「 理想と現実の狭間の教育基本法 」 より引用。

「愛国心ではなく、日本を愛する心の涵養としたのは、そうすれば、日本人と日本国を作りあげてきた祖先の生き方も伝統も文化文明も、全て包含される からです。聖徳太子以来の日本、大化の改新で太子の理想を具現化した日本、古事記や日本書紀に記されている日本国の足跡、そこから窺える日本人の価値観全 てを愛する心という意味で『日本を愛する心』としました」

聖徳太子、大化の改新、奈良時代に編纂された古事記と日本書紀を縦軸として貫くのはまさに旧き良き日本の価値観である。そこには、神道も仏教も含め た宗教への畏敬、天皇を戴く皇室の尊重、皇室を支えてきた男系男子による皇統の継続、善き道徳心、上も下も睦(むつ)びて和の精神を尊重することなどが、 当然含まれる。


この件で、皇室の男子系等を尊重すべきとまでいくのは拡大解釈だと思いますが、それはそれとして、民主党の教育基本法の改正案と、その意図に関してまとめてあるこの記事には一見の価値があります。


このような教育基本法のあり方だと、歴史を学ぶことの意義も見えてきます。特に、国際交流の敷居が低くなった現代人にとって、自国の歴史や価値観がどう変遷したかを学ぶことは、他国籍の人とコミュニケーションを図る上でも重要なことがらだからです。 別に戦うわけではありませんが、孫子の兵法にもあるではありませんか。「彼を知り己を知らば百戦してあやうからず」、と。

# 外交で日本が完全に負けているのは、己も他も知らないからに尽きます。

現代の日本人の心に根付くものは、古来よりの宗教であったり、武士道であったりしますが、そのような日本人の価値観・美徳を、歴史の授業を通して学べなかったことが悔いに残ります。そもそも高校までの歴史の授業がそのようなものを学ぶ場ではないとしたら、これから学べばいいだけのことですが。

今の日本を「愛せ」ではいけません。その部分だけを取り出すと軍国主義という印象がぬぐえないのです。一方、日本を愛する心を「涵養」するというのは、素敵な目標だと感じます。国を愛せるようになるためには、国を愛すべき姿に変えていくという過程も大切ですから。人々の政治や経済への関心を高めたり、公職に就く人には税金を貪る姿勢を自戒させるような精神を養わないといけません。

GyaOの苦しみの理由

【レポート】GyaOの苦しみ - 独自コンテンツの死角と活路 (MYCOMジャーナル)

GyaOの上の記事は、経済批評にありがちな、実態を見ずに、数値や与えられたデータだけから判断している記事ですね。木を見て森を見ずの逆。独自コンテンツでテレビ局に対抗しようとしているのに力量不足だという内容なのですが、コンテンツの内容として、GyaOには新旧のアニメなどが豊富であるし、面白い映画も置いてあるのでとても魅力的だと思います。独自コンテンツがなくても、過去の映像のアーカイブはこんなにも魅力的なのかと思わされるくらいです。ビデオやDVDのレンタル店にいく気分ですね。

それと同時に、ポルノ的なコンテンツも多いから、うかつにGyaOは開けないという事情はさておき、視聴し始めてわかることは、強制的に広告を見させられる時間が長いということ。広告再生中に画面も非表示にできないし、大きさも自由には変えられない(ブラウザを強制的に全画面表示にする方式は特に最低です)

今は、HDDディスクレコーダーなどで、広告をスキップしてTVを見られる時代です。ロケーションフリーテレビを使えば、自宅に取りためた映像をネット越しに見られるところまで来ています。コンピュータを経由して映像を見るからには、テレビを越える快適さが大事です。まず、そもそも映像的にはパソコンのディスプレイ(液晶)は、表示速度、色の補完性能に関してブラウン管のテレビにはるかに劣ります。

その質の悪さだけでも辛いのに、広告を見なくては番組が視聴できないという不便が視聴者に課せられます。時代錯誤もいいところです。テレビと同じビジネスモデルがネットの世界で通用するはずがありません。広告を番組視聴中に見せる、番組と連動させて商品ページにつなげるなどの工夫が必要です。上の記事では、安い費用で番組を制作していることを非難していますが、ここは逆にメリットになるともいえます。中小企業でも、高い広告費や、制作費を使わずに、独自コンテンツを映像という形で情報発信できる場ができているということです。

広告なしで映像を配信する有料のサービスもあるのでしょう。けれど、そこまでの誘導の仕方もスムーズではありません。無料コンテンツを見るのも苦痛であるし、誘導の下手さ加減でかなりの顧客を逃していると考えられます。無料を売りにしているのに、有料サービスを前面に出せないという事情もあるのでしょう。そもそも完全無料という謳い文句は、顧客を集めるため、知名度をあげるために見栄を切っているだけとも考えられます。

GyaOは、新しいメディアを使っているのに、何一つ新しい機能や満足感を与えてくれません。一度使ったことがある人なら、誰もが感じていることでしょう。GyaOの収益が悪い理由は、視聴者にとって不便だからという一言につきます。今のままでは広告用のメディアとしても魅力的ではありません。木を見て森を見ずという以前に、木すらも見ずに記事を書くのはいかがなものかと。MYCOMはタイムリーな情報は提供してくれるけれど、記者の質が低いからか記事が面白くないのです。

2006年5月29日月曜日

ブラウザがデータベースを持つ日

Ian Murdock’s Weblog » The thin(ish) client revolution
上のブログを読んで触発されたので、一言。

Googleが提供するWebアプリケーションの魅力から、あらゆるデータがローカルからネットワークへ移行する、Web2.0の時代が来ると巷では騒がれています。 でも、どんな時代がくるか予測するのはさほど難しいことではないと思います。

今のインターネットブラウザの問題であり、なおかつユーザーやWebアプリケーション開発者の双方にとって不便なのは、現代のブラウザがページの移動時にstateless(ページのデータなど、状態を保持しない)という点。AJAXという技術で、ブラウザがキャッシュしているデータを部分的に変更しながら、状態を保持できるようになったこと。でも、これはアイデア的にも思想的にも新しい技術ではありません。現に、Flashは、当初からこのような通信の仕方を想定して作られています。 AJAXを技術屋さんの目から見ると、よくぞ使い難いJavaScriptで、HTTPのstatelessという欠点をカバーしてくれた!という程度の気分のもので、革新的なものではありません。

大学にWebサービス(事務処理関係)を納入している質の低いシステム開発会社だと、こういう技術すらも使えていなかったりするので、困り者なのですが。。。(高いお金を払って出来の悪いシステムを発注する大学にも、見る目のある人がいない。この手のシステムの開発には若いWeb世代の人を監視役に入れないとだめだよ。)

GoogleなどのWeb企業が開発を支援するFirefoxと、MicrosoftのIEの新versionの開発が進められていますが、両者の当面の目標は、程度の差はあれ、ブラウザが仮想マシン(OS)として動くようになることでしょう。Web上で閲覧したメールなどの情報をローカルにおいておくことができるようになるだけで、Web2.0における「ネットワークが断絶されると何もできない」という最大の困難は解決されてしまいます。

ポイントはリモート(サーバー側)とクライアント(ブラウザ側)でのデータの同期のとり方。そして、暗号化を行う手法。技術的にはどちらも既存のもの。でも、それらのつながりとしてのDBMS(DataBase Management System)がまだできていないのです。

Web2.0でMicrosoftがGoogleに敗北して停滞するなんてとんでもない。ブラウザがデータベース機能を持ち、デスクトップアプリケーション並のGUIを作成できるようになったとき、データの通信部分のみがHTTP(Web)という事実だけが残って、Webアプリケーション開発と言っても、再び、自前のDBとともに、Officeなど強固な製品を持つMicrosoftの土壌に戻ることでしょう。

Officeの信頼性や使いやすさを保ったままWeb経由でWikiを編集できると考えるだけでも、大きな進歩です。そして、それを実行するだけの力をMicrosoftは既に持っています。

リンク先のIan Murdockの記事にあるように、誰が、open sourceのLinuxをfat client(高機能ブラウザ)の世界に導くことができるか、というのも争点。

けれど、DBとブラウザをつなぐのが一番技術的に、かつ概念的に難しいところだと僕は考えます。Relational Databaseでそれが実現できるなら、当に実践されているはずです。でも、その気配が見られないところから推察できるように、ITの世の中はそんなに単純ではないようです。

自身の作るDBMSや周辺のアイデアがDBとブラウザの結びつきを促進するきっかけになればと思って、日々研究しています。もう一息。

2006年5月24日水曜日

[Research] 久々に業績

久々に、論文がacceptされました。1年ぶりくらい。ただのWorkshopだけど、program committeeの面々が学会の最前線で活躍している人ばかりだし、倍率が4倍と意外に競争が厳しかったので、素直にうれしい。

この論文が通っていないと、Bioinformaticsの業績と、今の研究テーマ(XML database)を綺麗につなげられなくて、かなり苦しかったのです。収入を犠牲に研究に時間を投資しているのに、Ph. Dを取れない恐怖に怯える毎日。

子供と一緒に家にいると、プログラミングや執筆作業がまったくと言っていいほど進められないのです。だから、ひとつ仕事を論文の形にまとめるだけでも、至難の業。Joel on Softwareという本に、プログラミングを10分中断されるだけで、仕事の効率ががた落ちするという話がありますが、まさに、その状況が毎日繰り返されます。時間が取れたとしても、人間なので、気分が乗らず、仕事がはかどらないときもよくあります。 アイデアがひらめいたら、すぐ仕事にかかれるわけではないことが何よりつらいです。論文を出して落とされる以前に、論文を締切日までに書ききれない日々が続いてたのです。

博士課程は精神力との戦い。社会保障もないし、年齢はそれなりに経ているのに、いたるところで身分的には学生として低い扱いをうけます。たとえ、僕と違って、独り身で時間たっぷり研究する時間がある人でも、自己管理(motivationの維持、成果への集中)が難しいこともあるでしょう。

まだまだ、Ph. Dが取れると決まったわけではないし(というか、まだかなり危ないライン…)、状況が改善されたわけでもないのですが、俄然、次の1本を書く意欲が湧いてきました。世の中に認められるということは、motivationを維持するのにとっても重要ですね。

2006年5月17日水曜日

ラーメンが食べたい

ダイエット中には厳禁だけれど、ラーメンが無性に食べたくなるがあります。

そこで、上野のラーメン屋さんを紹介。

一蘭
スープも飲みやすいし、唐辛子の秘伝のタレとの組み合わせが絶妙です。ただ、客を大量にさばく体制のためか、経験の浅い人もスタッフに混じるようで、麺の水切りが下手なアルバイトさんにあたると、味がぼんやりしてしまって「あれっ?」と思うこともあり。 座席ごとに敷居があって、一人だととても入りやすい店だけれど、子連れでいくには荷物を置く場所狭かったり。。。

光麺
クリーミーな熟成光麺はなかなか。炭火焼チャーシューは、昔はおいしかったのですが、最近は、炭火の香りがついた肉!という感じになってしまって残念。でも、その日の気分に合わせて、あっさり系(元祖)とこってり系(熟成)を選べるのがいいですね。

山頭火
本店の旭川は、塩ラーメンのみです。山頭火といえば塩。だから、旭川は醤油、札幌は味噌と言われるように、旭川ラーメンの中では山頭火はかなり異端児です。 上野店のとろ肉ラーメンはおいしいのですが、脂がくどくなってくるので、2人以上で分けて食べるのがおすすめ。

一風堂
とんこつラーメンの完成度としては、一蘭に及ばないかもしれないけれど、ごまやにんにくなど、一蘭にはないトッピングでラーメンの味に変化をつけて楽しめます。

麺屋武骨
いつも行列の割には、ここのラーメンをそれほどおいしいと思ったことがありません。。。味は悪くないと思うのですが、健康に悪そうな味なのです。チャーシューの切り方、麺の水切は豪快で見ごたえがあります。まさに「武骨」。

上野 大勝軒
池袋の有名店ののれんわけのようです。つけめんが主役。甘酸っぱいスープに、ボリュームたっぷりの麺。これならお手ごろ価格なのですが、お店がさほどきれいでもないことと、どうしても、つけ麺という形態では、ラーメンの「熱さ」を楽しめなくて、僕はあまり好きではありません。本店とは味が違うのかな?

御徒町近辺では、

青葉
魚介系と鶏ガラ系のダブルスープにとっても期待していたのですが、どうしてこの程度のインパクトしかない味でそれほど有名になれるのか不思議です。東京のあっさり系のラーメンは、わりとおいしいとそうでない味が紙一重になる気がします。

ちゃぶ屋味噌専門
みそラーメンとしてはおいしいしお店の雰囲気も良いです。けれど、味にインパクトが足りない…。札幌のすみれのスープに、この店の面とトッピングだといい組み合わせの気もします。すみれは麺が太すぎてスープとよく絡まないのです。まぁ、ちゃぶ屋なら元祖の塩を食べてみたい気もしますが、ここは味噌専門なんですよね。残念。

六角家
お店がとにかく汚いし、ラードやらにんにくで臭い!ラーメンが来るのを待つ間に気分が悪くなってしまいました。味としては、ラードを多用する旭川の蜂屋とやや似ているのですが、蜂屋ではこんな匂いに悩まされることはなく、むしろおいしそうな匂いがただよってくる印象だったのですが。。。


湯島に来ると、

大喜
ここも有名店でいつも行列。あっさり系で、おいしいので、何回か来たくなるような味です。開店10分前くらいに行くと、すんなり入れるのではないでしょうか。

本郷通りには、
初代けいすけ風天破天とラーメン屋さんが並んで激戦区の様相がありますが、その中では初代けいすけの黒いスープが他店にくらべて際立っているかも。でも、瀬佐味亭の坦々麺がこの界隈では一番のような気がします。


このあたり(文京区、台東区)では、一蘭などとんこつ系がおいしいのですが、まだ醤油ラーメンでおいしいものには出会っていません。旭川の蜂屋くらいやみつきになるスープのお店が欲しいのですが。

2006年5月11日木曜日

pukiwiki-mode.el

アイデア集/pukiwiki-mode - Meadow memo

今まで、Firefox-mozex-Meadowの組み合わせで頑張っていたけれど、
pukiwiki-mode.elで、Meadowから直接PukiWikiを編集する方が簡単だ。

もっと早く知っていれば…

2006年5月10日水曜日

久々にmixi巡回

懐かしい人にmixiで会えたので、調子にのって小・中・高の知人を検索。でも、同期のはずなのに、本人かどうかは結局わからないことが多いなぁ。

思う存分徘徊したので、あと1ヶ月くらいはmixiにログインしなくてもいいかも。
rubyでRSSリーダーのようにデータを自動で集積できるコードを書くと楽しいかな…。

2006年5月9日火曜日

[Open Source] もはやGPLはmustの存在ではない

自分の書いたソースコードについてどのライセンスを適用すればいいか、考えが整理されてきたので、オープンソースや、フリーソフトウェアについてまとめてみることにしよう。

GNU GPLはviral(伝染する)ライセンスであるから良くない、という主張は、オープンソース開発の本質を得ていない。Emacsの開発者でもあり、GPLの生みの親でもあるStallmanがこの方法を取ったのは、プログラムをproprietary(独占、転じてclosedの意)、つまり、特定の個人や企業の所有物とされたくないという考えが大本にあって、それを実現(強制)するための手段がGPLという形になっているだけだ。

他人の書いたコードに依存しないプログラムを書くことは、膨大な労力を要するものだ。開発者の知性や時間を、真に新しいプログラムを生み出す方向に向けるためには、過去に作られたプログラム、つまり知識や道具を誰もが利用できる形にし、それらをつなぎあわせることで不必要な作業を省き、創造する力を助長してあげなくてはならない。ソースコードが企業の利益のために隠されてしまって、創造が止まってしまうことを避けたいという信念がGPLの中にはある。

ここで、非公開でもうまくいく、とMicrosoftの例を挙げるのはかなり極端な話だ。確かに彼らは、Windows用のAPIを公開して内部実装を非公開にしているが、そのclosedな実装であっても、プログラマは利益を損なうどころか、APIの恩恵を享受して、プログラミングを快適にしてもらっている。でも、勘違いしてはいけない。彼らのビジネスモデルは、WindowsというOSを売ることであり、そのためには、Windowsの価値を向上させる必要がある。価値を向上するには、Windows上で動く品質の良いソフトウェアが多く誕生しなくてはならないのだ。そのために、他人任せではなく、熱心に次々とWindowsの機能を生かすためのコードを自社開発している。ただそれだけの話だ。

でも、コンピュータという創造力を無限に引き出すようなものの前では、Microsoft一社だけでその開発をすべてまかなえるほど、人間の新しいものを生み出す知性や創造力は限られてはいないということだ。確かにMicrosoftの貢献は大きい。Officeのように優秀で安定していて実用的なアプリケーションはとても便利だ。でも、品質のいい製品をマーケティングまで考えて開発するのは時間がかかるし、それもMicrosoftが超巨大企業になったからこそできることだ。でも、カレンダーのようなWebアプリケーションなど、今すぐ使いたいものを開発する小回りの良さでは、小さなグループで開発を進めるGoogleに完全に出し抜かれてしまっている。もし、Microsoftや他の企業がソースコードのすべてを独占し、オープンソースのコードやOSが存在しなかったらGoogleが台頭することなんてできなかっただろうし、我々がWebアプリケーションの便利さを知ることすらできなかったかもしれない。

この例だけでも、GPLが世に与えた影響は大きい。けれど、GPLを自分のコードに適用しようとすると頭の痛い問題を抱えることになる。著作権保持以外は商用利用もソースコード非公開でバイナリ配布など何でもありのBSDライセンスと同様に、ソースコードの利用に関して制限の緩いApache Software License (ASL) version 2.0が適用されたプログラムであっても、GPLライセンスのコードと組み合わせた場合、ともに配布することはできなくなってしまう。それはASLには、特許に関連する訴訟を起こした場合、ライセンスに書かれている権利を失効させる条項が含まれているからだ。ASLの権利を失うということは、ASLのソフトウェアを配布できないということを意味する。

GPLはソフトウェア開発を阻害するような特許訴訟を起こした人物にさえも判決が確定するまで、ソースコードを配布する自由を守ろうとしているし、ASLは、プログラマや企業の心の平穏を保つため、そのような特許訴訟に対しての対抗策を講じている。けれど、ここや、ここの話を見る限り、両者は対決をしているわけではないし、問題点は特許に関する条項のみであるから、歩み寄りの方向に向かうのであろう。GPLのページで、GPLと他のライセンスが適用されたコードを同時に配布できるか(compatibility)について、 こと細かに述べられているが、compatibilityの問題はさほど重要でもない。要するに、いろんな独自ライセンスのproliferation(増殖)のために、GPLの親であるFree Software Foundation(FSF)が、GPLの制約の維持に苦慮しているということだ。


でも、GPLを自分のコードに適用することを考えると、そのコードを書いたことに対する自分への金銭的な見返りが何もなくなってしまうことがとても恐ろしい。GPL製品を使う企業は、製品そのもののソースコードは公開しなくてはならないから、製品そのものを売ることはできないけれどその周辺(サポートビジネスなど)で対価を得ることはできる(バザール型)という。でも、そもそも個人プログラマがそんなビジネスを一からはじめるのは、とても大変だし、かなり長い道のりだ。かといって、ASLのように、非公開でコードがどんどん拡張されて利用されることが認められる場合には、自分のプログラムが何の断りもなしに金儲けに利用されてしまうのではないかと思ってしまう。ただ、GPLと違い、ASLの場合は、自分も非公開にしてお金を稼ぐことはできる。

たとえば、データの通信ライブラリを自分が作ったとして、それを他人が利用してWeb通販などのビジネスを始めたとする。Web通販部分は、自分の作ったものとは別個のものだから、そこにまで自分の権利が及ぶと考えるのは傲慢だと純粋に感じる。もし通販部分のソースコードを公開してしまえば、通販部分の開発費を他人のために投げ捨てる事態になってしまう。データ通信部分がGPLだと、まさにこの状況になる。差別化を計れる機能を実装しても、自分自身ですら商用に利用できなくなってしまう。まぁ、著作者ならGPL以外を適用すればいいのだが、GPL製品に囲まれてしまうと、すべての著作者やcontributorをたどってGPL以外の適用を認めるように依頼しなくてはならない。開発者の意思としては、BSDライセンスのように緩いものを適用するだけでよかったとしても、コミュニティの中で開発するためにGPLを選択した例も多いはずだが、その意思を確認することはほぼ不可能だ。

GPLはGPLのコミュニティ内で活動しているとき以外は、どうも自分の手足を縛るようなものの気がしてならない。創造性を助長するというよりは、窮屈さや将来への不安を感じてしまうものなのだ。ただ、変化するソースコードを公開したままにするcopyleftというのは決して悪いアイデアではない。

そうすると、Sun MicrosystemsがOpen Soralisに適用しているCDDL (Common Development and Distribution License)というライセンスがとても魅力的になる。mozilla.orgのFirefoxなどに適用されているMPLと同様に、ソースコードはファイル単位でライセンスが付与されるなど、ライセンスの適用対象が明確。それゆえ、違うライセンスが付与されたファイルとともに配布することができる(配布物全体に影響が及ぶGPLコードとともに配布することは無理だが)。ファイルを更改して配布した人には、ソースコードの公開義務(copyleft)を課すことができる。バイナリ形式で配布するときには、違うライセンスを付けてもいい、など。

Sun関連の人のblog(これとか、これとかこれ)を読むと、CDDLができた経緯や意図がわかって、さらに面白いかもしれない。

CDDLは、MPLがmozilla.org専用のものであるのに対し、commonと銘打たれていることからわかるように、MPLを汎用化したライセンスとなっている。GPLが他のライセンスとのcompatibilityで苦労した轍を再び踏まないようにしたいのであろう。プログラマが開発中に法律的な条項の解釈で悩むのは、やはり好ましくない。

CDDLを使いつつも、GPLコミュニティの中で自分のプログラムが生きていけるようにするには、mozilla.orgと同様に、GPLとCDDLのデュアルライセンスを検討するといい。GPL単独での利用で困難なのは、開発メンバーが多岐に亘った場合に、条件の緩いライセンスへの変更の意思を確認することである。最初から、開発者にGPLとCDDLの双方の条項に同意してもらえれば、Firefoxの成功例のように、企業、個人、非営利団体の垣根を越えて、オープンソースソフトウェアとして安心して開発を続けられるものになるはずだ。

ただし、デュアルライセンスという形態では、GPLプログラムとの共存が完全ではない。一度GPLプログラムを取り込むと、デュアルライセンスという形式はとれずGPLライセンスのプログラムとなる道しか選べないからだ。 LinuxのようなGPLで固められたOS用に移植することは可能だが、そうするとGPL専用、CDDL/GPL兼用の2つのbranchができてしまうことは想像に難くない。開発者は、GPL製品を利用することはできるが、それを利用してできたコードを、CDDL/GPLのデュアルライセンスの形に戻すことはできない。

面倒な問題は山積みだが、ライセンスを考える上でのポイントは、プログラマの心の平穏と、創造性を助けるもの、開発コミュニティの形成を促すライセンスであるかどうか、だ。CDDLはOpenSoralisで多数のプロジェクトが生まれているように、企業や個人を含めた開発コミュニティを作りやすくすることを目的としている。

GPLとのcompatibilityの問題のように、ライセンスにこの不具合があるからだめだとかという議論は、概して不毛であるし、いいものを作るというソフトウェアライセンスにこめられた本当の目的からは外れてしまう。LinuxのようにGPLによって得られた産物のインパクトの大きさから、GPLに反するライセンスを安易に卑下する意見が巷でよく見られるのだが、GPLの威力は、GPLのcopyleftの性質によるものなのか、それとも、GPLの適用範囲がそれを利用するものすべてに拡大していくことによるものなのか、を区別して判断しなくてはいけない。けれど、そのどちらについても、FirefoxやEclipse、Apache Software Foundation、PostgreSQLなどの成功例によって、copyleftが必ずしも必須ではないこと、ライセンスの適用範囲を広げなくても、いいものは出来上がることが示唆されている。もしかしたら、それらはGPLによってオープンソース開発の土台ができたことによって成功した例なのかもしれない。けれど、はっきりと言えることは、もはやGPLはmustの存在ではない、ということだ。

そうすると、一個人プログラマとしての僕にとって重要な指標は、自分が自分のソースコード(とそれを利用したアプリケーション)を自由に(商用・非公開を含めて)利用でき、改良が僕の知らないところで行われないという点だ。これらを満たす選択肢としては、CDDLが今のところ最良のものとなる。GPL非依存のライブラリも増えてきたこともあり、GPL製品に頼らなくても、コードを開発する土台がある今なら、GPLへ回帰する選択肢だけは残したまま、つまりCDDL/GPLというデュアルライセンスの形態をとり、GPL非依存のライブラリやツールを構築していくというのが、今の僕の結論だ。

License

Creative Commons LicenseLeo's Chronicle by Taro L. Saito is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.1 Japan License.