双许可与企业版：九家询价、两家成交与 4,800 美元

双许可卖的不是代码，是「不用把你们的代码也开源」这一句承诺。

一、第一封问「能不能买商业许可」的邮件

2026 年 2 月，一家做内部工具的公司写信问：他们想把 syncwell 的引擎嵌进自己的闭源产品，但 GPL-3.0 要求衍生作品同样开源，法务不接受，问有没有商业许可。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

这封邮件开启了一条此前没想过的收入线。一年下来，九家询价、两家成交，每家 2,400 美元/年，合计 4,800 美元，占全年收入 23,388 美元的 20.5%。金额不算大，但它是唯一一条「单价高、交付轻」的收入：没有服务器成本，没有月度运维，只有一份合同和一条支持邮箱。

他没在当天回复。先花了两天确认三件事：自己有没有权利发放商业许可、商业版与开源版的差异该怎么写、支持义务的边界在哪。三件事里，第一件花了最久，因为它涉及过去三年的每一份贡献。

双许可的前提是「两个版本」。 一个 copyleft 版本给愿意遵守义务的人，一个商业版本给不能遵守的人。两个版本的代码可以完全相同，差别只在许可证；如果代码不同，维护成本会翻倍，一个人扛不住。

这也是为什么双许可不是「把开源版阉割一下卖企业版」。前者卖的是义务豁免，后者卖的是功能；混在一起，既得罪社区，也说不清价格。

两个版本的代码可以完全一致，也可以有细微差异，但差异不能是「功能多少」。可行的差异是「打包方式」：商业版提供签名安装包、离线文档与一个支持邮箱；这些都增加成本，但不改变功能。

二、双许可的四个前提

双许可能成立，需要四个前提同时满足。缺一个，交易要么谈不成，要么成交后变成负债。

第一条决定了你有没有东西可卖。如果项目是 MIT 或 Apache-2.0，任何人都可以闭源使用，双许可没有市场；只有当 copyleft 的义务真实存在，豁免才有价值。

这里有个反直觉的结论：许可证越宽松，双许可越难做。MIT 项目想卖商业许可，只能卖支持或托管；GPL 项目想卖商业许可，卖的是「不用开源」这个明确的豁免。选许可证时，这层商业含义应该被一起考虑。

第二条最容易被忽略。开源项目的代码往往有外部贡献，如果没有 CLA（贡献者许可协议），你只有这些贡献的使用权，没有对外再许可的权利。17 位贡献者里 14 位签了 CLA，占 82.4%；剩下 3 位的提交集中在文档与测试，已在商业版中替换。这不是完美的状态，但足以支撑当前规模。

CLA 的替代方案是「贡献者保留版权 + 你获得永久许可」。这种写法对贡献者更友好，但每份合同都要单独写；17 位贡献者里，3 位用的是这种安排，文件存在 docs/cla/ 下。

第三条是交易成本。一份 6 页的协议比 30 页的更容易走完法务；条款只需要覆盖四件事：许可范围、席位或用量、支持义务、终止条件。写得太复杂，成交周期会从三周变成三个月。

六页协议的目录是：定义、许可授予、限制、支持、费用与期限、终止。六节各一页，没有附件；需要附件的是「支持档位」，而它只有一页，写清响应时限与不含事项。

第四条决定成交后的负担。商业许可必须明确「不含 24×7」「不含定制开发」「不含源码交付」，否则第一封求助邮件就会变成一次无偿的项目交付。

三、九家询价、两家成交

九个询价里，真正走到合同的有两家。中间流失的七家不是价格问题，是需求与产品不匹配。

五家在法务评估阶段退出，原因高度一致：他们本来就可以用 GPL 版本，只是不确定义务边界。一封写清「什么情况下必须开源」的说明页，能把这五家的沟通成本从三次会议降到一封邮件。

这页说明的写法是三个场景：把代码嵌进闭源产品要开源、只在内部使用不开源、通过 API 调用不开源。三个场景覆盖了九家询价里的七家；剩下两家的情况更复杂，需要单独谈。

一家要求源码交付，报价后退出。这类需求本质上是「源码托管」或「escrow」，不是许可证问题；一个人做不了，也不该做。把它写进「不提供」清单，比事后解释省力。

「不提供」清单还有一项常被问到：能不能只买某一模块的许可。答案是不行，因为模块之间有调用关系，拆开授权会让义务边界变得无法解释；这条要写在报价单的备注里，而不是等对方问了才说。

两家的合同额都是 2,400 美元/年，没有席位限制，只有一条「不得用于对外提供的托管服务」。这条限制保护的是托管收入，不是代码本身；如果客户拿商业版去做 SaaS 卖给他们的客户，你就多了一个不承担运维成本的竞争者。

这条限制的执行方式不是技术，是合同。代码里不做限制，因为限制会被绕过；合同里写清违约后果，并在每年续约时确认一次用途。对一个人来说，这已经是最可行的防线。

双许可的定价锚点是「对方省下的合规成本」，不是你的开发成本。 2,400 美元大约等于一家公司请外部律师审一次 GPL 义务的费用；低于这个数，对方会怀疑协议不完整，高于这个数，采购会开始比较「自己写一个替代品」。

四、三条合同边界与一次复算

合同只需要写清三条边界，剩下的都可以引用标准条款。

第一条是许可范围：谁能用、用在什么产品里、能不能转授。第二条是支持义务：邮件响应时限、节假日是否计算、超出范围怎么收费。第三条是商标：商业许可不包含项目名与 logo 的使用权，如需使用要单独书面同意。

三条边界之外，还有一条时间边界：合同期一年，到期前 30 天书面确认是否续约。没有这条，第二年会自动续，而你可能已经不想维护这个商业版了。

到期确认还有个好处：它给你一次重新定价的机会。2,400 美元是 2026 年的价格；如果支持成本上升，续约时可以调整，但要在到期前 60 天书面通知，而不是到期当天说。

复算：
询价 9 → 法务 4 → 报价 3 → 成交 2
阶段转化：4 ÷ 9 = 44.4%；3 ÷ 4 = 75.0%；2 ÷ 3 = 66.7%
整体成交：2 ÷ 9 = 22.2%
收入：2 × 2,400 = 4,800/年；4,800 ÷ 23,388 = 20.5%
单家占收入：2,400 ÷ 23,388 = 10.3%
CLA：14 ÷ 17 = 82.4%；未签 3 人集中在文档与测试
支持成本：按每家每年 6 小时计，2 × 6 = 12 h → 4,800 ÷ 12 = 400 美元/h
与托管对比：托管净时薪 32.1 美元/h；双许可 400 美元/h（毛口径）

复算里最刺眼的是 400 美元/h 与 32.1 美元/h 的对比。它说明双许可的单位时间收入远高于托管，但不要据此得出「应该 all in 双许可」：九家询价才成交两家，售前时间没有计入这 12 小时。把九家的沟通时间按每家 3 小时算，27 小时摊进去，时薪降到 123 美元/h，仍然高，但已经不是数量级差距。

五、行动清单与复算验收

• 确认项目有 copyleft 版本，且能独立使用。
• 核对贡献者名单，统计签了 CLA 的比例，处理未签部分。
• 准备一份不超过 8 页的商业许可协议，覆盖四条边界。
• 写一页「什么情况下必须开源」的说明，减少法务阶段的来回。
• 列出「不提供」清单：源码交付、定制开发、24×7、escrow。
• 定一个价格锚点，并写清它对应的是合规成本而不是开发成本。
• 在合同里写期限与到期确认方式，避免自动续约。
• 记录每家询价走到哪一步、为什么退出，季度复盘一次。

验收标准：任取一家询价，都能说出它卡在哪个前提、哪条边界，以及这单值不值得跟。

前四条是「让交易能成立」，后四条是「让交易不变成负债」。如果只有一小时，先做第二条：没有清晰的权属，签了合同也可能无效。

清单里最容易被跳过的是第五条。不提供的清单不是拒绝客户，是让对方在第一次会议就知道边界；写下来，比每次口头解释省力得多。

使用边界与实操验收

本文不是法律意见。 商业许可协议的条款、CLA 的效力、衍生作品的判定，都以正式文本与专业顾问为准。

双许可不适合所有项目。 没有 copyleft 版本、没有外部贡献、客户规模太小的项目，做双许可的交易成本会高于收入。

4,800 美元不是稳定收入。 两家客户明年可能不续；把它当成基线收入，会让预算建立在两个不确定的决定上。

不要把商业版做成功能更多的版本。 功能差异会让社区觉得开源版是诱饵；双许可的差异应该只在许可证，不在功能。

支持边界必须能被验证。 「2 个工作日」要写清是否含节假日、从哪一刻开始算；写得模糊，第一条工单就会变成争议。

关键参考与核验范围

• GNU GPL-3.0 原文 ：用于核对 copyleft 义务与「分发」的边界。
• OSI 许可证目录 ：用于核对双许可中开源侧的合规性。
• Choose a License ：用于核对不同许可证对商业使用的影响。

以上链接于 2026-10-26 实测可公开访问；未核验版本、功能范围与政策更新。核验日期：2026-10-26。

范围上只讨论一个人维护项目的双许可结构、成交漏斗与合同边界，不讨论诉讼、专利许可、跨国税务与源码托管安排。

系列导航

• 上一篇：赞助之门：4,200 个 star 里的 23 个人与两家公司
• 下一篇：治理、fork 与退出：17 位贡献者、82% 的提交与一次改协议的代价
• 回到目录：一个人的开源产品：4,200 个 star、一百八十个付费与一年 612 小时的维护
• 相关阅读：一个人的公司：主体、税务与合规