开源项目许可证与贡献政策决策：从依赖约束到…

当需要为一个开源项目选择许可证、决定是否要求 CLA/DCO、或将现有项目改换许可证时，用一套可辩护的决策流程产出许可证决策记录与配套文件。

适用场景

解决思路

1. 先声明三条总规则：拒绝提供法律意见（只解释各法律工具的作用、义务与历史后果，绝不断言法院会怎么判，绝不解读具体雇佣合同，遇到专利组合、收购、有争议的贡献、任何进行中的纠纷时明确建议找律师）；把许可证当作分发决策而非意识形态决策来论证（它决定谁能无需许可就采用、能通过哪些公司的法务审查、以及未来还保留哪些商业模式）；每条论断都要有出处，否则标注为本技能自己的默认值，绝不把自己的默认值说成行业标准。
2. 按顺序一次问一个问题（尽量用多选题），直到能确定产物形态、依赖情况和目标为止，其余边走边确认。要问的 13 项：1) 项目是什么、是否已有许可证（新项目／未授权的公开仓库／变更现有许可证是三种不同的活）；2) 交付给用户的是什么（库、应用或 CLI、托管服务、宿主产品的插件、规范或 schema，还是一个仓库里多种并存）；3) 代码是谁在什么情况下写的（个人时间、雇主时间、混合、外包、已有团队）；4) 依赖有哪些、是否有 copyleft（不知道就先查）；5) 希望谁来采用（个人开发者自行决定、需要公司审批的工程师、还是两者）；6) 项目的目的（不惜代价获取采用、成为品类默认、防止改进被闭源、喂养商业产品、招聘信号、制定标准）；7) 现在或将来是否有商业模式，若有是哪种、最怕的竞争对手是谁；8) 是否有预先固定的约束（雇主开源政策、资助方、计划加入的基金会、客户采购规则、生态事实要求的许可证）；9) 已有多少人贡献过仍在仓库中的代码、能否联系到他们；10) 两年后谁维护、能否在你不知情下改许可证（继任问题属于 oss-governance，这里只问，因为它决定预授权改许可证的 CLA 是否值得那份摩擦）；11) 是否有必须敲定的截止日期（发版、发布、客户审查、基金会期限）；12) 这是一次性决定还是未来所有仓库继承的政策；13) 实际能施加多大摩擦（完全没有、commit trailer、签名墙、律师起草的协议），以及能接受多少不可逆性。
3. 在给出任何具体许可证名称之前先问第 7、11、12、13 题，并说明哪个回答改变了哪个选项的排序：已确认的商业模式或可预见的改许可证会把商业可选性和 CLA 档位从最后提到最前；硬性截止日期会把无需律师的方案提前；要被未来所有仓库继承的政策会把无需逐个追贡献者就能规模化的档位提前；'不要签名墙'的努力上限会直接删除 CLA 和版权转让档位，而不是把它们搁置。
4. 如果运行环境有持久记忆，存储产物形态、依赖约束、采用者类型、商业模式和最终决定，供后续发版、贡献政策问题和兄弟技能复用。
5. 第 1 步——先找约束再谈偏好：1) 枚举所有入站许可证，包括随产物分发的全部依赖（含传递依赖）、vendored 或复制粘贴的代码、来源不明的 AI 生成代码；区分仅构建／仅测试依赖与真正分发的部分（义务附着于被分发的部分）；如果能读仓库，直接从 manifest 和 lockfile 里查而不是问用户。2) 检查每一种组合的方向性，兼容性是单向的，特别留意 Apache-2.0 与 GPLv2 这类真实项目常踩的规则。3) 把归属问题摆到台面上：在雇主时间内写的代码通常归雇主所有，即使对方只是'顺便'开源一个副业项目也要明说，并让他们去找自己的法务，而不是替他们解读合同。4) 记录固定的外部规则：基金会要求、采购白名单、生态惯例。把约束报告成一份'被排除选项 + 各自原因'的清单——这是整场会话中最有用的产出，因为这部分日后没人能争。
6. 第 2 步——头脑风暴姿态，不要直接跳到许可证：明确声明现在处于头脑风暴模式、尚未给出推荐。给出两到三个候选姿态，绝不给一个（只给一个选项是宣布决定而非提供选择）。每个姿态描述为一个捆绑包：许可证家族 + 贡献政策 + 两年内它使什么成为可能或不可能。默认排序（少量贡献者、无确认买家，`>` 表示该维度上更强）：效率为 `最大采用 > 互惠 > 商业可选性`；若访谈中未提商业模式，价值排序同上；一旦存在商业模式或可预见的改许可证，价值排序完全反转：`商业可选性 > 互惠 > 最大采用`；努力与合规成本排序均为 `商业可选性 > 互惠 > 最大采用`。三个姿态：1) 最大采用——宽松许可证、inbound=outbound、变现推迟到托管或支持；努力近乎为零（一个文件、无贡献者步骤、无律师），但单向不可逆（没有协议在案，日后收紧需要每一位版权人同意）；买到最广的采用者集合和最少的法务审查。2) 互惠——强 copyleft 或网络 copyleft、DCO、只有在现在就加 CLA 时才保留商业许可空间；对你近乎零成本，对每个采用者是一次真实审查；目标客户若禁用网络 copyleft，那是被删除的市场而非变慢的市场；买到改进回流、闭源 fork 不再免费。3) 商业可选性——copyleft 或 source-available 内核、CLA、明确划出的专有边界；成本最大（律师起草协议、每个贡献者的签名墙、长期处理公司签名的活）；是唯一能在不做同意征集的情况下保留双许可和日后改许可证的姿态。第 1、2 行在自身努力上打平，区别在成本落在谁身上：第 1 行不向采用者施加任何东西，第 2 行把审查转移给他们。最便宜不等于最可逆——每个姿态都有粘性，已发布的版本永远保留其条款，改许可证需要一致同意；第 3 行贵正是因为它买回了另外两行花掉的不可逆性。排序会饿死第 3 行，但当访谈中出现真实竞争对手、双许可计划、基金会捐赠、或雇主会要求公司 CLA 的企业贡献者时，仍要把它提上来。把排序当默认而非法律，按已知情况重排：已经在跑 CLA bot 的项目已付过第 3 行的启动成本；同行都只发一种许可证的生态里，偏离本身就会损失采用；有内部法务的团队对第 3 行的定价与单打独斗的维护者不同。然后给出推荐和理由，并让用户在命名任何具体许可证之前先选定姿态——先选许可证再补姿态，实际上就是凭感觉选许可证再事后辩护。
7. 第 3 步——在选定姿态内挑许可证：把家族匹配到产物的触发事件，再在家族内挑一个知名许可证。绝不自己起草、修改或发明许可证——OSI 和 Fogel 都指出：定制许可证会迫使每个评估方的法务团队做一次未列入预算的审查，许可证泛滥的成本由采用者而非作者承担。不要在姿态内按效率给许可证排序：选择是被决定的而非权衡出来的，由产物的触发事件和第 1 步的约束清单决定，硬套比率是伪装成严谨的虚假精确。约束放开时的快速默认：采用最重要的小程序或库 → MIT，一旦涉及专利、企业贡献者或基金会就转向 Apache-2.0（这个 MIT/Apache-2.0 分界是本技能自己的默认，FSF 对小程序的推荐是 Apache-2.0，本技能因 MIT 更短更广为人知而放宽）；面对根深蒂固的非 copyleft 竞争对手的库 → LGPL（FSF 推荐）或 MPL-2.0（本技能的按文件替代方案）；希望改进回流的分布式应用 → GPL-3.0（FSF）；担心 SaaS 漏洞的托管／服务器软件 → AGPL-3.0（FSF）。AGPL 的代价有可查的例子：Google 的公开政策写明 'code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google'，连在公司笔记本上安装 AGPL 程序都不行；不存在有多少企业同样禁用的汇总数字——只点名政策，绝不说百分比——并询问项目需要的客户是否正处在某条禁令之后。
8. 第 4 步——决定向贡献者要求什么：Karl Fogel 在《Producing Open Source Software》中的阶梯有四档：除 inbound=outbound 外什么都不要求、DCO 签署、CLA（个人加公司）、版权转让。他的判断：DCO 'probably the minimum amount of CLA a free software project should adopt'；当项目确实需要那些权利时，CLA 'probably offer the best tradeoff between safety and convenience'；他不推荐新项目使用版权转让。按每单位摩擦买到什么来排序，而不是按负担递增：效率为 `DCO > 什么都不要求 > CLA > 转让`；价值为 `转让 > CLA > DCO > 什么都不要求`；努力（贡献者摩擦加自身管理）为 `转让 > CLA > DCO > 什么都不要求`；合规成本为 `转让 > CLA > DCO == 什么都不要求`。从 DCO 起步：一个 commit trailer 加自动检查，贡献者只多一个 flag、你零成本，却买到通常归功于 CLA 的来源与审计轨迹；它在效率上领先，尽管'什么都不要求'更便宜，因为后者除了许可证已授予的之外什么也没买到；DCO 与'什么都不要求'在合规成本上真正打平（都不产生需要起草、保存或应要求出示的协议），其他配对在该维度上都能分开。只在需要许可证未授予的权利时才往上走：日后改许可证、双许可、销售贡献代码的商业许可才是真正的理由；对专利，先检查许可证是否已含专利授权（Apache-2.0、GPL-3.0、MPL-2.0 有，MIT 和 BSD 没有）再决定是否为此加协议。新项目直接从菜单里删掉版权转让并说明原因（Fogel 本人的建议），只有当项目要加入的基金会要求时才恢复。效率排序会饿死 CLA：它是唯一保留改许可证可选性的档位，却施加了读者现实中会采纳的最大摩擦，所以每次都在比率上输掉；但当第 2 步选了商业可选性、可预见基金会捐赠或双许可计划、或企业贡献者的雇主会要求 CLA 时，仍要把它提上来。同时把后果说清楚：没有商业计划的 CLA 读起来像公司在保留改条款的权利，并会在签名墙处损失顺手贡献。排序是默认而非法律，按项目情况重排：已有 CLA bot 和法务团队会让 CLA 远比假设中便宜，而贡献者都是顺手修 bug 的项目则要为每一次改动付这份摩擦。
9. 第 5 步——接上商业模式，或明说没有：只有当真实商业模式需要时才动用许可杠杆；每种限制都有贡献者成本，所以'不需要杠杆'是要报告的结论而非失败。变现轴是上市动作而非买家类型：1) 销售驱动的 B2B——双许可、开放内核和 source-available 条款适用于会走法务和采购审查的组织，按每单位信任花费换来的收入排序：效率为 `双许可 > 开放内核 > source-available 改许可`；双许可向需要不同条款的买家收费而保持开源产物完整；开放内核移动一条贡献者随后会争论的边界；改许可为 source-available 为同样收入花掉最多信任，是三者中最不可逆的，有记录的每一次都产生了 fork。要点名具体防御的竞争对手——通常是转售为托管服务的大厂；若不存在这种竞争对手，限制什么也买不到还损失采用。2) 产品驱动（PLG）B2B——路径是个人开发者采用 → 公司签约而不走采购；许可证必须支持这个交接：宽松或弱 copyleft 让开发者自由采用，公司日后为支持、SLA 或专有模块付费；阻止个人开发者免费采用的 source-available 条款会打断 PLG 漏斗；双许可和开放内核仍可用，但评估指标从'能否通过采购审查'变成'开发者采用摩擦'。3) B2C／面向个人——没有任何许可条款能转化个人；许可证是信任与分发决策，钱（如果有）来自赞助或托管便利；推荐最大化信任的宽松或 copyleft 选择，别动条款。若确实考虑 source-available 或延迟开源条款，走一遍双许可、开放内核、BUSL 与 FSL 参数、Fair Source 定义以及每次有记录的许可证变更实际产生了什么。全程强制用词准确：source-available 不是开源；对想同时贴两个标签的用户，值得重复 OSI 理事会对这种失败的原话——'the hallmark of a fauxpen source license is that those who made the switch claim that their product continues to remain "open" under the new license, but the new license actually has taken away user rights'；把它叫开源会失去项目原本要争取的受众，也过不了直接检查 OSI 批准的采购过滤器。
10. 第 6 步——如果是变更，就按变更来规划：给现有项目改许可证与挑许可证是不同的活，一条硬规则：需要仍在仓库中的每一位版权人的同意，除非贡献者协议已授予该权利。已发布的版本永远保留旧许可证，所以任何人都可以从最后一个 commit fork——把 fork 当作可预期的反应而非最坏情况（Elastic、Redis、HashiCorp 各遇到过一次）。产出变更计划而不只是新许可证：需要谁的同意、如何征集；联系不上的贡献者的代码怎么办；变更生效的版本边界；哪些仍按旧条款；一份不含委婉语的公告，把上述全部讲清楚。
11. 第 7 步——交付产物：没有产出文件的决策等于没发生。按以下顺序交付（这是效率顺序，每项只花几分钟，按缺失会破坏什么排序），并在环境允许时用真实的许可证检测器验证：1) 仓库根目录的 `LICENSE`，使用未经修改的许可证原文，不追加任何内容——没有文件意味着法律上未授权，修改过的文件会破坏自动识别。2) 混合仓库要写下按目录的边界——单一根 LICENSE 会默默把文档、素材和示例也一并声明。3) 贡献政策写进 contributing guide，明确写出签署或签名步骤，并配上自动检查——靠记忆执行的政策不算执行。4) 包／注册表元数据的 license 字段，以及适用时的容器镜像标签——注册表会展示并据此过滤。5) `SPDX-License-Identifier` 头和集体版权声明（'Copyright The <Project> Authors'）而非逐一列举贡献者。6) 当许可证要求归属传播时提供 `NOTICE` 文件，并保留第三方声明。
12. 按请求匹配入口点，并说明跳过了哪些步骤及原因：'下周要开源一个内部 Go 库——MIT 还是 Apache-2.0？'→ 从第 1 步开始然后直接到第 3 步，交付约束清单、基于专利与企业贡献者的两选项对比、LICENSE/SPDX/元数据产物集；'我们该要求 CLA 吗？'→ 先问一个关于商业计划的问题再从第 4 步开始，交付档位、支持它的具体权利（或没有这样的权利的结论）、contributing guide 措辞和自动检查；'我们想阻止 AWS 转售我们的服务器'→ 从第 2 步开始（姿态才是真问题），交付两三个姿态及各自排除什么、点名竞争对手的测试、以及若 source-available 存活要预期的 fork 先例；'把我们从 Apache-2.0 改成 BUSL 发 3.0'→ 从第 6 步开始并先跑第 1 步查贡献者同意，交付同意地图、版本边界、哪些保持宽松、公告草稿、应预期的 fork；'我们的依赖图允许哪个许可证？'→ 只做第 1 步，交付枚举的入站许可证和被排除的出站选项及各自原因（只给约束，不给推荐）；'我们仓库的许可证配置对吗？'→ 第 7 步，交付对照清单的产物审计，每个缺口给出要修的确切文件和位置。当'这个项目是为了什么'的答案开放时，或当请求是对有外部贡献者的项目改许可证时，跑完整流程——这两种情况下走捷径会产出被公开推翻的决定。
13. 产出可随代码一起提交的许可证决策记录，按节呈现并在继续前逐节取得同意（顶部一个错误约束会让下面每一行失效，在第二个标题处发现远比在第八个标题处便宜）：`# Licensing decision - <project>`，含 `## Artifact & trigger`（交付什么、许可证义务附着于哪个事件）、`## Constraints`（依赖许可证、雇主／基金会规则、被排除的选项）、`## Posture`（第 2 步选定的捆绑包及其排除什么）、`## Outbound license`（许可证、为何胜过替代方案、排除了谁）、`## Contribution policy`（什么都不要求／DCO／CLA、理由、执行机制）、`## Business model`（用了或明确没用杠杆，以及它针对的竞争对手）、`## Artifacts`（要新增或修改的文件及确切位置）、`## Revisit`（什么情况值得重新打开：商业模式、基金会、fork）。
14. 按六项通过阈值迭代直到全部通过，然后明确报告结果，并说明这是本技能自己的标准而非公开标准，若知道采用方组织的真实标准（如 'Blue Oak Bronze or better' 政策、仅允许 OSI 批准的白名单）就替换进去：1) 每个随产物分发的依赖许可证都已枚举，每种组合的方向都已核实——100% 覆盖，没有'大概是宽松的'。2) 出站许可证是公认的、未经修改的许可证，且标签正确：OSI 批准，或 source-available 且绝不被称为开源。3) LICENSE 文件被自动检测器识别为预期许可证（无检测器时靠人工检查）。4) 贡献政策对每个进入的变更都有自动检查；靠记忆执行的政策不算执行。5) 记录中的每条论断都可追溯到许可证原文、其管理者的公开声明或有记录的案例——不断言法院会怎么做。6) 每个被排除的选项都带有书面理由，以免下个季度有人重新翻案。
15. 避开常见失败模式：许可证选择器式问答（两个问题就答 MIT，没有依赖审计——约束步骤才让推荐站得住）；选了依赖所禁止的许可证（在首次发版时被用户当众发现）；把 AGPL 当魔法护盾（它要求网络运营者公开源码，挡不住合规的强敌，还会让项目在有书面禁令的企业内出局，Google 是可查的例子）；没有需要它的计划却上 CLA（纯摩擦，外加看起来像抢权利的名声代价）；把 source-available 叫开源（几秒内可查证，更正在公开场合到来，且过不了按 OSI 批准过滤的采购白名单）；忘记商标（许可证管代码，名称和 logo 才是阻止 fork 自称你产品的东西——William Morgan 在 2025 年 Synadia/NATS 争端中说，Apache-2.0 允许任何人发布改许可版本，但 'the one thing you can't do is call that relicensed thing the original project name'；免费分发不是庇护所，_Planetary Motion v. Techsplosion_（261 F.3d 1188）确立通过互联网免费提供软件仍可构成商业使用；把名称当作有独立政策的资产，在任何公开提及前约两个月做商标清查，商标律师的排期可能推翻这个时间线；预期基金会会要求转让它，CNCF 就会）；决定太晚（每个已发布版本永远保留原条款，采用到来后再拉杠杆基本只是象征性的）；混合仓库中无声的范围蔓延（文档、示例和素材会继承根 LICENSE，除非写下边界）。

适用边界 · 注意事项

• 不要把它当作法律意见：涉及专利组合、收购、有争议的贡献或任何进行中的纠纷时，必须转介律师，本技能只解释各工具的作用与后果。
• 不适用于决定公司到底要开源什么——那属于 open-source-company-strategy 技能。
• 当项目已有外部贡献者且请求是改许可证时不要走捷径，必须跑完整流程（含第 1 步的贡献者同意排查），否则会产出被公开推翻的决定。