开源 v1.0.0 决策收敛（#166：#167–175、#177）

[zuohaisu]

最新已确认决策（Haisu 本轮确认；优先于下方初始讨论）

单仓、全开源与许可：#166 / #167 / #168 / #173

• cloud 源码不需要保密。自有归档核心与 cloud 运营代码一起采用 AGPL-3.0，在当前同一个仓库维护，安全审查通过后按当前仓库直接公开的方向执行。
• APP_EDITION 区分 selfhost/cloud 的运行功能，不再代表专有许可或源码保密边界；不为 cloud 添加限制使用的专有许可证，也不将其从公开源码中排除。
• 生产凭据、客户数据、真实运营配置仍不得公开；第三方资产（例如腾讯 SDK）仍受其自身许可约束。
• 以上是产品/许可方向的批准，不是立即修改仓库可见性的操作授权，也不是历史和平台内容已通过安全审查。
• 待决策收敛后同步修改旧票正文：原“cloud 专有层”“公仓全新历史/双仓快照”“排除 cloud 包”等要求已被本轮决定取代。不得按旧边界开始实现。

商标与来源署名：#167

• 商标为“康冠时代”，公司主体为“深圳康冠时代科技有限公司”。第三方部署不得冒充官方产品、官方托管或官方背书。
• 官方自部署包默认显示类似 Powered by 康冠时代 的来源署名。
• Haisu 选择声明性要求：在 NOTICE/商标政策中声明应保留合理来源署名；不使用技术手段阻止修改/删除，不做远程检测、许可锁或停用机制，也不承诺逐案执法。
• 文案应区分保留合理版权/许可/来源声明与把商标作为第三方自身品牌使用；须与 AGPL §7 允许的合理声明一致，不要求 fork 继续使用官方产品品牌。具体合规文案由 [OSS] License：替换占位 LICENSE 为 AGPL-3.0 + NOTICE + 商标政策 #167 落实，不扩展为任意额外许可限制。

贡献机制：#172

• 确定采用 DCO，不要求 CLA。DCO 1.1 与 Signed-off-by 的说明和贡献流程由 [OSS] 社区文件：CONTRIBUTING / CODE_OF_CONDUCT / CLA-or-DCO + issue/PR 模板 #172 落实。
• Haisu 表示若未来开源/闭源版本分化，再考虑修改贡献机制。
• 重要边界：未来可对新贡献调整协议；但既有 DCO 下第三方贡献不因此自动获得闭源/重授权许可，需另取得相应权利或替换相关代码。已发布 AGPL 版本的授权也不能通过更换未来贡献协议撤回。

#168 ops 报告与合并前关口

• Haisu 提供了 tasks/GH-168-ops-investigation.md 的摘要：无 SSH、无生产写入、无凭据输出；复用 Docs: record SSH host alias & clone ownership conventions (GH-155 closeout) #177 的事实并检查本地 53ec37f。当前应用尚无 APP_EDITION 消费代码，路由无条件注册；报告认为 env 文件是 web/worker 的配置注入点，不需修改 systemd 单元。
• 本会话在当前仓库及已注册的两个 worktree 未找到该报告文件，未读取完整报告；摘要作为 Haisu 转述的调查材料记录，而非本会话重新核验的在线生产状态。零 SSH 调查不能证明当前在线 env 中某变量的实际值。
• 按“一票一 commit、统一一个大版本 PR”的安排，前置时序应表述为：实现分支先明确消费机制与 worker 行为 → ops 复核并取得两处 env 变更的分项授权 → 在最终大版本 PR 合并前预置 APP_EDITION=cloud → 人工合并后由既有 CD 生效 → 核验 cloud 功能和 worker。
• 不在此授权修改生产/非生产 env、重启或部署。当前应保持暂不动作，等待实现分支和 ops 的实际复核。
• 必须纠正摘要中的回滚措辞：如果新代码默认 selfhost，删除 APP_EDITION=cloud 后重启会切到 selfhost，不能恢复生产 cloud。配置修复应保留/恢复 cloud；若要撤销新版本，应按获批的部署回滚流程恢复旧代码，再评估是否移除新增变量。

交付安排维持不变

#167–175 与 #177 各一个 scoped commit，统一一个 PR，作为 v1.0.0 发布候选。#176 排除。每票独立实现会话，不 squash 跨票提交；发布、仓库可见性、Wiki/Gitee 公开操作与合并仍需各自关口，不在开发阶段伪报已完成。

已确认：selfhost 的运行政策（#168 / #171）

Haisu 已明确同意：

• selfhost 不需要购买或试用，不因订阅到期停用。
• 不套用 cloud 商业套餐容量；由管理员配置存储限额，默认不设商业额度。
• 保留磁盘安全、权限、租户隔离、密钥、审计及必要安全状态的 fail-closed 保护；不通过伪造长期商业订阅、自动解除暂停等方式实现自部署可用。
• cloud 保持现有商业规则。实现须按 edition 明确分离相关商业策略，覆盖媒体写入、存储、激活和后台作业等实际调用链。

许可证再次确认：保留 AGPL-3.0，不改 MIT（#167）

Haisu 在讨论单仓是否更适合 MIT 后，明确表示「不接受别人把修改版闭源」。结合当前讨论的对外分发/商业云服务场景，确定维持 AGPL-3.0；单仓结构不是选择 MIT 的理由。

MIT 允许下游将修改版闭源，不符合这一诉求。AGPL 对受其约束作品的分发规定源码义务，并在 §13 要求修改版向远程网络交互用户提供对应源码的获取机会；这不等于要求所有私下修改都发布到公共 GitHub，也不要求公开客户数据、密钥或全部独立业务系统。

商业使用和竞争托管本身仍然允许；本决定要求遵守源码义务，不借许可证禁止合法竞争。声明、商标和安全审查边界维持此前决定。DCO 选择不变。此处不增设“任何私下修改都必须公开”等超出标准 AGPL 的额外限制。

---

初始讨论记录（保留决策过程；冲突处以上方最新确认内容为准）

用途与状态

Haisu 要求逐项收敛开源决策，尽量消除串行开发断点。本帖区分「Haisu 已确认」「方向意向」「建议/待确认」，未确认内容不得作为实施授权。尚未修改 Epic/子票正文，也未开始实现。

Haisu 已确认

交付范围与形式

• [OSS] Epic · wecom-archive 开源发布（AGPL-3.0 · Plane 模式 open-core） #166 为 Epic；实现范围包含 [OSS] License：替换占位 LICENSE 为 AGPL-3.0 + NOTICE + 商标政策 #167–175，以及 Docs: record SSH host alias & clone ownership conventions (GH-155 closeout) #177；ci: grant pull-requests:read to classify-push — association API was 403 all along (GH-164) #176 是已合并的 CI PR，不属于此次范围。
• 每个实现 issue 对应一个独立 scoped commit，统一在一个 PR 交付，作为 v1.0.0 大版本发布候选。
• 不把所有票 squash 为一个提交。开发会话仍按 AGENTS.md 分票；本次未授权跨票单会话例外。
• 上述交付安排不等于授权 agent 合并、打 tag、发布 Release、部署或改变仓库可见性。

#167 商标与署名

• 产品使用商标：「康冠时代」。公司主体：「深圳康冠时代科技有限公司」。
• 不向自部署者授予将该商标作为其自身产品/服务品牌使用的权利。
• 官方提供的自部署包默认在底部带类似 Powered by 康冠时代 的来源署名。
• 尚待明确：署名是否允许替换/移除、是否要求 UI 中持续保留何种最小署名，以及商标政策的具体范围。不得把默认署名等同于官方托管、认证或背书。

#169 域名与品牌

• Haisu 认为 crowntime.cn 本身不需要隐瞒，允许开源系统保留公司的痕迹。
• 不应仅因出现该域名就判定泄漏。具体默认值、子域和 URL 的适用性可技术评估。
• 这不放宽凭据、真实用户数据、生产内容和其他敏感信息的保护要求。
• 原票提出的域名一刀切拦截规则需要据此收敛；尚未修改票面或现有门禁/测试。

#174 Gitee

• Haisu 提供的账号：https://gitee.com/zuohaisu。
• 是否可通过 API/CLI 完成工作、需要何种最小权限和认证方式，尚未验证。未授权在未知目标上公开写入或执行同步。

#177 文档补记

• 纳入本次统一 PR，但仍严格限于票面指定的运维文档补记。
• 票面已有服务器事实与核查结论，明确无需复测；不得借此重做运维操作或修改 SSH/部署配置。

Haisu 的方向意向（尚待最终模型决定）

#173 倾向单仓直接开源

Haisu 不希望长期管理「私仓开发 + 公仓快照」两个仓库；倾向在没有泄露风险的前提下，将当前私仓直接公开。

这是对 #166 原双仓发布方案的重新讨论，不是立即改变可见性的执行指令，也不是历史/平台内容已经安全的证明。最终决定后需同步修订 #166、#168、#173 等受影响票。

建议与待确认

首先确认：cloud 源码是否随当前仓库公开？

公开仓库中的目录不能保持私有；目录级专有 LICENSE 可以限制授权，但不能隐藏源码。「两套许可证」不等于「两套可见性」。

为满足管理简单的偏好，建议：自有归档核心和 cloud 运营代码都在同一公开仓库采用 AGPL-3.0；APP_EDITION 仅区分部署功能，而不作为源码保密边界。生产凭据、客户数据、真实运营配置始终不进入公开内容；腾讯 SDK 等第三方资产按其自身条款另行处理。

该建议意味着其他人可在遵守许可证的情况下 fork、自部署和提供竞争托管服务，商标政策只能防止混淆和冒充，不能借商标禁止合法商业使用。

如果 cloud 源码必须保密，需要另一个私有代码载体；如果选择公开可见但专有授权，属于混合许可/源码可见模式，须明确 AGPL 组合和贡献者授权边界，不能仅加一个 LICENSE 就宣称兼容。以上均未获最终确认。

#167 署名建议

建议区分：商标/产品品牌使用，与真实来源署名。
默认保留 Powered by 康冠时代；允许 fork 使用自己的产品名称/Logo，但不得假装官方版本或获得官方背书。版权、许可和依法/依许可证需要保留的合理法律声明不应删除。UI 署名是否强制保留，等待 Haisu 决定；不添加未经确认的额外许可限制。

#168 ops 只读调查

建议先确认生产/非生产的 web 与定时 worker 实际配置来源、APP_EDITION 是否已设置，以及各进程继承方式；给出 cloud 模式启用顺序、验证、回滚和负责人。仅调查，不修改、不重启、不部署、不读业务数据库。#177 已验证事实可复用，无需重做 SSH 核查。

#172 CLA / DCO

• DCO：贡献者证明自己有权提交代码，通常用 Signed-off-by；不额外授予项目方任意重授权权利，也不转让版权。
• CLA：贡献者签署授权协议；是否支持额外授权/双许可取决于具体条款，通常也不等于转让版权。
• 若选择长期 AGPL + 托管服务，倾向推荐 DCO；若希望把未来社区贡献用于闭源/双许可发行，需考虑具有明确相关授权的 CLA。
• 尚未选择。

#170 / #171 / #175 的澄清

• [OSS] 命名链收口：#155 改名后的 SANITIZERS/README 品牌定调（康冠时代 × wecom-archive） #170：品牌/项目名已定、Rename repo: wecom-archive-365 → wecom-archive（生产零中断 runbook） #155 已完成；主要是技术收口，没有必须新增的品牌决策。
• [OSS] docker-compose 自部署：PG16 + web + worker 一键起 + quickstart #171：调度实现可由技术论证；selfhost 必须不依赖云版购买和试用到期。真实首条归档验收仍需非生产企业、SDK 和对应权限，不能用 mock 替代。
• [OSS] Wiki 一次性文档迁移与导航整理 #175：沿用原有仓内 docs 与 Wiki 双轨、不默认删除 docs 的方向；导出代码可准备，实际 Wiki 写入依赖发布与授权。

公开前不可省略的检查

若最终选择当前私仓直接公开，检查不能限于 HEAD 或 gitleaks：应覆盖将公开的历史、分支、tag、LFS/二进制、已删除敏感文件，以及 issues/PR/discussions/评论/附件等平台内容；Actions 日志、artifacts 等可见范围需按平台行为核查。凭据发现后须轮换，清洗 HEAD 或添加 .gitignore 不能清除历史。不得未经批准改写历史。

当前公开导出依赖存在静态确认的缺口，修复归属仍待确定；不能把基线视作已验证绿色。

本轮需要 Haisu 回答的第一个问题

是否接受 cloud 运营源码与核心一起公开，并采用 AGPL-3.0，从而以同一公开仓库维护？还是 cloud 源码必须继续保密？

参考

• AGPL-3.0 标准文本，特别是 §5、§7、§13：https://www.gnu.org/licenses/agpl-3.0.html
• DCO 1.1：https://developercertificate.org/

以上许可证边界为工程决策建议，不构成专业法律意见。