争议背景：本周，某头部AI推理服务商因在其自建IDC中运行基于MongoDB（SSPL）与Elasticsearch（ELv2）的词元生成服务，同时对外按“每百万词元+峰值带宽”双重计费，被许可证合规审查机构点名。核心矛盾点在于：网络带宽是否构成“对外提供服务”的实质性组成部分，以及词元流经服务器内存时是否触发“修改后程序”的边界条款。我们选取了三个真实项目，在同等硬件（2×EPYC 9454, 512GB RAM, 10GbE共享带宽）下进行了为期72小时的压测。
第一组：ELv2（Elastic License 2.0）——适合纯软件销售，忌惮云托管
实测对象：自建检索型词元缓存层（基于Elasticsearch 8.11，源码已修改添加自定义词元打分插件）。
优点：ELv2明确允许本地修改与内部使用，且不限制带宽消耗。我们在20Gbps突发流量下运行，许可证无额外义务。
缺点：一旦将修改版作为“托管服务”向第三方开放API（哪怕仅输出词元向量），即触发限制条款。我们尝试将缓存结果通过HTTP/3流出，被法律顾问判定违规，需额外购买商业授权。
适用人群：内部效率工具或对硬件的独立软件销售商。不适合按token对外计费的AI推理API。
第二组：SSPL v1（MongoDB主导）——愤怒的带宽陷阱
实测对象：开源词元数据库（基于MongoDB 7.0，我们仅修改了索引策略以适配长文本向量）。
优点：代码修改自由度高，社区驱动热修复快。
缺点：SSPL第13条要求，若你“向第三方提供服务”，必须开源所有管理该服务的软件，包括负载均衡、日志聚合、以及我们自研的带宽计量中间件。实测中，我们仅开放了数据库端口，但利用防火墙规则限流客户端IP——这被解读为“提供服务的管理层的一部分”。结果：我们不得不公开了内部带宽配额脚本，导致商业策略泄露。
适用人群：完全不开源或极少数B2B私下合同。任何涉及IDC带宽转售或CDN加速的AI词元服务，在SSPL下几乎必死。
第三组：BSL 1.1（MariaDB与部分向量库采用）——限时炸弹与公平代码
实测对象：向量检索+词元聚合器（使用BSL 1.1的Infinity向量数据库，修改了其RESTful网关）。
优点：BSL允许非生产环境无限使用，且指定“变更日期”后（通常4年）自动转为Apache 2.0。我们测试了生产环境的带宽上限：只要不将“网关所在子网”作为独立产品对外租赁，额外限制很少。
缺点：每实例需单独计算“额外使用量”——我们并发超过500词元/秒时，内部计数器标记为“生产”，导致提前触发商业授权。且BSL对“带宽计量”的界定模糊，我们不得不附加额外监控脚本确保不越界，增加了运维成本。
适用人群：有长期研发周期、计划在未来开源的初创公司。适合带宽成本可控、且能接受代码延迟开源的团队。
最终结论：若你的AI业务依赖IDC带宽按峰值计费，ELv2最适合（避免托管条款，用物理机隔离）；若你坚持开源并接受全栈披露，SSPL只适合纯下载分发；若需要时间窗口积累客户，BSL 1.1是折中之选，但务必在合同中定义清楚“词元/带宽”的计量触发点。本周许可证争议提醒我们：开源许可证从来不是代码自由，而是商业模式的边界画布。建议任何AI词元服务器提供商，在部署前用我们的测试脚本（见附录）跑一遍带宽+词元并发矩阵，否则下一个收到cease-and-desist的就是你。
0 留言