MonkeyCode 开源协议解读：为什么选择 AGPL-3.0 而不是 MIT 或 Apache
开源协议的选择决定了项目的命运。MonkeyCode 选择 AGPL-3.0 而非更宽松的 MIT/Apache，背后有着深思熟虑的战略考量。本文深度解析这一选择的逻辑、影响和意义。
📜 主流开源协议速览
开源协议"光谱图"
┌─────────────────────────────────────────────────────┐
│ 开源协议自由度光谱 │
│ │
│ 高自由度（宽松） 低自由度（严格） │
│ ──────────────────────────────────────────── │
│ │
│ MIT ─── Apache ─── BSD ─── GPL ─── AGPL │
│ │ │ │ │ │ │
│ ✅可闭源 ✅可闭源 ✅可闭源 ❌需开源 ❌SaaS也需开源 │
│ ✅无义务 ✅专利许可 ✅简单 ✅相同协议 ✅网络触发 │
│ │
│ 代表项目： │
│ MIT: React, Vue, jQuery │
│ Apache: Kubernetes, TensorFlow, Spring │
│ GPL: Linux, GCC, WordPress │
│ AGPL: MongoDB, MongoDB, MonkeyCode │
│ │
└─────────────────────────────────────────────────────┘
各协议核心条款对比
| 条款 | MIT | Apache 2.0 | GPL 3.0 | AGPL 3.0 |
|---|---|---|---|---|
| 商业使用 | ✅ 允许 | ✅ 允许 | ✅ 允许 | ✅ 允许 |
| 修改后分发 | ✅ 无需公开 | ✅ 无需公开 | ❌ 必须开源 | ❌ 必须开源 |
| 专利授权 | ⚠️ 隐含 | ✅ 明确授予 | ✅ 授予 | ✅ 授予 |
| SaaS 网络使用 | ✅ 无限制 | ✅ 无限制 | ⚠️ 有争议 | ❌ 必须开源 |
| 许可证传染 | ❌ 无 | ❌ 无 | ✅ 相同协议 | ✅ 相同协议+网络 |
| 代码署名 | 可选 | ✅ 要求保留 | ✅ 要求保留 | ✅ 要求保留 |
| 责任免除 | ✅ | ✅ | ✅ | ✅ |
🤔 为什么不选 MIT？
MIT 的优势与风险
MIT 协议的特点：
┌─────────────────────────────────────────────────────┐
│ │
│ ✅ 优势： │
│ ├── 极度简洁（~170 字） │
│ ├── 几乎无限制，任何人可用任何方式使用 │
│ ├── 企业友好，法律风险极低 │
│ ├── 社区接受度高，采用最广泛 │
│ │
│ ❌ 对 MonkeyCode 的风险： │
│ ├── 大公司可以拿走代码 → 闭源 → 商业化 │
│ │ 例：AWS 拿走 MongoDB → DocumentDB（闭源） │
│ │ │
│ ├── 无法强制回馈社区 │
│ │ 企业改进后无需分享 → 社区无法受益 │
│ │ │
│ ├── 可能被"吸血" │
│ │ 大厂用开源代码做竞品 → 原项目被边缘化 │
│ │ │
│ └── 与商业模式冲突 │
│ 如果靠企业服务盈利，MIT 让竞争太容易 │
│ │
└─────────────────────────────────────────────────────┘
真实案例：MongoDB 的教训
# MongoDB 的协议演变历程
phase_1: AGPL 时期（2009-2018）
license: AGPL-3.0
situation:
- 云厂商开始提供 MongoDB 托管服务
- AWS 推出 DocumentDB（兼容 MongoDB API）
- MongoDB 公司收入受影响
problem: "云厂商在'免费搭便车'"
phase_2: SSPL 转换（2018 至今）
license: Server Side Public License (自定义)
action:
- 从 AGPL 切换到更严格的 SSPL
- 明确要求 SaaS 提供商必须开源
result:
- 引发社区争议
- OSI 不承认 SSPL 为开源协议
- 但有效阻止了云厂商的"白嫖"
# MonkeyCode 的启示：
# 与其后期被迫更换协议，不如一开始就选择合适的协议
# AGPL-3.0 正是在"开放"和"保护"之间的最佳平衡点
🤔 为什么不选 Apache 2.0？
Apache 2.0 的诱惑
Apache 2.0 的吸引力：
┌─────────────────────────────────────────────────────┐
│ │
│ 🎯 对企业的超级友好： │
│ ├── 专利条款非常完善 │
│ │ 明确授予专利使用权 │
│ │ 专利反担保条款保护使用者 │
│ │ │
│ ├── 修改后可以闭源分发 │
│ │ 企业可以基于它开发内部工具 │
│ │ 不需要担心代码泄露 │
│ │ │
│ ├── 大厂最爱用的协议之一 │
│ │ Google: Android, TensorFlow, Kubernetes │
│ │ Apache: Hadoop, Spark, Flink │
│ │ Facebook: React (曾用，后改回 MIT) │
│ │
│ ❌ 但对 MonkeyCode 来说： │
│ ├── 同样存在被"拿走即闭源"的风险 │
│ ├── 无法保障 SaaS 场景下的开源义务 │
│ └── 与长亭科技的商业策略不完全匹配 │
│ │
└─────────────────────────────────────────────────────┘
Apache vs AGPL：关键差异
# 场景模拟：某大厂基于 MonkeyCode 提供 SaaS 服务
# Apache 2.0 下：
company_actions_apache = {
"步骤一": "Fork MonkeyCode 仓库",
"步骤二": "进行定制化开发和优化",
"步骤三": "作为付费 SaaS 服务提供给客户",
"步骤四": "收取服务费用",
"步骤五": "代码改进完全保密",
"结果": "原项目社区得不到任何回馈 💸"
}
# AGPL-3.0 下：
company_actions_agpl = {
"步骤一": "Fork MonkeyCode 仓库",
"步骤二": "进行定制化开发和优化",
"步骤三": "作为付费 SaaS 服务提供给客户",
"步骤四": "收取服务费用",
"步骤五": "⚠️ 必须公开所有修改后的源代码！",
"结果": "社区获得改进，形成正循环 🔄"
}
✅ 为什么选择 AGPL-3.0？
核心决策因素
┌─────────────────────────────────────────────────────┐
│ MonkeyCode 选择 AGPL-3.0 的五大理由 │
│ │
│ 1️⃣ 防止 SaaS "白嫖"（最关键！） │
│ ───────────────────────────────── │
│ AI 编程工具天然适合 SaaS 模式： │
│ - 用户通过 Web/IDE 使用 │
│ - 代码在云端运行 │
│ - 传统 GPL 无法覆盖这种场景 │
│ - AGPL 的"网络触发"条款正好解决 │
│ │
│ 2️⃣ 保障社区正循环 │
│ ───────────────────────────────── │
│ 企业改进 → 必须回馈 → 社区受益 → 更多用户 → │
│ 更多贡献者 → 项目更好 → 更多企业使用 │
│ │
│ 3️⃣ 与商业模式兼容 │
│ ───────────────────────────────── │
│ - 开源 ≠ 免费（服务收费） │
│ - 企业仍需：部署、维护、培训、支持 │
│ - 长亭科技可以卖"服务"而非"软件" │
│ │
│ 4️⃣ 法律清晰度高 │
│ ───────────────────────────────── │
│ - 经过多轮法律审查 │
│ - FSF/OSI 认证 │
│ - 全球司法管辖区有判例支持 │
│ │
│ 5️⃣ 与价值观匹配 │
│ ───────────────────────────────── │
│ "真正的开源应该是可持续的， │
│ 而不是一次性奉献后被商业化吞噬。" │
│ │
└─────────────────────────────────────────────────────┘
AGPL-3.0 的"网络触发"条款详解
# AGPL-3.0 第 13 条（远程网络交互）
原文摘要：
"如果你修改了程序，并通过计算机网络
向其他用户提供修改版本的功能，
你必须让这些用户能够获取完整的
对应源代码。"
通俗解释：
trigger_conditions:
condition_1: 你使用了 AGPL 软件
condition_2: 你对软件进行了修改
condition_3: 你通过网络向用户提供服务
obligations:
- 必须向用户提供完整源代码（包括你的修改）
- 必须保持 AGPL-3.0 许可证
- 必须保留原始版权声明
不触发的场景：
- 内部使用（不对外提供服务）
- 未修改直接使用
- 仅作为客户端/前端使用
对 MonkeyCode 的意义：
scenario_cloud_provider:
who: 云服务商想基于 MonkeyCode 做 AI 编程 SaaS
what: 修改了代码以适配自己的基础设施
how: 通过网络向客户提供编程辅助服务
result: "必须开源所有修改！"
scenario_enterprise_internal:
who: 企业内部 IT 部门
what: 定制化部署以满足内网需求
how: 仅内部员工使用，不对外提供服务
result: "✅ 无需公开修改！"
🏢 对不同用户的影响
个人开发者
## 个人开发者使用指南
### ✅ 你可以做什么？
- [x] 免费下载和使用 MonkeyCode
- [x] 学习源代码并借鉴设计思路
- [x] 在个人项目中使用（包括商用）
- [x] 修改源码满足个人需求
- [x] 在 GitHub 上 Fork 并发布自己的版本
- [x] 参与社区贡献（提交 PR）
- [x] 写博客/教程介绍 MonkeyCode
### ⚠️ 注意事项
- 如果你基于 MonkeyCode 开发了新功能，
并通过网络向他人提供服务，
那么你需要开源这些修改
### 实际例子
情况 A：你在公司内部部署了 MonkeyCode
→ 仅供同事使用，不对外服务
→ ✅ 无需公开任何代码
情况 B：你基于 MonkeyCode 做了一个在线编程学习平台
→ 学生通过网站访问
→ ❌ 需要开源你对 MonkeyCode 的修改部分
情况 C：你写了一个 VS Code 插件调用 MonkeyCode API
→ 插件本身是独立作品
→ ✅ 插件可以用任何协议（AGPL 不传染）
### 中小企业（<100 人）
```yaml
# 中小企业合规使用指南
recommended_approach: 直接使用官方版本
steps:
- 使用云端版或自行部署开源版
- 如需定制，联系长亭采购企业支持服务
- 内部使用无需担心 AGPL 限制
cost_benefit:
- 成本：免费（或可选的企业服务费）
- 收益：获得持续更新的稳定版本
- 风险：几乎为零
alternative_approach: 自行修改并内部使用
conditions:
- 有足够的开发能力
- 修改仅用于内部
- 不计划对外提供 SaaS 服务
compliance_check:
- question: 是否修改了源代码？
yes: continue
no: fully_compliant
- question: 修改后的版本是否通过网络对外提供服务？
yes: must_open_source
no: fully_compliant
- question: 是否分发了二进制文件？
yes: must_provide_source
no: fully_compliant
大型企业（>100 人）
# 大型企业合规使用建议
scenario_1: 作为内部工具使用
compliance_level: 低风险
action: 直接部署使用
obligation: 无需公开代码
recommendation: ✅ 推荐
scenario_2: 集成到自有产品中（不开源产品）
compliance_level: 中等风险
action: 法律团队评估集成方式
options:
- option_a: 通过 API/CLI 调用（进程隔离，无传染风险）
- option_b: 修改源码嵌入产品（可能触发 AGPL 义务）
recommendation: ⚠️ 建议方案 A
scenario_3: 基于 MonkeyCode 提供 SaaS 服务
compliance_level: 高风险
action: 必须遵守 AGPL-3.0
obligations:
- 公开所有对源代码的修改
- 保持 AGPL-3.0 许可证
- 在服务界面提供源代码获取方式
alternatives:
- alt_1: 采购长亭的商业授权（可能有不同条款）
- alt_2: 自研替代方案
- alt_3: 接受开源义务，将贡献回馈社区
recommendation: "咨询法务后决定"
scenario_4: 参与生态共建
compliance_level: 正面
action: 成为积极的社区贡献者
benefits:
- 影响技术方向
- 获得优先技术支持
- 品牌曝光
- 吸引人才
recommendation: ✅ 强烈推荐
🔄 AGPL vs 其他协议的实际案例
知名项目的协议选择及原因
| 项目 | 协议 | 选择原因 | 后续变化 |
|---|---|---|---|
| Linux | GPL-2.0 | 防止闭源分支 | 30 年未变，生态繁荣 |
| MySQL | GPL-2.0 | 保护商业利益 | 被 Oracle 收购后社区 fork 出 MariaDB |
| MongoDB | AGPL → SSPL | 反抗云厂商白嫖 | SSPL 未获 OSI 认可，引发争议 |
| Elasticsearch | Apache → ELv2 | AWS 发行 OpenDistro | 双重许可模式 |
| Redis | BSD → RSALt/BSL → AGPL | 云厂商竞争压力 | 多次变更，社区分裂 |
| GitLab CE | MIT | 追求最大普及率 | EE 版专有 |
| Odoo | LGPL → AGPL Enterprise | SaaS 化转型 | 双重许可 |
| MonkeyCode | AGPL-3.0 | 平衡开放与保护 | 长期坚持 |
教训总结
┌─────────────────────────────────────────────────────┐
│ 从其他项目学到的经验 │
│ │
│ ❌ 尽量避免中途更换协议 │
│ → 会严重伤害社区信任 │
│ → 可能导致 fork（如 MySQL → MariaDB） │
│ → 法律复杂性极高 │
│ │
│ ✅ 一开始就选择合适的协议 │
│ → MonkeyCode 选择 AGPL 是经过深思熟虑的 │
│ → 预见了 SaaS 场景的风险 │
│ → 与长期战略一致 │
│ │
│ 💡 给其他开源项目的建议： │
│ 如果你的项目可能被用于 SaaS 场景， │
│ 且你希望防止被"白嫖"， │
│ AGPL-3.0 是目前最好的选择。 │
│ │
└─────────────────────────────────────────────────────┘
📊 AGPL-3.0 对生态的影响
正面影响
positive_impacts:
community_health:
description: 促进健康的社区生态
details:
- 防止"拿走即跑"的行为
- 鼓励企业回馈改进
- 形成正循环的贡献文化
evidence:
- MongoDB 在 AGPL 下获得了大量企业贡献
- Nextcloud (AGPL) 拥有活跃的企业参与社区
sustainable_development:
description: 保障项目可持续发展
details:
- 核心团队可以通过服务盈利
- 不必担心被大厂"降维打击"
- 可以长期投入研发
evidence:
- Grafana (AGPL) 成功构建了商业模型
- WordPress (GPL) 支撑了整个生态系统
enterprise_adoption:
description: 企业更愿意投入资源
details:
- 企业知道不会被"卡脖子"
- 可以放心地深度定制
- 投资培训和人力的回报有保障
evidence:
- 大量银行/政府使用 PostgreSQL (类似宽松协议)
- 但安全敏感领域更倾向于 AGPL/GPL
潜在顾虑与回应
| 顾虑 | 回应 |
|---|---|
| "AGPL 会吓退企业用户" | ❌ 不会。MongoDB、Elasticsearch（早期）、Grafana 都有大量企业用户 |
| "AGPL 法律风险高" | ⚠️ 任何协议都有法律风险。AGPL 是经过充分验证的成熟协议 |
| "AGPL 会限制传播" | ✅ 反而促进传播。因为贡献者知道自己的工作不会被窃取 |
| "不如用双许可（Dual License)" | 双许可更复杂，且本质上也是"付费即可闭源"。AGPL 更纯粹 |
🛡️ 合规最佳实践
如何确保 AGPL 合规？
# 1. 明确使用场景
cat << 'EOF'
问自己三个问题：
1. 我是否修改了 MonkeyCode 的源代码？
2. 我修改后的版本是否通过网络对外提供服务？
3. 我是否分发了编译后的二进制文件？
如果以上任何一个答案是"YES"，请咨询法务。
如果全部是"NO"，你可以安心使用。
EOF
# 2. 建立合规流程
# .github/agpl-compliance-checklist.md
## AGPL-3.0 合规检查清单
### 代码修改记录
- [ ] 所有修改都有 commit 记录
- [ ] 修改内容有清晰的文档说明
- [ ] 修改的 diff 可以随时提取
### 分发/服务检查
- [ ] 如果对外提供服务，确认已准备源代码获取方式
- [ ] 服务界面包含 AGPL-3.0 许可证链接
- [ ] 源代码仓库保持公开可访问
### 第三方组件检查
- [ ] 依赖库的许可证兼容性已审核
- [ ] 没有 GPL 不兼容的闭源依赖
- [ ] 动态链接的库不需要开源（但静态链接需要）
# 3. 工具辅助合规
# 使用 SPDX 标识符管理许可证
# 安装许可证扫描工具
pip install license-scanner
# 扫描项目依赖
license-scanner scan ./node_modules
license-scan scan ./vendor
常见合规问题 FAQ
### Q1: 我的插件需要用 AGPL 吗？
**A:** 不一定。如果你的插件是独立程序（进程隔离），通过 API 与 MonkeyCode 通信，那么插件可以使用任何许可证。
### Q2: 我们用了 MonkeyCode 的 SDK，需要开源吗？
**A:** SDK 本身通常使用更宽松的许可证（如 MIT）。但具体要看 SDK 的许可证声明。MonkeyCode 的 SDK 文档会明确说明。
### Q3: Docker 镜像分发算"分发"吗？
**A:** 如果镜像中包含编译后的 MonkeyCode 二进制，且你修改过源码，那么需要提供对应的源代码获取方式。
### Q4: 只修改了配置文件，算"修改"吗？
**A:** 配置文件修改不算"对程序的修改"，不受 AGPL 约束。
### Q5: 我们是外包公司，帮客户部署 MonkeyCode，客户需要开源吗？
**A:** 如果你们只是帮客户部署官方版本（未修改），客户没有开源义务。如果你们做了定制化修改，需要看客户的用途。
🔮 未来展望
AGPL-3.0 的趋势
┌─────────────────────────────────────────────────────┐
│ AGPL-3.0 的未来趋势 │
│ │
│ 📈 采用率增长： │
│ ├── 越来越多的 SaaS 项目选择 AGPL │
│ ├── 云计算时代 AGPL 比 GPL 更适用 │
│ ├── 数据库/基础设施领域尤其明显 │
│ │
│ 🏢 企业接受度提高： │
│ ├── 法务团队越来越熟悉 AGPL │
│ ├── 合规工具链逐渐成熟 │
│ ├── 成功案例增多降低了心理门槛 │
│ │
│ ⚖️ 法律环境改善： │
│ ├── 更多司法判例提供参考 │
│ ├── 各国对开源协议的解释趋于一致 │
│ ├── FSF 和 OSI 持续提供指导 │
│ │
│ MonkeyCode 的承诺： │
│ ├── 长期坚持 AGPL-3.0 │
│ ├── 不会切换到更严格的协议（如 SSPL） │
│ ├── 也不会放宽到 MIT/Apache │
│ ├── 致力于建设健康可持续的开源生态 │
│ │
└─────────────────────────────────────────────────────┘
💬 结语
MonkeyCode 选择 AGPL-3.0 不是为了"限制"谁，而是为了"保护"所有人——
- 保护贡献者的劳动不被无偿占有
- 保护社区的活力不被商业化吞噬
- 保护项目的长期可持续发展
- 保护每一个用户的权益不被边缘化
╔═══════════════════════════════════════════════════════════╗
║ ║
║ 📋 MonkeyCode 开源协议选择总结 ║
║ ║
║ 协议：AGPL-3.0 ║
║ 核心目标：平衡开放与保护 ║
║ 关键机制：网络触发开源义务 ║
║ 适用场景： ║
║ ✅ 个人使用 — 完全免费，无任何义务 ║
║ ✅ 企业内部使用 — 无需公开代码 ║
║ ✅ 基于 API/CLI 集成 — 无传染风险 ║
║ ⚠️ 修改后提供 SaaS 服务 — 需开源修改部分 ║
║ ║
║ 长期承诺： ║
║ 不会更改协议 → 不会走向极端 → 坚持开放共享 ║
║ ║
╚═══════════════════════════════════════════════════════════╝
🔗 相关链接
- 📜 AGPL-3.0 全文: https://www.gnu.org/licenses/agpl-3.0.html
- 📦 MonkeyCode GitHub: https://github.com/chaitin/monkeycode
- 📖 OSI 开源定义: https://opensource.org/osd
- ⚖️ FSF 许可证列表: https://www.gnu.org/licenses/license-list.html
- 💬 讨论 AGPL 选择: https://github.com/chaitin/monkeycode/discussions/categories/licensing
- 🐛 问题反馈: https://github.com/chaitin/monkeycode/issues
本文由 MonkeyCode 团队原创，欢迎转载但请注明出处。
🎉 MonkeyCode —— 用 AGPL-3.0 守护真正的开源精神！
如果你认同我们的理念，欢迎给 MonkeyCode 点一个 Star！
👉 https://github.com/chaitin/monkeycode ⭐
浙公网安备 33010602011771号