开源许可证商用注意事项

拿来一段开源代码放进商业产品，算不算侵权？答案取决于许可证，而不少团队直到收到律师函，才第一次认真读那份随代码分发的文本。 一、两大流派 开源许可证大体分两类。GPL 这一类带有"传染性"：只要软件分发时包含了 GPL 代码，整个软件就必须以 GPL 协议开源，所谓传染，指许可证义务沿着代码组合的路径扩散。MIT、BSD、Apache 2.0 这一类宽松许可证则允许商用和闭源，基本义务是保留原作者的版权声明和许可证文本。两类之间，就是闭源商业软件能不能自由引用开源代码的分水岭。宽松协议的义务具体到操作层面：把原作者的许可证文本和版权声明随你的软件一起分发，放在安装包或关于页面里让用户能看到，基本就履行完毕。 二、容易踩的几个坑 同一流派内部也有差别。动态链接 GPL 库是否构成衍生作品一直有争议，稳妥的做法是闭源产品避免直接链接 GPL 库。Apache 2.0 比 MIT 多了专利授权条款，对商业产品更友好。还有 AGPL：连通过网络提供服务都算触发开源义务，做在线系统时要格外留意，这是 SaaS 团队最常中招的一条。另外注意，许可证约束的是代码本身，训练数据、模型权重可能附带单独的使用协议，下载时需要一并查看。 三、合规动作清单 工程上可以做的事很具体。建立第三方组件清单，登记每个依赖的名称、版本和许可证。Ubuntu 下可以用 licensecheck 工具扫描源码目录，命令是 licensecheck -r ./src，扫出的结果和清单核对漏项。升级依赖时同步检查许可证有没有变化，从宽松协议换成传染性协议的情况真实存在。团队内部再定一条规矩：新引入任何第三方组件，先查许可证再进主干，事后清理的成本远高于事前一分钟的确认。 四、一句建议 开源不等于免费无义务，许可证就是使用说明书。产品立项时花一个下午做许可证盘点，比事后重构代码、应诉扯皮便宜得多。许可证问题几乎都出在"以为没事"上，盘点做得越早，可选项越多。