ADR 0009: 重新定义"不绑定框架"——无框架锁定 + 仅限宽松许可证

状态：accepted · 日期：2026-06-17

不可变记录。豁免漂移追踪（无 covers）。只可被取代，不可编辑。

隶属于 0002 产品方向。

背景

"framework-free / zero-SDK-core / 可离线运行"这个卖点表述并未准确描述真正的约束。真正的要求是：(a) 不被 LangChain 系编排框架锁定（LangChain / LlamaIndex / Dify / LangGraph），以及 (b) 依赖许可证卫生——不接受比 Apache-2.0 更严格的许可证（排除 GPL/AGPL/LGPL、SSPL、非商用等）。成熟的基础库（torch、numpy、sentence-transformers）是可接受的。"零依赖"从来不是重点。

决策

重新定义不绑定框架 = (a) 无编排框架锁定 + (b) 仅限宽松许可证（宽松程度 ≤ Apache-2.0）。具体而言：

• **重写定位表述：**从"zero-SDK / 可离线运行"改为"无框架锁定 + 许可证干净 + 每个后端都可通过 Protocol 替换"。
• **CI 中的依赖许可证门禁：**每一个传递依赖都必须使用宽松许可证，否则门禁失败。这将约束落到实处，其本身对注重合规的用户也是一个卖点。
• **精简的默认安装：**真实后端（torch/embeddings）通过 extra（[embed] 等）按需启用——这是一个关于安装体积和可选 GPU 的打包/用户体验选择，不再是纯粹性选择。离线确定性路径（BM25 + MockProvider）仍是默认的测试/演示循环，是被保留的优势，而非教条。

考虑过的备选方案（已否决）

• 绝对零 SDK 核心，为纯粹性把所有真实后端放进 extra（方案 A）：其_理由_被否决——torch/numpy 在许可证和锁定层面都是可接受的，所以纯粹性不是原因；安装体积才是。（精简默认安装这一结果被保留，但基于不同的理由。）
• 开箱即用的默认安装（在基础安装中附带一个真实 CPU embedding）：否决——数 GB 的默认安装对一个尚在评估阶段的库是采用门槛。
• 分层的 ragspine-core + ragspine 发行版：否决——对单作者的 v0.1 而言是过早的运维负担。

影响

• README 和 pyproject 的定位/措辞更改。
• 新的 CI 工作流：依赖许可证门禁。
• 放宽 0005/0006：真实 embedding 模型在许可证和锁定层面是可接受的；它作为 extra 存在是出于体积考量，而离线默认仍是纯占位实现，并有清晰标注。