GreptimeDB 双许可证机制解析Open-Core 架构下的 Apache-2.0 与 Enterprise License 治理实战【免费下载链接】greptimedbThe open-source observability database. One columnar engine for metrics, logs, and traces, on object storage.项目地址: https://gitcode.com/GitHub_Trending/gr/greptimedbGreptimeDB 采用 open-core开放核心商业模式核心代码以 Apache-2.0 许可开源少数企业级特性则受独立的 GreptimeDB Enterprise License 约束。本文以仓库 licenses/README.md 为主线结合licenserc.toml、licenserc-enterprise.toml、许可文本与 CI 校验脚本完整讲解这套双许可证布局、Cargo feature 门控机制、hawkeye 双重校验流程以及新增企业源文件时必须遵循的操作步骤帮助贡献者理解并正确维护仓库的许可边界。一、双许可证布局总览GreptimeDB 是一个 open-core 项目仓库内同时存在两套许可体系适用范围和声明位置如下表所示范围许可证声明位置核心默认构建Apache-2.0LICENSE逐文件 Apache 头由 licenserc.toml 强制执行企业特性GreptimeDB Enterprise LicenseLICENSE-ENTERPRISE逐文件企业头由 licenserc-enterprise.toml 强制执行仓库根目录的 LICENSE 是标准 Apache License 2.0 全文201 行约束所有默认构建包含的源代码。根目录的 LICENSE-ENTERPRISE 是企业许可全文。其开头的START NOTE明确声明该许可不适用于GreptimeDB 核心由仓库根目录/LICENSE定义核心可以在不侵犯本许可的前提下自由使用与运行受企业许可约束的源文件均携带明确的企业头并通过enterpriseCargo feature 门控不会编译进默认的开源构建。企业头模板位于 licenses/enterprise-header.txt内容声明版权归GrepTime Inc.2023-2026并指向LICENSE-ENTERPRISE获取完整条款。从目录结构看仓库将许可证相关的配置文件集中放置根目录两份许可全文、两份 hawkeye 配置licenserc.toml/licenserc-enterprise.toml、licenses/目录下存放 README 说明与头文件模板职责划分清晰。二、企业特性如何被隔离enterpriseCargo feature 门控企业源码与核心源码的根本区分点在于 Rust 的#[cfg(feature enterprise)]条件编译属性。凡是被企业许可约束的文件只能通过企业门控的模块声明被引用默认构建不开启enterprisefeature时这些模块不会被编译。仓库中存在大量此类门控点例如src/common/function/src/admin.rs 与 src/common/function/src/function_registry.rs 中的#[cfg(feature enterprise)]src/catalog/src/system_schema/information_schema.rs 中的企业门控模块声明src/common/meta/src/ddl/drop_table.rs 与 src/common/meta/src/ddl/drop_table/executor.rs 中的企业特性分支。这些门控对应的实际源文件正是两份许可配置中列出的企业文件如src/common/meta/src/rpc/ddl/trigger.rs、src/operator/src/expr_helper/trigger.rs、src/mito2/src/extension.rs、src/common/function/src/admin/purge_table.rs、src/catalog/src/system_schema/information_schema/recycle_bin.rs等印证了门控声明位置与许可配置文件清单之间的一一对应关系。三、许可头如何被强制CI 中的 hawkeye 双重校验仅靠文档声明无法保证许可合规仓库通过 CI 自动化强制每一份源文件都携带正确许可头。依据 licenses/README.mdCI 中的license-header-check任务会运行 hawkeye 工具两次默认配置licenserc.toml对所有源码应用 Apache-2.0 头但排除企业文件清单企业配置licenserc-enterprise.toml仅对企业文件应用企业许可头。其中licenserc.toml的includes覆盖*.rs、*.py、*.ts三类源码文件并将若干拷贝自第三方的源码如src/common/base/src/readable_size.rs、src/servers/src/http/test_helpers.rs等放入excludes豁免。文件头的属性配置在[properties]段inceptionYear 2023头模板中年份的起始值copyrightOwnerlicenserc.toml中使用Greptime Teamlicenserc-enterprise.toml中使用GrepTime Inc.两套许可体系对应不同版权主体。企业配置则通过headerPath licenses/enterprise-header.txt指向企业头模板其includes精确列出全部企业门控文件与主配置的excludes中# enterprise:start/# enterprise:end标记块内容完全互补。四、两份清单必须保持同步互补关系与脚本校验licenserc.toml与licenserc-enterprise.toml的关系是互补且必须同步的licenserc.toml的excludes# enterprise标记块—— 将企业文件从 Apache 头检查中排除licenserc-enterprise.toml的includes—— 将同一批文件纳入企业头检查。两份清单一旦失同步就会出现两类 CI 失败企业文件被误打上 Apache-2.0 头或企业文件完全没有许可头。更关键的是hawkeye 本身无法发现某文件本应属于企业清单却漏列的问题——因为这样的文件没有被从默认检查中排除它会带着 Apache-2.0 头顺利通过默认检查。为了堵住这个漏洞仓库提供了专门的同步校验脚本 scripts/check-enterprise-license.py通过git ls-files枚举所有被版本控制的*.rs文件静态解析每个文件中的#[cfg(feature enterprise)] mod ...;声明支持#[cfg(all(test, feature enterprise))]等复合谓词且会递归下沉到被门控模块的子模块因为子模块同样属于企业门控范围将解析出的实际企业门控文件集合分别与licenserc-enterprise.toml的includes、licenserc.toml的# enterprise:start/# enterprise:end标记块对比报告四类问题漏于 includes、漏于 excludes、过期的 includes 条目、过期的 excludes 条目。该脚本在 Makefile 中以make check-enterprise-license暴露配套的单测位于 scripts/check-enterprise-license-test.py覆盖了门控只作用于下一条声明测试专用门控#[cfg(all(test, feature enterprise))]也计为企业any(...)等非门控组合被忽略等边界情形保证解析逻辑本身可信。五、新增一个企业源文件的完整操作步骤当需要为企业特性新增源码文件时按以下步骤操作来自 licenses/README.md 并结合仓库配置细化确认门控方式新文件必须通过#[cfg(feature enterprise)] mod ...;声明而非内联mod { ... }因为内联模块没有独立文件确保它不会进入默认开源构建。同时加入两份清单将该文件路径添加到licenserc-enterprise.toml的includes并同步添加到licenserc.toml的excludes# enterprise:start与# enterprise:end标记之间。两份清单必须保持一致否则make check-enterprise-license会报漏列或过期条目。应用企业许可头hawkeye format --config licenserc-enterprise.toml验证许可头hawkeye check --config licenserc-enterprise.toml两条铁律必须遵守不要在企业文件上放置 Apache-2.0 头不要让企业文件缺失许可头。两种情况都会导致 CI 失败前者会被主配置的排除逻辑与同步脚本双重拦截后者会被企业配置的 hawkeye 检查拦截。修正清单后可运行hawkeye format --config licenserc-enterprise.toml自动补齐企业头。六、常见问题与排查建议Q1为什么新增企业文件后make check-enterprise-license失败说明新文件没有被正确加入两份清单或清单中出现过期条目。运行python3 scripts/check-enterprise-license.py脚本会分类打印缺失的includes/excludes条目以及不再属于企业门控的过期条目。Q2为什么企业文件只加进了licenserc-enterprise.toml却仍然报错因为该文件未从licenserc.toml的excludes中排除会被默认的 hawkeye 检查Apache-2.0 头命中。两份清单是互补关系必须成对维护。Q3#[cfg(all(test, feature enterprise))]算企业门控吗算。从 scripts/check-enterprise-license-test.py 的测试用例可见只要谓词中要求feature enterprise即视为企业门控如recycle_bin_test.rs就因此被列为企业文件而any(test, feature enterprise)这类非门控组合则被忽略因为它在非企业构建下依然可编译。Q4内联的mod { ... }声明需要单独列入清单吗不需要。同步脚本只处理有独立文件的目标模块name.rs或name/mod.rs内联模块没有自己的文件也就不属于许可清单的管理对象。七、总结GreptimeDB 通过双许可文本 Cargo feature 门控 hawkeye 双重检查 同步校验脚本四层机制构建了可自动验证、难以被误改的许可治理体系。对贡献者而言核心要点只有三个企业代码必须用#[cfg(feature enterprise)]门控、必须同时出现在两份许可配置中、必须携带企业许可头。理解这套机制既是向仓库提交代码的前提也是判断哪些代码可自由使用、哪些受企业许可约束的权威依据。【免费下载链接】greptimedbThe open-source observability database. One columnar engine for metrics, logs, and traces, on object storage.项目地址: https://gitcode.com/GitHub_Trending/gr/greptimedb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
GreptimeDB 双许可证机制解析Open-Core 架构下的 Apache-2.0 与 Enterprise License 治理实战【免费下载链接】greptimedbThe open-source observability database. One columnar engine for metrics, logs, and traces, on object storage.项目地址: https://gitcode.com/GitHub_Trending/gr/greptimedbGreptimeDB 采用 open-core开放核心商业模式核心代码以 Apache-2.0 许可开源少数企业级特性则受独立的 GreptimeDB Enterprise License 约束。本文以仓库 licenses/README.md 为主线结合licenserc.toml、licenserc-enterprise.toml、许可文本与 CI 校验脚本完整讲解这套双许可证布局、Cargo feature 门控机制、hawkeye 双重校验流程以及新增企业源文件时必须遵循的操作步骤帮助贡献者理解并正确维护仓库的许可边界。一、双许可证布局总览GreptimeDB 是一个 open-core 项目仓库内同时存在两套许可体系适用范围和声明位置如下表所示范围许可证声明位置核心默认构建Apache-2.0LICENSE逐文件 Apache 头由 licenserc.toml 强制执行企业特性GreptimeDB Enterprise LicenseLICENSE-ENTERPRISE逐文件企业头由 licenserc-enterprise.toml 强制执行仓库根目录的 LICENSE 是标准 Apache License 2.0 全文201 行约束所有默认构建包含的源代码。根目录的 LICENSE-ENTERPRISE 是企业许可全文。其开头的START NOTE明确声明该许可不适用于GreptimeDB 核心由仓库根目录/LICENSE定义核心可以在不侵犯本许可的前提下自由使用与运行受企业许可约束的源文件均携带明确的企业头并通过enterpriseCargo feature 门控不会编译进默认的开源构建。企业头模板位于 licenses/enterprise-header.txt内容声明版权归GrepTime Inc.2023-2026并指向LICENSE-ENTERPRISE获取完整条款。从目录结构看仓库将许可证相关的配置文件集中放置根目录两份许可全文、两份 hawkeye 配置licenserc.toml/licenserc-enterprise.toml、licenses/目录下存放 README 说明与头文件模板职责划分清晰。二、企业特性如何被隔离enterpriseCargo feature 门控企业源码与核心源码的根本区分点在于 Rust 的#[cfg(feature enterprise)]条件编译属性。凡是被企业许可约束的文件只能通过企业门控的模块声明被引用默认构建不开启enterprisefeature时这些模块不会被编译。仓库中存在大量此类门控点例如src/common/function/src/admin.rs 与 src/common/function/src/function_registry.rs 中的#[cfg(feature enterprise)]src/catalog/src/system_schema/information_schema.rs 中的企业门控模块声明src/common/meta/src/ddl/drop_table.rs 与 src/common/meta/src/ddl/drop_table/executor.rs 中的企业特性分支。这些门控对应的实际源文件正是两份许可配置中列出的企业文件如src/common/meta/src/rpc/ddl/trigger.rs、src/operator/src/expr_helper/trigger.rs、src/mito2/src/extension.rs、src/common/function/src/admin/purge_table.rs、src/catalog/src/system_schema/information_schema/recycle_bin.rs等印证了门控声明位置与许可配置文件清单之间的一一对应关系。三、许可头如何被强制CI 中的 hawkeye 双重校验仅靠文档声明无法保证许可合规仓库通过 CI 自动化强制每一份源文件都携带正确许可头。依据 licenses/README.mdCI 中的license-header-check任务会运行 hawkeye 工具两次默认配置licenserc.toml对所有源码应用 Apache-2.0 头但排除企业文件清单企业配置licenserc-enterprise.toml仅对企业文件应用企业许可头。其中licenserc.toml的includes覆盖*.rs、*.py、*.ts三类源码文件并将若干拷贝自第三方的源码如src/common/base/src/readable_size.rs、src/servers/src/http/test_helpers.rs等放入excludes豁免。文件头的属性配置在[properties]段inceptionYear 2023头模板中年份的起始值copyrightOwnerlicenserc.toml中使用Greptime Teamlicenserc-enterprise.toml中使用GrepTime Inc.两套许可体系对应不同版权主体。企业配置则通过headerPath licenses/enterprise-header.txt指向企业头模板其includes精确列出全部企业门控文件与主配置的excludes中# enterprise:start/# enterprise:end标记块内容完全互补。四、两份清单必须保持同步互补关系与脚本校验licenserc.toml与licenserc-enterprise.toml的关系是互补且必须同步的licenserc.toml的excludes# enterprise标记块—— 将企业文件从 Apache 头检查中排除licenserc-enterprise.toml的includes—— 将同一批文件纳入企业头检查。两份清单一旦失同步就会出现两类 CI 失败企业文件被误打上 Apache-2.0 头或企业文件完全没有许可头。更关键的是hawkeye 本身无法发现某文件本应属于企业清单却漏列的问题——因为这样的文件没有被从默认检查中排除它会带着 Apache-2.0 头顺利通过默认检查。为了堵住这个漏洞仓库提供了专门的同步校验脚本 scripts/check-enterprise-license.py通过git ls-files枚举所有被版本控制的*.rs文件静态解析每个文件中的#[cfg(feature enterprise)] mod ...;声明支持#[cfg(all(test, feature enterprise))]等复合谓词且会递归下沉到被门控模块的子模块因为子模块同样属于企业门控范围将解析出的实际企业门控文件集合分别与licenserc-enterprise.toml的includes、licenserc.toml的# enterprise:start/# enterprise:end标记块对比报告四类问题漏于 includes、漏于 excludes、过期的 includes 条目、过期的 excludes 条目。该脚本在 Makefile 中以make check-enterprise-license暴露配套的单测位于 scripts/check-enterprise-license-test.py覆盖了门控只作用于下一条声明测试专用门控#[cfg(all(test, feature enterprise))]也计为企业any(...)等非门控组合被忽略等边界情形保证解析逻辑本身可信。五、新增一个企业源文件的完整操作步骤当需要为企业特性新增源码文件时按以下步骤操作来自 licenses/README.md 并结合仓库配置细化确认门控方式新文件必须通过#[cfg(feature enterprise)] mod ...;声明而非内联mod { ... }因为内联模块没有独立文件确保它不会进入默认开源构建。同时加入两份清单将该文件路径添加到licenserc-enterprise.toml的includes并同步添加到licenserc.toml的excludes# enterprise:start与# enterprise:end标记之间。两份清单必须保持一致否则make check-enterprise-license会报漏列或过期条目。应用企业许可头hawkeye format --config licenserc-enterprise.toml验证许可头hawkeye check --config licenserc-enterprise.toml两条铁律必须遵守不要在企业文件上放置 Apache-2.0 头不要让企业文件缺失许可头。两种情况都会导致 CI 失败前者会被主配置的排除逻辑与同步脚本双重拦截后者会被企业配置的 hawkeye 检查拦截。修正清单后可运行hawkeye format --config licenserc-enterprise.toml自动补齐企业头。六、常见问题与排查建议Q1为什么新增企业文件后make check-enterprise-license失败说明新文件没有被正确加入两份清单或清单中出现过期条目。运行python3 scripts/check-enterprise-license.py脚本会分类打印缺失的includes/excludes条目以及不再属于企业门控的过期条目。Q2为什么企业文件只加进了licenserc-enterprise.toml却仍然报错因为该文件未从licenserc.toml的excludes中排除会被默认的 hawkeye 检查Apache-2.0 头命中。两份清单是互补关系必须成对维护。Q3#[cfg(all(test, feature enterprise))]算企业门控吗算。从 scripts/check-enterprise-license-test.py 的测试用例可见只要谓词中要求feature enterprise即视为企业门控如recycle_bin_test.rs就因此被列为企业文件而any(test, feature enterprise)这类非门控组合则被忽略因为它在非企业构建下依然可编译。Q4内联的mod { ... }声明需要单独列入清单吗不需要。同步脚本只处理有独立文件的目标模块name.rs或name/mod.rs内联模块没有自己的文件也就不属于许可清单的管理对象。七、总结GreptimeDB 通过双许可文本 Cargo feature 门控 hawkeye 双重检查 同步校验脚本四层机制构建了可自动验证、难以被误改的许可治理体系。对贡献者而言核心要点只有三个企业代码必须用#[cfg(feature enterprise)]门控、必须同时出现在两份许可配置中、必须携带企业许可头。理解这套机制既是向仓库提交代码的前提也是判断哪些代码可自由使用、哪些受企业许可约束的权威依据。【免费下载链接】greptimedbThe open-source observability database. One columnar engine for metrics, logs, and traces, on object storage.项目地址: https://gitcode.com/GitHub_Trending/gr/greptimedb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
