选开源组件时许可证不是附在 README 末尾的装饰。AGPL-3.0 和只约束再分发二进制的许可证不一样它把通过网络提供服务也写进了义务范围。常见理解是如果你修改了程序并通过网络让用户与这个修改版交互通常要向这些用户提供对应源码。这不是开源就可以任意改、任意做成内部平台的同义词。工程上要单独核对三件事。第一你有没有改代码还是只是原样部署上游版本。原样部署和修改后再提供服务义务触发点不同。第二使用者是谁。只在小范围评估和向公司内外用户提供持续服务不是同一件事。第三对应源码准备好了没有。网络条款要的是用户能拿到与线上版本对应的源码而不是仓库里某个旧标签。没做版本对应就算打算遵守也交不出那一份源码。对应源码通常不只是业务仓库的压缩包。构建脚本、修改过的依赖补丁、实际启用的配置生成逻辑只要影响线上行为就应该能和这次发布对上。只归档一个差不多的分支不够。发布流程里可以加一个检查镜像摘要、源码提交号、许可证文本三者一起入库。缺任何一项这次发布就还不能说已经准备好源码义务。内部平台还要分清员工能打开网页和对外售卖服务。前者不一定自动免除义务后者则更不能用内部评估的结论带过。触发条件要以许可证原文为准而不是以产品是否收费为准。免费提供修改版只要用户通过网络交互仍可能落入同一条款。把我们不卖钱写成合规理由是常见的误读。MonkeyCode 仓库标明的许可证是 GNU AGPL-3.0。把它当作需要单独看法务文本的具体例子而不是许可证教程的全部。本文不是法律意见。真正决策前应读许可证原文必要时让法务确认修改范围、网络交互对象以及源码提供方式。可以把它收成选型问题这个服务会不会跑修改版用户是否通过网络使用它对应源码由谁在发布时一起归档。三个答案没写下来之前不要用反正是开源结束讨论。内部评估可以继续但评估记录里应写明还没有做许可证结论。归档时不要只存一个仓库地址。应同时留下该次构建使用的提交号、修改过的补丁和许可证文本副本。线上如果还能热更新脚本热更新也要进入同一份归档否则用户拿到的源码对不上正在跑的服务。内部试用另记范围、是否改过代码、是否已经对外部用户开放。范围扩大到正式服务时要重新核对不能沿用试用记录。若还没有许可证结论工程侧可以继续在隔离环境读代码但不要把试验环境接到真实用户流量上。试验记录里写明日期、镜像摘要和当时的许可证文本版本避免事后无法复现当时的判断。范围、修改和用户是否通过网络使用这三项缺一项就不要进入正式发布。