GPL、LGPL 与 AGPL 的义务何时触发？从使用行为判断互惠范围

Copyleft通常译为互惠或著佐权，其作用需要结合许可文本和实际使用行为理解。仅凭扫描结果出现GPL、LGPL或AGPL，不能判断企业全部代码都要公开；忽略这些许可，也可能在交付时遗漏应履行的义务。

先问四个问题

取得的是哪个版本，是否允许后续版本？有没有复制或修改受许可代码？它与自有程序怎样组合？向谁传播副本，或怎样提供网络交互？这些事实应先由研发记录，再用于许可判断。

三类许可的关注点不同

| 类型 | 应优先核查什么 | | --- | --- | | GPLv2/GPLv3 | 分发或传播受许可作品时的声明、许可和对应源码；组合作品范围与独立聚合的区别 | | LGPL | 库是否被修改，以及应用与库组合分发时是否满足对应版本对材料、替换或重新链接等条件 | | AGPLv3 | 除传播义务外，还要检查第13节中修改后的程序与用户远程网络交互时的对应源码提供要求 |

GPL许可不因为程序收费就禁止商业使用。源码的提供对象、方式和所需材料应对照实际传播路径分析，不能概括成“每次内部修改都必须立即上传到公开仓库”。GPLv2原文与GPLv3原文

LGPL 2.1下，静态链接和共享库机制均有具体条件；使用动态链接不代表零义务。AGPLv3第13节也不能简化为任何服务器运行都无条件公开全部系统源码。LGPL 2.1与AGPLv3第13节

不把不同规则归为一个标签

SSPL虽然公开源码并设置互惠要求，但OSI明确其不是获得批准的开源许可证。评审中应单独标识，不能因为它与AGPL名称或形式相近就按相同规则处理。OSI说明

将许可判断落实到发布包

建议把组件版本、文件级许可、修改范围、链接与通信关系、源码提供方式及验证记录一起归档。声明、源码和重建材料需要能对应实际交付版本，不能只链接上游当前分支。

发生争议时，应区分第三方许可是否履行、自有代码是否具有独创性以及主张哪些权利。某一许可违规并不自动证明自有代码的全部著作权消失。项目需要保存事实证据，再就具体问题作审查。