Caveman 的双许可模型详解:MIT + BSL-1.1 目录级分治、OEM 商业边界与 Apache-2.0 日落计划 Caveman 的双许可模型详解MIT BSL-1.1 目录级分治、OEM 商业边界与 Apache-2.0 日落计划【免费下载链接】caveman why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman项目地址: https://gitcode.com/GitHub_Trending/caveman1/cavemanCaveman 仓库采用 MIT BSL-1.1 的双许可split license模型面向技能与生态接入面的代码保持 MIT而压缩引擎及内嵌它的 Go 二进制则使用 Business Source License 1.1并附带一项允许第一方自托管生产使用的 Additional Use Grant。读完本篇你将能够准确判断仓库中任意目录受哪种许可约束、自托管生产使用与对外商用服务的边界在哪里、哪些条款会在 2030-06-21 或版本发布四年后转换为 Apache-2.0以及向 BSL 目录贡献代码时需要履行的 DCO 与再许可授予义务。双许可模型总览Caveman 许可证说明 开篇即给出整体定位公共仓库的对外身份对 Caveman 技能skill与生态接入面adoption surfaces保持MIT压缩引擎compression engine以及内嵌该引擎的 Go 二进制使用Business Source License 1.1BSL-1.1并附带一项 Additional Use Grant允许第一方自托管的生产使用而把 Licensed Work 或其功能以托管hosted、管理managed或嵌入embedded服务的形式提供给第三方则要求商业许可。这种 开源核心 源码可见运行时open core / source-available结构的意义在于技能、SDK、CLI 等生态层可以完全自由地被集成和再分发而承载核心压缩 IP 的引擎层保留了商业化的空间且 BSL 条款本身承诺了向 Apache-2.0 的日落sunset转换因此 BSL 目录的代码在 Change Date 之前属于 source-available, not OSI Open Source。代理服务、引擎 等模块的 README 中也都明确标注了这一身份。三份许可文件与权威层级仓库用三份文件共同构成许可体系的规范文件Canonical Files各自职责不同文件角色根 LICENSEMIT 许可全文 顶部范围注释Scope note指向引擎相关目录应查阅LICENSE.BSLLICENSE.BSLCaveman Engine 相关代码的 BSL-1.1 规范文本包含全部参数Licensor、Licensed Work、Additional Use Grant、Change Date、Change LicenseLICENSING.md目录级许可的权威来源per-directory source of truth根 LICENSE 的前五行就是范围注释明确列出引擎相关目录Scope note: this MIT license covers this repository except Engine-linked directories listed in LICENSING.md (engine/, proxy/, cacheengine/, rewriter/, browse/, mcp/, shrink/, cavemem Go core, shared/platform/), which are licensed under Business Source License 1.1 — see LICENSE.BSL. New Engine-linked runtime modules default to BSL-1.1 unless explicitly classified as MIT.值得注意的是根 LICENSE 的版权行是Copyright (c) 2026 Julius Brussee与 LICENSE.BSL 中Licensed Work: Caveman Engine. The Licensed Work is (c) 2026 Julius Brussee的声明相互印证。目录级许可对照表LICENSING.md 给出了完整的目录—许可映射表这是使用者进行合规判断时最核心的参考资料。下表完整继承原文档内容并结合仓库中实际存在的各目录 LICENSE 文件做了核验路径许可说明skills/MIT既有 Caveman 技能保持 MIT不受引擎条款影响packages/agent/MITAgent 运行时、构建编译器、Claude lane、框架适配器与编码代理 APIpackages/create-caveman-agent/MIT零运行时依赖的 Agent SDK 初始化器packages/cli/MIT入口/引导层funnel/on-ramp会启动 BSL 二进制但本身不包含引擎代码packages/sdk/typescript/MIT轻量客户端与结构化 SDK 接口packages/sdk/python/MIT轻量客户端分发名为caveman-sdkpackages/subagent-tax/MIT本地零 provider 调用的 harness 前缀度量工具extension/MIT shell清单、popup、内容脚本与 UI 为 MIT但捆绑的engine.wasm是 BSL-1.1因此内嵌该 WASM 的构建产物对该结合作品整体承载 BSL 条款packages/shared/contracts/MIT公共 wire schema 与生态契约shared/provider-catalog/MIT公共 provider/model 元数据与目录 schemamem/js/MITcavemem 的轻量 JavaScript 客户端mem/py/MITcavemem 的轻量 Python 客户端engine/BSL-1.1核心压缩 IP 与 CCRcacheengine/BSL-1.1provider 原生 prompt-cache 规划器与 wire 引擎rewriter/BSL-1.1引擎关联的反思重写器与恢复门控browse/BSL-1.1本地浏览器驱动内嵌引擎同时 vendor 了 MIT 的 chromedp 模块proxy/BSL-1.1独立网关与 provider 适配器mcp/BSL-1.1Go 二进制内嵌引擎shrink/BSL-1.1Go 二进制/包内嵌引擎的工具 schema 压缩器mem/ Go 核心BSL-1.1Go 核心内嵌引擎mem/js与mem/py保持 MIT 客户端shared/platform/BSL-1.1被静态链接进各 BSL Go 二进制的平台层路径均相对于仓库根目录。技能自带的基准测试 harness 位于 evals/与技能一样为 MIT。默认归类规则Engine-linked 即 BSL文档同时给出了一条面向未来的默认规则任何新模块只要导入、链接、内嵌或作为 Engine-linked 运行时的一部分发布默认即为 BSL-1.1除非后续决策显式将其归类为 MIT 接入面。这意味着在 BSL 目录下新增代码不会改变其许可身份跨目录引用时也要注意依赖方向——例如 packages/cli/ 之所以能保持 MIT正是因为它只启动BSL 二进制而不包含引擎代码。一个很直观的对照是mem/目录其 Go 核心mem/store.go、mem/bm25.go 等受 BSL-1.1 约束而 mem/js/index.mjs 和 mem/py/cavemem.py 只是薄客户端各自带 MIT 的 LICENSE 文件保持 MIT 身份。MIT 启动器 BSL 二进制的分发形态mcp/README.md 与 shrink/README.md 描述了同一套分发策略npm 上的 MIT launcher 在首次运行时下载匹配的 BSL-1.1 二进制并做校验两个目录都包含LICENSE.launcher、BINARY_LICENSE.md等配套文件。即用户通过包管理器安装的启动脚本按 MIT 使用下载到的可执行文件则遵循 LICENSE.BSL 中列明的 BSL-1.1 条款。这也是理解CLI 是 MIT、它启动的引擎是 BSL这一分治原则的关键细节。Additional Use Grant第一方生产可用的边界License.BSL 的 Parameters 段落是理解商用边界的核心。其 Additional Use Grant 的完整表述为Additional Use Grant: You may make production use of the Licensed Work for internal evaluation, local development, CI testing, integration, and self-hosted use for your own first-party traffic. This grant does not permit offering the Licensed Work, or its functionality, to third parties as a hosted, managed, or embedded service. Such use requires a separate commercial license from the Licensor.结合 LICENSING.md 的解读该 Grant 具体覆盖内部评估internal evaluation本地开发local developmentCI 测试CI testing集成integration自有第一方流量的自托管使用包括生产环境self-hosted use for your own first-party traffic, including production而把 Caveman、Licensed Work 或其功能作为托管、管理或嵌入式服务提供给第三方则必须从 Licensor 处取得商业许可——文档称之为 OEM/platform boundaryOEM/平台边界。具名的商业/OEM 合作伙伴可以另行签署 carve-out 协议获得特定托管/管理/嵌入用法的额外授权。Change LicenseApache-2.0 日落机制BSL 1.1 的精髓在于每个版本都有确定的转换终点。LICENSE.BSL 中声明Change Date: 2030-06-21 Change License: Apache License, Version 2.0而 LICENSING.md 强调转换发生在两个时间点中的较早者2030-06-21该版本在 BSL 下首次公开发布满四年之日the fourth anniversary of that versions first public distribution under BSL。License.BSL 正文还说明 BSL 按版本分别适用This License applies separately for each version of the Licensed Work and the Change Date may vary for each version——即每个 BSL 版本拥有自己独立的转换时钟。这意味着早期发布的 BSL 版本会先于 2030-06-21 转为 Apache-2.0越晚发布的版本越接近但不晚于这个固定日期。对使用方的实际含义BSL 目录的代码今天是可审阅、可自托管、可修改的源码但不是 OSI 定义的开源软件它承诺了一条明确的开源化路径而非无限期的 source-available 状态。TRADEMARKS.md 中也有同样的提示BSL-1.1 directories are source-available, not OSI Open Source before Change Date。商业边界清单LICENSING.md 用两张清单把免费区与商业区分隔得很直白判断自己处于哪一侧时可以直接对照免费 / 源码可见Free/source-available本地与单租户使用local and single-tenant useBYOK / 自托管的第一方流量inferred savings推断式节省即本地估算口径SDK、CLI、扩展 shell、contracts、provider catalog商业Commercial面向第三方的托管/管理/嵌入优化服务跨组织的 verified savings验证式节省报表多租户控制面、SSO/RBAC/RLS、治理与审计签名的计量回执signed metering receipts、收益分成计费、Enterprise/OEM 许可贡献流程DCO 与 BSL 再许可授予LICENSING.md 与 CONTRIBUTING.md 共同规定了贡献规则两条线并行MIT 区域inbound outbound你的变更以同样的 MIT 条款授权无额外负担。BSL 区域需要同时满足两项要求DCO 签署CONTRIBUTING.md 给出了具体操作每个 commit 追加 sign-off例如git commit -s -m your message这会在 commit 末尾追加Signed-off-by: Your Name youremailtrailer没有 CLA、没有表单。再许可授予relicense grant向 BSL 目录engine/、proxy/、cacheengine/、rewriter/、browse/、mcp/、shrink/、cavemem Go 核心、shared/platform/贡献代码即同时授予 Julius Brussee 以商业或 OEM 条款对你贡献再许可的权利。其目的是保持 open-core 模型的一致性——社区对引擎的改进能够进入商业产品与 OEM 交付而不会使代码库碎片化。你的贡献在公共仓库中保持 BSL-1.1并在与引擎其余部分相同的 Change Date 上日落为 Apache-2.0。CONTRIBUTING.md 还明确如果对 BSL 再许可授予不放心可以转而贡献 MIT 部分。PR 流程上维护者会检查受影响目录的许可范围、测试、生成物与安全边界。第三方代码与字体资产LICENSING.md 单独列出了两处重要的第三方代码归属engine/pixel/该目录是 pxpipe 的 Go 移植版MIT, Copyright (c) 2026 claude-image-proxy contributors并内嵌了派生自 Spleen 5x8BSD-2-Clause与 GNU UnifontOFL-1.1 / GPLv2 with font-embedding exception字体的字形图集。BSL-1.1 适用于该结合作品上游的 MIT 声明与字体声明保留在 engine/pixel/NOTICE 与 engine/pixel/assets/ 中。仓库中实际可见 engine/pixel/assets/SPLEEN_LICENSE.txt 与 engine/pixel/assets/UNIFONT_LICENSE.txt以及atlas-pixels.bin.gz等图集资源文件。browse/vendor 了 MIT 许可的 chromedp 模块见 browse/NOTICE。对下游集成方的提示即使你只在 MIT 范围内使用某个组件这类 NOTICE 文件与字体版权声明也是必须随结合作品保留的部分。商标代码许可不授予名称权LICENSING.md 最后一段声明 Caveman 及 Caveman 标志是 Julius Brussee 的商标代码许可不授予任何商标权诚实的指示性使用nominative use例如 Powered by Caveman 或 Optimized by Caveman是被允许的而以暗示 Caveman 背书的方式命名你的产品、托管服务或 fork 则需要书面许可。完整政策见 TRADEMARKS.md。TRADEMARKS.md 补充了操作层面的细节无需许可works with Caveman、powered by Caveman、compatible with Caveman 等准确描述以及在文档、博客、演讲、比较评测中提及本项目以及按许可 fork 代码并运行需要许可把你的产品/服务/公司命名为 Caveman 或易混淆的名称、把 Caveman 标志用作自家产品图标、暗示你的 fork 或托管服务是官方或获 Julius Brussee 背书、销售使用名称或标志的周边商品商标权独立于 MIT 接入面、BSL 运行时与商业版 Caveman Cloud 三者之外单独存在滥用标志会导致你使用标志的授权终止但代码许可不受影响。快速合规自检在实际使用或集成仓库中的某个目录之前可以按以下步骤自检定位目录确认你要使用的代码属于哪个目录对照本文的目录级许可对照表确定它是 MIT 还是 BSL-1.1新模块默认 BSL 的规则适用于 Engine-linked 运行时确认使用形态如果是本地、单租户、BYOK 自托管的第一方流量——包括生产环境——BSL 的 Additional Use Grant 已经覆盖如果计划把功能作为托管/管理/嵌入服务提供给第三方先联系取得商业许可注意捆绑产物的整体身份如浏览器扩展这类 MIT shell BSLengine.wasm的组合内嵌 WASM 的分发物整体承载 BSL 条款npm launcher 同理——launcher 是 MIT下载的二进制是 BSL-1.1贡献前MIT 区域直接提交BSL 区域记得git commit -s附 DCO并理解 relicense grant 的含义保留第三方声明涉及 engine/pixel/ 或 browse/ 的衍生使用保留对应 NOTICE 与字体许可文件核对商标对外表述保持指示性使用不将 Caveman 用作自有产品名或标志。以上边界全部以当前仓库的 LICENSING.md、LICENSE、LICENSE.BSL、TRADEMARKS.md 与 CONTRIBUTING.md 为准若仓库后续调整目录归类或 Change Date以届时文档与许可文件为准。【免费下载链接】caveman why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考