先日の記事 「2010-09-06KVS*Sekka 個人的なNoSQL(KVS)のライセンス調査」で、[Sekka]用のKVSをどれにすればいいのかという件について書いた。 選定の観点は、二つだった。

[Sekka]をBSDLにしたい(BSDLにしたい理由は、[Sekka]で書いたコードを[Nendo]に輸入したいため)

将来どこかのPaaSでホスティングしたい(Heroku/EngineYardなど)

結局、KyotoCabinetとMemcached互換プロトコルの両方をサポートする方針でプログラム変更中。 ただ、KyotoCabinetのクライアントライブラリを使ってしまうと、SekkaがGPLに感染する懸念を払拭できないため、最終的にはKyotoCabinetの代わりを探してKyotoCabinetから離脱する必要がある。 KyotoCabinetのRubyクライアントライブラリは1.9.2対応しているし，非常に使いやすいAPIを持っているのに残念。ライセンス問題なんで致しかたない… 代わりとしてKyotoCabinetをやめてTokyoCabinetに戻るという方法もありかなと思っている。まあTokyoCabinetの方が枯れているし、EngineYardでサポートされているし、Linuxディストリビューションの多くでパッケージが用意されている等、考えてみるとメリットも多い。

それから、前回はKVS以外にamatchという曖昧検索ライブラリがGPLv2なのを書き忘れていたが、これも代替製品を探している。なかなか代替が見つからないのだが… amatchは[Sekka]と一緒に配布するわけではなくgem installするので、GPLv2を気にする必要はないのかも知れないが、それでもamatchはメモリリークを起こすのが問題だ。漢字変換を繰り返す度にどんどんメモリ使用量が増えていく。amatchをリンクしないでも動くように代替手段を用意しておくほうがいいだろう。 将来amatch相当のものをPure Rubyで書くか、リークしないC言語版ライブラリを作るかしないといけないが、それぞれパフォーマンス面と手間の面で一長一短ある。

振りかえってみると、[Sekka]はちょっとした寄り道プロジェクトと軽く見ていたが、やってみると意外と色々問題が立ちはだかり、修行になる。 [Sekka]は毎日使ってみて自分では気にいっているので、何とか手軽にインストールできるようにして一人でも多くの人に試してもらいたいなあと思っている。 [Sekka]は[Sumibi.org]と違って、反応速度にも気を遣っているので、その部分ももうちょっと拘り続けたい。KVSの特性を理解するのにも良い題材だし。

追記: 上記の「KyotoCabinetのクライアントライブラリを使ってしまうと、SekkaがGPLに感染する懸念を払拭できない」は私の勘違いです。 KyotoCabinetのクライアントライブラリがGPL2でもGPL3でもSekkaはBSDLのままでOKであり、ライセンス変更する必要はありません。 GPLとBSDLはライセンスに整合性があるので、リンクした時の相性が良いです。 FUDを流してしまってすみません。OSSである限り、GPL感染を心配する必要はありません。

---

コメント by kiyoka:
自分でコメントします。 その後、KyotoCabinetからTokyoCabinetに変更する作業をしてみたら、30分ほどでテストまで終わった。やっぱりTest Driven Developmentのメリットが効いている。