Dockhand 调整开源许可模式：企业使用需购买商业授权

开源 Docker 管理工具 Dockhand 近期对其许可证模型做出了关键调整，引发社区关注。这次变更的核心在于转换时间线的改动，以及对商业使用场景的收紧。对于依赖该工具管理容器基础设施的开发者和企业而言，理解这些变化至关重要。

许可证模型发生了哪些变化

根据 Dockhand 在 GitHub 上提交的变更记录（commit 95a79d4），最核心的两行条款被修改：

变更前，Dockhand 采用的是固定日期的转换机制——所有版本都将在 2029 年 1 月 1 日统一转为 Apache License 2.0。而变更后，转换时间改为自某一版本首次公开发布之日起四年。

这意味着转换机制从「全局固定日期」变成了「按版本滚动计算」。换句话说，每个新发布的版本都会从其发布时点起，单独计算四年的封闭期，之后才会转为宽松的 Apache 2.0 许可。这种做法在采用 Business Source License（BSL）的项目中并不罕见，它能让厂商对最新版本保持更长时间的商业控制，而不是让所有代码在某个固定节点一次性全部开放。

Business Source License（BSL）由 MariaDB 于 2016 年首创，其核心设计理念是在「完全开源」与「完全私有」之间寻找平衡点：源代码对外公开、可供审阅和非商业使用，但在一段时间窗口内对特定商业用途设有限制，窗口期结束后自动转换为 Apache 2.0 等宽松许可证。BSL 被 HashiCorp（Terraform）、Sentry、CockroachDB 等知名基础设施项目相继采用，也因此引发持续争议——开源社区普遍认为 BSL 不符合 OSI（开源促进会）对「开源」的定义，实为「源代码可见」（source available）而非真正意义上的开源。理解 BSL 的基本框架，有助于评估 Dockhand 此次调整对不同用户群体的实际影响。

商业使用门槛被明确抬高

这次调整的另一个重点，是对商业使用边界的重新界定。新条款明确列出了哪些使用场景无需额外许可：

• 组织内部的业务使用：无论管理多少个 Docker 环境，内部使用都被明确允许；
• 托管服务提供商（MSP）：允许 MSP 代表客户管理 Docker 基础设施，前提是 MSP 本身不能把 Dockhand 作为服务对外提供。

而关键的变化在于——除上述情形外的任何生产环境使用，包括由公司、个体经营者、自雇人士、公共机构或其他任何组织进行或代其进行的生产使用，都需要向 Licensor 购买商业许可证（Commercial License）。

这一表述比此前的条款更加严格。过去 BSL 主要限制的是「将 Dockhand 作为商业 SaaS/托管服务对外提供」，而现在的措辞把商业生产使用的范围进一步明确和扩大，企业用户想要在生产环境中合规使用，基本绕不开商业授权。

文档与代码之间的不一致

一个值得留意的细节是，尽管许可证条款已经更新，Dockhand 的 README.md 文件却仍然保留着旧版本的描述。Reddit 讨论指出，README 中依旧写着：

Dockhand 采用 Business Source License 1.1（BSL 1.1）授权。

• 免费适用于：个人使用、内部业务使用、非营利组织、教育、评估
• 不允许：将 Dockhand 作为商业 SaaS/托管服务提供
• 转换为 Apache 2.0：2029 年 1 月 1 日

这段描述与已经生效的 LICENSE 文件内容存在明显出入，尤其是转换日期仍停留在旧的「2029 年 1 月 1 日」。社区普遍认为这很可能是维护者在更新时遗漏了文档同步。发帖者还补充道，官方网站上也存在同样的未更新问题。

这种代码与文档不一致的情况，对用户来说是个潜在陷阱。法律效力通常以实际的 LICENSE 文件为准，而非 README 中的说明文字。如果用户仅凭 README 判断自己的使用是否合规，可能会得出错误结论。

在软件许可证的法律实践中，项目仓库根目录下的 LICENSE 文件通常被视为具有约束力的授权文本，README、官网或其他文档中的许可说明属于非正式描述，不构成法律条款。当两者存在冲突时，以 LICENSE 文件的实际内容为准。对于企业用户而言，合规审查应直接针对 LICENSE 文件原文，并在必要时咨询法律顾问，而不能依赖任何二手摘要或简化说明。这一原则同样适用于所有采用 BSL、SSPL 或类似定制许可证的开源项目。

对用户意味着什么

对于个人开发者和内部使用的团队，这次变更的直接影响有限——内部业务使用依然免费，且不受管理环境数量的限制。真正受影响的是那些希望在商业生产环境中部署 Dockhand 的企业，它们现在需要评估是否需要采购商业许可。

从更宏观的角度看，这是开源与商业化之间张力的又一个典型案例。BSL 这类「源代码可见但有商业限制」的许可证，近年来被越来越多的基础设施类项目采用——它既保留了代码透明度和社区贡献的可能，又为厂商提供了可持续的商业变现路径。Dockhand 从固定转换日期改为按版本滚动的四年期，本质上是在延长商业窗口期，这反映出项目方对长期商业化的考量。

对于正在考虑采用 Dockhand 的团队，建议直接以 GitHub 仓库中最新的 LICENSE 文件为准，而不要依赖 README 或官网上可能尚未更新的说明。在商业场景落地前，明确自己的使用是否落入「需要商业许可」的范畴，是避免合规风险的必要一步。