开源许可证的商业影响：选错一个词的代价
先讲一个事实：协议一旦发布就改不回来。你可以给新版本换协议，但已经出去的版本永远是当时的协议，任何人都可以继续用那个版本。
一、四类协议，四种商业后果
| 协议 | 能拦住的 | 拦不住的 |
|---|---|---|
| MIT / Apache | 几乎不拦 | 任何商业使用、闭源集成、云托管 |
| GPL | 闭源分发 | 自用、SaaS 提供服务 |
| AGPL | 闭源分发 + 闭源 SaaS | 内部自用 |
| 商业源码许可（BSL/SSPL 等） | 托管竞争 | 非商业使用（视条款） |
关键差别在 AGPL：它把「通过网络提供服务」也视为分发，因此云厂商不能直接拿你的代码做成托管服务而不开源。这就是为什么基础软件项目越来越倾向 AGPL。
二、三种典型场景的最优解
1. 想最大化传播
用 MIT 或 Apache-2.0。代价是放弃「靠授权收费」这条路，收入只能来自托管、支持、或附加产品。
2. 想防云厂商
用 AGPL。代价是部分企业客户会因此不敢用（他们的法务会卡），传播速度下降。
3. 想两者兼顾
用「开放核心」：核心 MIT，企业功能单独授权。难点是分割线怎么画——切得太狠社区不买账，切得太松企业版没价值。
三、被忽略的细节
- 依赖的协议会传染：你的项目用了 GPL 的库，整体可能都要按 GPL 发布；
- 模型权重和代码是两套协议：AI 类项目常见「代码 Apache、权重非商用」，很多人只看前者；
- 专利条款：Apache-2.0 含明确的专利授权，MIT 没有。做企业客户时这项很重要；
- 贡献者协议（CLA）：没有 CLA，将来想换协议要征得所有贡献者同意，几乎不可能。
最后一条最坑：项目做大之后想商业化，才发现自己换不了协议。
四、给决策者的四个问题
- 三年后我靠什么赚钱？（托管 / 授权 / 支持 / 引流）
- 我的用户里，企业占比多少？它们在不在意协议？
- 我需要拦住云厂商吗？
- 我打算接受外部贡献吗？如果打算，CLA 现在就加。
五、一个反直觉的建议
如果你只是想做作品集、拿影响力，别纠结协议，用 MIT，把精力放在文档和生态上。协议的价值只在「你要靠它赚钱」时才显现。
具体到各协议的商用边界和落地检查项，见 开源协议与商用红线；商业化路径的选择，见 开源项目的商业化路径。
相关阅读
版权声明：如无特殊标注，文章均为本站原创，转载时请以链接形式注明文章出处。
评论