フリーソフトウェア運動は方向性を間違えてはいない

TechCrunchの翻訳記事でフリーソフトウェア運動はどこで方向性を間違えたのか（そしてその修正方法）というものが掲載された。この記事を読んだとき、そもそもそのタイトルに違和感を覚えてしまった。疑問が「どこで」というものになっているので、何だかフリーソフトウェア運動が方向性をすでに間違えているような印象を与えるわけだが、そもそもフリーソフトウェア運動は方向性を間違えているのだろうか？すでにタイトルで結論を書いてしまっているが、興味のある方はぜひ少しだけお付き合い頂きたい。

LPI-Japanによるオープンソースデータベース技術者認定試験の名前を見直すべき5つの理由

前回のエントリでは、真のオープンソースとは何か？と題して、LPI-Japanがオープンソースの定義を間違えているという点を指摘した。今回はさらに別の角度から、この認定試験の名前を変更するべき理由について考えてみたい。

真のオープンソースとは何か？

@tmaesaka氏からのツイートで知ったのだが、LPI-Japanが見過ごすことが出来ない発言をしている。

PostgreSQL技術者を認定、LPI-Japanが「OSS-DB技術者認定試験」開始 - ITpro

以下、引用。

OSS-DBには、PostgreSQLと米OracleのMySQLがあるが、「特定ベンダーの管理下にあるソフトは真のOSSとは言えない」（LPI-Japanの成井弦理事長、写真）として、今回スタートするOSS-DB ExamではPostgreSQLのみを対象とした。

これはおかしなことだ。一体誰が「特定ベンダーの管理下にあるソフトはOSSではない」などと決めたのだろう？

Fedora 14のインストールに10分かからなかった件

改めて計測してみたら自分でもびっくりした。VirtualBoxを使ってFedoraをインストールしたら10分かからなかったのである。いつも「嫌に早いな」とは思っていたけれど、まさか「仮想マシンを作ってFedora 14をインストールし、ブラウザを起動して本ブログを開くまでに8分程度しかかからない」というのは驚きである。

YouTubeにその様子をアップしてみたのでぜひ一度ご覧頂きたい。Linuxのインストールに慣れた人にとっては退屈な光景だろうが、Windowsしかインストールしたことないよ！という人にとってはきっと驚きと発見があるはずだ。

日本人として今回の著作権法改正に反対する理由

朝日新聞によると、日本版DMCAとも言える法案が文化庁から提案されようとしている。

--- 引用 ---
ＤＶＤやブルーレイなどに収録されている市販の映画やテレビドラマなどの映像ソフトをコピー（複製）する行為は、家庭内であっても違法になりそうだ。暗号化技術を使って保護されているソフトが対象で、保護を破るプログラムの製造や配布も禁止される。ネット上にあふれる「海賊版」を抑制するのが狙い。文化庁が３日、方針を固めた。

これは、映画会社に一時的な利益をもたらすかも知れないが、社会にとって如何に弊害をもたらす行為かということを、文化庁はまるで分かっていない。ソフトウェア産業が萎縮するだけでなく、利用者にとっても、そして本来利益を享受できるはずだった利権者側にとっても最終的には不利益となるであろう法案である。一体誰が得をするというのだろうか？

今日は、如何にこの法案が間違っているかということについて論じようと思う。

"オープンソース"の名を冠したプロプライエタリな人向けのセミナーに参加した件

先月中旬の話になるが、マイコミジャーナルで紹介されていた「事例に学ぶ オープンソース知財セミナー2010」というセミナーに参加してきた。（主催はオージス総研）サブタイトルは「オープンソースに潜む法的リスクとその対策のヒント」という謳い文句であり、オープンソース独特の法的リスクの話が聞けるかも知れないと思い申し込んだ。だが、結果は見事に裏切られた！

ひとことで言うと、今回のセミナーはオープンソースのセミナーではなかった！というのが拙者の正直な感想である。あまりにも酷い内容だったと言って差し支えない。酷かったのは各々のプレゼンの質などではなく、その欺瞞に満ちたメッセージである。そのようなメッセージを放置すると、オープンソースに対する誤った知識が広まる恐れがあるので、本エントリにて批判させて頂こうと思う。

オープンソースの道 〜 よりよい社会を育てる方法 〜

最近、自治体においてオープンソースソフトウェア（以下OSS）を採用する例が増えてきたように思う。(注1)ニュースに上がったものだけでも、次のような例がある。

• 自治体に広がるOpenOffice.org - ITpro
• さらばWindows、Linux時代幕開け - 読売新聞
• 県が「オープンオフィス」導入へ　次期オフィスソフト - 山形新聞

ニュースになっているのはOpenOffice.orgやGNU/Linuxであるが、採用に至った主な理由はOSSにするとコストが下がるからであると記されている。確かにOSSはタダだ。商用で提供されているものもあるがタダでオペレーティングシステム（以下OS）やオフィスソフトのように人数に応じたライセンスが必要なものは、そのライセンスコストだけでも相当な額になる。しかも古くなってソフトウェアを更新するたびにライセンス料金が発生してしまう。それがタダになるのは確かにメリットがある。

ここでひとつ疑問が生じる。OSSはタダで配布されているが、開発者の給料はタダではない。現在OSSの恩恵を謳歌しているユーザーはこう不安に思うかも知れない。「もしかしたら今使ってるこのOSSは今後使えなくなってしまうのでは？だって開発者はどうやって食ってるのか分からないから！」と。OSSをどうやって育んでいくかは、OSSのメリットを理解している人にとって興味のある事柄であろう。そこで、今日はどうやってOSSの発展に貢献できるかということについて、論じてみようと思う。

無料のソフトウェアをフリーソフトと呼んではイケない理由

俺のようにフリーソフトウェア＝自由なソフトウェアだという、リチャード・ストールマン支持者は当然のごとくそのような誤ちを犯してはならないのだが、そうではない全ての人にとっても無料のソフトウェアをフリーソフト（もしくはフリーウェア）と呼ぶべきではない理由がある。

Desktop Linux Is Great

最近、PC Worldに「Desktop Linux: The Dream Is Dead」という記事が投稿され、非常に多くの注目を集めているようである。筆者はGNU/Linuxをデスクトップとして愛用しているが、決して「もう終わりだ」などとは感じていない。むしろようやく始まったな！と実感しているところである。筆者は「LinuxにはGNUを冠せよ！」などと思っているフリーソフトウェア支持者であるが、GNU/Linuxをデスクトップとして利用するのは、何も「自由が大切だから」という理由だけではない。もちろんそれもあるが、最大の理由は「死に狂うほど便利だから」である。そんなことを言うと、WindowsやMacに慣れきったユーザーの中には、

「（GNU/）Linuxが便利だとぉ〜？！寝言は寝てから言いなッ！！」

などと思われる方もいらっしゃるかも知れない。なので、今日はGNU/Linuxがデスクトップとして如何に優れているかということについて、とくとくと語りたいと思う。

Moongiftよ、俺の背中を押してくれ！

恐らくこのブログの読者の皆さんであれば、Moongiftを愛読されている方が多いのではないだろうか。Moongiftはオープンソースソフトウェアや無料のソフトウェアを紹介するブログで、更新頻度も高いため俺も日々チェックしている。そのMoongiftが最近プレミアムユーザー向けの有料サービスを始めたのだが、なかなか申込むまでには至らないのだ。情報発信で対価を得るというビジネスモデルは個人的には応援したいと思っているのだが、それでも申し込もうという気が起こらないのだ。今日はその理由について色々と書いてみようと思う。

ついカッとなってCyanogenModをインストールした。

先週、Android OSのOTA（バージョンアップ）の通知が来たのだが、実はroot化しているとアップグレードが少々面倒くさい。バージョンアップ時にはすべていったん標準環境に戻してやらないとダメだからだ。そんなわけで、かねてより一度試してみようと考えていたCyanogenModを導入してみたのでレビューしようと思う。なお、自分で試したりする場合には一切を自己責任で行なって欲しい。

自由なソフトウェアと自由なWeb

先日、ソフトウェアライセンスの勉強会に参加したり、オープンソースライセンスの議論が炎上白熱したりしているので、俺自身ソフトウェアライセンスについて考える機会が増えたように思う。プロフィールにも書いてある通り、俺はフリーソフトウェアが大好きである。フリーソフトウェアライセンスは（乱立したので）星のかずほど存在するのだが、その中でもやはりフリーソフトウェアという概念を提唱したリチャード・ストールマン等によるGPLを支持せずには居られない。GPLにもいくつかバリエーションが存在するのだが、その中でももっともとんがっている（最も強いコピーレフト条項が盛り込まれた）AGPLの採用事例が少ないように思う。なぜ採用があまり進まないのだろうかと考えた結果、ある重大な事実、特にWeb業界にまつわる事実に気がついたので、今日はそのことについて紹介しようと思う。結論は最後の方にあるが、あきらめずに頑張って読んで頂きたい。

GPLは感染するか否か

前回のエントリにおいて、GPLに対するFUDについて触れたところ、

というコメントを頂いてしまった。ちょッ、代表ッ！！と言いたいところであるが、これは視点を変えると現在はGPLに対するFUDが成功してしまっている状況なので変えなくてはマズイという認識に至った。@tmtms氏ほどの人物をして、「GPLが感染するというのはFUDでない」と思ってしまっているのだから。しかもごく自然に。

「java-ja 第1.9.2回 チキチキ ライセンスって何ですか？」に参加した。

先日、「java-ja 第1.9.2回 チキチキ ライセンスって何ですか？」という勉強会に参加してきたのでレポートしたい。宣伝文がやたらとお茶目（タイトルも？！）だが、その日の雰囲気も負けず劣らず楽しいものであったと思う。ライセンスというお固い議題なのに！！である。ちなみに、本ブログでは常々ライセンスについて色々と綴っているが、今回は基本的に聞く側として参加した。（最後にちょっとだけマイクを握らされて（？）しまったけれども。）

Ruby会議2010へ行ってきた。

Ruby会議2010へ行ってきた。何を隠そう、Ruby会議に参加したのは今回が初めてである。休日に自由時間を確保するのは、小さな子供が居る既婚者男性諸君であればそれが如何に厳しいことかということを理解しているはずだ。だが息子も３歳になり、さらに幸いにも予定が一切かぶっていなかったため、３日間すべて参加することが出来たのであった。

Ruby会議2010のテーマは「Conflict and Resolution」（衝突と解決）である。大規模なオープンソースプロジェクトには人々の衝突がつきものであるため、日本有数のオープンソースプロジェクトであるRubyにはピッタリのテーマであるといえよう。というわけで、Ruby会議初参加者による視点で、面白かったことや気になったことなどについてレポートをお届けしたい。

受託開発とGPL ー 補足事項

前回は受託開発をする際にGPLライブラリを用いた場合のライセンスの扱い、主にソースコードの開示義務について説明した。今日はさらにもっと掘り下げて、受託開発でGPLが使える場合、使えない場合、使いたい場合などについて考察してみたい。なお、今回のエントリは前回の続きであるため、まだ前回のエントリを読まれていない方は先にそちらを読んで頂きたい。

EclipseのプラグインをGPLで公開する

今回の記事には、Eclipse界の人からすると「お前は何を言っているんだ？」と思われるようなタイトルかも知れない。Eclipseのライセンス=Eclipse Public LicenseとGPL=GNU General Public Licenseには互換性がなく、両者のライセンスを組み合わせることが出来ないのはいわば常識化している話題のひとつである。両者のライセンスが非互換であることは、フリーソフトウェア財団のライセンスページにも、EclipseのFAQページにも書かれている。

GPLには、システムライブラリはライセンスの適用範囲と見なさないという例外規定があり、プロプラエタリなOSの上でもGPLなソフトウェアが実行できるようになっている。しかし、Eclipseのようなプラットフォームに対してそのような例外は存在しない。なので、Eclipseのプラグインは、EPLとGPLの非互換性のため、GPLを適用することが基本的には出来ないのである。「基本的には」と書いたのは、GPLを適用するための裏ワザがあるからに他ならない。

オープンソースでお金を稼ぐ方法いろいろ。

オープンソースソフトウェア（以下OSS）が広く使われるようになって久しい。ご存じの通りOSSは無償で入手できるものばかりであるため、多くの人が疑問に思うことがひとつある。それは、「OSS開発者はどこから収入を得ているのか？」ということだ。収入源の実体がよく分からないために「霞を食って生きているのか？」などと揶揄されることもある。実際OSS開発者は「どうやって収入を得るか？」ということについて色々と悩んでいる場合も多かったりするのだが、実はOSSには様々なビジネスモデルも存在する。そんなわけで、今日はOSSを活用して収入を得る様々な方法について詳解しよう。OSS開発者になることに躊躇している人の背中を後押しすることが出来れば幸いである。

GPLソフトウェアのパッチをBSDライセンスで提供することの意義

先日の投稿「GPLが適用されているソフトウェア＝MySQLのパッチをBSDライセンスでリリースする。」では、GPLが適用されているソフトウェアにBSDライセンスのパッチを提供することが出来るということを書いた。ただし、それが出来ることによってどのような意義があるのかということについては触れていなかった。その結果、

単独で動かないパッチに元のと違うライセンスをつける感覚がよくわからない。

という疑問が生じたらしい（ブコメ参照）ので、パッチをBSDライセンスで提供するということはどういうことなのかを説明しようと思う。

まず第一に、パッチ自身はBSDライセンスなので、BSDライセンスに従う限り他のプログラムへ流用することが出来る。パッチといえども、それが何かの機能を追加する類のものであれば巨大なプログラムになり得るだろう。事実、Googleが提供するMySQLのパッチもかなりデカイ。パッチの規模がでかくなれば、独立して機能する有益なロジックが多々含まれることになるだろう。パッチのライセンスがBSDライセンスであれば、その機能をGPL以外のライセンスのソフトウェア、例えばBSDライセンスのPostgreSQLなどに追加するということも可能である。つまり、パッチをBSDライセンスにすることで、MySQLとPostgreSQLに同じ機能を追加するということが出来るわけだ。

第二に、MySQLはデュアルライセンスなので、BSDライセンスで提供されたパッチであればGPL版とコマーシャルライセンス版の両方に機能を追加することが出来る。従って、BSDライセンスのパッチはMySQLにとっては都合が良いのである。（MySQLがデュアルライセンスを貫く以上、GPLで提供されたパッチは適用出来ないのである。）

ちなみに、GPLソフトウェアであるMySQL 6.0からforkしたDrizzleも、全てのContributionはBSDライセンスのもとに行われている。（Drizzleに提供された全てのソースコードはBSDライセンスが適用されている。）従って、Drizzleに追加された全ての機能は、GPL版、コマーシャルライセンス版のいずれのMySQLにも取り込むことが出来るのである。また、DrizzleにContributeされたコードは、PostgreSQLなどの他のライセンスのRDBMSソフトウェアにも取り込むことが出来るので、PostgreSQLerの人は是非Drizzleのソースコードを覗いて見ると良いのではないだろうか。ただし、Drizzleでは積極的に外部のライブラリを取り込んで利用しようという方針があるので、外部のGPLが適用されたライブラリに依存した機能については、BSDライセンスによる利用は出来ない点には注意が必要である。（もちろん元のMySQL 6.0から残っているコードはPostgreSQLに取り込むことは出来ないので注意しよう。）

さて、ここまで書くと「GPLよりBSDライセンスの方が優れている」ということを言い出す人が居るかも知れないので、この点について少し捕捉しておく。GPLとBSDライセンスを比較するのはハッキリ言って無意味である。確かにBSDライセンスの方が再利用出来るソフトウェアの範囲が広い。（商用、無償、プロプラエタリ、OSSを問わず利用可能である。）しかし一方で、GPLはソフトウェアの利用者に（それをカスタマイズすることを含めて）未来永劫最大限の自由を約束するライセンスであり、GPLを継承することによって再利用可能な場面が限定されることは、その自由を約束するために必要な措置なのである。つまり、GPLとBSDライセンスはそれぞれ異なる属性を持ったライセンス（かたやCopyleft、かたやPermissive）であり、それぞれのライセンスを適切に使い分けるのが重要だということである。ライセンスに対する理解とそれらの使い分けは、オープンソースに生きる人々にとっては最も重要な嗜みと言えるだろう。

Chrome OSアーキテクチャ大予想！

Chrome OSが出るぞ！というニュースを聞いたとき、ある種の衝撃が走った。というよりとても腑に落ちたと言った方がより正確に俺の心情を表しているかも知れない。そう、まるで心の鍵穴にChrome OS発表のニュースが鍵となって、今まで開くことが出来なかった心の奥底にある謎の扉を開いたような感覚だった。世間的には「ChromeブラウザがのっかったLinuxの1ディストリビューション」だという見方が趨勢であるように思うが、俺はChrome OSが断じてそのような安易で在り来たりなものとして登場するのではないと予感している。そしてまだ見ぬChrome OSにワクワクしながら、そのアーキテクチャを想像してニヤニヤしたりしているのである。まだChrome OSのアーキテクチャについては詳細が公表されていないが、以下のようなものになるんじゃーないだろうか。

この図はあくまでも個人的な予想というか妄想によるものなのでその点は了承して欲しい。公式にGoogleからChrome OSの詳細が発表されたとき「全然違うじゃないか！」となったら、笑いぐさにでもして頂ければ幸いである。



さて、この図（俺の心の中で想像しているChrome OSのアーキテクチャ）を解説しよう。

1. UIはChromeのみ。

一つ確信していることがある。それは、Chrome OSにおいてユーザーが触れることができるUIはChromeブラウザだけになるだろうということだ。Linuxだからといって、UNIXユーザーが慣れ親しんだシェルが搭載されることはないだろう。ギークなユーザーにとっては「なにー？！そんなものはLinuxではない！言語道断！！」と激高してしまう仕様かも知れないが、そもそもChrome OSはそのようなギークをターゲットにしていないだろうと思われる。全ての操作はChromeを通じて行われることになるだろう。

2. Webサーバを搭載

上記の仮説が正しければ、Chrome OSにはWebサーバが搭載されるはずである。lighttpdやApacheのような。何故かって？それは、そのコンピュータ自身を操作するためである。おそらくはコンピュータの電源を切る操作すら、ブラウザを通じて行うことになるだろうが、その場合ブラウザでクリックした操作を誰が実際に実行するのかと言えば、HTTPリクエストを処理するWebサーバーでなければいけない。コンピュータの管理や設定は、そのWebサーバー上で動くアプリケーションとして実装されることになるだろう。

3. ユーザーアプリケーションはサーバープログラム

Chrome OSはGoogleのサービスやその他Web上にあるリソースを活用するOSであるのは言うまでもない。しかし本当に全ての処理（電卓アプリのようなネットを一切必要としない）アプリケーションまで、Googleのクラウド上で実行するとしたらそれは愚かなことであり、Googleのデータセンターは大量のリクエストによって飽和してしまうことになるだろう。従って、いくらブラウザだけで操作するChrome OSとて、ローカルにアプリケーションが一切必要ないというわけではないだろう。そうすると、アプリケーションはJavascriptによって実装されるか、ローカルのWebサーバー上でWebアプリとして実装されることになるのではないだろうか。今、巷にはWebアプリを得意とするプログラマが溢れているので、彼らはきっとChrome OS用アプリの開発も活発に行ってくれるに違いない。

4. ファイル管理からの解放

おそらくここがChrome OSの最も革新的な側面になると思われるが、Chromeブラウザから自身のコンピュータ上の「ファイル」へアクセスする手段はないだろう。WindowsのExplorerのようなファイルマネージャーっぽいアプリケーションは、おそらく存在しない。そもそもであるが、静止画像や動画、音声、プレゼンテーション、文書、テキストなどの各種データを「ファイル名」で識別して、それをツリー状のファイルシステムで管理するというやり方は如何にも古典的であり、本来の人間の要求であるはずの「データを整理し、確実に保存し、必要なときに素早く検索する」ということからはかけ離れた方法であると言えよう。その代わり、Chrome OSではデータは全てデータベースへ格納され、Webサーバー上で動くアプリケーションがデータベースからの検索や保存を肩代わりしてくれることだろう。その結果、人間は「ファイル名と中身を紐付けて覚える」という無駄な行為から解放されることになる。

ここで一つ疑問が生じる。Chromeがデータベースを搭載するとしたら、どのデータベースソフトウェアを搭載するのだろうか？ということだ。これまでにGoogleがsqliteを（AndroidやGoogle Gearsなどで）採用してきたことを考えると、sqliteのような気がしなくもない。しかし、もし上記のような使い方を本気で考えるのであれば、sqliteではスケーラビリティの問題に直面することが容易に予測できる。そうするとやはり、MySQLやPostgreSQLのように大規模なデータを扱えるRDBMSを搭載して欲しいところであり、MySQLerとしてはぜひMySQLを薦めたい。もし、MySQLのライセンスがGPLv2であることがFOSS Exceptionを適用するといいだろう。そうすれば、GPLv2であるMySQLを搭載しつつ、Chrome OS全体のライセンスを例えばApache 2.0ライセンスにすることができる。

5. 強固なセキュリティ

Chrome OSでは恐らくユーザーが直接コマンドを実行することはないし、システム的にそれは出来なくなっているだろう。実際、ユーザーが起動することができるプログラムは何もなくても良い。もちろんブラウザプロセスでさえ。じゃあ誰がブラウザを起動するんだ？！と思うかも知れないが、起動するプログラムがブラウザだけで良いならば、Chrome OS自身が事前にブラウザのプロセスを起動しておけば良い。そうすれば、Chromeブラウザの実行ファイルの所有者をrootにすることによってrootだけがコマンドを実行可能に出来るように出来るし、rootが起動したChromeブラウザのプロセスは、自身が起動後にsetuid()をして実効ユーザーを切り替えれば良い。このようにすれば、ユーザー自身の手によってブラウザを起動せずともブラウザを利用することが可能になるわけである。

極端に言えば一般ユーザーは通常ファイルへのアクセス権限が一切なくても良い。（ただしブラウザはバックグランドで動くプロセスにはアクセスするかも知れない。）この場合、ブラウザがバッファオーバーフローなどによっていくらクラッキングの被害にあったとしても、クラッカーが実行出来るコマンドは存在しないので被害は最小限にとどめることが出来るだろう。クラッカーが何か悪事を働くには、さらにそこからroot権限を奪取するか、Chromeを操ってローカルのWebサーバーで動くアプリケーションにアクセスするように仕向けるかである。だが、そのような場合もローカルのWebサーバーで不正なアクセスをブロックする仕組みを実装しておけば、いくらChromeブラウザを乗っ取ったところでクラッカーは何もすることが出来ないだろう。（せいぜい他の悪事を働くための踏み台＝ボットとして利用する程度であろう。）

このように、実行可能なコマンドが存在しなければ「ウィルススキャン」という煩わしい行為から解放されることになる。なぜなら、スキャンする対象の「プログラムファイル」が一切存在しないから。

・・・

このような「Chrome OS」が本当に実装されれば、確かにGoogleが言うように「OSの再考」であると言えるだろう。こんな具合に俺の妄想は広がっているわけであるが、果たしてこの予想はどれほど当たっているのだろうか？一つだけ言える事は、もし俺の予想が当たっていたら、俺は確実にChrome OSのファンになるだろうということである。