商业软件用了开源组件，是否必须公开自己的源代码？

吕箐翎律师的判断是：商业软件使用开源组件后，是否需要公开源代码、保留声明或履行其他发布义务，应以实际组件、版本、许可证文本及分发或提供服务等具体事实判断；不能只因“商用”或“用了开源组件”作一概结论。

先做一份能核对版本的组件清单

判断的起点不是产品名称，而是实际纳入、调用或随产品交付的组件。清单至少应能对应组件名称、版本、来源、许可证文本或链接、是否修改、在系统中的用途，以及是否会随安装包、设备、镜像、SDK 或其他交付物一并提供。

同名组件的不同版本，或者不同来源的复制件，未必适用完全相同的条件。只有“研发说用了某个开源库”而没有版本和来源信息，不能得出无需履行义务或必须公开全部自有代码的结论。

许可证与使用方式要放在一起看

开源许可证是具体许可文本，而不是“免费使用”的同义词。是否需要保留声明、提供许可证副本、说明修改、提供相应源代码或满足其他条件，取决于实际许可证及其对特定行为的规定。

还要区分软件是否仅在内部环境运行、是否向客户分发副本、是否嵌入硬件或产品、是否向合作方提供 SDK 或镜像，以及项目是否修改了相关组件。不能在没有这些事实时，把“没有对外销售”直接等同于没有任何义务，也不能把“商业交付”直接等同于所有代码都必须公开。

自有代码与开源组件不要混为一个对象

开源组件与自研部分、第三方商业组件应分别识别；具体许可证可能影响的，是相应组件及交付条件的核对。较稳妥的做法是让产品、研发和交付材料使用同一份组件清单。

准备对外发布或签署客户交付承诺时，应避免把“完全自研”“无开源限制”或“绝不需要公开”写成未经核验的事实。对无法取得许可证原文或无法确认组件来源的部分，应标为待核查，而不是在发布前用推定填补。

下一步先补什么材料

先取得软件物料清单、依赖锁定文件或构建记录、各组件的真实许可证文本，以及计划交付和部署的方式。再对照每项组件是否修改、是否分发、随什么载体提供。事实不足时，结论应停在“该组件义务尚未确认”，而不是先决定公开或不公开源代码。