OpenWork 贡献指南全解析DCO 签名、open core 双许可证与 ee/ 目录 CLA 流程【免费下载链接】openworkThe open-source alternative to Claude Cowork (powered by opencode)项目地址: https://gitcode.com/GitHub_Trending/ope/openwork本文基于 CONTRIBUTING.md 整理系统讲解向 OpenWork一个基于 opencode 构建的开源 AI Agent 桌面工作台提交代码前必须了解的两件合规大事Developer Certificate of OriginDCO签名要求以及 MIT OpenWork EE License 双许可证结构下按贡献目录区分的授权流程。读完本文你将掌握正确的git commit -s用法、个人与公司两种 Contributor License AgreementCLA的适用场景以及仓库对 pnpm、最小 diff、测试证据等提交规范能够安全、合规地发起你的第一个 Pull Request。一、为什么贡献 OpenWork 前必须先读这份指南OpenWork 是一个开源桌面应用macOS / Windows / Linux用于在你自己的文件上协同 AI Agent 完成工作是 Claude Cowork 与 Codex 的开源替代品构建于 OpenCode 之上可运行 50 提供商的任意模型。仓库采用 monorepo 结构包含桌面应用apps/、packages/、OpenWork MCP 网关ee/apps/den-api与 OpenWork Den 组织控制平面ee/apps/den-*三大面详见 AGENTS.md。由于仓库同时包含 MIT 许可的开源部分与按订阅销售的 Enterprise EditionEE部分贡献进来之后代码归谁、按什么许可分发这个问题必须用明确的流程约束。CONTRIBUTING.md 开宗明义有两件事维持着这个项目的许可清洁licensing clean在打开 Pull Request 之前请务必读完——即 DCO 签名与贡献授权条款。这意味着即使你的代码写得再漂亮若缺少合规签名或适用的 CLA维护者也不会合并。二、Developer Certificate of OriginDCO每个提交都必须签名2.1 签名命令所有提交commit都必须经过签名以证明贡献者知晓并同意 Developer Certificate of Origin v1.1 的内容。做法是在提交时追加-s参数git commit -s -m your message该命令会在提交信息中自动追加一行 trailerSigned-off-by: Your Name youremail这行签名相当于一份声明认证两点你编写了该变更或者你有权提交它并且你同意在本仓库的许可证下提交它。未签名的提交无法被合并Pull requests with unsigned commits cannot be merged这是硬性门槛不是建议。2.2 实操补充补签与批量处理如果你是 Git 新手或此前遗漏了签名可以参考以下通用 Git 能力补足不改变 DCO 本身的要求对最近一次提交补签git commit --amend -s --no-edit对尚未推送的多个历史提交补签可用交互式变基并逐条git commit -s --amend或使用git rebase --exec git commit --amend -s --no-edit base批量处理养成习惯的方式在仓库级或全局配置中设置commit.gpgsign之外可以在.git/hooks/commit-msg中挂校验脚本或在 CI 中校验每个提交是否含Signed-off-bytrailer。DCO 的核心价值在于它把我有权提交这份代码的法律声明分散到每个提交上保证任何一次变基、cherry-pick 之后代码来源依然可追溯、可审计这与本仓库 SECURITY.md 对供应链与来源一致性的要求一脉相承。三、open core 双许可证结构按目录决定贡献的授权方式3.1 两种贡献两种授权路径本仓库是 open core开放核心模式贡献的手续取决于你改动的目录——CONTRIBUTING.md 明确说明这与 GitLab 对其ee/目录采用的结构相同贡献位置接受的许可证所需额外手续ee/之外的代码MIT licenseinbound outbound入向即出向仅需 DCO 签名认证ee/之下的代码需在 EE 许可证下分发必须签署 Contributor License AgreementCLA所谓 inbound outbound是指进来时按什么许可证授权出去时就按什么许可证分发你贡献给 MIT 部分的代码也以 MIT 许可对外分发无需额外协议。而 EE 部分则不同——EE 许可的软件按订阅销售且每个版本在发布两年后会自动转换为 MIT详见下文因此需要一份足够宽泛的授权同时覆盖订阅分发与后续的 MIT 转换两种场景。3.2 仓库层面的许可证据双许可证结构在仓库中层层落实形成完整证据链根目录 LICENSE 开篇即声明/ee目录下的所有内容按 ee/LICENSE 中定义的 OpenWork Enterprise Edition (EE) License 许可/ee之外的内容按 MIT 许可第三方组件保留其原始许可。机器可读层面仓库遵循 REUSE 规范REUSE.toml 中显式声明了两条注解规则path **对应SPDX-License-Identifier MIT而path ee/**对应SPDX-License-Identifier LicenseRef-OpenWork-EE许可证全文存于 LICENSES/LicenseRef-OpenWork-EE.txt。也就是说自动化工具如 license 扫描器可以直接依据 SPDX 标识区分两个许可域。从 pnpm-workspace.yaml 的packages配置可以看到ee/apps/*与ee/packages/*与其他apps/*、packages/*同属一个 pnpm 工作区说明 EE 代码并非孤岛而是与 MIT 部分一起构建、测试的 monorepo 成员——这也解释了为何 CLA 必须覆盖EE 许可分发与未来 MIT 化两种状态。3.3 EE License 的实质内容为什么 CLA 要覆盖转换阅读 ee/LICENSE 可知 EE License 的核心约束生产使用需订阅软件仅在你及你代表的实体持有与用户数匹配的有效 OpenWork 订阅时方可生产使用无需订阅的例外不超过 5 个总用户的小组织不含 Enterprise Features的生产使用首次部署起 30 天内的内部评估不限用户数以及开发与测试用途未来许可授予Grant of Future License每个版本的软件在其首次公开发布满两周年之日起自动获得一份不可撤销的 MIT 许可——这正是 CONTRIBUTING.md 所说每个版本之后都会转换为 MIT的法律出处不得移除或篡改版权与许可声明不得使用 Different AI 的商标。因此EE 贡献者的代码会在受控的订阅分发与两年后 MIT 化之间切换身份单一来源的 DCO 签名不足以覆盖这两种分发方式必须依赖 CLA 中更宽泛的授权条款。这就是整个授权设计的根本原因。四、ee/ 目录的 CLA个人版与公司版向ee/贡献代码除 DCO 外还须签署 CLA。仓库提供了两份协议按贡献者身份二选一个人贡献者签署 Individual Contributor License Agreement代表公司签署 Corporate Contributor License Agreement。两份协议均声明贡献者保留对其贡献的所有权reserve all right, title, and interest授予 Different AI, Inc. 的是永久、全球、非独占、免费、不可撤销的许可包括再许可sublicensing权利覆盖订阅分发与 EE License 约定的 MIT 转换。维护者在对应 CLA 到位之前不会合并任何ee/贡献。4.1 个人 CLA 要点个人版legal/individual-contributor-license-agreement.md由以下部分组成定义明确 You 指版权所有者或经其授权的法律实体含控制关系下的关联实体Contribution 指有意提交给 Different AI, Inc. 的任何原创作品包括对既有作品的修改与增补覆盖邮件列表、源码管理系统、问题跟踪系统等渠道的交流版权许可授予授予永久、全球、非独占、免费、不可撤销的版权许可涵盖复制、派生、公开展示/表演、再许可与分发明确包含按 EE License 的 MIT 转换计划分发的权利专利许可授予授予对必然侵犯的专利权利要求的许可同时设有终止条款——若任何实体就你的贡献提起专利侵权诉讼则其在本协议下的专利许可自诉讼提起之日起终止防御性终止贡献者保证声明每份贡献为原创若提交非原创作品须单独提交并完整说明来源与第三方许可/限制并显著标注Submitted on behalf of a third-party: (名称)免责声明贡献按 AS IS 提供不附带任何明示或默示的担保包括所有权、不侵权、适销性与特定用途适用性。4.2 公司 CLA 要点公司版legal/corporate-contributor-license-agreement.md在个人版基础上增加企业治理维度授权员工机制公司可指定若干员工代表公司提交贡献并须在指定员工名单或联系人变更时及时通知 Different AI, Inc.版权与专利许可条款与个人版结构一致同样覆盖 EE License 的 MIT 转换分发公司须保证其有权授予上述许可且每个被指定的员工均获得代表公司提交贡献的授权。4.3 付费工作与雇主关系CONTRIBUTING.md 特别提醒如果你是以带薪工作、工作试用work trial或代表雇主的身份贡献务必在第一个 Pull Request 之前确保与 Different AI, Inc. 之间已签署覆盖知识产权转让的协议不确定时向你的 OpenWork 联系人确认。没有此类协议时维护者不会合并来自付费合作关系的实质性贡献。这与个人 CLA 第 3 条中若雇主对你创造的 IP 享有权利须取得雇主许可、豁免或已由公司签署公司 CLA的表述相互印证。五、贡献实践规范除了合规还有工程约束CONTRIBUTING.md 的 Practical notes 部分给出四条工程实践底线与仓库实际工程体系相互印证使用 pnpm绝不用 npm 或 yarn仓库根目录 package.json 与 pnpm-workspace.yaml 共同构成 pnpm monorepo覆盖apps/*、packages/*、ee/apps/*、ee/packages/*并配置了 catalog、overrides、patchedDependencies 等统一依赖治理AGENTS.md 同样强调 pnpm only, never npm/yarn。混用包管理器会破坏锁文件一致性。保持 diff 尽可能小倾向更简单的方案小 diff 便于评审者聚焦、降低合入风险也减少后续代码审查与回滚成本。运行时可见的变更需要在 PR 上提供测试证据详见 AGENTS.md仓库在evals/specs/下维护了大量 e2e 测试如app-smoke.e2e.test.ts、session-archive-undo.e2e.test.ts、desktop-policy-restricted-mode.e2e.test.ts等 200 余个任何影响运行时行为的改动都应附带相应测试或运行证据而非仅凭主观描述。绝不提交密钥、凭据或个人数据这一点与 AGENTS.md 的保密硬规则一致——本仓库是公开仓库分支名、提交、PR 文案、fixture 或证据均不得暴露客户、潜在客户、合作伙伴或外部人员身份。六、动手前的一分钟自检清单结合全文提交前请确认每个提交都带Signed-off-bytrailergit commit -s未签名提交不会被合并改动涉及ee/目录时已签署适用的个人或公司 CLA否则 PR 不会被合并带薪/代表雇主贡献时已提前与 Different AI, Inc. 落实 IP 协议使用 pnpm 而非 npm/yarn 安装与提交diff 精简运行时可见变更附测试证据无密钥、凭据、个人数据或客户标识进入公开仓库。完成以上检查后即可基于 HANDOFF.md 与 CONTRIBUTING.md 的指引提交你的首个 Pull Request。合规先行代码随后这是 OpenWork 维护团队对每一位贡献者的基本要求也是保证该项目能持续以 open core 模式健康演进的前提。【免费下载链接】openworkThe open-source alternative to Claude Cowork (powered by opencode)项目地址: https://gitcode.com/GitHub_Trending/ope/openwork创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考