摘要

  • SQLite 官方版本记录在 2001 年 9 月 20 日的 2.0-alpha-2 下列出四件事：放弃 SQLus 名称、让 pager 与 B-tree 成为唯一后端、移除 Dbbe 抽象和 GDBM／内存驱动、放弃所有代码版权。
  • SQLite 的版本号说明指出，1.0 至 1.0.32 使用 GDBM，2.0.0 至 2.8.17 使用自有 B-tree；当时版本号的首位标示数据库文件格式。

自由拿代码，不等于自由挑官方后端

“公有领域”很适合做标题，却不能替代安装时真正运行的程序。SQLite 今天的版权说明列明复制、修改、编译、出售和分发交付代码的自由。这些是用户对代码的权利。它没有承诺项目会一直维护多个存储驱动。9 月 20 日的记录也没有说，因为代码开放，所以才移除其他驱动。两项决定出现在同一版本里，各自改变不同的门槛。

旧门槛并非纸上设计。SQLite 1.x 的底层是 GDBM。2001 年 4 月 4 日，1.0.28 增加有限的事务支持：GDBM 后端通过锁表工作，却还不支持回滚和原子提交。SQL 接口可以说“事务”，用户得到的故障保障却取决于实际存储实现。把语法当成行为保证，数据出问题时就会付账。

项目随后试过另一条路。4 月 15 日，它加入尚未启用的 pager。7 月 23 日的 1.0.32 又把 pager 与 B-tree 移走，打算用在叫 SQLus 的后续 SQL 服务器库中。到 9 月 20 日，SQLus 名称被放弃，SQLite 名称保留，两套组件回到 SQLite，并成为唯一可用后端。Dbbe 这一用于隔开存储驱动的抽象，同时和 GDBM、内存驱动一起退场。发布记录没有披露每场内部争论，却清楚保留了产品路线的折返。

版本号的首位指向磁盘上的事实

官方版本号文档解释，当时首位数字是文件格式。由 1 转 2，不是单纯换一个宣传数字。1.x 的 GDBM 文件与 2.x 的自有 B-tree 属于不同的存储时代。文档还写明 2.x 的 B-tree 只处理文本键和数据；支持二进制数据与 Unicode 的现代 3.x 是后来的另一代。若把今天 SQLite 3 的能力倒灌回 2001 年，最要紧的工程差异反而被抹平。

9 月 20 日推出的是 2.0 的第二个 alpha，不是最终 2.0.0。9 月 27 日 alpha-3仍在修回滚与锁定行为，并把文件格式改回 alpha-1 的状态。9 月 28 日 2.0.0才记录了自动构建 Linux 和 Windows 二进制文件并放到网站上。一个权利声明让人可以使用代码；能否把数据库用于自己的程序，还要看格式、并发行为和可安装的构建。

这段历史的刺点在于：最宽的法律许可，可以与最窄的官方实现选择并存。用户能把代码分叉，自己恢复别的驱动；SQLite 项目没有义务替分叉维护接口、测试和发行。它给出复制权，也给出了一个明确的产品方向。2001 年 9 月，真正改变运行结果的是后者。