Apache SkyWalking OAP 后端依赖许可证合规治理基于 license-eye 的第三方依赖管理与 LICENSE/NOTICE 维护实战【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sk/skywalkingSkyWalking 作为 Apache 软件基金会ASF的顶级项目其 OAP 后端与 UI 的每一次依赖变更都必须满足 ASF 第三方许可证政策。本文以官方指南 dependencies.md 为主体系统讲解如何使用 license-eye 自动解析依赖、生成许可证摘要、审查兼容性并正确维护LICENSE、NOTICE与licenses/目录帮助贡献者在提交新依赖时一次性通过合规检查。为什么 OAP 后端需要专门的依赖管理适用范围OAP Server 与 UI 的依赖官方文档明确限定该依赖管理章节仅适用于 OAP Server 与 UI 的依赖 This section is only applicable to dependencies of the OAP server and UI.。换句话说Java Agent、浏览器 Agent 等组件的依赖治理并不在本流程覆盖范围内进行依赖合规操作前应先确认新增依赖所属模块。ASF 第三方许可证政策的约束SkyWalking 是 Apache 软件基金会ASF的 Top Level Project因此必须遵守 ASF 的第三方许可证政策ASF 3RD PARTY LICENSE POLICY。其核心约束是新增依赖不得违反该政策必须将新依赖的 LICENSE 与 NOTICE 补充到项目中。这意味着任何引入新第三方库的 PR除了代码审查外还需要完成一轮“许可证合规审查”否则可能影响发布流程。依赖合规的整体工作流将官方指南中的操作步骤归纳为一条可执行流水线安装许可证检查工具license-eye来自 Apache SkyWalking Eyes 项目在仓库根目录运行依赖解析命令生成许可证摘要通过git diff检查LICENSE文件的变更行判断新依赖的许可证是否与 Apache 2.0 兼容对于 Apache 2.0 许可证的新依赖若其带有 NOTICE 文件则将其 NOTICE 内容追加到NOTICE文件中对于非标准 Apache 2.0 许可证的新依赖将其许可证全文复制到licenses/目录。下面逐一展开每个步骤。第一步安装 license-eyelicense-eye是 Apache SkyWalking Eyes 项目提供的许可证检查工具负责自动收集项目全部依赖的许可证信息并生成汇总报告避免人工遗漏。官方指南要求按照该工具的使用文档完成安装例如通过 Go 工具链或预编译二进制方式安装安装完成后需保证license-eye命令可在终端直接调用。第二步解析依赖并生成许可证摘要在仓库根目录执行以下命令license-eye dependency resolve --summary ./dist-material/release-docs/LICENSE.tpl该命令的作用是递归解析项目Maven 多模块 前端 npm 依赖的全部第三方依赖以 LICENSE.tpl 为模板将依赖按许可证类型分组渲染生成完整的许可证汇总文件结果写入 dist-material/release-docs/LICENSE。从模板源码可以看出其渲染逻辑模板通过{{ range .Groups }}遍历“许可证分组”每组输出{{ .LicenseID }} licenses标题再通过{{ range .Deps }}遍历组内依赖每个依赖条目根据regexSplit : .Name -1判断名称格式形如group:artifact的 Maven 坐标输出为https://mvnrepository.com/artifact/{group}/{artifact}/{version} {LicenseID}而单段名称npm 包则输出为https://npmjs.com/package/{name}/v/{version}。{{ .LicenseContent }} Apache SkyWalking Subcomponents: ... {{ range .Groups }} {{ .LicenseID }} licenses The following components are provided under the {{ .LicenseID }} License. {{- if eq .LicenseID Apache-2.0 }} The text of each license is the standard Apache 2.0 license. {{- else }} The text of each license is also included in licenses/LICENSE-[project].txt. {{ end }} {{- range .Deps }} https://mvnrepository.com/artifact/{{ $group }}/{{ $artifact }}/{{ .Version }} {{ .LicenseID }} {{- end }} {{ end }}这里体现了两种许可证材料的组织策略Apache-2.0 组由于 Apache 2.0 许可证全文已在文件头部随{{ .LicenseContent }}输出组内依赖只需列出坐标与许可证标识无需单独存放许可证文件其他许可证组每个依赖都需要在licenses/LICENSE-[project].txt中提供对应许可证全文模板会明确提示该组许可证文本存放位置。第三步审查 LICENSE 差异与许可证兼容性运行解析命令后使用零上下文行差分的 git 比较命令精确查看变更git diff -U0 ./dist-material/release-docs/LICENSE-U0让 diff 只输出发生变化的行便于快速定位新依赖对应的许可证行。审查的核心标准是新依赖的许可证是否与 Apache 2.0 兼容。若许可证不兼容该依赖将无法被合并进项目。从当前仓库已生成的 LICENSE 文件可以看到实际存在的许可证分组可作为兼容性判断的参考样本许可证分组代表依赖当前仓库实例Apache-2.0guava、netty、grpc、jackson、log4j、kafka-clients 等绝大多数依赖BSD-2-Clauseorg.postgresql/postgresqlBSD-3-Clausecom.google.protobuf/protobuf-java、org.antlr/antlr4-runtimeCC0-1.0org.latencyutils/LatencyUtils、org.reactivestreams/reactive-streamsCC0-1.0 and BSD-2-Clauseorg.hdrhistogram/HdrHistogramMITgraphql-java、slf4j-api、checker-qual、graphql-java-toolsMPL-1.1 and LGPL-2.1org.javassist/javassistPublic Domainaopalliance/aopalliancehttps://golang.org/LICENSEcom.google.re2j/re2jBSD-2-Clause带描述变体com.github.luben/zstd-jni可见项目实际依赖覆盖了从宽松许可证Apache-2.0、MIT、BSD到双许可证CC0-1.0 and BSD-2-Clause、MPL-1.1 and LGPL-2.1等多种类型每类都以独立分组形式呈现在 LICENSE 文件中供审查者快速核对。第四步维护 NOTICE 与 licenses 目录Apache 2.0 依赖补充 NOTICE若新依赖采用 Apache 2.0 许可证且自身带有 NOTICE 文件如 gRPC、Netty 等需要将对应 NOTICE 内容追加到 dist-material/release-docs/NOTICE。当前 NOTICE 文件头部为项目自身声明其后按依赖组织 NOTICE 段落例如grpc-java NOTICE、grpc NOTICE、joda-time NOTICE、netty NOTICE、Apache commons-codec NOTICE、Apache Kafka Notice等。这是 Apache 2.0 许可证第 4(d) 条“再分发时保留 NOTICE 声明”的直接落地。非标准许可证依赖补充许可证全文若新依赖不是标准 Apache 2.0 许可证则必须将其许可证文件复制到 dist-material/release-docs/licenses 目录文件命名遵循LICENSE-[project].txt约定如LICENSE-postgresql.txt、LICENSE-antlr4-runtime.txt、LICENSE-slf4j.txt。当前目录已收录 25 个许可证文件覆盖 H2、protobuf-java、graphql-java、okhttp、zstd-jni 等组件LICENSE 模板中“The text of each license is also included in licenses/LICENSE-[project].txt”即指此处。特殊依赖zipkin-lens 的前端依赖LICENSE 文件末尾有一段补充说明zipkin-lens.jar内部还包含更多前端依赖这些前端依赖的许可证单独列于zipkin-LICENSE文件中见 dist-material/release-docs/zipkin-LICENSE。遇到“打包产物内部再携带依赖”的组件时需要同样核查并维护其内部依赖清单这一约定同样记录在 LICENSE.tpl 模板末尾。发布物中的许可证材料assembly 打包上述所有合规材料最终会进入正式发行包。在 apm-dist/src/main/assembly/binary.xml 的fileSet配置中发布物根目录outputDirectory/直接引用了dist-material/release-docs整个目录fileSet directory${project.basedir}/../dist-material/release-docs/directory outputDirectory/ /fileSet因此发行包根目录会包含完整的合规材料集LICENSE # 许可证汇总文件由 LICENSE.tpl 渲染生成 LICENSE.tpl # 汇总文件模板 NOTICE # 各依赖 NOTICE 声明集合 README.txt # 发行版欢迎页与许可说明 licenses/ # 非 Apache-2.0 依赖的许可证全文 zipkin-LICENSE # zipkin-lens 前端依赖许可证清单配合 dist-material/release-docs/README.txt 中的“Licensing”说明指向同目录的 LICENSE 文件最终用户拿到发行包即可完整追溯所有第三方组件的授权信息。依赖变更提交检查清单综合官方指南与仓库实现为贡献者整理如下提交前自检清单确认新增依赖属于 OAP Server 或 UI 模块其他模块不适用本流程已安装license-eye并在仓库根目录执行license-eye dependency resolve --summary ./dist-material/release-docs/LICENSE.tpl用git diff -U0 ./dist-material/release-docs/LICENSE核对新依赖的许可证行确认其许可证与 Apache 2.0 兼容Apache 2.0 且带 NOTICE 的依赖已将 NOTICE 内容追加至dist-material/release-docs/NOTICE非标准 Apache 2.0 许可证依赖已将许可证全文复制为dist-material/release-docs/licenses/LICENSE-[project].txt若依赖内部还携带第三方前端/子组件如 zipkin-lens已同步核查并补充对应许可证说明重新生成后确认LICENSE、NOTICE、licenses/三处材料一致发行包assembly 阶段可正确打包全部合规文件。通过这一套由 license-eye 驱动的流程SkyWalking 贡献者可以在依赖引入阶段就完成许可证合规闭环既满足 ASF 的政策要求也保证发行包的许可证材料完整、可审计。【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sk/skywalking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
