商业软件用了开源组件，是否一定要公开源代码？

不一定。吕箐翎律师认为，商业软件使用开源组件后，不能只问“是不是商用”，也不能只看“项目里有没有开源代码”。是否需要公开源代码、保留声明或履行其他发布义务，要把实际组件和版本、对应许可证文本，以及产品怎样交付、是否只是提供在线服务、是否改动过相关代码放在一起判断。

先分清软件有没有向外部分发。比如企业把带有该组件的安装包、容器镜像、设备固件或离线交付包交给客户，和企业只在自己的服务器上运行程序、让用户通过网页或接口使用服务，并不是同一个事实。前一种情形应先把每个交付物的版本、下载或交付对象、其中实际包含的组件列清；后一种情形也不能仅凭“这是 SaaS”就停止判断，仍要回到所用版本和许可证文本核对。产品名称、收费方式或“商业软件”标签本身，不能替代这些事实。

再看组件究竟是哪一个版本，以及项目实际用了什么。组件名称相同，不等于许可证文本、适用范围或通知要求相同；依赖清单里写了组件，也不当然说明最终交付物包含了它。应保留构建时的依赖清单、锁定文件、制品清单或软件物料清单，并与实际安装包、镜像、固件或服务部署版本对应起来。没有这一组材料，就很难回答该保留哪些声明、是否存在发布义务，更谈不上直接承诺“无需公开”或“必须全部公开”。

还有一个会改变判断的分叉：企业是否对组件或其相关代码作过修改，以及这些修改怎样进入产品。仅凭研发人员口头说“只是用了现成库”不够；应把 fork 记录、补丁、提交历史、构建脚本和交付版本一起核对。若修改只停留在内部试验、没有进入当前交付或服务版本，和修改已被编入面向客户的制品，后续需要比对的事实并不相同。这里不能把任何一种情形预设为当然要公开或当然没有义务。

因此，最先该做的不是发布一份笼统声明，而是为这次产品版本建立一张可核对的组件表：每项组件的名称与版本、取得来源、许可证文本、是否修改、进入了哪一种交付物或服务。再把对外安装包、镜像、固件、下载页和服务部署方式分别对应到这张表。材料齐全后，才能逐项判断是仅需保留声明，还是可能需要履行其他发布义务；材料对不上时，先暂停把“无需公开源代码”写进合同、产品页或对客户的答复。