许可证合规

• AGPL 与传统 GPL 的差异
• 网络服务条款的含义
• 对 SaaS 的影响

AGPL（Affero GPL）是 GPL 的变体，其核心新增条款是"网络服务条款"：传统 GPL 只在"分发"软件时触发 copyleft，而 AGPL 规定即使软件仅通过网络提供服务（如 SaaS 场景，未经分发），只要用户通过网络与软件交互，也必须向其提供源代码。这意味着在 SaaS 产品中若使用 AGPL 组件，服务端代码可能被迫开源，这对靠闭源核心竞争力变现的商用产品是重大风险。工程上需严格规避在核心服务中使用 AGPL 依赖，或在法务确认后可接受的前提下谨慎使用。

AGPL 的"网络服务也触发开源"填补了 GPL 在 SaaS 场景的漏洞，是传染性最强的许可证之一，商用推荐在使用前做严格合规审查。

• Apache 2.0 的专利授权条款
• 商标边界
• 工程影响

Apache 2.0 是宽松许可证，其特点之一是明确的专利授权（patent grant）：贡献者授予使用者使用其专利的权利，且若使用者对贡献者提起专利诉讼，则此授权自动终止（专利报复条款），从而平衡专利风险。同时 Apache 2.0 有商标边界条款：许可证不授予使用 Apache 基金会或项目商标（如 Apache 名称、logo）的权利，使用者不得用其暗示官方背书。工程上，Apache 2.0 适合商用（宽松、可闭源、有专利保护），但需注意商标使用规范与专利报复条款的潜在影响。

Apache 2.0 的专利授权与商标条款使其成为商业友好的宽松许可证，理解这些边界有助于规避专利与商标风险。

• 许可证级联与传递依赖
• 扫描工具的识别与汇总
• copyleft/专利触发时的处理流程

传递依赖的许可证级联指间接依赖的许可证与直接依赖、项目自身许可证叠加后产生的合规影响。扫描工具（如 FOSSA、Licensee、Snyk）通过解析完整依赖树，识别每个直接与传递依赖的许可证并汇总生成合规报告，判断是否与项目许可证冲突。当传递依赖触发 copyleft（如 GPL/AGPL）或专利条款时，处理流程：先定位来源（哪些直接依赖引入）、评估传染范围（是否影响分发/服务）、再由法务判断合规影响，最后选择"替换该依赖、升级到兼容版本、申请豁免或调整项目许可证"等方案，并记录审批结果。

传递依赖可能"悄悄"引入 copyleft，扫描工具负责识别，决策与处置则需法务与工程协同，形成"识别-评估-处置"的闭环。

• GPL 的 copyleft 条款
• 衍生作品的定义
• 工程影响

GPL（General Public License）的 copyleft（传染性）指：若你基于 GPL 代码制作衍生作品（derivative work），则整个衍生作品必须以 GPL 许可发布，即"你用了 GPL 代码，你的代码也要 GPL"。其目的是保证自由软件生态的延续。工程上，闭源商用产品若链接或集成了 GPL 组件，衍生作品可能被要求整体开源，因此需谨慎评估"是否构成衍生作品"（如链接方式、静态/动态、是否修改）。分发场景下触发最强，内部使用相对宽松。规避方式是避免在闭源产品中使用 GPL 组件，或改用宽松许可证替代。

GPL 的传染性取决于"是否构成衍生作品"及"是否分发"，是商用产品许可证合规的核心风险点，需结合法务判断。

• LGPL 与 GPL 的差异
• 动态链接与静态链接的区别
• 对使用者的影响

LGPL（Lesser GPL）是相对宽松的 GPL 变体，允许非开源代码以"库"的方式链接使用。关键在链接边界：动态链接（如运行时加载 .so/.dll）时，主程序与 LGPL 库相互独立，主程序可不开源，只需允许用户替换库版本；静态链接（编译进可执行文件）时，主程序与 LGPL 代码合并，需开放可重新链接的中间产物（relinkable object）或在满足条件下以 GPL 或 LGPL 发布。工程上，动态链接 LGPL 库相对安全，静态链接则需承担更多义务。

LGPL 的链接边界决定其传染范围，动态链接是最宽松的使用方式，静态链接需满足可重新链接等额外义务。

• MIT 许可证的条款
• 允许的使用方式
• 注意事项

MIT 许可证是极其宽松的许可：允许自由使用、复制、修改、合并、发布、分发、再许可，允许商用、允许修改、允许闭源（可将 MIT 代码集成进闭源商业产品），仅要求保留版权声明与许可声明。其兼容性极好，可与绝大多数许可证（包括 GPL、Apache 等）组合使用。工程上 MIT 是开发者的"默认宽松项"，但使用时应保留原始版权通知，并注意 MIT 代码与 GPL 组合时混合项目的整体许可复杂性。

MIT 的核心是"几乎不限制 + 保留版权声明"，是商用闭源最友好的许可证之一，兼容性最优。

• 宽松许可证与传染许可证的区别
• 典型代表
• 选型影响

开源许可证主要分两类：宽松许可证（permissive，如 MIT、Apache、BSD）允许几乎任何使用，包括商用闭源，仅要求保留版权声明，传染性弱；传染性许可证（copyleft，如 GPL、AGPL）要求衍生作品以相同许可证开源，传染性强，尤其 AGPL 在网络服务场景也传染。工程上，宽松许可证适合商用闭源与库的广泛使用，传染性许可证更适合强调开源的生态项目。选型时需根据商业模式与分发方式决定。

宽松 vs 传染的核心差异是"是否要求衍生作品开源"及"触发条件"，决定了商用产品的合规边界。

• 专利条款的含义
• 不同许可证的专利处理
• 工程影响

部分许可证含专利条款（patent clause），处理专利与软件的授权关系。Apache 2.0 明确授予专利许可并含专利报复条款；GPL v3 含专利保护条款（授权使用者获得必要专利，且协议可终结某些专利诉讼威胁）；MIT 等传统宽松许可证通常无明确专利条款。工程影响：使用含专利条款的许可证时，贡献者需注意其专利授权与报复条款；使用者需评估专利风险（依赖的专利是否被授权）。选型时应了解许可证是否覆盖专利授权，以规避专利诉讼风险。

专利条款影响"谁授权谁、以及专利诉讼时的后果"，对商用与贡献者都重要，Apache 2.0 的专利授权是商业友好的典型。

• copyleft 在 SaaS 场景的风险
• 扫描门禁的落地
• 合规治理

在 SaaS 分发场景，copyleft 风险尤其突出：AGPL 明确要求网络服务也开源，GPL 在部分解读下也可能影响分发。若 SaaS 产品使用了 GPL/AGPL 组件，核心服务端代码可能被迫开源，威胁商业闭源模型。管控上：在 CI 中接入许可证扫描门禁（如 FOSSA、Licensee、Snyk），扫描依赖树识别 copyleft 许可证，设置策略（如"检出 GPL/AGPL 即阻断或告警"），由法务与工程评估后决定替换或审批。同时建立公开的许可证清单与合规审批流程。

SaaS 场景的 copyleft 风险来自"网络服务也触发"，需要通过扫描门禁在引入依赖时提前拦截，而非事后补救。

• 员工使用开源代码的权属
• 向上游贡献的权属
• CLA 与政策的作用

员工在公司内使用开源代码、向上游贡献修复时，权属边界常模糊：公司内使用的开源代码纳入公司产品，知识形态归公司；员工向上游开源项目贡献代码时，若是在工作时间内或使用公司资源完成的，贡献的权属可能存在争议。避免纠纷的措施：制定明确的开源政策（什么情况下可贡献、需审批）；使用 CLA（Contributor License Agreement，贡献者许可协议）明确贡献者授予项目方许可、并确认其有权贡献；贡献前确认代码不包含公司机密；对员工个人开源项目与公司业务明确划分，避免"拿着公司代码做个人项目"。

权属边界靠"政策 + CLA + 审批"三重机制落地，明确贡献内容、贡献时间与资源归属，避免事后纠纷。

• 扫描工具的能力边界
• 无法判断的项
• 误报漏报治理

许可证扫描工具能识别：依赖清单中组件的许可证类型（基于包元数据或 LICENSE 文件）、许可证文本与常见许可证的匹配。无法判断：真实使用方式（是否构成衍生作品、链接方式）、许可证与业务场景的兼容性、无许可证/自定义许可证的合法含义、复制代码片段（非整包依赖）的许可。因此工具结果需人工复核。治理误报漏报：对工具标注的"unknown/自定义许可证"人工审查 LICENSE 文本；对可疑事项建立审批清单；补充代码片段扫描（如版权头、许可证头检测）；定期抽样复核降低漏报。

扫描工具是"识别助手"而非"合规裁判"，复杂的法律判断（传播范围、业务兼容）必须由法务与人工复核完成。

• 许可证回归概念
• 自动检测机制
• 重新评估流程

许可证回归（license regression）指依赖升级后其许可证发生变化（如从 MIT 变为 GPL/AGPL），导致原本合规的依赖变得不合规。自动检测：在 CI 中持续运行许可证扫描（如 FOSSA、Licensee），每次依赖更新（含 Dependabot/Renovate PR）时重新扫描，对比新旧许可证，变更时触发告警或阻断。重新评估流程：发现许可证变更后，由法务评估新许可证与业务的兼容性，工程评估替代方案（回退、替换、升级到兼容版本），记录决策并更新合规清单。将许可证扫描纳入依赖 PR 门禁可防患于未然。

许可证回归是"升级救了一处、却引入另一处合规风险"的典型，需在依赖更新时同步做许可证回归检查。

• 分发（distribution）的触发条件
• 内部使用与公开的区别
• 许可影响

许可证的"分发"（distribution）指将软件提供给第三方（如对外发布、销售、提供给客户），是 copyleft（如 GPL）触发开源义务的关键条件。仅内部使用（员工内部使用、内部部署）通常不构成分发，GPL 义务相对宽松；而公开分发（对外发布、销售交付）则触发 copyleft，要求衍生作品开源。AGPL 更进一步，网络服务（不分发）也触发。工程上需准确判断"是否分发"以确定合规义务，分发场景需更严格审查 copyleft 依赖。

"分发"是 copyleft 触发边界的关键，内部使用与公开分发的义务差异显著，需结合业务交付方式判断。

• 静态链接与动态链接的区别
• 对 copyleft 传染的影响
• 工程考量

静态链接（static linking）把库代码编译进可执行文件，二进制合并，通常被视为与库构成"衍生作品"，会更易触发 copyleft（如 GPL、LGPL 的静态链接义务）；动态链接（dynamic linking）在运行时加载库，主程序与库相对独立，通常被视为"隔离使用"，copyleft 传染较弱（如 LGPL 动态链接时主程序可不开源）。工程上，对含 copyleft 的库优先考虑动态链接以降低传染风险，静态链接时需评估并承担相应开源义务。

链接方式影响"是否构成衍生作品"，从而决定 copyleft 传染范围，是使用 GPL/LGPL 库时的关键判断。

• 许可证兼容性概念
• 组合与分发的要求
• 常见兼容规则

许可证兼容性指不同许可证的代码能否组合/再分发并满足各自义务。兼容性规则：宽松许可证（MIT、Apache、BSD）通常可与任何许可证兼容组合（可被 GPL 兼容）；GPL 与 AGPL 兼容但不一定与其他 copyleft 兼容；组合时需满足所有许可证义务（如保留版权声明、提供源码、注明许可）。分发时宽松许可证要求保留许可声明，copyleft 要求衍生作品相应开源。工程上通过许可证矩阵判断兼容性，避免组合冲突。

兼容性决定"能否组合"，组合与分发要求决定"需履行哪些义务"，是许可证合规的核心判断依据。

• Licensee 的特点
• FOSSA 的特点
• 工具选型

Licensee 是 GitHub 开源的许可证检测工具，基于 LICENSE 文件与 SPDX 库匹配许可证，常用于识别项目许可证，简单轻量；FOSSA 是商业级 SCA/合规平台，能解析完整依赖树、识别各组件许可证、提供合规报告与门禁、支持与 CI 集成，覆盖更广并支持政策管理。工程上：轻量场景用 Licensee 快速识别，企业级合规治理用 FOSSA 等平台实现依赖许可证扫描、门禁与报告。选型看规模、合规要求与集成需求。

Licensee 是"单文件识别"，FOSSA 是"全依赖合规治理"，二者定位不同，可按需组合或选择。

• 许可证审批政策的要素
• 黑白名单与审批流程
• 落地方式

企业许可证审批政策应包含：许可证黑白名单（允许的宽松许可证、禁止的 copyleft/未知许可证）、审批流程（超出白名单的许可证需提交申请、法务审核）、责任划分（引入方、法务、安全）、合规记录（审批结果存档）。落地方式：在 CI 中集成许可证扫描，对照政策自动判断（白名单放行、黑名单阻断、灰名单转人工审批），并将审批纳入依赖引入流程。同时政策需定期更新以适应新许可证与业务变化。

许可证政策把"合规要求"变成"可执行的规则"，黑白名单 + 审批流程 + 门禁自动化的组合是落地关键。

• 许可证冲突类型
• 检测工具
• 检测流程

许可证冲突主要类型：依赖许可证与项目许可证冲突（如闭源项目引入 copyleft）、多个依赖许可证之间不兼容、传递依赖引入的冲突。检测工具：SCA/合规平台（FOSSA、Snyk、Black Duck）通过依赖树与许可证矩阵自动检测冲突，Licensee 辅助识别。检测流程：在依赖引入与升级时运行许可证扫描，结合许可证兼容矩阵判断冲突，命中冲突时触发告警/阻断，由法务评估后走替换、豁免或调整流程，并记录决策。将检测纳入 CI 门禁可提前发现冲突。

冲突检测靠"扫描工具 + 兼容矩阵 + 审批流程"三环，把冲突发现前置到依赖引入阶段，避免事后整改。

• 三种许可证对采用率的影响
• 对商业化的影响
• 权衡决策

许可证选择影响采用率与商业化：MIT 最宽松、采用率最高（被广泛集成、无使用障碍），但缺乏专利保护与约束；Apache 2.0 同样宽松且含专利授权，对大型企业与商用友好，采用率高；GPL/AGPL 传染性强，会限制部分商业用户采用（闭源产品不愿引入），采用率相对低，但能保护开源生态、防止被闭源分叉。权衡：追求最大采用率与生态传播选 MIT/Apache；追求商业可持续（如开源核心 + 商业版）且保护知识产权，Apache 2.0 常是平衡选择；GPL 适合纯开源理念项目。

许可证是"开放度"与"商业保护"的权衡，Apache 2.0 兼顾宽松与专利保护，是多数商用开源项目的首选。