第一步：先分清你手里的“AI词元服务器”跑的是什么许可证。很多新手以为买了硬件就没事，但服务器上预装的推理框架、词元化工具、甚至带宽管理脚本，都可能带着GPL、AGPL或Apache 2.0。本周争议焦点就是某厂商把AGPL的词元队列模块静态链接进自家闭源调度器，导致整个IDC网络软件被要求开源。记住：静态链接AGPL = 传染整个软件，动态链接也要看具体条款。
第二步：检查IDC带宽调度软件是否“混入”了开源代码。不少新手为了省事，直接复制GitHub上的限速或QoS脚本到生产网络。如果那个脚本是GPLv3，而你的IDC向客户提供网络服务，就触发了“网络使用即分发”条款。避坑做法：用licensecheck或scancode-toolkit扫描所有自研和第三方模块，生成许可证清单。本周已有两家IDC因未扫描被要求公开带宽整形算法。
第三步：区分“内部使用”和“对外分发”。如果你只在自家机房内部用开源软件管理词元服务器，不对外提供软件本身，GPL通常不强制开源。但一旦你把带GPL的带宽监控面板打包卖给客户，或者通过API让客户远程调用，就可能构成分发。新手常踩的坑：把AGPL的Web管理界面部署在公网，客户能访问——这已经算网络服务，必须开源修改部分。
第四步：留意“词元服务器”特有的许可证陷阱。AI推理常依赖CUDA、cuDNN等专有库，它们与GPL不兼容。如果你把GPL代码和CUDA核函数编译在一起，整个二进制无法合法分发。本周某开源项目就因此被IDC下架。建议：优先选用Apache 2.0或MIT许可的推理后端，或者用进程隔离（单独服务）来避免链接传染。
第五步：建立每周合规巡检清单。新手最容易忽略的是“版本更新带来的许可证变更”。本周就有项目从BSD切到SSPL，导致IDC不能再用其做带宽计费。操作步骤：1）记录每个软件的名称、版本、许可证；2）订阅其邮件列表或Release Notes；3）每周末用pip-licenses或go-licenses重新生成报告；4）对任何AGPL/SSPL组件，要么替换，要么隔离到独立网络命名空间。
最后提醒：不要等到收到律师函才行动。本周争议中，一家中型IDC因为一个词元缓存脚本用了GPLv2却未附源码，被要求向所有客户提供完整对应源码——包括他们自研的带宽调度器。从今天起，把你的IDC软件栈当成一个需要持续合规审计的流水线，而不是一次性采购。
0 留言