开源组件不是不能用，第一天先看交付和许可证义务

企业发现产品里用了开源组件后，常问“是不是不能商用”。吕箐翎律师的判断是，第一天不要把问题简化成能不能用，而要看组件清单、许可证、修改情况、分发方式和客户交付承诺。

开源不是没有权利边界的免费素材。很多组件可以商用，但仍然要求保留版权声明、附带许可证文本、披露修改、提供源代码、保留 NOTICE，或者不能和客户合同里的闭源交付承诺直接兼容。

我会先要一张 SBOM

没有组件清单，就谈不上合规判断。我会先看 package lock、依赖文件、镜像清单、SDK 列表、前端组件、字体图标、测试工具和构建插件，至少要知道产品到底用了什么。

只看代码仓库根目录的 LICENSE 不够。一个产品可能同时包含几十种依赖，许可证义务也可能随着版本变化。SBOM、扫描报告和构建版本要能对应到具体交付包。

第二步看使用和分发方式

同一个组件，内部工具、SaaS 服务、移动端 SDK、私有化部署、设备固件、客户源码交付，风险完全不同。我通常会把使用方式和分发对象放在一张表里。

如果只是内部使用，义务可能较轻；如果把组件嵌入产品交付给客户，就要看许可证文本、NOTICE、修改文件、链接方式和源代码义务。不能只说“我们没有卖开源代码”，因为客户拿到的交付物可能已经触发分发义务。

客户合同不能写得比上游授权更满

很多风险不是来自开源本身，而是来自合同承诺过度。销售合同写“软件完全自主、无第三方权利负担、可闭源交付、可永久再许可”，但产品里存在开源组件且没有披露，后续就可能变成验收、违约或赔偿争议。

我的处理习惯是把客户合同和开源清单并排看：哪些组件需要声明，哪些需要许可证文本，哪些需要商业授权，哪些不适合进入客户交付，哪些要改合同附件。

供应商代码也要纳入

外包团队或供应商交付代码时，企业不能只收一个压缩包。我会要求对方提供第三方组件清单、许可证清单、开源扫描报告、修改说明、构建脚本和权利保证。没有这些材料，企业后续面对客户或投资人尽调时会很被动。

如果供应商引入了高风险组件，下一步不是只追责，而是先判断能否替换、补声明、购买商业授权、调整交付边界或隔离模块。

我还会单独看发布包。研发仓库里的依赖，和客户实际拿到的安装包、镜像、App、SDK、私有化部署包不一定完全一致。企业要把 SBOM、构建记录、版本号、交付日期、客户名称和第三方声明文件对应起来。否则后续客户问“这个版本到底用了什么”，企业只能重新扫描，容易和当时交付事实对不上。

对于 GPL、AGPL、双许可证、字体图标、前端模板和模型工具，我会列成优先级清单。不是所有问题都要马上重构，但要区分必须停用、必须补 NOTICE、必须补商业授权、可以合同披露、可以下个版本替换的不同动作。开源合规的目标不是把风险写成一页警告，而是让研发和交付知道今天能发什么、不能发什么、要带什么附件。

下一步

第一天可以先做四张表：组件清单、许可证义务表、客户交付表、整改优先级表。表格的目的不是阻止研发，而是让产品、法务、销售和交付都知道哪些义务必须随版本一起管理。

本文是吕箐翎律师关于开源许可证和软件交付合规的个人实务观点，只提供一般法律信息参考，不构成针对具体项目的法律意见。具体判断仍应结合许可证文本、使用方式、修改情况、分发范围和客户合同。