MySQLのmanページのライセンスについて

MySQLのmanページのライセンスがGPLからプロプライエタリライセンスに変更されたというようなことが騒ぎになっている。既にご存知の方はいらっしゃるだろうが、これはバグであり意図して行ったものではない。何故このようなバグが起きたかということも含め、今日はmanページにまつわる話をしたい。

GPLソフトウェアの移植とライセンスの変更に見る著作権の問題

昨年、#笑ってはいけないSIerというハッシュタグがTwitter上で流行したことがあった。その際、数々の優秀な（ブラック）ジョークに紛れてGPLに対する誤った批判がなされてしまった。その内容はTogetterにおいて「そもそもOSSがサポート無いと使えない。GPLは禁止。OSSを使うのに研修を受ける必要がある。OSSのソースを読むのは禁止。#笑ってはいけないSIer」から派生したGPLについての談義としてまとめられている。その後さらに、書籍「ソフトウェアライセンスの基礎知識」の著者である可知豊氏が「GPL適用のソースコードを他言語に移植してBSDライセンスに変更できるか」というエントリで著作権法と照らし合わせながら見解を語ってくれ、そしてコメント欄でいくつかのやり取りが発生するということがあった。可知氏の考察はさすがというべきか、著作権法の適用範囲について詳しく解説されているので一見の価値があるのでぜひ本ブログの読者も見て頂きたい。

問題のTogetterのまとめでは、GPLが伝搬する範囲を誇大に表現し、「GPLは危険だから使うな」というニュアンスを含んだメッセージが投下されていた。GPLのファンとしてはGPLに対するネガティブな誤解を産むような誤った発言は見過ごすことは断じてできない！！遅筆中の遅筆になってしまったが、今日は改めてGPLの適用範囲について解説しようと思う。なぜ遅筆になっていたかは、フリーソフトウェア財団の見解を聞いていたからだ。問い合わせれば遅くなってもちゃんと返事をくれるので、疑問がある人は聞いてみるのもいいだろう。（ただし英語）もちろんその際大人のマナーとして寄付を忘れないようにしたい。

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

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

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

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

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

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

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

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

GPLv3とソフトウェア特許

GPLv3にはソフトウェア特許についての言及（GPLv3 第11条）がなされているが、どうもこの点については誤解が多く人々がGPLv3の利用を躊躇する理由になっているように思う。GPLv3の特許条項はGPLv3に対するFUDの元凶になっているように思う。実は筆者は最近「GPLv3を適用したソフトウェアを公開するとあなたの持っている特許は全て無効になる」という（如何にもGPLv3を適用すると不利益を被るような）誤った説明がなされているのを目の当たりにしたところであり、筆をとる必要があると感じた次第である。そこで、今日はGPLv3における特許の取り扱いについて説明しようと思う。

恵比寿にあるLinux会社の熱いギークたちに会ってきた話。

先日、友人の紹介でRed Hat社に勤めるエンジニアの方たちと食事をした。Red Hat社のエンジニアの方々とはあんまり交流が無かったのだが、やはりLinuxに、そしてフリーソフトウェアに魂を燃やす漢たちの発想は一味違う！！興味深い話を聴き、とても良い刺激を受けることができたので皆さんにも紹介したいと思う。

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

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

GPLは感染するか否か

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

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

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

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

ゲーム業界にもフリーソフトウェアの風が吹く？！MMORPG RyzomがAGPLv3でソースコードを公開。アートワークはCC-BY-SAで。

なんと、本格的な3D MMORPGであるRyzomのソースコードが公開されるというニュースが流れたのは先月のことである。ニュースから少し時間が経ってしまったが、今日は皆さんにフリー（自由な）ソフトウェア版Ryzomについて紹介したい。

オープンソースによる新しい受託スタイルの提案

前々回のエントリ「受託開発とGPL」では、受託開発においてGPLのソフトウェアを用いる際に注意すべき点やライセンスの扱いについて書いた。ただし、その視点はあくまでも「GPLはSIerにとって注意すべき≒厄介なシロモノであり、如何に地雷を踏まないようにするか」というものであったように思う。だが、「厄介である」という性質は、裏を返せば「味方につけると頼もしい」ということだ。つまり、GPLは、味方になれば強力で頼もしい存在なのである！今日は、SIerが今の開発スタイルから脱却し、如何にしてGPLを味方につけて戦っていくかということについて語ろうと思う。ちょっとひどい妄想夢物語的な記述も入っているのだが、「何言ってんだコイツ？！」とツッコミたいところをぐっとこらえて最後までお付き合い頂ければ幸いである。

受託開発とGPL ー 補足事項

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

受託開発とGPL

GPLに対する代表的な誤解・・・というかむしろ謎のひとつに、受託開発（SI）におけるライセンスの扱いがある。この点が明確になっていないため、受託開発において無意味にGPLを回避しようとしたり、GPLに対するFUDを流布することに対する原因になっていたりするように思う。フリーソフトウェアおよびオープンソースソフトウェアを愛する者として、そのような状況は断じて見過ごすことができない！！というわけで、今日はGPLを受託開発（SI）において用いる場合の注意事項を説明しよう。

GPLの使いどころ

受託開発においてGPL（とその仲間たち＝LGPL、AGPL）が登場するのは、第三者、つまり発注側でも受託側でもない者が作成したGPLのソフトウェアを利用する場合である。例えばGPLが適用されたライブラリなどだ。周知の通り、GPLのソフトウェアをリンクしたソフトウェアを再配布する場合は、そのソフトウェア全体に対してGPLを適用しなければならない。この約束事によって、受託側には次のような漠然とした不安が生じることになる。

• 1. 社員がライセンスがGPLであることを理由に開発中のソフトウェアを一般向けにバラまいてしまうのでは？！
• 2. GPLを適用してお客さんにソフトウェアを納入したらソースコードを一般公開しなければいけないの？？
• 3. 私は発注者です。受託側はGPLに基づいてソフトウェアをバラまきやがるのが不安です。

だが、実際これらの懸念はNo！！である。心配ない。受託開発で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を適用するための裏ワザがあるからに他ならない。

真の自由とは？フリーソフトウェアにおける究極の選択。CopyleftかPermissiveか。

オープンソースソフトウェアにとって、ライセンスが何であるかというのは非常に大切なことである。なぜならば、ソフトウェアのライセンスの種類によっては、組み合わせることができるものと、そうでないものがあるからだ。ソフトウェアの利用制限がない「自由なライセンス」として有力なものの中には、Copyleftと呼ばれる種類のものとPermissiveと呼ばれる種類のものがある。いずれも、フリーソフトウェアライセンスとして定義されているライセンス形態であり、Copyleftで代表的なものにはGPL（GNU Public License）、Permissiveの代表格としてはBSDLやMIT Licenseなどが挙げられる。これらは一体全体どちらが真に自由をもたらすソフトウェアライセンスなのであろうか？

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）であり、それぞれのライセンスを適切に使い分けるのが重要だということである。ライセンスに対する理解とそれらの使い分けは、オープンソースに生きる人々にとっては最も重要な嗜みと言えるだろう。

GPLが適用されているソフトウェア＝MySQLのパッチをBSDライセンスでリリースする。

Googleがリリースしている有名なMySQL 5.0用パッチは、なんとBSDライセンスで提供されている。MySQLは周知の通りGPLでリリースされているが、GPLソフトウェアはその性質上、改変するとそのソフトウェアもGPLでリリースしなければいけない。だったら何故そのパッチをBSDライセンスで提供することが出来るのか？！ホントにそんなこと出来るのか？！Googleは何か間違ってるんじゃないか？！などと疑問に思われることだろう。

結論から言うと、Googleは何らライセンスの間違いを犯しているわけではなく、GPLソフトウェアにGPL互換のライセンスでパッチを書くことが出来るのは、GPLの条文そのものにしっかりと書いてあるのである。

以下、GPLv2の日本語訳より抜粋。

http://sourceforge.jp/projects/opensource/wiki/licenses/GNU_General_Public_License

以上の必要条件は全体としての改変された著作物に適用される。著作物の一部が『プログラム』から派生したものではないと確認でき、それら自身別の独立 した著作物であると合理的に考えられるならば、あなたがそれらを別の著作物として分けて頒布する場合、そういった部分にはこの契約書とその条件は適用されない。しかし、あなたが同じ部分を『プログラム』を基にした著作物全体の一部として頒布するならば、全体としての頒布物は、この契約書が課す条件 に従わなければならない。というのは、この契約書が他の契約者に与える許可は『プログラム』丸ごと全体に及び、誰が書いたかは関係なく各部分のすべてを保護するからである。 よって、すべてあなたによって書かれた著作物に対し、権利を主張したりあなたの権利に異議を申し立てることはこの節の意図するところではない。むしろ、その趣旨は『プログラム』を基にした派生物ないし集合著作物の頒布を管理す る権利を行使するということにある。

つまり、パッチとしてオリジナルのGPLソフトウェアから完全に切り離された部分に関しては、GPLが適用されないわけである。ただし、そのパッチをGPLソフトウェアに適用するためには、そのパッチはGPL互換のライセンス（例えばBSDライセンスなど）でリリースしなければならない。そして、それをオリジナルのGPLソフトウェアと合体した時点でGPLが適用される。つまり、

GPLソフトウェア ＋ BSDLパッチ ＝ 改変されたGPLソフトウェア

という関係が成り立つわけである。従って、件のGoogleパッチがBSDLでリリースされているのは、一切問題はないというわけであり、Googleパッチに含まれるソースコードはBSDライセンスで利用することが可能である。

なぜ上記のような条項がGPLに盛り込まれているのか？と疑問を持たれることだろう。もし上記の条項がなければ、全ての変更はGPLを適用したソフトウェアで行わなければならず、従って他のライセンスでリリースされた優秀なソフトウェアやライブラリをGPLソフトウェアと組み合わせて利用することが出来ないという事態になってしまう。例えそれがFSFが作成した他のライセンス、例えばLGPLなどを適用したソフトウェアであっても！である。上記の条項があれば、ライセンス上は安全に他のGPL互換のライセンス（BSDライセンスなど）のソフトウェアとGPLライセンスのソフトウェアを組み合わせて別のソフトウェアを開発することが可能になる。

まったくもってややこしい話であるが、オープンソースソフトウェアに携わる人間としてライセンスの組み合わせは避けて通ることが出来ない問題であり、数あるオープンソースライセンスの中でも最もシェアが多いのはGPLなので、GPLの互換性に関する知識は身につけておく必要があるだろう。GPLが嫌いな人は「GPL汚染」などと揶揄してとかくGPLソフトウェアに対して脊髄反射的な嫌悪を示すことが多いのだが、それはきっと未知なるものに畏怖の念を抱くのは人間の性だからであり、しっかりライセンスを読んでよく理解すれば何も恐れる必要はないのである。

GPLの境界線

GPLを利用するにあたって度々議論されるのが「プログラムの境界」という問題である。GPLソフトウェアを改良または組み込んで別のソフトウェアを作成すると、頒布する際に新しく作成したソフトウェアのライセンスもGPLにしなければならない。ここで注意しなければいけないのは、どこまでがそのソフトウェアの「境界」なのかということである。言い換えると、どこまでが「GPLソフトウェアを組み込んだ」状態なのかということである。自分のソフトウェアをGPLで頒布しようと考えている人にとっては、境界線はあまり意識しなくてもいいテーマである。優れたGPLソフトウェア資産は利用し放題のワンダーランドである。しかしGPL以外のライセンスを利用したいと考えている人にとっては、どこまでならGPLのソフトウェアを利用しても構わないのか？ということを明確に把握していないと、後で著作権法違反で訴えられることになってしまうので注意が必要である。そのような問題があるとなるとGPLソフトウェアを毛嫌いするようになって、極端な人は「コンピュータ内でひとつでもGPLソフトウェアが動いていればそのコンピュータ全体をGPLにしなければいけないのか？」と考えてしまう人も出てくるだろう。GPLについての知識が乏しく、「得体の知れない恐ろしいライセンス」だと考えている人はそのような誤解をしてしまうかも知れないが、しかし実際はそのようなことはない。そのように恐怖してしまうのはGPLについてよく知らないからであり、GPLについて正しい知識を身につければ無闇に恐れることもなくなるだろう。より多くの人にGPLソフトウェアを利用して貰い、時には他のライセンスを用いて上手にGPLとつきあい、時にはGPLでソフトウェアをリリースして社会に貢献することができるよう、今日はGPLの境界線について説明しようと思う。

ズバリ、境界線はプロセス

多くのOSにはGPLソフトウェア、例えばGNU tarやGCC、gdb、bash、GNOME、MySQLなどがバンドルされている。商用ライセンスのもの、例えばMac OS X Serverなどである。GPLソフトウェアをバンドルするとOS全体をGPLにしてソースコードを公開しなければいけないんじゃないか？と思うかも知れないが、そのようなことはない。GPLにおいて、「ソフトウェアを一部に取り入れた」と見なされるのはプロセスまでである。従って、GPLと同一のプロセスで動作するようにしなければ、ライセンスをGPLにしなくても良いのである。いくらMySQL Serverをバンドルしていようが、Mac OS X ServerをGPLにしなくても良いのはこのためである。

同一のプロセスとして動作するということは、

• 元のGPLソフトウェアを改造
• GPLのライブラリをリンク

のいずれかをするということである。それ以外の場合は、安全にGPLと他のソフトウェアを組み合わせて利用することが出来るのである。

ここはMPLやCDDLなどのライセンスと大きく異なる点である。MPLやCDDLにおけるソフトウェアの境界線は「ソースコード」である。ライブラリをリンクしようが何しようが、元のソースコードに手を加えなければライセンスをMPLまたはCDDLにしなくても良い。このため、これらのライセンスはGPLとは非互換であり、コピーレフトの強制力はずっと緩い。（コピーレフトの観点からしても、互換性の点からしてもダメライセンスなのである。）

ネットワーク経由で利用する場合

GPLのサーバープログラムへネットワークを介して接続するクライアントプログラムを作成する場合、そのクライアントはGPLにしなければいけないのか？答えはNo!!である。上記の通りGPLソフトウェアの境界線はプロセスであり、ネットワークを介して接続する場合にはGPLの強制力は働かない。どのようなライセンスを採用するかは自由である。MPLでも、Apacheライセンスでも、プロプラエタリでも問題ない。

だったらMySQL Serverに接続するクライアントプログラムもGPL以外のライセンスを自由に採用してもいいのか？！と思うかも知れないが、ここには注意すべき点がある。クライアントプログラムがlibmysqlclientやConnector/J（JDBCドライバ）を利用する場合、これらのライブラリがGPLであるためリンクするとGPLの強制力が働いてしまう。MySQL Serverへ接続するプログラムをGPL以外のライセンスでリリースしたければ、これらのライブラリを利用せず自分で接続用のドライバを開発するか、libmysqlclientやConnector/Jの商用ライセンスを購入する必要がある。

インタープリターは？

もしインタープリターのライセンスがGPLだった場合はどうだろうか？実はGPLにはインタープリター上で動くプログラムに対する強制力はない。インタープリターがGPLであっても、インタープリター上で動くプログラムはGPLにしなくても良い。

ただし、インタープリターに拡張モジュールを追加した場合には注意が必要である。もしインター上で動くプログラムが拡張モジュールを利用するようであれば、そのプログラムはGPLにしなければいけない。この点はとても理解に苦しむ点かも知れない。何故ならばインタープリターがGPLでもGPLの強制力はないのに、そのインタープリターにGPLの拡張モジュールを追加した場合は強制力が働いてしまうからだ。

このようなややこしいルールが設定されている理由は明確で、それは抜け穴を塞ぐためである。もし、拡張モジュールとしてGPLのライブラリを利用しても良いのであれば、GPLのライブラリはインタープリターを介せばGPLの強制力が失われてしまうことになり、プロプラエタリな製品で利用し放題になってしまう。これではGPLの意義は失われてしまうだろう。優れたGPLライブラリがあり、そのライブラリを拡張モジュールとしてインタープリター上で動くプログラムで利用したければ、そのプログラムはGPLにしなければならないのである。

PHPやPerl、RubyなどでMySQL Serverへ接続するためのプログラムをGPLにしなければいけないのはこの制約があるからであり、これらのプログラムがMySQL Serverへ接続するための拡張モジュール（mysql拡張、mysqli拡張、DBD::mysql、MySQL/Rubyなど）はlibmysqlclientのバインディングになっているのである。GPLのlibmysqlclientを利用するため、例えインタープリター上で動くプログラムであってもGPLにしなければならないのである。

オトコの理想国家

もうすぐ第45回衆議院議員総選挙の投票日である。選挙が近づいてくるといつも考えるのだが、「自分が考える理想の国家と現在の国家があまりにもかけ離れている」と。特にITに関して各党が掲げる政策があまりにも残念で、「ここに投票したいんだ！」というような政党が見あたらないのでちょっとツマラナイのである。（だからといって選挙に行かないわけではないのだが。）というわけで、今日は「こんな公約してくれれば票をバッカンスッカン入れちゃうよ！（俺が持ってるのは1票だけだけどね！）」という政策案（≒妄想）について語ってみようと思う。

完全電子マネー化

世の中が全て電子マネーになればどれだけ便利になるだろうか。コンビニで釣り銭として小銭をたくさん貰って財布がふくらんでしまうこともなくなるし、自動販売機でジュースを買うのに小銭を用意する手間も省けるだろう。電子マネーになればどこで何を買ったかという履歴が残るだろうし、そうすれば領収書を発行してもらう必要もなければ家計簿をつける必要もない。履歴が残れば脱税も不可能であるし、確定申告も不要になるだろう。現金が手元になければ窃盗も出来ないので犯罪の減少にも繋がるだろう。

役所の窓口業務のオンライン化

引っ越しをしたときのように何か身の回りに変化があると必ず役所に行って届出をしなければならないが、結構面倒だったりする。何故ならば役所は平日しか空いてないし、早々に締まってしまうところも多い。特に多忙で残業が多いサラリーマンにとって、平日に時間を作って役所に出向くという行為自体が割と大変だったりする。役所に出向いて行わなければいけない一連の諸手続が全てオンラインで出来ればどれほど便利だろうか。システム化すれば24時間365日利用できるだろうし、もはや役所に出向くためにわざわざ仕事を休む必要もなくなる。（休む口実が無くなって困る！という人が居るかも知れないが。。。）そもそも論であるが、住民票は日本全国共通の仕組みなので、市町村の役所ではなく国が一括して管理すれば良いのではないだろうか。

選挙の電子化

考えて見れば選挙カーほど無駄で迷惑なものはない。選挙カーは基本的に候補者の名前を連呼するだけで発信する情報量は皆無に等しいし、選挙カーが走行するための燃費や運転手の人件費だってバカにならないだろう。そして何より選挙カーは五月蠅くて迷惑な存在であり、そのようなものは一刻も早く禁止するべきであると思う。その代わりにインターネットを利用した選挙活動を認めるのがいい。そうすれば、各候補者（ないしは政党）がどのような政策を謳っているかも分かり易いし、何より選挙期間中静かになる。投票もオンラインで出来るようにするべきである。

国会の電子化

国会が格式張っていて非効率だと感じるのは俺だけだろうか。誰が何を言ってるのか把握しづらいし、法案の審議にもやたらと時間がかかる。牛歩戦術などは非効率性の象徴であるが、とにかく国会の決議は進まない、決まらない、既定路線のものだけすんなり決まるといった印象がある。国会議員たるもの普段からよく各法案についてはよく理解して、どの法案に対して賛成または反対すべきかなどということは即答できてしかるべきなので、投票に要する時間などは5分もあれば十分なはずである。決議はすべて押しボタン式投票にするべきだし、誰がどの決議においてどのような判断をしたかということは全て履歴をとってウェブ上で公開するべきである。（そうすれば次の選挙の時に投票するための判断基準になろう。）さらに議事進行においても、プロジェクト管理ソフトウェアを駆使して優先順位の高いものから順に話合うようにするなどの工夫が欲しいところで、さらに欲を言えば議論する内容については事前に十分に内容を吟味し、国会では賛成か反対かという意思表示だけをするところまで煮詰めておいてくれれば国会で審議される法案の数が劇的に増えることだろう。その結果、国民の生活は豊かで便利になるだろう。

裁判の電子化

国会の審議以上に時間がかかるのが裁判である。裁判もオンライン化すれば良い。そうすればわざわざ裁判所に出向く必要がなくなるし、裁判官が類似の事例を即座に検索できるような支援機能を利用すれば判決のスピードアップが図れるだろう。さらに裁判員が出廷しなくてよくなればパーフェクトである。

ETCの義務化

個人的に、民主党の「高速道路無料化」には反対である。むしろ堀江氏（ホリエモン）が言うように戦略的な価格付けをして渋滞を緩和するべきだと思う。冒頭で述べた電子マネー化にも繋がるが、料金を徴収するならクルマにはETCを義務化するべきである。料金所における渋滞は、ETCを完全義務化することである程度防げるからである。

著作権の再考

現在の著作権は保護され過ぎだと思う。とにかく著作物の扱いは不便で仕方がない。特にDRMというものは最悪で、「楽曲を購入しても自分のお気に入りのプレイヤーで聴くことが出来ない！」とか「携帯電話の着信音に設定できない！」という事態が生じてしまうので購買意欲も削がれてしまう始末である。地デジも不便だ。コピーが1回までだろうが9回までだろうが10回までだろうが同じことで、自由にコピーが出来ないデータというものは至極扱いづらい。我々国民はそのように不便を生じさせること≒DRMに対しては断固としてNo!というべきである。

著作権の全てを否定するわけではないが、現在はあまりにも保護され過ぎているのが問題である。著作者の死後70年も保護されるような権利とは一体何か？死後も保護されるのは何のためか？誰が幸せになるのか？今この瞬間に生きている国民はそれで幸せになれるのか？確かにミッキーマウスのようなキャラクターが真似されてしまっては、ディズニーのビジネスが成り立たないのは分かるし、夏目漱石の著作物は全て著作権が失効しているからと言って誰かが「我が輩は猫であるは自分が書きました」と偽ることは許されない。つまり何が言いたいかというと、著作物を保護するというコンセプトの全てを無効にするべきではないということである。

ただし著作物に纏わる権利には色々あって、それらを一緒くたにしてしまっているために種々の不便や問題が生じているのだと俺は思う。著作権という巨大な権利をもっと細分化して、例えば次のような権利ごとにそれぞれ期限を設けてはどうだろうか。

クレジット表示（誰が作成したかということを示す権利）・・・永遠に執行しない
キャラクターを利用する権利・・・商標法で長期間保護
映画や音楽を商業利用する権利・・・著作物が登録されてから5年〜10年
私的に利用する範囲でコピーする権利・・・自由！

商業的に投資を回収するのに十分な期間だけ著作権を認めるようにしておけば、著作者側も困らないし利用する消費者側も不便さを感じなくて済むだろう。

GPLないしはOSSの利用

政府の様々な仕組みを電子化するとなると、それはそれは大がかりなソフトウェアが必要になるだろう。しかし、現行の体制ではシステムを構築する時の一時的な価格優位性によってベンダーが決められてしまうが、それは時としてベンダーロックインという問題に直面してしまう危険性を孕んでいる。ベンダーにひとたびロックインされてしまうと、システムをメンテナンスしたり再構築する場合に他のベンダーへ切り換えるのに莫大な費用が必要になってしまう。プロプラエタリなソフトウェアは最悪で、ベンダー側がどのように危険なバックドアを仕掛けていてもユーザー側にはそれに気づくための手段がない。例えユーザーが国家であったとしても！だ。ベンダーロックインによって、国家のシステムを一ベンダーのコントロール下に置いてしまうという事態はあってはならないのである。このような危険なベンダーロックインを防ぐには、国家が調達するソフトウェアを全てGPLないしはOSSにするという決まりを作って、ソースコードごともらい受け、なおかつソースコードを一般公開してしまうのがベストである。特にGPLライセンスを利用すれば他の自治体でソフトウェアを再利用することも可能であるし、他のベンダーがそのソフトウェアを研究して改良や機能追加などを行い再利用することも可能である。国家が調達したものは国民の利益に還元されるべきなのでGPLでソフトウェアを公開するのはとても理に適っている。ソースコードが公開されていればバックドアを見付けることも出来るし、実装されたロジックを見ればどのような形式でデータが保存されているかも一目瞭然だからそのソフトウェアで作成したデータが将来に渡って安全に利用出来るということが保証される。国家がソフトウェア資産への投資を最小化し、なおかつセキュアなシステムを構築するにはベンダーロックインを避けることが出来るGPLないしはオープンソースソフトウェアでなければならないのである。

:

というような政策を打ち出してくれる政党があれば全力で応援するのだが、残念ながらそのような政党はまだ俺の脳内にしか存在しないのである。

そもそも日本のIT業界が残念だ。

梅田望夫氏のインタビューに対して様々な反応が上がっている。

• 日本のWebは「残念」　梅田望夫さんに聞く（前編） (1/3) - ITmedia News
• Web、はてな、将棋への思い　梅田望夫さんに聞く（後編） (1/3) - ITmedia News

俺に言わせてみれば、Webだけでなく日本のIT業界そのものが残念だ。

俺は、2000年に大学院を卒業してからSun Microsystemsの門を叩いた。なぜSun？という疑問は色々とあるだろうが、いずれにしても外資系が良かった。日本企業に勤める気にはならなかった。なぜか？

日本のIT業界が残念なことになっていたからだ。

周りを見渡してみよう。一体どれだけの（人気のある）コンピュータ製品が日本製だろうか。俺は今、MacBookでこのブログを書いている。組み立てはどこの国で行われたかは知らないが（たぶん台湾あたりか？）設計したのはアメリカの企業であるAppleだ。

サブマシンで使ってるLinuxは北欧の人が設計した。

最もシェアの高いOSはWindowsであり、これまたアメリカ製である。

スマートフォンのOSは、Android、iPhone OS、WM、Symbian OS、WebOSなど様々だが、いずれも海外のものだ。

今俺の本職であるデータベースだって、オープン系システムで利用されるものはほとんどが海外製のものばかりである。MySQLはスウェーデン生まれだ。

ハードウェアはどうだろう？メモリやHDDは日本製のものもあるが、花形であるCPUはIntel/AMD/VIAなど海外勢ばかりであり、GPUもnVidia/AMDとこれまた海外である。おっと・・・最近富士通が世界最速のCPUを発表したところだった。10年ぶりに。

そんなわけで、日本のIT製品・・・特に基盤となるソフトウェアは、海外発のものを輸入して利用しているのがほとんどである。俺はそれが残念でならない。

だから外資系企業に入って、日本ではなく海外の技術を学ぼうと考えたわけだ。ただし配属された部署の関係で、あまり希望するような仕事は出来ず、お世話になったSunを去ってMySQLへ転職したわけだが、どういう因果なのかまたもやSunに買い戻されてしまい、今度はそのSunが買われることになってしまった。これまた残念なストーリーである。

Webが残念なことになっているというのは、IT業界そのものの体質だと思えばそれほど不思議ではない。元々日本のIT業界は世界をリードする立場に無かったのだから、それがWebで立場が変わる方が不思議なのである。

なぜ日本のIT業界は残念なことになっているのか？社会に出て、俺なりに経験を積んできた中で思うことには、例えば次のようなことが挙げられる。

1. 技術者の待遇がよくない。出世するには管理職にならなければならない。技術を学んでも待遇がよくならないので、技術を学ぶことに対するインセンティブが業界全体で低い。
2. ソフトウェアのライセンスはプロプラエタリなものばかりで、開発者がその方が良いと信じている傾向がある。実質的には経営者や営業職など、開発職以外の人達だけが得をしている。
3. 国内市場向けの商品が大半である。特にソフトウェアでは顕著であり、日本から海外へ販売している例は少ない。Web系のサービスではもっと顕著で、殆どが国内消費向けである。
4. 言語の壁が高い。

このように分析してみると、日本で開発されたものが世界標準になる可能性は極めて低いと考えざるを得ない。とても残念なことである。

じゃあどうすればいいか？結論だけ書くと、

• ソフトウェアのライセンスはGPLにする。（1、2の問題への対策）
  
• 英語を学ぶ。（3、4の問題への対策）

というわけだ。こんな風に考えているので、俺は今のところ身を置いているわけである。今が残念ならば、少しでも良い方向へ進むよう努力すべきなのである。

日本発のもので勢いがあるものもある。例えばRubyだ。俺はRubyを猛烈に応援・支持している。松本さん、頑張ってください :)

正直言って、Webには国境はないのに、日本むけのサービスばかり展開していては勿体ないという気持ちもある。海外でもサービスを展開できればビジネスの規模も大きくなるし、Web系の企業は是非とも日本市場だけにとらわれない経営をして頂きたいものだ。