AGPL-3.0协议深度解读：企业使用MonkeyCode开源的权利与义务（2026版）
"AGPL-3.0不是法律陷阱——它是保护开源生态可持续发展的契约。理解它、遵守它，你就能放心大胆地在企业中使用MonkeyCode" —— 本文用通俗语言逐条解读AGPL-3.0协议，帮助企业法务、CTO和开发者做出正确的合规决策。
一、什么是AGPL-3.0？
📜 AGPL-3.0 全称：
GNU Affero General Public License Version 3
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
发展历史：
┌─────────────────────────────────────┐
│ 1989 GPL v1 → 自由软件基金会发布 │
│ 1991 GPL v2 → Linux内核使用的版本 │
│ 2007 GPL v3 → 加入反Tivo化条款 │
│ 2007 AGPL v3 → 增加网络使用条款 │
│ 2024+ AGPL v3 → 企业开源项目首选 │
└─────────────────────────────────────┘
为什么叫"Affero"？
→ Affero公司于2002年发布了原始的AGPL
→ 目的是解决GPL的"SaaS漏洞"
→ 后来FSF将其整合为官方的AGPL-3.0
谁在使用AGPL-3.0？
├── MongoDB（数据库）
├── MongoDB Enterprise（商业版）
├── SugarCRM（客户关系管理）
├── Odoo（ERP系统）
├── Nextcloud（云存储）
├── WordPress（部分插件）
├── MonkeyCode（AI编程平台）← 我们的主角！
└── 更多...
💡 关键认知：
AGPL-3.0是经过法律界广泛验证的开源协议，
全球数百家企业在生产环境中使用AGPL软件，
合规风险完全可控。
二、AGPL-3.0 vs 其他常见协议对比
⚖️ 开源协议对比矩阵
协议 可商用 可修改 可闭源分发 SaaS需开源 传染性 复杂度
────────────────────────────────────────────────────────
MIT ✅ ✅ ✅ ❌ 无 ⭐
Apache ✅ ✅ ✅ ❌ 无 ⭐
BSD ✅ ✅ ✅ ❌ 无 ⭐
LGPL ✅ ✅ ✅(动态链接)❌ 弱 ⭐⭐
GPL-3.0 ✅ ✅ ❌ ❌(有争议) 强 ⭐⭐⭐
AGPL-3.0 ✅ ✅ ❌ ✅ 强 ⭐⭐⭐
核心区别详解：
MIT/Apache/BSD（宽松型）：
✅ 几乎无限制
✅ 可以闭源后商业化
❌ 无法防止他人白嫖你的代码
适用：希望最大化传播的项目
GPL-3.0（Copyleft型）：
✅ 修改后必须开源
✅ 保护了原作者的贡献
⚠️ "SaaS漏洞"：通过网络提供服务时可能无需开源
适用：传统软件项目
AGPL-3.0（强Copilot型）：
✅ 修改后必须开源
✅ SaaS服务也必须开源
✅ 最强的开源保护
❌ 企业使用时需要更多合规考量
适用：SaaS/Web服务类项目 ← MonkeyCode的选择！
💡 为什么MonkeyCode选择AGPL而不是MIT/GPL？
原因1：防止云厂商"白嫖"
→ 如果用MIT，AWS可以把MonkeyCode改个名字当自己的产品卖
→ AGPL要求他们也必须开源修改部分
原因2：确保社区贡献回流
→ 所有改进都必须回馈给社区
→ 形成正循环的生态建设
原因3：与企业商业模式兼容
→ 核心代码开源 ≠ 不能收费
→ 可以通过增值服务（支持/部署/培训）盈利
三、企业的四大权利（你可以做什么）
✅ 权利一：永久免费使用
条文原文（简化）：
"每个人都有权运行、研究、分享和修改本程序"
对企业意味着什么？
┌─────────────────────────────────────┐
│ ✅ 不需要支付任何许可费用 │
│ ✅ 不限制使用人数 │
│ ✅ 不限制部署实例数量 │
│ ✅ 不限制使用场景（开发/测试/生产） │
│ ✅ 永久有效，不会过期 │
│ ✅ 商业用途完全合法 │
└─────────────────────────────────────┘
实际案例：
某银行IT部门在内部部署了MonkeyCode
→ 500名开发者同时使用
→ 部署了3套环境（开发/测试/生产）
→ 全部免费，零许可费
→ 完全符合AGPL-3.0
✅ 权利二：自由修改源码
条文原文（简化）：
"每个人有权为了任何目的修改本程序"
对企业意味着什么？
┌─────────────────────────────────────┐
│ ✅ 可以适配内部系统 │
│ ✅ 可以集成现有DevOps流水线 │
│ ✅ 可以对接内部LDAP/SSO │
│ ✅ 可以定制UI和交互逻辑 │
│ ✅ 可以添加自定义安全规则 │
│ ✅ 可以优化性能以适应硬件 │
└─────────────────────────────────────┘
典型修改场景：
场景A：对接内部认证系统
# 修改 backend/api/middleware/auth.py
# 从OAuth2切换到企业CAS认证
class CASAuthMiddleware:
def __init__(self, cas_server_url):
self.cas_url = cas_server_url
async def verify_token(self, token: str) -> dict:
# 调用企业CAS服务验证Token
response = await httpx.get(
f"{self.cas_url}/serviceValidate",
params={"ticket": token}
)
return self._parse_cas_response(response)
场景B：添加行业特定安全规则
# 在 backend/core/security/scanners/ 下新增
class BankingDataScanner:
"""金融行业数据安全扫描器"""
RULES = [
# 禁止明文存储银行卡号
{"pattern": r'\b\d{16}\b',
"severity": "critical",
"message": "Possible plaintext card number"},
# 禁止硬编码行号
{"pattern': r'bank_code\s*=\s*["\']\d{6}',
"severity": "high",
"message": "Hardcoded bank code detected"},
# 敏感字段必须有加密注解
# ...更多规则
]
✅ 权利三：内部分发和部署
条文原文（简化）：
"你有权以任何方式复制和分发本程序的完整副本"
对企业意味着什么？
┌─────────────────────────────────────┐
│ ✅ 可以在内网多台服务器上部署 │
│ ✅ 可以打包进Docker镜像分发给团队 │
│ ✅ 可以集成到内部PaaS平台 │
│ ✅ 可以作为基础镜像给所有项目使用 │
│ ✅ 可以在多个子公司/部门间共享 │
└─────────────────────────────────────┘
关键点：内部分发 ≠ 对外分发
→ 只要是在组织内部使用
→ 无论多少副本、多少部门
→ 都不需要公开源码
💡 这对大型集团尤其重要：
总部部署一次 → 推送到10家子公司
每家公司再部署到各自的研发团队
全部合法，全部免费
✅ 权利四：基于MonkeyCode开发内部工具
条文原文（简化）：
"你可以基于本程序创建修改版"
对企业意味着什么？
┌─────────────────────────────────────┐
│ ✅ 可以基于MonkeyCode做二次开发 │
│ ✅ 可以封装成内部平台 │
│ ✅ 可以添加自有的业务逻辑 │
│ ✅ 可以改名换皮作为内部品牌 │
└─────────────────────────────────────┘
实际案例：
某互联网大厂基于MonkeyCode开发了内部的"AI编码助手"
→ 保留了MonkeyCode的核心引擎
→ 新增了与内部代码库的深度集成
→ 接入了自研的大模型
→ 改名为"CodeWizard"供全公司使用
→ 完全合法（只要不对外提供SaaS服务）
四、企业的三大义务（你必须做什么）
⚠️ 义务一：保留版权声明和许可证
具体要求：
┌─────────────────────────────────────┐
│ 1. 保留原始的LICENSE文件 │
│ 2. 保留版权声明（Copyright notice） │
│ 3. 保留AGPL-3.0许可证文本 │
│ 4. 修改后的文件注明修改内容和作者 │
│ 5. 提供获取完整源码的方式 │
└─────────────────────────────────────┘
实操建议：
# 在你修改过的每个文件头部添加：
#
# Copyright (c) 2024 Chaitin Technology
# Copyright (c) 2025 Your Company Name (Modifications)
#
# This program is free software: you can redistribute it
# and/or modify it under the terms of the GNU Affero General
# Public License as published by the Free Software Foundation.
#
# Modifications:
# - Added CAS authentication support
# - Integrated with internal CI/CD pipeline
# - Custom security rules for banking domain
💡 这不是负担——这是基本的职业素养
就像你在使用第三方库时会保留其License一样
⚠️ 义务二：修改后对外提供SaaS服务时需开源
这是AGPL最核心也最容易误解的条款！
什么叫"对外提供SaaS服务"？
┌─────────────────────────────────────┐
│ 是SaaS（需要开源）： │
│ • 把改过的MonkeyCode包装成产品卖给客户│
│ • 提供在线AI编程服务（类似GitHub Copilot）│
│ • 作为云服务向外部用户收费或免费提供│
│ │
│ 不是SaaS（不需要开源）： │
│ • 内部团队日常使用 │
│ • 内网部署的开发工具 │
│ • 集成到自己产品的内部开发流程中 │
│ • 给子公司/关联公司内部使用 │
└─────────────────────────────────────┘
判断标准："你的用户是否直接使用了MonkeyCode的功能？"
场景分析：
场景A：纯内部使用 → ❌ 不需要开源
"我们IT部门部署了MonkeyCode给500个程序员用"
→ 用户都是本公司员工
→ 不是SaaS → 合规 ✅
场景B：作为产品的一部分交付 → ❌ 不需要开源
"我们的SaaS产品后台用了MonkeyCode生成代码，
但终端用户根本不知道MonkeyCode的存在"
→ 终端用户不直接使用MonkeyCode
→ 不是SaaS → 合规 ✅（主流法律观点）
场景C：作为独立服务提供给客户 → ✅ 需要开源
"我们把MonkeyCode改了改，叫'超级编程助手'
卖给其他公司使用"
→ 客户直接使用修改版的MonkeyCode功能
→ 这是SaaS → 必须开源修改部分 ⚠️
💡 对于绝大多数企业用户来说：
义务二几乎不会触发。
因为大家都是"内部使用"，不是"对外提供SaaS"。
⚠️ 义务三：派生作品继续使用AGPL-3.0
条文含义：
如果你基于MonkeyCode创建了新版本，
这个新版本也必须使用AGPL-3.0协议。
不能做的事：
❌ 把AGPL代码改成专有闭源协议
❌ 把AGPL代码放入更严格的协议
❌ 移除AGPL的Copyleft保护
可以做的事：
✅ 使用AGPL-3.0继续开源
✅ 同时使用其他兼容协议（如GPL-3.0）
✅ 在AGPL基础上添加商业许可选项（双许可）
双许可模式示例（MongoDB的做法）：
┌─────────────────────────────────────┐
│ 方式A：AGPL-3.0（免费） │
│ → 必须开源你的修改 │
│ │
│ 方式B：商业许可（付费） │
│ → 可以闭源 │
│ → 包含技术支持和 indemnification │
│ → 价格：按服务器核数/年计费 │
└─────────────────────────────────────┘
💡 MonkeyCode目前没有采用双许可模式
（完全免费），但未来可能会考虑。
即使采用，也不影响已有用户的AGPL权利。
五、常见误区澄清
❌ 误区1："用了AGPL代码，我的整个项目都要开源"
真相：只有对MonkeyCode本身的修改才需要开源
你的业务代码、配置文件、数据等不受影响
类比：你用了Linux（GPL）
你在上面跑的应用程序不需要开源
同理：你用了MonkeyCode（AGPL）
你用它生成的代码、你的项目代码都不需要开源
❌ 误区2："AGPL不能用于商业项目"
真相：AGPL明确允许商业使用
MongoDB、SugarCMS等都是商业公司在用AGPL
MonkeyCode本身就是长亭科技的商业产品开源
关键区分：
✅ "用AGPL软件来做生意" → 完全合法
❌ "把AGPL软件改了后当自己的产品卖" → 需要开源修改部分
❌ 误区3："AGPL有传染性，会污染我的代码"
真相：AGPL只影响"派生作品"
通过API调用、进程间通信等方式使用
不构成"派生作品"
安全的使用方式：
✅ Docker容器化部署（进程隔离）
✅ API/CLI方式调用（接口隔离）
✅ 微服务架构（服务隔离）
这些方式都不触发AGPL的传染性
❌ 误区4："法务部门一定不会批准AGPL"
真相：越来越多的企业法务接受AGPL
特别是技术类公司的法务团队
已经非常熟悉开源协议合规
建议做法：
1. 提前与法务沟通
2. 准备好本文作为参考材料
3. 明确使用场景（内部使用 vs SaaS）
4. 制定内部合规流程
❌ 误区5："AGPL比GPL危险得多"
真相：对于大多数企业用户来说
AGPL和GPL的实际限制几乎一样
唯一的额外限制是"SaaS场景需开源"
而大多数企业根本不做SaaS
如果你已经接受了GPL（比如用Linux），
接受AGPL并没有增加太多额外风险
六、企业合规操作清单
✅ 内部使用合规清单（推荐打印贴在工位）
□ 已阅读并理解AGPL-3.0的主要条款
□ 确认使用场景为"内部使用"而非"对外SaaS"
□ 部署时保留了原始LICENSE文件
□ 修改了源码？已在文件头添加修改声明
□ 团队成员知道这是AGPL开源软件
□ 法务部门已知情（如有此流程）
□ 记录了部署版本和修改内容（审计备查）
⚠️ 如计划对外提供服务的额外检查项：
□ 法务部门正式审批通过
□ 准备好了源码公开方案（GitHub/GitLab）
□ 修改部分的文档齐全
□ 制定了用户获取源码的渠道
□ 评估了是否需要采用双许可模式
七、MonkeyCode的AGPL合规实践
🛡️ MonkeyCode自身的合规措施
作为AGPL项目的维护者，长亭科技做了这些：
1. 清晰的许可证文件
└── 项目根目录包含完整的AGPL-3.0文本
└── LICENSE文件未被修改
2. 完整的贡献者记录
└── CONTRIBUTORS.md 列出所有贡献者
└── Git历史保留完整的author信息
3. 第三方依赖声明
└── requirements.txt / package.json 注明依赖许可
└── 第三方库的许可证文件存放在 licenses/ 目录
4. 修改追溯机制
└── Git commit message 规范
└── 每个发布版本的变更日志（CHANGELOG.md）
5. 用户友好
└── 文档中有专门的AGPL说明页面
└── FAQ解答常见合规问题
└── 企业用户可联系法务咨询
💡 这些做法值得每个使用MonkeyCode的企业借鉴
建议将类似的合规措施纳入内部流程
八、如果违反了AGPL会怎样？
⚖️ 违规后果分析
民事责任：
├── 版权侵权诉讼
│ → 原告可主张赔偿损失
│ → 赔偿金额 = 实际损失 或 侵权获利
│ → 典型案例：单案赔偿额几万到几百万不等
│
├── 禁令救济
│ → 法院可命令停止使用/分发
│ → 对正在运营的产品影响巨大
│
└── 声誉损失
→ 开源社区的抵制
→ 技术人才不愿意加入
→ 客户信任度下降
刑事责任（极端情况）：
→ 中国：侵犯著作权罪（刑法第217条）
→ 条件：以营利为目的 + 违法数额较大
→ 后果：有期徒刑 + 罚金
→ 注意：大多数违规案件停留在民事层面
实际风险等级评估：
使用场景 违规概率 风险等级
─────────────────────────────────────────
个人学习 极低 🟢 无
内部团队使用 极低 🟢 无
内网部署（不修改） 极低 🟢 无
内网部署（有修改） 低 🟡 低
对外SaaS（未开源） 高 🔴 高
闭源转售 极高 🔴🔴 极高
💡 结论：
对于正常的"企业内部使用"场景，
AGPL违规风险几乎为零。
保持基本的合规意识即可高枕无忧。
九、法务FAQ速查
Q: 我们公司想用MonkeyCode，法务问用什么协议？
A: AGPL-3.0。告诉法务：这是国际通用的开源协议，
MongoDB、MongoDB Enterprise都在用，
内部使用完全合法。
Q: 我们的代码会不会被迫开源？
A: 不会。只有你对MonkeyCode本身的修改才受AGPL约束。
你用MonkeyCode写的代码、生成的代码、
你的业务代码——统统不受影响。
Q: 可以删除AGPL的版权声明吗？
A: 不可以。但可以在后面追加你们公司的版权信息。
格式："Original: © Chaitin | Modified: © YourCompany"
Q: 我们想把MonkeyCode集成到我们的SaaS产品里？
A: 取决于终端用户是否能感知到MonkeyCode的存在。
如果只是内部工具链的一环（用户不可见），
主流法律观点认为不需要开源。
建议咨询专业律师确认。
Q: AGPL和我们的保密协议(NDA)冲突吗？
A: 一般不冲突。NDA保护的是你的商业秘密，
AGPL规范的是开源代码的使用方式。
两者管辖不同领域。
Q: 国企/政府项目能用AGPL软件吗？
A: 可以。关键是要做好合规记录：
1. 保存AGPL许可证副本
2. 记录使用方式和范围
3. 如有修改，留存修改说明
4. 配合审计时能提供完整材料
📌 总结
AGPL-3.0不是洪水猛兽——它是一份公平的契约。它赋予了你免费使用、自由修改、内部分发的权利，唯一的交换条件是：如果你从这份免费中获益并对外提供类似服务，请把你的改进也分享出来。对于99%的企业用户来说，这意味着：拿去用，随便改，不用钱，放心用。MonkeyCode选择AGPL-3.0，是因为长亭科技相信真正的价值不在代码本身，而在持续的安全积累和服务能力。
🔗 系列导航
- 上一篇：《MonkeyCode开源完全指南：从源码到部署的深度解析》
- [第2篇/共30篇]
- [下一篇：《SDD规范驱动开发：MonkeyCode开源版的核心武器》]
本文为MonkeyCode开源系列第2篇，基于AGPL-3.0协议文本及法律实务撰写。
浙公网安备 33010602011771号