MonkeyCode 与 AGPLv3：为什么我们选择最严格的开源许可证
MonkeyCode 与 AGPLv3：为什么我们选择最严格的开源许可证
MonkeyCode 使用 GNU Affero General Public License v3.0（AGPLv3）开源。这是最严格的主流开源许可证之一。为什么？这篇文章解释我们的思考过程。
开源许可证光谱
主流开源许可证从宽松到严格：
宽松 ←————————————————————→ 严格\n\nMIT/BSD → Apache 2.0 → LGPL → GPL → AGPL\n\n特点:\nMIT: 随便用，不需要开源你的代码\nApache: 随便用，需要保留版权声明，有专利保护\nLGPL: 可以链接使用，修改LGPL部分需要开源\nGPL: 使用就必须开源你的全部代码\nAGPL: 使用就必须开源，包括网络服务（SaaS）为什么不用MIT？
MIT是最流行的开源许可证，简单、宽松。很多知名项目都用MIT：React、Vue、Next.js等。
但对MonkeyCode来说，MIT有一个致命问题：云厂商可以直接拿走你的代码，包装成商业服务，不需要回馈社区。
具体场景：
- 某云厂商Fork MonkeyCode
- 做一些表面定制
- 作为自己的"AI编程平台"提供服务
- 赚取利润，但不需要公开任何改进
- 用户不知道底层用的是MonkeyCode
这在开源世界不是假设，而是已经发生过很多次的事实。AWS就曾因为类似行为引发争议。
为什么不用GPLv3？
GPLv3要求分发软件时必须开源。但有一个关键漏洞：网络服务不算"分发"。
也就是说：
- 把MonkeyCode打包成软件给用户安装 → 需要开源（GPL ✅）
- 把MonkeyCode部署为SaaS服务 → 不需要开源（GPL ❌）
作为AI编程平台，MonkeyCode的核心使用方式就是SaaS服务。如果用GPL，云厂商完全可以部署成SaaS而不回馈社区。
AGPLv3解决了什么？
AGPLv3在GPLv3的基础上增加了一个关键条款：即使通过网络（如SaaS）提供服务，也必须向用户提供源代码。
这意味着：
| 使用方式 | GPLv3 | AGPLv3 |
|---|---|---|
| 下载使用 | 需要开源修改 | 需要开源修改 |
| 部署为SaaS | 不需要开源 | 需要开源修改 |
| 内网部署 | 灰色地带 | 需要开源修改 |
对企业用户的影响
很多企业看到AGPL就紧张："我们能不能用？"答案取决于使用方式：
✅ 可以自由使用的场景
- 使用MonkeyCode在线服务— AGPL约束的是代码分发，不影响用户使用
- 按照原样私有化部署— 不修改代码，内部使用完全没问题
- 为MonkeyCode贡献代码— 贡献的代码本身就是开源的
⚠️ 需要注意的场景
- 修改MonkeyCode核心代码— 修改后的版本必须开源
- 将MonkeyCode集成到自己的产品中— 需要仔细评估是否构成"衍生作品"
- 二次分发— 必须保持AGPL许可证
企业常见问题
Q：我们公司内部部署MonkeyCode，做了一些配置调整，需要开源吗？
A：不需要。配置调整（如修改配置文件、环境变量）不算代码修改。
Q：我们开发了一个MonkeyCode插件，需要开源吗？
A：取决于插件的集成方式。通过公共API开发的插件通常不需要开源。但直接修改核心代码的插件需要开源。
Q：我们想把MonkeyCode部署给客户使用，可以吗？
A：可以。但如果你修改了MonkeyCode的代码，修改部分需要开源。
商业授权
对于无法接受AGPL的企业，MonkeyCode 提供商业授权选项：
许可证对比:\n\nAGPLv3 (免费):\n ✅ 使用源代码\n ✅ 修改源代码\n ⚠️ 修改后必须开源\n ⚠️ SaaS服务需要开源\n\n商业授权 (付费):\n ✅ 使用源代码\n ✅ 修改源代码\n ✅ 修改后不需要开源\n ✅ 可以集成到商业产品\n ✅ 企业级技术支持\n ✅ SLA保障开源社区的反应
选择AGPL后，社区的反应：
支持的声音
- "终于有一个不怕被大厂白嫖的AI编程工具了"
- "AGPL保护了真正的开源精神"
- "这让我更愿意贡献代码，因为知道不会被利用"
担忧的声音
- "AGPL让企业客户望而却步"
- "集成到其他开源项目会有许可证冲突"
- "Python/JS生态中AGPL项目较少，可能影响生态"
其他知名AGPL项目
MonkeyCode不是唯一选择AGPL的项目：
- MongoDB（后改为SSPL） — 数据库巨头，同样为了防止云厂商白嫖
- Mattermost— 开源Slack替代品
- OpenSearch— AWS的Elasticsearch替代品（部分组件AGPL）
- iText— PDF处理库
我们的反思
选择AGPL不是结束，而是开始。我们面临的挑战：
- 生态建设更难— 有些开发者因为AGPL而犹豫
- 需要更多文档— 帮助企业理解AGPL的实际影响
- 插件生态需要特殊设计— 确保插件开发者不受AGPL约束
- 需要维护双授权体系— AGPL + 商业授权并行
总结
AGPLv3是我们经过深思熟虑的选择。它不是最流行的许可证，但对我们来说是最合适的——它保护了社区贡献者的利益，防止了云厂商的"白嫖"行为，同时通过商业授权为企业用户提供了灵活的选择。开源不只是"开放源代码"，还包括对生态的长期负责。
GitHub：github.com/chaitin/MonkeyCode
许可证：github.com/chaitin/MonkeyCode/blob/main/LICENSE