原代码ORIGINAL CODE订阅入口
导航
EP.006 / EVIDENCE

sqlite.c证据关系

逐字稿主张、关系类型与来源之间的双向公开映射。

阅读逐字稿全部来源

C-006-031

支持
TRANSCRIPT CLAIM

关于 SQLite，很多人知道的是两个大得有些失真的数字。 一个，是那近乎恐怖的百分之百测试覆盖率。准确地说，是核心代码在实际部署配置下，保持百分之百的分支测试覆盖。 另一个，是无法精确统计、但至少要以 billions 计的部署规模。 可这两个数字，都在讲 SQLite 已经抵达了多远。 它的首页上，还有一句更短、也更接近起点的话。

supports
PUBLIC SOURCES

SQLite, How SQLite Is Tested

SQLite, Most Widely Deployed SQL Database Engine

当前官方页面支撑核心代码在实际部署配置下的百分之百分支覆盖，以及项目方对 billions 级 copies 的估算。精确数量无法取得，copies 不等于设备装机数，覆盖率也不等于绝对无缺陷或历史上始终如此。

定位：How SQLite Is Tested sections 1.1 and 7, including '100% branch test coverage in an as-deployed configuration'; Most Widely Deployed opening paragraph and exact-ranking caveat

C-006-002

支持
TRANSCRIPT CLAIM

故事的起点，恰好是一群不能决定数据库命运的人。 二零零零年，D. Richard Hipp 是一名做定制软件的开发者。他参与的一套应用部署在舰船上，程序需要读取数据库里的资料。数据库服务已经安装好，却由另一支团队管理。 多年以后，Hipp 回忆，服务一旦停止，应用能做的只有报告无法连接。应用团队不能进入数据库服务器，也不能直接修复它。他们可以说明问题，却无法控制提供数据的那台服务。 这里不需要把一次服务故障写成灾难。真正改变 Hipp 判断的，是一条很普通的工程边界：程序依赖数据库，但写程序的人没有数据库的控制权。

supports
PUBLIC SOURCES

CoRecursive #066, The Untold Story of SQLite, Richard Hipp 访谈

Hipp 2021 年后见叙述支撑舰船应用、既有数据库服务和团队无控制权；主持人补充的舰名、承包关系与具体数据库产品不进入本段。

定位：CoRecursive #066 page transcript, Richard Hipp account in the origin section before the first implementation discussion

C-006-003

支持
TRANSCRIPT CLAIM

Hipp 注意到，这套程序并不需要一台远端服务器替它长期处理复杂事务。它主要是把数据读进内存，在应用里继续工作。 于是问题缩小了：为什么程序不能自己打开磁盘上的数据库文件？为什么读取一份本地数据，还要先请求另一个进程、另一台机器和另一位管理员？ SQLite 后来的官方文档把这种结构叫作 serverless。数据库引擎不是独立服务，而是和应用运行在同一个进程里，直接读取和写入数据库文件。这里的“没有服务器”不是没有提供网络服务的应用，而是数据库引擎本身不再隔着一条 client/server 边界。 这一步先移走的，不是许可证，而是运行时必须请求的人。

supports
PUBLIC SOURCES

CoRecursive #066, The Untold Story of SQLite, Richard Hipp 访谈

SQLite, SQLite Is Serverless

SQLite, Zero-Configuration

本人后见回忆支撑当时的问题，当前官方文档支撑技术模型；不能把今天的 serverless / zero-configuration 文案写成 Hipp 在 2000 年已经使用的完整路线图。

定位：CoRecursive #066 origin account; SQLite Is Serverless sections 1-2; Zero-Configuration explanation of no setup, server process, or administrator

C-006-027

支持
TRANSCRIPT CLAIM

把数据库放进应用进程，听起来只像少开一个服务。实际改变的是故障与控制的边界。 在 client/server 结构里，应用先把 SQL 请求交给数据库服务，再等待另一端处理和返回。连接、服务进程、账户配置和服务器状态，都可能成为一次本地操作之外的条件。 SQLite 把这条路径缩回一台设备。应用调用库函数，数据库引擎就在进程内部工作，数据通常也在同一台设备的文件中。没有独立服务需要安装和启动，也没有一位数据库管理员必须先替这个应用准备运行环境。 这不保证程序永远不会失败。磁盘、锁、断电和应用自己的错误仍然存在。它改变的是，应用团队终于可以把数据库和自己的程序作为一个交付物一起测试，一起部署，也一起承担后果。 对“任何人”来说，这是很早却很容易被忽略的一步：能够使用一项技术，首先意味着不用等待另一个组织替你把它运行起来。

supports
PUBLIC SOURCES

SQLite, SQLite Is Serverless

SQLite, Zero-Configuration

当前官方技术页面支撑进程内库、直接文件访问与无需独立服务配置；故障责任变化是节目基于该结构作出的工程分析，不等于无故障承诺。

定位：SQLite Is Serverless section 2 direct file access model and comparison diagram; Zero-Configuration list of absent setup and administration steps

C-006-004

支持
TRANSCRIPT CLAIM

官方历史页把 SQLite 项目的起点记在二零零零年五月二十九日。 它最初不是要建立一家数据库公司，也不是要替代所有大型数据库。它从更小的目标开始：让一个应用拥有自己需要的数据能力，不再因为外部数据库服务失去控制。 这已经让“任何目的”获得了第一项技术条件。数据库可以进入设备，跟着应用运行。 但跟着应用走的，不只有代码，还有代码的权利。

supports
PUBLIC SOURCES

SQLite, SQLite Developers 历史版 crew 页面

CoRecursive #066, The Untold Story of SQLite, Richard Hipp 访谈

官方历史页支撑项目起始日，Hipp 回忆支撑问题背景；不开列后来成就，也不把后来的公司与制度倒写成初始目标。

定位：historical SQLite Developers page entry for Hipp and project start; CoRecursive #066 origin section

C-006-005

支持
TRANSCRIPT CLAIM

SQLite 第一版使用 GDBM，也就是 GNU Database Manager，作为底层存储。它采用哈希结构，并受 GPL 约束。 Hipp 后来想加入范围查询。只按哈希查找一个键还不够，数据需要保持顺序，查询才能找到一段连续范围。他研究过当时另一套现成存储库的文档，最后判断，与其继续试探接口，不如自己写一棵 B-tree。 于是，SQLite 失去了一项外部依赖，也获得了一项此前没有的能力。更重要的是，准备交付的核心实现开始变成 Hipp 能够说明权利来源的代码。

supports
PUBLIC SOURCES

Changelog Interviews #201, Why SQLite succeeded as a database，D. Richard Hipp 访谈

2016 年本人后见叙述支撑 GDBM、GPL、范围查询与自写 B-tree 的关系；本期只作带归属的转述，不把其他 GPL 软件描述成错误选择。

定位：official transcript lines 227-245 and 473-491, Hipp account of GDBM, range queries, self-written B-tree, and later public-domain choice

C-006-028

支持
TRANSCRIPT CLAIM

Hipp 后来回忆，底层存储变成自己的实现以后，整份核心代码的授权选择终于回到他自己手里。然后，他把答案说得很轻。 D. Richard Hipp（原声）： And I looked at the BSD license, and I looked at the MIT license and I thought, “You know, really, what's the point?” Why not just say, “Hey, it's public domain” and put it out there? And that's what I did. 这个反问，不是在否认 BSD 或 MIT 的商业友好。它们本来就是宽松的开源许可证。Hipp 选择的是再往前一步：尽量不要求下游携带来自 SQLite 的许可条件。 这项选择也把风险集中回来。只要将来混入一段权利不清的代码，SQLite 就不能继续对下一位使用者作出同样简单的承诺。 在二零零一年，最后这项代价还没有出现在故事里。此刻能看见的，只是输出端的门被推开了。

supports
PUBLIC SOURCES

Changelog Interviews #201, Why SQLite succeeded as a database，D. Richard Hipp 访谈

SQLite check-in 4e926efe2b, Disclaimed copyright. Preparing for release 2.0.

Hipp 2016 年后见叙述支撑 BSD / MIT / public domain 的选择理由，同期 check-in 只固定转折时间；不贬低其他宽松许可证，也不提前使用现行贡献制度。

定位：Changelog official transcript public-domain discussion beginning around 56:01; Fossil check-in 4e926efe2b

C-006-006

支持
TRANSCRIPT CLAIM

二零零一年九月十六日，SQLite 仓库留下一条很短的 check-in 注释：放弃版权，准备发布二点零。 十二天以后，SQLite 二点零正式发布。 今天回看，这像是首页那句“公共领域”的起点。但在当时，它首先只是把一个新的障碍移开：别人拿到 SQLite，不必再从 SQLite 这里取得复制、修改或商业使用的许可。 它没有自动带来手机、浏览器和操作系统。它只是让这些后来者出现时，不必先停在授权桌前。

supports
PUBLIC SOURCES

SQLite check-in 4e926efe2b, Disclaimed copyright. Preparing for release 2.0.

SQLite, History Of SQLite Releases

同期仓库与发布记录支撑权利转折时间；不能仅凭 check-in 注释还原完整法律讨论或现行 affidavit 制度。

定位：Fossil check-in 4e926efe2b on 2001-09-16; History Of SQLite Releases entry for 2.0.0 on 2001-09-28

C-006-007

支持
TRANSCRIPT CLAIM

许可桌被移开以后，电话开始打进来。 Hipp 在二零一六年回忆，早期有一通电话来自 Motorola。对方希望把 SQLite 放进手机，也需要一些增强和后续支持。 Motorola 不必购买把公共领域代码复制进手机的权利。那项权利，别人也有。它真正愿意付钱购买的，是一个熟悉这套代码的人愿意为具体需求工作，并在产品继续推进时留下来回答问题。 我们不知道 Motorola 当时比较过哪些方案，也不知道它为什么具体选择 SQLite。这份合同对应哪一种手机、哪一次出货，同样没有 Motorola 一侧的同期记录。因此，这里只能保留 Hipp 多年后的讲述：对方要把数据库放进手机，现有版本还需要增强，产品也需要后续支持。 到那时，SQLite 已经可以跟着应用运行，公共领域也已经允许商业内嵌。它们是这通电话发生以前已经成立的条件，却不能冒充 Motorola 留下的选型理由。 但这段讲述让“任何目的”第一次穿过一条重要边界：商业目的没有被排除。免费使用与付费合作，也没有互相抵消。

supports
PUBLIC SOURCES

Changelog Interviews #201, Why SQLite succeeded as a database，D. Richard Hipp 访谈

Hipp 2016 年后见回忆支撑商业采用与支持合同；缺 Motorola 侧材料，不能补写型号、合同日期、金额、功能或实际出货范围。

定位：official transcript lines 237-247, Hipp account of Motorola requesting phone enhancements, support, and a contract

C-006-030

支持
TRANSCRIPT CLAIM

下一位采用方带来的，不是同一种问题。 Hipp 回忆，AOL 联系他时，需要 SQLite 能够处理二进制数据。当时的 SQLite 二点零只能处理文本。AOL 为这项增强提供资金，SQLite 因而要补上一种真实产品已经需要、现有版本却没有的能力。 现有材料没有留下 AOL 的具体产品，也不能把 SQLite 三点零的全部变化归因于这一家公司。能够确认的是更短的一条因果：允许商业使用，只解决了“能不能拿走”；采用方能否真正留下来，还取决于数据库能不能处理它的资料。

supports
PUBLIC SOURCES

Changelog Interviews #201, Why SQLite succeeded as a database，D. Richard Hipp 访谈

Hipp 2016 年后见回忆支撑 AOL 的二进制数据需求与付费增强；缺 AOL 侧材料，不补具体产品，也不把 AOL 写成 SQLite 3 的单一原因。

定位：official transcript lines 241-245, Hipp account of AOL requesting binary-data support and funding enhancements

C-006-008

支持
TRANSCRIPT CLAIM

这种需求也开始超过一个人能够长期承担的范围。 SQLite 的历史 Developers 页面称，Dan Kennedy 从二零零二年起成为 key contributor。Hipp 后来把 Kennedy 开始为他工作的时间放在 AOL 资助功能增强的阶段，并说 Kennedy 写下了 SQLite 的重要部分。 两个材料给出的关系起点并不完全相同，所以不能把某一通客户电话写成唯一原因。能够确定的是，SQLite 很早就不再是 Hipp 一个人的代码；当“任何目的”把项目带进更多产品，维护承诺也开始由一个小团队承担。

supports
PUBLIC SOURCES

SQLite, SQLite Developers 历史版 crew 页面

Changelog Interviews #201, Why SQLite succeeded as a database，D. Richard Hipp 访谈

SQLite Fossil timeline, u=dan, 2017-02

材料共同支撑 Kennedy 的长期核心参与；2002 年 key contributor 与 AOL 阶段工作关系不强行合并为同一精确日期，Fossil 记录也不当作工作量统计。

定位：historical Developers page Dan Kennedy entry; Changelog transcript lines 241-245; Fossil timeline filtered to user dan in 2017-02

C-006-009

支持
TRANSCRIPT CLAIM

手机仍然让我们想象得到 SQLite 在哪里：它在设备里，替某个应用保存数据。 浏览器把这件事推进得更隐蔽。 二零零四年六月，Mozilla 开发者 Mike Shaver 在 Bugzilla 提议，用 SQLite 替换浏览历史原来的 Mork 后端。他没有只写“SQLite 更好”，而是列出这次替换要减少的工作：获得索引，不必在业务代码里重新实现分组一类的 SQL 操作，可以使用现成工具；正确使用时可以支持多进程和多线程，而且数据库本身不必由 Mozilla 维护。 这些是采用方在动手时写下的理由。九月，另一项 bug 开始建立最初的 mozStorage 接口。十月，基于 mozStorage 的 history 实现继续推进，最终被标记为修复完成。 这不是把 SQLite 做成浏览器里的一个新按钮。恰恰相反，mozStorage 在它外面增加了一层属于 Mozilla 的接口。浏览器其余部分面对的是 Mozilla 的存储组件，SQLite 退到实现内部。

supports
PUBLIC SOURCES

Mozilla Bug 245745, use SQLite as the history backend

Mozilla Bug 261861, initial mozStorage interface

Mozilla Bug 266174, mozStorage-based history

Bug 245745 comment 0 支撑 Mike Shaver 当时列出的索引、SQL、工具、并发使用和免于自行维护等理由，后续同期 issue 支撑 mozStorage 与 history 实现推进；早期 patch 不等于 Firefox 3 最终 Places 的全部设计。

定位：Bugzilla bugs 245745, 261861, and 266174: summaries, creation dates, dependency links, comments, and final resolution state

C-006-010

支持
TRANSCRIPT CLAIM

Mozilla 后来的 Places 文档又从成品一侧回顾了旧后端的阻力：某些搜索和维护操作很慢，RDF 面向文件系统的一侧会出现损坏或意外状态，分离的数据不利于交叉使用，RDF 的维护前景也不清楚。这里必须分开两层时间：前一组是 Mike Shaver 在二零零四年的同期提案，后一组是采用方后来对 Firefox 三 Places 的总结。 最终用户安装 Firefox 时，不会收到第二个问题：你是否同意另外安装 SQLite？ 他选择的是浏览器。浏览器团队已经替他取得源码、完成集成、决定版本、编译产品，并承担数据库如何保存历史与书签的工程判断。 Firefox 后来的源码文档回顾，Firefox 二的历史和书签使用分离的 RDF 数据库；Firefox 三以 SQLite 为后端实现 Places。 到这里，“任何人”出现了新的含义。直接行使源码自由的是 Mozilla 的开发者，真正得到使用结果的，却是大量不必知道 SQLite 名字的浏览器用户。

supports
PUBLIC SOURCES

Firefox Source Docs, Places

采用方后见文档支撑旧后端阻力和 Firefox 3 的内部 SQLite 后端；不把它伪装成 2004 年同期原话，不由此推算用户总数，也不声称用户本人直接下载或行使 SQLite 源码权利。

定位：Firefox Source Docs, Places overview History and Bookmarks section on Firefox 2 RDF databases, performance, reliability, flexibility, maintainability, and Firefox 3 Places

C-006-011

支持
TRANSCRIPT CLAIM

一套公共领域代码可以进入产品，还不等于一家平台敢把未来押在它上面。 Hipp 后来回忆，大约二零零五年，Symbian 需要为手机操作系统选择一套数据库。对方把十种嵌入式数据库放进一次 bake-off，最后选择了 SQLite。 Hipp 同时明确说，他不知道那次评测的具体标准。我们因此只能确认三件事：操作系统需要数据库，Symbian 比较了候选方案，SQLite 被选中。不能拿 SQLite 后来公开的优点，替 Symbian 补写一张已经丢失的评分表。 Symbian 的选择目前只有 Hipp 的后见回忆，不能写成已经取得对方会议记录的同期现场。

采用以后，问题变了。 到二零零七年前后，Symbian 正准备把 SQLite 放进手机基础设施。Hipp 后来这样回忆。 D. Richard Hipp（原声）： But they realized that if this is a critical part of their infrastructure, they needed to make sure my business was sustainable. 这已经不是初次选型标准，而是继续依赖的条件。关键产品需要的，不只是一份今天可以编译的源码，还要有人在明天解释故障、维护旧版本、制作定制测试，并让知识不只存在于一个人身上。 这段担忧仍然来自 Hipp 的后见讲述；随后出现的制度，则可以由协议独立核对。

supports
PUBLIC SOURCES

Changelog Interviews #201, Why SQLite succeeded as a database，D. Richard Hipp 访谈

Hipp 2016 年后见叙述分别支撑 Symbian 初次选择与采用后的持续性问题；缺 Symbian 侧材料，且 Hipp 明说不知道 bake-off 标准。

定位：official transcript lines 299-303 on Symbian database need, bake-off and unknown criteria; lines 521-529 on critical-infrastructure continuity and orphanware concern

C-006-012

支持
TRANSCRIPT CLAIM

二零零七年的 SQLite Consortium 协议模板，把这种担忧写成了可以购买的服务。 协议要求至少保持两名合格开发者；成员可以获得支持、调试、定制开发、定制构建、旧版本支持和定制测试；成员报告或关注的 bug 可以得到优先处理。 但资金没有买走官方主线。协议同时把最终代码责任和权力留给 SQLite Architect，成员不能直接要求某一种实现必须进入原本。 这是一种不对称的交换。采用方用资金降低无人维护的风险，核心团队用支持和测试回应真实产品；技术控制仍然集中，公共领域的使用权仍然向所有人开放。

supports
PUBLIC SOURCES

SQLite Consortium Agreement 模板

SQLite, SQLite Consortium

官方协议模板支撑制度设计，不证明每一位成员的实际履约细节；当前宣传页只作现行交叉。

定位：2007 Consortium Agreement sections 1-5 on purpose, qualified developers, services, bug priority, and architect authority; current Consortium overview

C-006-013

支持
TRANSCRIPT CLAIM

浏览器内部组件和手机平台让 SQLite 获得了一条不同于普通软件产品的传播路径。 它不一定以自己的名字、安装器和图标抵达用户。经常是浏览器、操作系统、语言接口或应用先把它装进自己的交付物，再把运行结果带到设备上。 这也是为什么不能简单说“多数 SQLite 都作为依赖部署”。世界上没有一张能够计算所有实例的清单，“依赖”也混合了 vendored source、平台组件、语言 binding 和应用内部实现。 我们能确认的是两个沿时间线继续向前的结果：Firefox 三把它放进 Places；Android 从最早的平台 API 起提供 SQLite。现有 AOSP 材料能证明 SQLite 已经成为平台组件，却没有保存 Android 最初为什么从候选中选择它。这个动机缺口不能用今天的 AOSP 文档倒填。 没有全球分母，仍然可以看见同一种动作：下游产品替最终用户完成了部署。

supports
PUBLIC SOURCES

Firefox Source Docs, Places

AOSP framework android.database.sqlite package docs

两个采用方材料支撑具体传播结果；不把案例集合包装成多数部署或全球比例，也不从 API 表倒推 Android 最初选型原因。

定位：Firefox Places overview; AOSP android.database.sqlite API-version table beginning at API 1

C-006-014

支持
TRANSCRIPT CLAIM

官方给出的答案，是 amalgamation。 维护者平时工作的 canonical source 仍由许多文件组成。发布时，这些源码被合成为一个巨大的 C 文件：sqlite3.c。另有一个对外声明接口的 sqlite3.h。 sqlite3.c 不是人类维护的原本。它是由 canonical source 生成的构建产物，也是一整个 C translation unit。下游可以把这两个文件放进自己的 source tree，用自己的 Makefile、编译器和选项，和产品其余代码一起构建。 我们这一期的标题写成《sqlite.c》，故意少了一个数字。它指的不是仓库里真实存在的文件名，而是这种分发方式：一套数据库变成一份可以搬走的 C 源码材料。

supports
PUBLIC SOURCES

SQLite, The SQLite Amalgamation

SQLite, The Amalgamation Versus Canonical Sources

SQLite, How To Compile SQLite

官方构建文档支撑生成关系、单 translation unit 和下游 source-tree 用法；标题 `sqlite.c` 是节目简化命名，实际文件为 `sqlite3.c`。

定位：The SQLite Amalgamation sections 1-2; Amalgamation Versus Canonical Sources sections 1-4; How To Compile SQLite section 2

C-006-029

支持
TRANSCRIPT CLAIM

这条分发链上，因此同时存在两棵源码树。 第一棵在 SQLite 维护者手里。语法、测试、工具和多个源文件在这里演化，Fossil 保存它的 canonical 历史。 第二棵属于下游产品。那里也许有浏览器渲染代码、操作系统框架、设备适配和公司自己的构建规则。sqlite3.c 与 sqlite3.h 被放进去以后，就和这棵树里的其他代码一起接受版本锁定、编译选项和发布流程。 amalgamation 像一只标准化的接口箱。上游不必教会每一个采用方怎样运行自己的全部代码生成过程，下游也不必把 SQLite 的开发仓库原样变成产品仓库。 文件看起来很大，协作边界却被压缩成两个动作：取得生成物，把它交给 C 编译器。

supports
PUBLIC SOURCES

SQLite, The Amalgamation Versus Canonical Sources

SQLite, How To Compile SQLite

SQLite, How To Download Canonical SQLite Source Code

官方文档支撑 canonical source、生成物与下游 source tree 的分工；接口箱是节目类比，不表示所有下游只需两个文件或无需配置测试。

定位：Amalgamation Versus Canonical Sources sections 1-4 and diagrams; How To Compile SQLite sections 1-2; How To Download Canonical Source urtext and verification sections

C-006-015

支持
TRANSCRIPT CLAIM

二零一六年的访谈里，Hipp 先提到一位曾经参与 SQLite 团队的开发者，Shane Harrelson，然后把 amalgamation 的构想归功于他。 这句归功很重要。sqlite3.c 很容易让人产生一个错觉：一个文件，看起来像一个人的作品。可文件的单一，来自构建过程的合成，不代表设计、实现和维护只属于一个人。 现有材料没有闭合这个构想第一次出现的年份，所以不能把二零一六年写成发明时间。我们只能说，到了那次回顾里，Hipp 明确把这个分发构想交还给另一位参与者。 一个文件减少的是下游搬运时必须理解的边界，不是上游真实存在的协作与复杂度。

supports
PUBLIC SOURCES

Changelog Interviews #201, Why SQLite succeeded as a database，D. Richard Hipp 访谈

2016 年本人后见回忆支撑 Harrelson 曾参与团队及 amalgamation 归功；首次实现年份未闭合，不把访谈发布日期当作发明日期，也不作直接引语。

定位：official transcript amalgamation discussion in the later distribution section, Hipp attribution to Shane Harrelson

C-006-016

支持
TRANSCRIPT CLAIM

二零一九年，SQLite 又多了一扇更熟悉的门：官方 GitHub 镜像。 在 GitHub 上，任何人都可以浏览源码、克隆仓库、创建自己的分支。网页甚至摆着 pull request 的入口。可是 SQLite 官方文档明确说，这是一份从 Fossil canonical repository 单向导出的只读镜像。内容由 Fossil 输入，不经 GitHub 接受修改。 这扇门像玻璃。代码向外看得更清楚，也更容易被复制；从 GitHub 向官方原本写回的通道，仍然关闭。 此时还不能急着把它解释成维护者拒绝社区。我们只知道，SQLite 把“拿走代码”和“改变下一份官方代码”做成了两个不同动作。

supports
PUBLIC SOURCES

SQLite, Why SQLite Does Not Use Git

GitHub sqlite/sqlite mirror README

官方文档支撑 2019-03-20、单向只读镜像和不经 GitHub 接收变更；不能把当前全部 Git/Fossil 理由倒推到早期项目。

定位：Why SQLite Does Not Use Git section 3.1, Official GitHub Mirror; mirror README sections The SQLite Source Repository and Contributing To SQLite

C-006-017

支持
TRANSCRIPT CLAIM

代码被拿走以后，会发生什么，可以在今天的 Android 开源项目里看见。 这些材料没有记录 Android 当初为什么选择 SQLite。它们回答的是另一个时期的问题：SQLite 已经成为平台组件以后，维护者为什么不能只换掉一个版本号就结束工作？ AOSP 的 platform/external/sqlite 把 SQLite 放在自己的源码树中。升级文档要求维护者取得上游的 amalgamation 归档，导入新版本，再应用 Android 自己的 patch。如果上游变化让 patch 不能干净套用，下游要处理冲突。版本变化以后，还要更新 CTS 里的 SQLite 版本测试。 Android 已经有自己的 patch、对外 API 和兼容测试。继续采用 SQLite，意味着既要取得上游变化，又要守住这些平台差异和兼容口径。它取得了修改自由，也因此拥有自己的版本、构建和验证责任。

supports
PUBLIC SOURCES

AOSP platform/external/sqlite source tree

AOSP dist/README-Android

AOSP README-upgrade.md

AOSP framework android.database.sqlite package docs

采用方源码文档支撑 vendoring、Android.patch、升级冲突与 CTS；2026 快照不代表所有设备使用同一 SQLite 版本或同一厂商构建。

定位：AOSP platform/external/sqlite tree; dist/README-Android; README-upgrade.md import, patch, conflict, version-file, and CTS steps; framework package version note

C-006-018

支持
TRANSCRIPT CLAIM

回到 SQLite 首页。 这一次，不再停在那句承诺。点开 public-domain 链接，进入 SQLite Copyright 页面。 页面先把“任何目的”逐项展开：任何人都可以复制、修改、发布、使用、编译、出售或分发 SQLite 的源代码和二进制形式，用于商业或非商业目的，以任何方式。 它甚至明确说，做这些事不需要得到许可。 这是输出端。代码从这里向外走。

supports
PUBLIC SOURCES

SQLite, SQLite Copyright

当前版权页支撑项目方列出的使用范围；网页是项目权利声明而非节目提供的法律意见，也不覆盖网站文字、商标或第三方扩展。

定位：SQLite Is Public Domain section, paragraphs beginning All of the code and Anyone is free

C-006-019

支持
TRANSCRIPT CLAIM

紧接着，页面把镜头转了过来。 不是继续列举使用者还能做什么，而是追问写下代码的人是谁。 页面说，SQLite 的所有代码作者，以及他们所在公司的代表，都签署了 affidavit，把各自贡献投入公共领域。签字文件的原件，被保存在 Hwaci 主办公室的一只 firesafe 里。 我们不知道这只保险柜的品牌、尺寸、颜色，也不知道它放在哪一个房间。网页没有提供这些细节，本期也不会替它发明画面。 能够确认的物理事实只有一个：一项看起来没有纸面的自由，靠一批纸面原件维持。

supports
PUBLIC SOURCES

SQLite, SQLite Copyright

当前版权页支撑作者、雇主代表、affidavit 原件和 firesafe；不扩写保险柜外观、办公室位置、签署过程或具体公司文件。

定位：SQLite Is Public Domain section, affidavit and firesafe paragraphs immediately before the usage grant

C-006-020

支持
TRANSCRIPT CLAIM

affidavit 可以理解为一份经过宣誓的书面声明。 SQLite 公布的 Copyright Release 模板把它要解决的问题写得更具体。签署者把已经写下的贡献投入公共领域，也处理今后为了 SQLite 发布而产生的修改；签署者还要说明，这些内容由自己原创，或者来自已经确认的公共领域作品。 如果贡献者是代表雇主工作，权利问题就不能只停在个人账户的一句“我同意”。公司是否拥有相关权利、是否授权释放，也必须进入证明链。 一条 commit 可以证明谁按下了提交按钮。它不一定能证明那个人拥有把代码交给全世界任意使用的权利。 保险柜保存的，正是 Git 历史无法独自回答的部分。

supports
PUBLIC SOURCES

Copyright Release for Contributions To SQLite 模板

SQLite, SQLite Copyright

公开模板支撑权利声明范围；模板不证明每一位历史贡献者都签署当前这一版本，也不替代具体法域法律意见。

定位：Copyright Release template dedication, future modifications, originality, and employer acknowledgement clauses; Copyright page affidavit summary

C-006-021

支持
TRANSCRIPT CLAIM

这条证明链之所以重要，是因为 SQLite 承诺的不是“绝大部分代码大概没问题”。 版权页说，所有 deliverable code 都能追溯到原始作者，而且这些作者都完成了公共领域声明。源码镜像里的 LICENSE 文件又补充了范围：SQLite 的主要源码、测试、扩展以及实际构建输出属于这项公共领域声明；仓库里少量用于构建的辅助逻辑可能使用其他开放许可证。 这是一条需要小心表达的边界。不能把“SQLite 代码是公共领域”扩展成“sqlite.org 上每一个字节都没有版权”，更不能把第三方扩展和采访材料一起装进去。 真正被承诺的是能够进入交付物的那条代码链。

supports
PUBLIC SOURCES

SQLite, SQLite Copyright

SQLite source repository, LICENSE.md

两个官方材料共同限定公共领域范围；不能扩展到网站内容、商标、第三方扩展、采访或全部构建辅助文件。

定位：Copyright page deliverable-code paragraph; source mirror LICENSE.md scope and build-logic exception paragraphs

C-006-022

支持
TRANSCRIPT CLAIM

现在，把一份来自网络的 patch 放到这条链上。 代码也许完全正确，测试也许全部通过。可是维护者仍然需要知道：是谁写的？是在个人时间完成，还是属于他的雇主？里面有没有从另一份带许可证的项目复制过来的实现？作者有没有权利把它投入公共领域？几年以后，下一位使用者能不能继续不问许可？ 只要这些问题有一项不清楚，首页的“任何人”就多出一项隐藏作业：请先审计这份 patch 的版权。 这正是 SQLite 输入端最深的阻力。它防的不是别人使用代码，而是来历不明的权利进入下一份官方代码。

所以，copyright 页面使用了一句故意显得刺耳的标题：Open-Source, not Open-Contribution。 页面说，SQLite 不接受互联网上随机提交的 patch。完成正式权利流程成本很高，小修改通常不值得这样做。外部 patch 可以作为 proof of concept，告诉维护者问题可以怎样解决，但核心团队可能查看思路以后，从头重新实现。 这不是说外界不能报告 bug、提出需求或展示代码。SQLite 的 Forum 和 bugs forum 都是公开入口。它说的是另一件事：提供一个想法，与让某一行外部代码获得 canonical 身份，不是同一项权利。 “not Open-Contribution”也不能被压缩成“SQLite 从不接受外部贡献”。项目公开的 Copyright Release 模板本身，就证明外部代码存在一条正式入口；只是作者、雇主、原创性和公共领域声明都要进入权利流程。 门没有焊死。它拒绝的是把随机网络 patch 默认并入官方原本，而不是拒绝所有外部报告、想法或代码。对未来使用者来说，这套严格的证件检查，正是首页那句简单承诺的一部分。

supports
PUBLIC SOURCES

SQLite, SQLite Copyright

Copyright Release for Contributions To SQLite 模板

SQLite source repository, README.md

SQLite User Forum, about

官方当前政策支撑随机 patch、权利成本、proof-of-concept、重写与公开反馈入口；公开模板证明正式贡献路径存在，不能把现行措辞伪装成 2001 年口号，也不能概括为绝对零外部贡献。

定位：Copyright page Open-Source, not Open-Contribution section; Copyright Release template; source repository README contributing and forum sections; User Forum about page

C-006-024

支持
TRANSCRIPT CLAIM

即使每一位作者都完成了声明，“公共领域”在所有地方也不一定产生同样顺滑的法务结果。 SQLite 的版权页列出几种情况：有的公司需要版权侵权赔偿承诺；有的法域不承认公共领域，或者不允许作者把作品投入公共领域；有的采购流程必须拿到一份有形文件，证明公司有权使用和分发这套代码。 这些组织并不是被排除在“任何人”之外。SQLite 为它们准备了 Warranty of Title。

supports
PUBLIC SOURCES

SQLite, SQLite Copyright

当前版权页支撑项目列出的法务场景；它是项目方商业与权利说明，不是本节目对各法域作出的法律结论。

定位：Warranty of Title section, listed reasons for purchasing including indemnity, non-recognition of public domain, and tangible legal document

C-006-025

支持
TRANSCRIPT CLAIM

Warranty of Title 不是一份只有付费客户才能获得的 SQLite 使用许可。 页面先明确：SQLite 属于公共领域，不需要许可证。随后才说明，有额外法务需求的组织可以购买一份权利保证。文件主张签署方有权把 SQLite library 投入公共领域，也提供相应保证。销售收入继续用于资助 SQLite 的改进和支持。 这条商业路径没有在首页的承诺后面补上一句“企业除外”。它承认，不同使用者抵达同一项自由时，面对的法域和组织程序并不相同，于是为更高的证明需求增加一座桥。 免费的，是使用权。收费的，是额外的证明、保证和责任承担。

supports
PUBLIC SOURCES

SQLite, SQLite Copyright

当前项目页面支撑免费使用权与付费权利保证的区分；不据此推断任何具体客户购买、法律结果或收入规模。

定位：Warranty of Title section, no-license preface, document description, and proceeds-fund-SQLite closing paragraph

C-006-026

支持
TRANSCRIPT CLAIM

首页还有一个容易被误解的词，需要在结尾收紧。 “用于任何目的”，说的是你不必向 SQLite 请求用途许可。它不等于 SQLite 适合任何技术架构。 SQLite 自己的 Appropriate Uses 页面写得很直接：如果许多客户端要通过网络同时直接访问同一个数据库，更适合 client/server 数据库；写入量很大的多服务器网站，应该考虑另一种引擎；SQLite 同一时间对一个数据库文件只允许一个 writer，需要大量并发写入的应用也可能要选择别的方案。 公共领域不会改变网络延迟、文件锁和并发写入的物理条件。

supports
PUBLIC SOURCES

SQLite, Appropriate Uses For SQLite

官方当前适用性文档支撑技术边界；`any purpose` 是权利范围，不是性能、架构适配、支持或无缺陷保证。

定位：Situations Where A Client/Server RDBMS May Work Better and Checklist sections on network access, high-volume websites, and concurrent writers

全部来源

33 SOURCES

SQLite, How SQLite Is Tested

1 条关系

TH3、TCL tests、故障 / crash / fuzz 测试、branch 与 MC/DC coverage，以及参数化测试数量；数字属于当前文档口径，不能证明历史上一直如此，也不能推出绝对无缺陷

SQLite / 日期未知 / sanitized-full

SQLite, Most Widely Deployed SQL Database Engine

1 条关系

提供 Android、iOS、Firefox、Chrome、Safari 等采用线索和 trillion 级实例估算；标题不能直接作为节目事实。页面明确使用 likely、probably、seems likely，必须拆指标并由采用方材料交叉

SQLite / 日期未知 / sanitized-full

SQLite homepage

1 条关系

首页原句 SQLite source code is in the public-domain and is free to everyone to use for any purpose.；用于建立本期核心命题。周边 all mobile phones、most computers 与 countless 等采用文案不因同页出现而自动成为节目事实

SQLite / 日期未知 / sanitized-full

CoRecursive #066, The Untold Story of SQLite, Richard Hipp 访谈

3 条关系

舰船应用、无法控制既有数据库、服务器故障、预算争执、Mozilla / AOL、商业支持、航空测试、自建工具与自给哲学；页面 transcript 只能定位，直接引语、说话人和时间码必须人工复听。主持人给出的舰名、承包关系、产品名和采用规模需另找来源

CoRecursive / 2021-07-02 / sanitized-full

SQLite, SQLite Is Serverless

2 条关系

解释数据库引擎与应用位于同一进程并直接读写文件，以及 client/server 的优劣；页面使用当前术语，不自动证明 2000 年人物动机

SQLite / 日期未知 / sanitized-full

SQLite, Zero-Configuration

2 条关系

“无需安装 / setup / server 管理员 / 配置文件”的明确含义；只适用于页面定义的 SQLite 使用方式，不推出所有宿主应用都无配置成本

SQLite / 日期未知 / sanitized-full

SQLite, SQLite Developers 历史版 crew 页面

2 条关系

可确认 Hipp 启动项目、Dan Kennedy 自 2002 年起为 key contributor、Joe Mistachkin 背景；只代表 2022 页面版本，不把历史职责当成现状

SQLite / 2022-01-08 / sanitized-full

SQLite, History Of SQLite Releases

1 条关系

定位 1.x、2.0.0、3.0.0 和后续版本日期，并回到对应 Fossil timeline；不能从发布日期直接推断设计动机、采用压力或稳定程度

SQLite / 日期未知 / sanitized-full

SQLite Fossil timeline, u=dan, 2017-02

1 条关系

证明 Dan Kennedy 账户在具体时期直接进入 canonical repository；不是完整贡献史或职责说明

SQLite / 日期未知 / sanitized-full

Firefox Source Docs, Places

2 条关系

Places 用 SQLite 替代 Firefox 2 的 RDF history / bookmarks 后端；当前文档是后来的技术回顾

Mozilla / 日期未知 / sanitized-full

SQLite Consortium Agreement 模板

1 条关系

至少两名合格开发者、支持、定制测试、优先修复、architect 最终责任和控制边界；模板不证明每个成员的执行细节

SQLite / 2007-12-01 / sanitized-full

SQLite, SQLite Consortium

1 条关系

成员资助、直接访问开发者、企业支持与维持独立性的自述；成员收益与项目因果需要合同 / 历史材料或参与者来源交叉，不照抄宣传措辞

SQLite / 日期未知 / sanitized-full

SQLite, The SQLite Amalgamation

1 条关系

sqlite3.c 单 translation unit、集成方式与编译优化；amalgamation 是核心入口物件，但其首次出现时间、采用效果和传播因果仍需历史来源

SQLite / 日期未知 / sanitized-full

SQLite, The Amalgamation Versus Canonical Sources

2 条关系

canonical source 生成 amalgamation、下游可把文件嵌入自己的 source tree、预构建产物经过测试；用于建立 主线 -> 构建产物 -> 下游产品 链条

SQLite / 日期未知 / sanitized-full

SQLite, How To Compile SQLite

2 条关系

官方称 amalgamation 更易处理、推荐所有应用使用，并给出 sqlite3.c / sqlite3.h 的直接编译路径；证明项目设计的预期分发方式，不证明每个下游实际采用这种路径

SQLite / 日期未知 / sanitized-full

SQLite, How To Download Canonical SQLite Source Code

1 条关系

canonical source、Fossil repository、历史版本与 verify-source；用于区分 urtext 和生成的 amalgamation，不把当前流程倒推为 2000 年流程

SQLite / 日期未知 / sanitized-full

SQLite, Why SQLite Does Not Use Git

1 条关系

GitHub 镜像自 2019-03-20 起由 Fossil 单向导出、只读、不接收 pull request；当前理由不能全部倒推到早期历史

SQLite / 日期未知 / sanitized-full

GitHub sqlite/sqlite mirror README

1 条关系

再次区分 Fossil urtext 与 Git 镜像；GitHub 可见性不等于 GitHub 协作入口

SQLite / 日期未知 / sanitized-full

AOSP platform/external/sqlite source tree

1 条关系

确认 AOSP vendored source、Android.patch 与升级工具存在；树快照不说明所有设备使用同一版本

Android Open Source Project / 日期未知 / sanitized-full

AOSP dist/README-Android

1 条关系

Android port 有定制 patch 并为后续升级保留差异；不把 patch 存在解释成偏离上游全部行为

Android Open Source Project / 日期未知 / sanitized-full

AOSP README-upgrade.md

1 条关系

上游 source 导入、Android patch、版本文件与 CTS 验证步骤；证明下游主动维护版本边界

Android Open Source Project / 日期未知 / sanitized-full

SQLite, SQLite Copyright

7 条关系

SQLite 核心代码 public-domain dedication、贡献限制和商业 license 选项；不是法律意见，不能把代码状态扩展到网站内容、商标、构建脚本或第三方扩展

SQLite / 日期未知 / sanitized-full

SQLite source repository, LICENSE.md

1 条关系

说明主源码、test、ext 与实际 build output 的公共领域范围，以及少量 build logic 的许可例外；GitHub 页面不是 canonical 写入入口

SQLite / 日期未知 / sanitized-full

SQLite source repository, README.md

1 条关系

Fossil repository 是 urtext、Git 服务副本是次级载体、Forum / bugs forum 是联系入口、项目通常不接受 pull request 的 public-domain 理由；当前页面不能单独证明历史时期政策

SQLite / 日期未知 / sanitized-full

SQLite User Forum, about

1 条关系

公开问题、讨论与反馈入口；能够影响维护不等于获得 canonical commit 权限

SQLite / 日期未知 / sanitized-full

SQLite, Appropriate Uses For SQLite

1 条关系

区分 SQLite 的 local application / device storage 目标与 client/server 数据库；列出嵌入式、应用文件、内部数据库等适用场景及多机直接访问、高并发等反例。证明 any purpose 是使用权，不等于技术上适合所有工作负载

SQLite / 日期未知 / sanitized-full