要約

  • SQLiteの公式変更履歴によると、2001年9月20日の2.0-alpha-2でSQLusへの改名を取りやめ、pagerとB-treeを唯一のバックエンドとして復活させ、Dbbe抽象とGDBM・メモリードライバーを削除し、全コードの著作権を放棄した。
  • 公式のバージョン番号解説は、1.0から1.0.32までがGDBM、2.0.0から2.8.17までが独自のB-treeを使ったと記す。当時の先頭数字はデータベースのファイル形式を表していた。

宣言が開いた扉、実装が閉じた扉

パブリックドメインという語には勢いがある。SQLiteの現在の著作権説明によれば、利用者は配布対象のコードを複製、変更、販売、再配布できる。だが、その自由は公式版に以前の保存エンジンを残す約束ではない。9月20日の変更履歴は両方を同時に記録しているだけで、権利の変更が設計変更を引き起こしたとは書いていない。

保存層の違いは、SQLの表面に現れない。1.xで使われたGDBMをめぐり、2001年4月4日の1.0.28は限定的なトランザクションを追加した。テーブルをロックする方式で、ロールバックも原子的なコミットもまだなかった。利用者が「トランザクション」という名前から期待する安全性と、実際の保存処理が保証する安全性には差があった。4月15日にはpagerが追加されたが、その時点では使われていないと履歴は明記する。

設計は一直線に進まなかった。7月23日の1.0.32はpagerとB-treeを削除し、SQLusという後続のSQLサーバー用ライブラリーへ回す計画を示した。しかし9月20日にはSQLusの名を捨て、SQLiteの名前を守り、二つの部品を唯一のバックエンドとして戻した。Dbbeという切り替えの抽象層も、GDBMとメモリーのドライバーも外された。内部で誰が何を主張したかは履歴にない。製品に残った構成だけは読める。

「2」はファイルに刻まれた変更だった

バージョン番号の解説では、当時の最初の数字はファイル形式を示す。1から2への移行は看板の交換にとどまらない。2.xの独自B-treeが扱ったキーとデータはテキストに限られた。バイナリーデータとUnicodeを十分に扱う現行3.xのB-treeは別の段階である。今のSQLiteを2001年の製品に重ねれば、移行時に問題になったファイルと実装の差が見えなくなる。

しかも9月20日は正式な2.0.0ではなくアルファ版だ。9月27日のalpha-3ではロールバックとロックが修正され、ファイル形式もalpha-1のものへ戻された。9月28日の2.0.0ではLinuxとWindows向けのバイナリーを自動で作り、サイトに置くようになった。権利を広げる宣言の後にも、使える製品を作る工程は続いていた。

利用者は自由にソースを持ち帰り、別のエンジンを組み込む派生版を作れる。しかし公式版で複数のエンジンを試験し、修正し、配布する仕事は別だ。SQLiteは法律上の入口を広げ、保守する実装の出口を絞った。2001年の記録は、この二つを一つの美談にまとめるよりずっと面白い。