本周二（8月13日），开源软件托管平台GitHub上爆发了一场关于AGPL-3.0许可证的争论，起因是某IDC（互联网数据中心）厂商在其AI词元服务器的管理固件中，集成了基于AGPL协议的带宽监控库，却未按条款开放其修改后的源代码。这不是孤例——据LF AI & Data基金会的周报，2025年第二季度针对AI基础设施的许可证合规投诉环比上升了47%。对于刚入行的开发者或运维，你可能只想快速搭好一台能跑大模型的服务器，但许可证问题轻则收到律师函，重则导致整个服务被迫下线。下面，我们按‘选、改、发、卖’四个动作，梳理本周的避坑要点。
第一步：选型时，先分清‘传染性’强弱。 本周争议的焦点是AGPL，它比GPL更严格——不仅要求你分发软件时提供源码，还要求你通过网络提供服务时（比如你的AI词元API），也要开放服务端代码。如果你只想内部测试，不对外提供网络服务，AGPL暂时无害；但只要你的服务器一上线，哪怕只是给合作伙伴试用，就触发了‘网络传播’条款。新手建议优先考虑Apache 2.0、MIT或BSD，它们允许你在不开放自身核心代码的前提下商用（但需保留版权声明）。本周新发布的OpenCompute 4.0服务器参考设计，其默认固件采用MIT许可证，就是为了降低AI部署的合规门槛。
第二步：改动时，记录每一行‘借来的代码’。 本周爆料的一起案例中，某团队在带宽调度软件中使用了tc命令的第三方封装库（BSD-3-Clause），但在后续修改中删除了原作者的版权头，导致被原作者投诉。新手最容易犯的错是‘复制粘贴后忘记来源’。建议使用工具如license-checker（npm）或reuse（Python）在CI流程中自动扫描。记住：即使是修改两行，也算‘衍生作品’，必须保留原许可声明。本周GNOME社区发布的《AI依赖清单模板》也强调：每个依赖包都要记录其许可证哈希值，便于追溯。
第三步：发布时，区分‘内部’与‘外部’。 如果你把修改后的AGPL代码做成Docker镜像，只在自己的IDC机房内部使用，不向外部客户提供接口，那不算‘传播’。但本周的争议恰恰在于，那家创业公司将AI词元服务器以‘托管服务’形式卖给游戏公司，这属于‘向第三方提供网络服务’，因此必须公开所有修改后的服务端代码。新手常忽略‘云服务例外’——MongoDB SSPL、Elastic License 2.0等专门针对SaaS场景，而AGPL没有这个例外。所以，如果你计划将软件作为托管服务，最好直接选SSPL或商业许可，否则就要做好开源全部代码的心理准备。
第四步：销售时，警惕‘带宽’相关的间接侵权。 本周一条有趣的新闻：一家提供AI推理API的公司，因在其带宽计费模块中使用了GPLv2的加密库（但通过动态链接绕过），仍被法院判决侵权。因为法官认为‘动态链接’并不改变‘衍生作品’的性质。新手在卖服务器或API时，往往只关注主程序，却忽略了网络层面——比如你用的负载均衡器、流量整形工具，若是GPL且你修改了其源码，同样要开源。建议在采购硬件时，要求供应商提供SBOM（软件物料清单），明确每个固件、驱动、管理工具的许可证。本周Linux基金会发布了新工具sbom-tool v2.0，可以自动生成SBOM，适合入门者使用。
总结与行动清单：本周的教训是，别等收到律师函再后悔。给新手的三个立即动作：1) 用license-sniffer扫描你的服务器镜像，列出所有依赖的许可证；2) 如果发现AGPL或GPL，评估你的部署方式是否构成‘对外服务’；3) 在项目README中建立NOTICE文件，记录所有第三方版权声明。本周四，OSI（开源促进会）将举办线上讲座《AI时代的许可证陷阱》，免费，但需要提前注册。别错过——下一次争议可能就发生在你的机房里。
0 留言