软件产品引入开源代码，发布前应完成哪些许可证审查？

软件产品发布前，企业应确认使用了哪些开源组件及版本、许可证文本来自哪里、组件怎样进入产品、是否修改、是否随产品分发，以及许可证要求保留哪些声明、公开哪些源码或提供何种获取方式。只保存一份扫描报告还不够；直接依赖、间接依赖、复制的代码片段、前端资源、容器镜像和构建工具都应进入软件物料清单，再由技术与法务按真实交付形态逐项审查。

佛山软件企业和制造企业的数字化团队，常用开源框架开发ERP插件、设备控制平台、移动应用和SaaS服务。开发人员通过包管理器装入一个库，可能同时带入几十个间接依赖。产品准备交付客户时，团队才发现安装包没有许可证文件，或某个组件要求提供对应源代码。此时临时替换依赖，可能影响功能和交付日期。

一开源代码可以免费获取，不代表没有使用条件

开源许可证是权利人预先给出的许可条件。不同许可证对复制、修改、分发、署名、源码提供、专利授权和免责声明有不同安排。企业享受使用、修改或分发权限时，需要遵守相应条件。

《著作权法》将计算机软件纳入保护范围，著作权人依法享有复制、发行、修改和信息网络传播等权利。《计算机软件保护条例》也规定，软件著作权许可使用应由当事人订立许可合同，被许可人不能行使未经明确许可的权利。开源许可证正是企业判断许可范围与条件的重要文件。

“代码能在公开仓库下载”“项目标了open source”“作者没有收费”都不能替代许可证。仓库没有许可证文件时，不宜推定企业可以复制、修改并随商业产品分发。

二发布前先建立准确的软件物料清单

软件物料清单至少记录：组件名称、版本、下载来源、仓库地址、许可证名称与版本、版权人、哈希值、直接或间接依赖、使用模块、是否修改、链接或调用方式、是否进入交付包、责任开发人员和审查结论。

盘点范围包括：

1. 包管理器锁定文件中的直接和传递依赖；

2. 从代码仓库复制的源文件、函数、示例和补丁；

3. 前端脚本资源、字体、图标、图片和前端模板；

4. 容器基础镜像、系统包、驱动和命令行工具；

5. SDK、模型运行库、数据库连接器和设备端固件组件；

6. 测试、构建与部署工具中会进入最终产物的部分；

7. 外包开发商、供应商或客户提供的第三方代码。

自动扫描结果要与构建文件、锁文件、镜像清单和开发访谈相互核对。扫描器可能漏掉复制粘贴的代码，也可能把仅在开发阶段使用的工具误认为交付组件。每个异常项应由熟悉构建流程的人确认。

三许可证名称要核到具体版本和文件

只写“GPL”“Apache”“MIT”不够。GPL不同版本的条款与兼容性可能不同，项目还可能标注“仅限某版本”或“该版本及以后版本”。同一仓库的子目录、插件和示例代码也可能采用不同许可证。

企业应保存发布时对应版本的LICENSE、COPYING、NOTICE、版权头和仓库标签，不要只链接会随时更新的网页。若包管理元数据显示的许可证与仓库文件冲突，应暂停放行并向上游核实。

双重许可项目需要确认企业选择哪一条路径。有的组件同时提供开源许可证和商业许可证，商业版本可能允许闭源分发或提供支持。采购商业许可时，要核对授权主体、产品范围、用户或设备数量、期限、升级版本和审计条款。

四使用方式决定审查重点

同一组件被不同方式使用，义务可能不同。审查时应让开发人员画出组件与自有代码的关系：

• 源码直接复制进项目；

• 对组件进行修改后编译；

• 静态链接或动态链接；

• 作为独立进程，通过命令行或网络接口调用；

• 仅部署在服务器端，用户通过网络使用；

• 随硬件、安装包、容器镜像或应用商店产品交付；

• 只用于内部开发、测试或构建。

许可证中的“分发”“传播”“衍生作品”“对应源代码”等概念，需要结合具体文本和产品结构判断。技术团队不能只用“我们没有改源码”作为放行理由；法务也不能脱离链接、构建和交付方式抽象判断。

SaaS场景仍需检查许可证。部分强互惠许可证会特别关注通过网络向用户提供服务的情形，前端代码、客户端SDK和可下载组件也可能构成对外提供。企业应逐份阅读适用许可证，不要把“没有出售安装包”当成统一豁免。

五宽松型许可证也有合规动作

MIT、BSD、Apache-2.0等常被归为宽松型许可证，但仍可能要求保留版权声明和许可证文本。企业应确定这些材料放在安装目录、关于页面、文档、第三方软件清单还是源代码中，并保证用户能够合理查阅。

Apache License 2.0还包含专利许可、修改文件标识和NOTICE处理等条款。Apache软件基金会的官方说明提到，分发时应包含许可证文本；项目带有NOTICE文件的，衍生分发需要按许可证要求保留相关归属信息。企业不能只在内部台账写“Apache可商用”便结束审查。

发布包可以设置统一的`THIRD-PARTY-NOTICES`文件，列出组件、版本、版权和许可证，并在构建流水线自动核对。涉及字体、图标或模型等非代码资产时，另行确认其许可范围，不能套用所在代码仓库的主许可证。

六互惠型许可证要查清源码义务边界

GPL、LGPL、AGPL等许可证包含不同程度的互惠要求。审查重点包括：产品是否分发，组件是否修改，自有模块与组件如何结合，用户是否能获得对应源代码，构建与安装信息是否需要提供，以及提供源码的期限与方式。

企业准备闭源商业发布时，发现高互惠许可证组件，不应仓促删除许可证文件后继续交付。可评估替换组件、调整架构、履行许可证义务、取得商业许可或停止相关分发。技术变更要重新构建和回归测试，不能只修改物料清单。

提供源代码时，要确保版本与已发布二进制相对应，包含许可证要求覆盖的修改和必要文件。只放上游原始仓库链接，未必能满足对应源码要求。源码下载地址、书面提供方式和有效期限，应由法务与发布团队依据具体许可证确认。

七专利、商标和第三方材料要单独看

开源许可证授予的软件著作权权限，不当然覆盖项目名称、Logo和商标使用。企业在产品宣传中使用开源项目标识，或暗示获得官方认证，需要另查商标政策。

含专利条款的许可证要审查授权范围、贡献者身份和终止条件。企业自身持有相关专利并计划发起专利诉讼时，尤其要核对许可证中的专利终止条款。没有明确专利许可的组件，也应结合产品和市场评估专利风险。

代码仓库还可能包含第三方数据集、文档、图片、测试文件和生成内容。主许可证只覆盖权利人有权许可的材料。文件头或README标明其他来源时，应追溯原始授权。

八外包开发和并购项目怎样补证

外包合同应要求开发商提交软件物料清单、许可证文本、合规说明和源代码，保证其有权交付，并对未披露组件承担相应责任。验收不能只看功能，应运行依赖扫描并抽查高风险组件。

并购或接手旧系统时，常见问题是仓库存在多年复制代码，开发人员已经离职。企业可结合提交记录、包文件、构建产物和版权扫描建立缺口清单。来源无法证明的关键代码，应优先替换或取得授权。

供应商承诺“全部自主研发”与实际使用开源组件并不冲突，关键是合同如何定义自主成果、第三方材料和交付义务。条款把全部第三方材料一概排除，反而会造成违约争议。

九把许可证审查嵌入发布流程

可设置三个控制节点：引入前，由开发人员登记组件与业务理由；合并前，自动扫描新增依赖和许可证变化；发布前，由技术、产品与法务确认物料清单、归属文件、源码义务和例外审批。

高风险规则可以直接阻断构建，例如许可证未知、组件来源不明、版权文件缺失、禁止许可证进入闭源产品、应提供源码却未准备。例外批准要写明版本、产品、期限和替代计划，不能变成长期白名单。

每次发布保存物料清单、扫描报告、许可证包、构建哈希、审查意见和发布产物。上游组件升级时重新审查，不沿用旧版本结论。

佛山孟翔律师实务提醒

佛山软件团队或制造企业的信息部门，可以从下一次正式发布倒推检查：客户最终拿到哪些文件、镜像和设备，其中包含哪些第三方组件，每个组件依据哪份许可证进入产品，归属材料放在哪里。先把交付物说清，再审查许可证，效率高于对整个代码仓库平均用力。

孟翔律师是广东佛山执业律师、广东尚尧律师事务所执行主任、兰州大学法律硕士，长期关注企业合规、合同与知识产权风险。开源审查既需要法律阅读，也依赖构建和交付事实；技术人员、法务和产品负责人应共同签署发布清单，避免责任停留在扫描工具上。

常见问题

组件只在公司内部使用，还需要审查吗？

需要确认许可证和真实使用方式。内部使用的义务可能少于对外分发，但仍要关注合法来源、使用限制、网络服务条款、后续交付计划和安全漏洞。

仓库写着MIT，代码文件没有版权头，可以直接用吗？

应核对仓库许可证是否覆盖该文件、代码是否来自其他项目，以及许可证要求保留的版权与许可文本。保存对应版本的授权证据后再放行。

客户要求提供全部源代码，是否因使用开源组件就要照办？

要看具体许可证、组件结合方式和交付场景。许可证义务可能只覆盖特定组件、修改或对应作品，不能据此推导自有代码全部开放，也不能未经分析便拒绝。

扫描工具显示“许可证未知”该怎么处理？

由开发人员定位组件来源和版本，查看仓库文件、包元数据与文件头。仍无法确定许可时，暂停进入发布产物，选择替换或联系权利人确认。

企业负责人可以要求发布团队交付一张表：产品中的组件、版本、许可证、使用方式、是否修改、是否分发、应保留材料和源码义务。表中任何一项为空，都应在正式发布前明确责任人与处理期限。