MySQL・PostgreSQLユーザーグループ（MyNA・JPUG）合同DB勉強会で発表した資料を公開しました。「データモデルについて知っておくべき7つのこと 〜NoSQLに手を出す前に〜」

表題の通り、MyNAとJPUGの合同DB勉強会で発表をしたので資料を公開した。



内容の詳細はスライドそのものを見ていただくとして、言いたいことの主旨はこうである。世の中に完璧なデータモデルはないので、NoSQLは当然の如く必要になる。だが、何でもかんでもNoSQLを使えば良いというものではない。むしろアプリケーションが必要としているデータモデルが何かということをよく理解し、本当に必要な場合にこそ、NoSQLを使うべきなのである。つまり「ご利用は計画的に！」ということだ。

大切なのは、様々なデータモデルを理解し、アプリケーションにとってベストな製品を選択するということだ。ベストなのがRDBかも知れないし、そうでないかも知れない。最適なデータモデルを選択した場合に、出来上がったものの性能も最高になるし、開発効率も最も良くなる。データベースの主流はRDBだが、それはリレーショナルモデルがカバーできる範囲がとても広く、他のアプローチでは代替できないというちゃんとした理由がある。それ以外の選択肢が過去にはあまり流行らなかったのには理由があるのだ。

だから、単にNoSQLを使うだけでトータルの人件費を安くできる・・・なんてことはあり得ない！！絶対にだ！！

アーキテクチャを選択する立場にある人は、ぜひとも合理的な判断をしていただきたいと思う。

ところで、今回はオープンソースのRDBであるMySQLとPostgreSQLが合同で勉強会をするという、個人的にはエポックメイキングなものであった。ここ最近ではほとんど聞いたことがなく、個人的には合同勉強会に出席したのは初めてのことである。

本来であれば、会社や立場の垣根を超えて協業ができるのがオープンソースの利点であるはずである。であれば合同勉強会を阻むものは何もないはずだ。同じRDBというジャンルの製品であるので、話が通じることも多いだろう。面白いので関係者各位にはもっと開催する方向でお願いしたいと思う。

講演の予定等：dbtech showcase、software design 7月号、MyNA・JPUG合同DB勉強会 in 東京

何だか6月は忙しくなってしまった。講演2回、雑誌での執筆1回がある。もし興味があれば講演を聞きに来たり雑誌を買ったりして頂きたい。

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ではない」などと決めたのだろう？

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

AGPLのライセンス互換性の問題について - 解決策はRoR

Webの世界にもGPLと同様の自由や相互運用性をもたらす小粋なAGPLであるが、運用に際しては注意点がある。それは、ライセンスの互換性である。結論から言うと、AGPLはGPLv2と互換性がない。GPLv2を利用したソフトウェアを改変またはリンクして、AGPLとしてリリースすることは出来ない。それが最大の問題である。GPLv3では一部互換で、GPLv3のソフトウェアを改変してAGPLとしてリリースすることは出来ないが、GPLv3のコードをリンクしたソフトウェアをAGPLv3としてリリースすることが可能である。

FOSSで節約IT生活

ITにかかるコストを下げる。これは企業にとって常に重要な課題であるが、最近はフトコロ事情のせいでこの課題に対する要望や圧力が高まっていることだろう。

専用ハードウェアや商用のミドルウェアは高価なものが多い。UNIX系のプラットフォームを利用してごく一般的なN層アーキテクチャのシステムを構築する場合でも、フリーソフトウェアやOSSを利用せずにシステムを構築してしまうととても高価になってしまう。今の時期はたとえ会社の利益が出ているとしても、財布の紐は緩めたくないものである。かといってシステムを構築する際、細部をケチってもあまり高価はない。あるコンポーネントを80%節約したとしても、それが全体のコストのうちたった5%しか占めないものであれば、その節約は全体で見るとわずか4%の節約にしかならない。（全く節約しないよりは遙かにいいのだが。）