开源项目管理软件许可证怎么看：GPL、AGPL、Apache对企业使用的影响

Black Duck《2026年开源安全与风险分析报告》审计了947个商业代码库，数据采集期为2024年11月至2025年10月。98%的代码库包含开源代码，平均每个应用有1180个开源组件，64%是传递依赖；68%的代码库存在许可证冲突，冲突数量中位数为8个；8%的组件没有检测到许可证。项目管理软件还会叠加插件、二次开发、私有化交付和对外服务，许可证判断不能只看一份LICENSE文件。

许可证义务由四个变量决定：交付形态、修改层级、使用主体、网络交互。把四个变量映射到GPL、AGPL、Apache-2.0的条款，再进入配置管理、变更管理、发布管理和采购验收，才能得到可执行结论。

一、建立许可证影响矩阵

1. 四个变量描述使用场景

交付形态分为内部系统、私有化安装包、容器镜像、SaaS和嵌入自有产品。修改层级分为配置、插件或扩展、内核代码。使用主体分为同一法人、集团关联公司、客户、合作伙伴和外包商。网络交互分为无远程访问、内部远程访问和外部用户访问。

四个变量写成一行，就是许可证影响矩阵的一行。内部部署、仅改配置、同一法人使用、无外部网络交互，义务集中在内部分发和声明留存；容器镜像交付客户、修改内核代码、外部客户使用，进入分发场景；多租户SaaS、修改内核代码、外部用户远程访问，进入AGPLv3第13条。

图1：使用、修改、分发和网络服务对应的许可证义务不同。

2. 以部署单元生成SBOM

代码仓库的许可证扫描不能替代交付物清单。一个部署单元可能包含前端依赖、容器基础镜像、插件、二进制组件和初始化脚本。报告显示，84%的开源组件可通过包管理器和清单文件自动识别，16%需要片段匹配、二进制分析或人工复核；只扫package.json或pom.xml，会漏掉供应商代码、复制片段和传递依赖。

以部署单元生成SBOM，记录组件名、版本、许可证、来源、依赖关系和是否修改。格式可采用SPDX或CycloneDX，输出到制品库并绑定构建号。

二、三类许可证的义务边界

1. GPLv3：分发修改版时提供对应源码

GPLv3允许商用、内部使用和修改。内部修改不对外提供副本，通常不需要公开源代码。把修改版交付客户、合作伙伴，或随安装包、容器镜像、硬件提供，进入分发场景，需要向接收者提供对应源码，并让衍生作品继续使用GPLv3。

对应源码不仅是业务代码，还包括生成、安装和运行目标代码所需的脚本与接口定义。是否构成衍生作品，要看链接、共享内部接口和整体交付关系，不能只按进程边界判断。

2. AGPLv3：修改版加远程网络交互

AGPLv3在GPLv3基础上增加第13条。修改程序后，如果版本支持远程网络交互，要向所有远程用户提供对应源码，允许从网络服务器免费获取。远程用户包括外部客户，也包括通过浏览器或客户端访问的内部员工。

原样部署通常不触发第13条；把原版副本交付客户，仍按分发判断。多租户本身不是触发条件，修改和远程交互才是。

3. Apache-2.0：分发时保留声明

Apache-2.0允许商用、修改、闭源衍生和再分发，通常不要求公开衍生作品源码，也不要求SaaS提供源码。分发时要附许可证副本，保留版权、专利、商标和归属声明，修改文件加显著说明，原有NOTICE随衍生作品提供。它包含专利授权，发起专利诉讼可能导致相关许可终止；商标权不授予。

4. 四类场景对照

四类场景的义务对照如下。

义务差异集中在三个触发点：副本是否交付、是否修改、是否存在远程网络交互。

图2：四类场景下三种许可证的源码与声明义务。

三、项目管理软件的二开与交付

1. 二开按配置、扩展、内核分级

项目管理软件的二开通常落在字段、工作流、权限模型、报表、通知和API集成上。按改动层级分成三类，便于确定审查材料。

A类配置层：改字段、状态机、流程、模板、报表。保留配置导出、版本号和变更记录。

B类扩展层：插件、独立服务、API集成。保留架构图、接口清单、部署边界和插件分发方式。

C类内核层：修改核心代码、共享内部接口、随主程序整体打包。准备对应源码、构建脚本、修改说明和法务意见。

2. 交付物清单决定义务范围

同一套系统，私有化安装包、容器镜像、插件包和SaaS的许可证结论可能不同。交付物清单要列出安装包、镜像、数据库脚本、初始化数据、插件、文档和第三方组件。每个交付物绑定SBOM、许可证、源码获取方式和声明文件。

验收记录同步归档这份清单。

3. 双授权只作为许可选项

例如，禅道开源版采用AGPLv3与ZPL1.2双授权，禅道企业版按合同授权。选择ZPL1.2仍需遵守标志保留和服务告知，双授权不会自动消除义务。

四、嵌入项目流程

1. 立项与选型：许可证准入矩阵

立项阶段确定交付形态、使用主体和网络交互方式，形成许可证准入矩阵。矩阵按交付模式设置，不用一张全局白名单。私有化交付、SaaS、嵌入自有产品分别列出允许的许可证、需要法务审批的许可证和禁止使用的许可证。

角色分工写进项目计划：产品负责人确认交付形态，架构师确认修改层级，法务确认义务，采购确认合同条款，发布经理确认证据包，业务负责人批准。

2. 开发与变更：合并请求检查

在合并请求和CI中加入SCA扫描、SBOM差异和许可证策略检查。新增依赖、升级大版本、替换插件、修改核心代码、改变分发方式，都触发复审。只扫清单文件不够，报告显示16%的开源组件需要更深层的片段或二进制分析，8%的组件没有检测到许可证。

AI生成代码也要纳入同一检查。报告显示，仅54%的组织评估AI生成代码的IP和许可证风险，24%做全面评估。

3. 发布与交付：四类证据

发布基线保留四类证据：许可证文本和版本；部署单元SBOM；对应源码、构建脚本和必要依赖；NOTICE、修改说明和审批记录。源码提供方式写成固定字段，记录下载地址、接收对象和有效期。

每次发布使用独立基线，审查对象是可交付版本，证据包与基线绑定，版本升级后重新生成。

图3：组件清单、许可证核验、源码归档、声明文件和发布检查点。

4. 采购与退出：合同条款

采购合同写明许可证类型和版本、修改与分发权、源码和构建材料交付、第三方及外包责任、赔偿条款、供应商退出和代码托管。验收标准加入SBOM、许可证清单、NOTICE和源码包。退出、并购或停更时按同一清单迁移。

五、FAQ：五个高频边界问题

1. GPL组件打进Docker镜像交付客户，只给Dockerfile够吗？

不够。镜像交付通常构成分发，需要提供对应源码，包括修改代码、构建脚本和必要依赖。Dockerfile只说明构建过程，不等于完整对应源码。

2. AGPL软件不改代码，做多租户SaaS，要给租户源码吗？

第13条针对修改版。原样部署且不向用户交付副本时，通常不因多租户本身触发。修改后让租户远程交互，就要向这些用户提供对应源码。

3. 开源项目管理软件的插件必须和主程序同许可证吗？

取决于插件与主程序的结合方式。独立进程、公开API、独立分发更可能分开；直接链接、共享内部接口、随主程序整体交付则需要审查。保留架构图和构建关系。

4. Apache-2.0项目没有NOTICE文件，交付时要附什么？

附许可证副本，保留版权、专利、商标和归属声明，修改文件加显著说明。没有NOTICE不需要凭空补，但原有声明不能删。

5. GPLv2和GPLv3组件能直接合并吗？

不能默认合并。GPLv2-only与GPLv3或更高版本不自动兼容，需要核对每个组件的版本和兼容条款，必要时由法务判断。