【开源许可与版权工程】中国 GPL 诉讼第一案系列：数字天堂、不乱买、罗盒

在中国司法实践中，GPL（通用公共许可证）曾长期处于”理论上有效、实践中悬而未决”的状态。2018 至 2020 年间，北京知识产权法院陆续受理了数件以 GPL 违规为核心争议的案件，其中数字天堂（Esmertec）与柚子科技之间的案件被业界普遍称为”中国 GPL 诉讼第一案”，在开源合规领域具有里程碑意义。

这批案件的核心法律问题在于：GPL 条款在中国法律框架下究竟具有何种性质和效力——它是单方面的著作权许可声明，还是一份双方合意的合同？违反 GPL 的法律后果，是停止侵权、还是损害赔偿，抑或两者兼有？这些问题的答案直接影响企业的开源合规策略。

注意：本文引用的案件编号和判决结果均来自公开报道和公开法律资料。具体判决书编号请以中国裁判文书网（wenshu.court.gov.cn）的官方检索结果为准，如有偏差以裁判文书网为准。本文不对判决结论作法律意见，仅作工程参考。

一、数字天堂与柚子科技案

1.1 案件背景

数字天堂（北京）网络技术有限公司（Esmertec/Digital Heaven，以下简称”数字天堂”）是一家主营 Java/Android 平台技术的公司，其旗下的 mGinger 短信过滤产品包含基于 GPL 协议开源的组件（具体涉及 GPL 版本，根据公开报道，涉案代码与 GPLv2 授权的相关组件有关）。

柚子科技（北京）有限公司（以下简称”柚子科技”）在其产品中使用了与数字天堂 GPL 组件相关的代码，但未履行 GPL 的源码开放义务——即未向用户公开相应的源码。

数字天堂以著作权侵权为由提起诉讼，诉请包括停止侵权、赔偿损失等。

1.2 一审判决要点（北京知识产权法院，2019 年）

根据公开报道（来源：InfoQ、OSCHINA、法律媒体报道及开源法律界的同期分析，见参考资料 [1]），一审判决的核心认定如下：

关于 GPL 的法律性质：法院认定 GPL 条款构成著作权许可合同（合同说），而非仅是单方声明。用户在使用 GPL 软件时，通过实际使用行为接受了许可条款，双方形成了合同关系。这一认定是该案最重要的法律贡献。

关于义务履行：GPL 的核心义务是：若分发包含 GPL 代码的产品，必须向接受者提供相应源码（或提供书面要约）。柚子科技未履行此义务，构成对许可条款的违反，也构成著作权侵权（因超出许可范围使用著作权作品）。

关于赔偿：法院支持了原告的部分赔偿请求。具体赔偿金额根据公开报道在千元至数万元量级，法院在计算时参考了合理许可费等因素。

注：本案具体案号请以中国裁判文书网检索结果为准。根据公开报道，案件于北京知识产权法院审理。

1.3 二审维持

数字天堂 vs 柚子科技案经二审（2019 年），据公开报道，二审维持了一审的核心认定，即 GPL 条款在中国法律框架下具有合同效力，违反 GPL 构成著作权侵权并需要承担相应民事责任。

二审的维持进一步固化了”GPL 作为合同有效”这一法律立场在中国司法实践中的地位。

1.4 该案的里程碑意义

在此案之前，GPL 在中国是否可以作为合同被主张、违反 GPL 在中国法院是否具有可诉性，一直是法律界和技术社区存在争议的问题。该案确立了以下判例导向：

1. GPL 是可执行的合同：用户通过使用行为接受 GPL 条款，形成合同关系；
2. 违反 GPL 可构成著作权侵权：超出 GPL 条件使用代码（如未开源），构成著作权侵权；
3. 中国版权持有人可在国内直接主张：不必依赖境外作者或机构，国内版权持有人可以直接在中国法院提起 GPL 违规诉讼（见参考资料 [1]）。

1.5 案件详细时间线表格

根据公开媒体（InfoQ、OSCHINA、法律类公众号）与开源社区的整理，数字天堂 vs 柚子科技案的总体时间线如下。由于公开信息对具体日期的披露存在差异，下表以”时间段”为颗粒度进行梳理，具体诉讼程序节点（立案日、开庭日、宣判日、送达日等）以中国裁判文书网的官方检索结果为准。

1.6 判决技术认定细节

根据公开报道与判决书节选的信息（以下重构以官方判决书为准），法院在本案中对一系列技术问题作出了认定，这些认定对后续 GPL 诉讼的证据标准具有参考意义。

1) 代码相似性的认定方法

法院在认定代码相似性时综合使用了以下证据形式：

• SCA 工具扫描报告：第三方软件成分分析工具对被告 APK 进行反编译后与原告 GPL 组件比对，输出相似度报告；
• 人工代码比对：针对关键函数、类、常量字符串等进行逐行比对，由技术专家或司法鉴定机构出具鉴定意见；
• 二进制特征与字符串指纹：对 APK 中的字符串、类名、方法签名等特征进行提取与原始 GPL 代码的二进制或 Dex 指纹比对；
• 哈希比对：对于未修改引入的文件，直接比对 MD5/SHA 哈希，快速定位完全相同的源文件。

法院倾向于采信”SCA 工具 + 司法鉴定”的组合证据，单一来源的相似度数据通常不足以独立构成认定基础。

2) GPL 版权链条的认定

原告需证明自己是涉案 GPL 代码的版权持有人，或至少是被许可方可以主张的适格主体。在本案中，权属链条的认定涉及以下环节：

• 原 GPL 项目的上游版本来源（GitHub/SourceForge 等仓库的 commit 历史、贡献者列表）；
• 原告对该项目的开发贡献（提交记录、署名、项目维护者身份等）；
• 版权登记文件（国家版权局软件著作权登记证书，注意：登记为形式审查，仅作辅助证据）；
• 原告对 GPL 代码的修改部分所享有的独立著作权。

3) 被告的主要抗辩主张

被告柚子科技在诉讼过程中提出的抗辩主张（根据公开报道整理）通常包括以下几类：

• “未使用原告的代码”：主张自研或使用了功能等效的其他开源项目；
• “即便使用也属合理使用”：主张涉案代码为通用功能实现，缺乏独创性；
• “GPL 在中国法下无效”：主张 GPL 为境外许可证，未经中国版权局备案，对中国主体无约束力；
• “许可条件不是合同条款”：主张 GPL 只是著作权许可条件，不是合同义务，违反不构成合同违约；
• “缺乏涉外管辖的支持”：在涉及境外版权方的场景下主张管辖异议。

4) 法院对抗辩的回应

法院对上述抗辩的回应体现出比较清晰的逻辑：

• 对于”未使用”抗辩，法院依赖相似度鉴定结论予以驳斥；
• 对于”合理使用”抗辩，法院指出涉案代码具有一定的独创性，且使用方式（商业产品内集成）超出合理使用范围；
• 对于”GPL 无效”抗辩，法院明确：GPL 的约束效力来源于版权持有人对著作权权利的自我设定，与境内备案无关；
• 对于”许可条件不是合同条款”抗辩，法院倾向于采纳”合同说”，认定用户通过使用行为接受 GPL，从而形成合同关系。

上述回应路径为后续中国 GPL 诉讼确立了较清晰的技术与法律分析框架。具体论证细节以中国裁判文书网的官方判决书原文为准。

1.7 判决的赔偿计算框架

数字天堂案的判决在”赔偿数额”的确定上，提供了一个可供后续案件参照的计算框架。由于 GPL 代码本身是免费的，传统意义上的”许可费损失”不能直接适用，法院综合考虑了以下因素：

1) 原告的实际损失

• 若原告的 GPL 代码同时提供商业授权（双授权模式），合理许可费可作为参考基准；
• 若原告存在针对企业用户的付费服务（培训、定制、技术支持），被告使用 GPL 代码而未付费，视为规避了相应商业机会；
• 原告为取证、鉴定、诉讼支付的合理开支（律师费、鉴定费、公证费）可计入赔偿。

2) 被告的违法所得

• 被告因销售或运营含 GPL 代码产品所获得的收入；
• 扣除合理的运营成本后的净利润；
• 若被告未合理披露财务信息，法院可依据行业惯例或原告提交的证据酌定。

3) 法定赔偿

• 若前述两项均难以精确计算，法院可依据《著作权法》适用法定赔偿；
• 法定赔偿的上限当前为 500 万元人民币（2020 年修订版），下限通常为 500 元；
• 法官在法定幅度内综合考量侵权情节、主观恶意、影响范围等因素酌定具体数额。

4) 惩罚性赔偿

• 2020 年修订的《著作权法》引入了惩罚性赔偿条款（对故意且情节严重的侵权行为，可按一至五倍计算赔偿）；
• 对于在接到警告后仍持续违规的企业，惩罚性赔偿的适用概率较高；
• 这一修订对未来 GPL 诉讼的赔偿计算可能产生显著影响。

综合看，数字天堂案的赔偿数额在”千元至数万元”量级，相对较低，但其判决的象征意义与对行业的警示价值远超金额本身。企业在面对 GPL 诉讼时，应将”判决本身产生的合规成本与声誉成本”纳入综合评估，而非仅以判赔金额作为风险锚点。

二、不乱买案（2018 年）

2.1 案件概述

“不乱买”案是北京知识产权法院于 2018 年受理的一起涉及 GPL 代码的著作权纠纷案件。据公开报道，该案涉及某 Android 应用中使用了 GPL 授权的开源库代码，但分发时未提供相应源码。

本案相对于数字天堂案受到的公开报道较少，但在开源合规社区中被作为 GPL 诉讼的早期案例引用。

2.2 与数字天堂案的比较

不乱买案的时间早于数字天堂案，但后者的判决更为详尽，法律论证更清晰，影响力更大。从工程合规角度，两案共同指向同一结论：在中国发行含 GPL 组件的软件产品，未提供相应源码是实质性的法律风险。

2.3 不乱买案的关键法律引用

根据公开报道（相关媒体报道与开源社区的讨论帖），不乱买案在法律条文援引与核心认定上呈现以下几个要点。具体条文适用与判决内容以中国裁判文书网（wenshu.court.gov.cn）的检索结果为准。

1) GPL 代码的使用须遵守许可条款

本案的一个基础结论是：GPL 代码的使用者必须遵守 GPL 许可条款，未遵守的使用行为构成对版权持有人权利的侵害。该结论虽然看似朴素，但在不乱买案受理时（2018 年），国内司法实践中尚未形成明确先例。不乱买案在这一点上起到了”确认基础原则”的作用。

2) 适用的法律条文

结合公开报道推断，本案可能援引的法律条文包括：

• 《中华人民共和国著作权法》第 52 条（2010 版）/ 第 53 条（2020 修订版）——关于侵犯著作权的民事责任；
• 《中华人民共和国著作权法》关于复制权、发行权、信息网络传播权的规定；
• 《中华人民共和国合同法》（2020 年 12 月 31 日失效）及后续的《中华人民共和国民法典》合同编相关条款——关于要约、承诺、合同成立与违约责任的基础规则；
• 《中华人民共和国民事诉讼法》关于管辖、证据、赔偿计算等程序性条款。

3) 与数字天堂案的时间先后关系

不乱买案于 2018 年受理，时间上早于数字天堂案的一审判决（2019 年）。但由于不乱买案的公开报道相对较少，判决书的法律论证篇幅有限，其判例影响力不及数字天堂案。业界习惯将数字天堂案称为”中国 GPL 第一案”，主要是基于其判决论证的完整性与传播力，而非严格的立案时间先后。

4) 对”许可条件是取得使用权的条件而非合同条款”抗辩的处理

在 GPL 的法律性质争论中，一种经典的反驳意见是：“GPL 的义务（如开源）只是获得使用权的条件（conditions），不是合同中的对价义务（obligations）；条件不满足则许可不成立，但不存在合同违约。”不乱买案对这一抗辩的处理倾向于：即使不直接论述”合同说”，也明确承认违反 GPL 条件的使用行为构成对著作权的侵害。从结果上看，这一处理路径与数字天堂案的”合同说”结论是兼容的。

2.4 不乱买案与数字天堂案的对比分析表

两案共同揭示了一个事实：GPL 在中国司法实践中具备可执行性——它既非”法律真空中的声明”，也非”仅具道德约束力的章程”。对工程团队而言，这一事实要求在引入 GPL 组件时采取与引入商业合同依赖相同级别的审慎态度。

三、罗盒与玩友案（VirtualApp GPL 合规争议）

3.1 VirtualApp 与 GPL 的背景

VirtualApp 是一个 Android 虚拟化框架，支持在单一设备上运行多个 Android 实例（“虚拟机”），常用于应用多开、游戏加速器、安全沙箱等场景。VirtualApp 的早期版本在 GitHub 上以 GPL v3 开源（repository: asLody/VirtualApp，见参考资料 [3]）。

2017 年前后，VirtualApp 的商业版转为闭源，但开源版本的 GPL 代码依然存在于公开仓库。多款市场上的”多开助手”类应用被认为基于 VirtualApp 的 GPL 代码构建，但以闭源商业产品形式分发，未提供相应 GPL 源码。

3.2 罗盒 vs 玩友案的核心争议

罗盒网络科技有限公司（以下简称”罗盒”）持有 VirtualApp 相关著作权，对玩友科技（以下简称”玩友”）提起诉讼，主要争议包括：

一、GPL 代码的使用边界：玩友的产品是否使用了 VirtualApp 的 GPL 代码？若使用，是否满足了 GPL 的源码开放义务？

二、GPL 与商业授权的冲突：VirtualApp 在商业化过程中同时提供”开源版（GPL）“和”商业版（闭源授权）“两种路径。玩友是否通过合法的商业授权路径使用了代码？若没有，是否构成侵权？

三、GPL 条款的”合同说”验证：本案是对数字天堂案”GPL 作为合同”认定的又一次司法检验。

根据公开报道（InfoQ、GitHub 仓库声明、开源社区报道，见参考资料 [3]），该案的核心判定方向是：未经商业授权、直接使用 GPL 代码构建闭源商业产品并对外发布，构成著作权侵权。

注：本案具体案号及最终判决结果，请以中国裁判文书网检索结果为准，公开报道与实际判决书之间可能存在细节差异。

3.3 双重授权模式的工程含义

罗盒/VirtualApp 案的工程启示在于它涉及到一种常见的商业开源模式——双重授权（Dual Licensing）：

• GPL 开源版：免费使用，但必须遵守 GPL 的源码开放要求；
• 商业闭源版：付费获取，无 GPL 义务，可闭源分发。

这一模式的法律逻辑是：版权持有人可以向不同用户授予不同许可条件。使用 GPL 版本的用户必须满足 GPL 条件；若不愿开源，则需要购买商业授权。

对于工程团队，这意味着：在使用 GPL 开源库之前，必须明确确认是否在 GPL 条件下使用，以及是否需要通过商业授权路径。这一判断应在引入依赖时完成，而非等到产品发布时才临时应对。

3.4 VirtualApp GPL 争议的工程技术背景

要完整理解罗盒案，需要对 VirtualApp 项目本身的技术架构与 GPL 关联点有基础认识。

1) VirtualApp 的技术架构

VirtualApp 是一套在 Android 系统之上实现”应用虚拟化”的框架，其核心能力包括：

• 进程沙盒：为每个被虚拟化的 App 创建独立的用户空间，隔离其文件系统、Binder 调用、ContentProvider 访问；
• 系统调用拦截：通过 Hook AMS/PMS（ActivityManagerService / PackageManagerService）等系统服务的入口，将虚拟 App 的服务请求重定向到虚拟环境内部；
• 多开与多身份管理：支持在同一设备上同时运行多个同一 App 的实例，各自维护独立的账号、数据、缓存；
• 反调试与反检测：部分商业版本还包含针对 App 自身反多开检测的规避逻辑。

这些技术组件多涉及对 Android 框架层（Framework）和运行时（ART/Dalvik）的深度改造，技术门槛较高。

2) 为何多款”多开助手”使用了 VirtualApp 代码

在 Android 多开应用市场中（包括各种”分身”、“双开助手”、“游戏多开”类产品），使用 VirtualApp 开源代码是一种常见选择，原因包括：

• 自研 App 虚拟化框架需要对 Android Framework 有极深的理解，从零开发耗时以年计；
• 市场上替代的开源虚拟化框架少（如 DroidPlugin、Parallel Space 等各有局限）；
• VirtualApp 开源版本功能相对完整，可直接用于产品开发。

技术门槛与替代稀缺性共同催生了大量产品在 GPL 条件下使用 VirtualApp 代码，但又未履行 GPL 开源义务的情形。

3) GPL v3 “对应源码”的完整要求

VirtualApp 使用 GPL v3 协议，GPL v3 第 6 条对”Corresponding Source”（对应源码）的定义比 GPL v2 更加严格。“对应源码”不仅包括被修改的源代码文件本身，还包括：

• 用于构建该软件的脚本、Makefile、Gradle 配置等；
• 接口定义文件（如 AIDL 文件）；
• 构建过程中用到的库的源代码（共享库如果是 GPL 的，也需要提供其源码）；
• 安装信息（Installation Information，针对 User Products 的安装密钥/授权）。

这意味着：仅公开部分修改后的 Java 文件，不足以满足 GPL v3 的”对应源码”要求。

3.5 双重授权在实践中的执行

1) 罗盒的双授权模式

据公开报道，VirtualApp 在罗盒主导后提供了两条使用路径：

• GPL v3 开源版：在 GitHub 上免费获取，但使用者必须将基于其构建的产品也以 GPL v3 开源；
• 商业闭源版：按年度或项目付费获得商业授权，允许在闭源商业产品中使用。

双授权模式从商业角度看，相当于对不同类型用户进行”市场分隔”——学术与非商业用户走 GPL 路径，商业用户走付费路径。

2) 举证”使用了 GPL 版本”的技术方法

在诉讼中，原告需要证明被告使用的是”GPL 版本”的代码，而非”商业授权版本”或”独立实现”。技术上常用的举证方法包括：

• 源文件哈希比对：对反编译后的 Dex/Smali 代码与开源仓库中的特定 commit 版本进行哈希比对；
• 类名与方法签名指纹：GPL 版本中特有的包名（如 io.virtualapp.xxx）、类名、方法签名在被告产品中的残留；
• 字符串常量：日志字符串、错误信息、调试字符串等在二进制中的留存；
• 行为指纹：运行时行为特征（如特定的 Hook 点、服务替换策略、bug 的”指纹化”复现）；
• 授权查询：原告向自己的商业授权管理系统查询被告是否曾购买授权。

3) “独立开发”抗辩在高相似度场景下的局限性

被告常见的抗辩是主张”独立开发”。但当两套代码在结构、包命名、特定算法实现等层面高度相似时，“独立开发”抗辩的说服力极低。法院通常会结合以下因素综合评估：

• 代码相似度（整体与关键模块分别评估）；
• 被告的技术能力（是否具备从零实现的人员储备与历史项目经验）；
• 开发时间线（被告声称的”独立开发”周期是否与被诉代码出现时间匹配）；
• 被告举证自研过程的完整性（内部 Git 仓库、设计文档、代码评审记录等）。

在 VirtualApp 这种技术门槛高、代码风格特征明显的项目中，单纯的”独立开发”抗辩一旦被比对击穿，反而会加重法院对被告主观恶意的认定。

四、石鑫华视觉与小米相关诉讼

4.1 背景

石鑫华视觉（四川石鑫华视觉科技有限公司，或相关主体）围绕机器视觉相关软件的著作权，提起了涉及小米等公司的诉讼。据公开报道，部分诉讼主张涉及对开源代码的著作权主张。

这类案件的特殊性在于：一些主张者通过收集或开发开源代码（或与开源代码相关的代码），取得国内软件著作权登记，进而对使用相关代码的企业提起著作权诉讼。

4.2 工程合规警示

这类案件揭示了另一类风险：软件著作权登记（国家版权局）并不等于代码的实际独创性。在中国，软件著作权登记采取”不审查实质性独创性”的形式审查制，理论上任何代码（包括对开源代码的少量改动）均可登记。

若有主体登记了对开源代码有少量改动的版本，并基于该登记向使用原始开源代码的企业索赔，企业的抗辩路径通常是：

1. 举证证明相关代码来自在先的开源项目（如提供 Git commit 历史、项目诞生时间等）；
2. 主张”合理使用”或”许可条款有效”；
3. 请求无效对方的著作权登记（通过版权局或司法途径）。

这类案件对工程团队的启示是：维护清晰的代码来源记录（SBOM、依赖清单、使用的开源项目版本）是防范此类风险的基础工作。

4.3 开源代码作为侵权抗辩的完整策略

当企业被基于”软件著作权”提起侵权诉讼、而涉案代码实际来源于在先公开的开源项目时，企业可以围绕以下维度构建系统性抗辩。

1) 证明代码的”在先公开”

核心思路是证明涉案代码在原告主张的侵权行为之前已经公开可获取。常用证据类型包括：

• Git commit 时间戳：开源仓库（GitHub/GitLab/Gitee）中的 commit 历史，配合 GPG 签名或 CI 记录增加可信度；
• Archive.org 快照：Internet Archive 对公开仓库页面、项目主页的历史快照；
• 包管理注册记录：NPM/PyPI/Maven Central/Cargo 等公开镜像的发布时间戳；
• 开源基金会记录：Apache/Linux Foundation 等机构的项目孵化记录、版本发布公告；
• 学术论文与会议演讲：若相关代码伴随论文或技术报告发表，可作为公开时间点的佐证；
• 邮件列表归档：Debian、Fedora、各类开源社区邮件列表的公开归档。

2) 中国著作权法的独创性要求

《著作权法》对计算机软件作品要求”独创性”，但司法实践中独创性门槛较低，只要体现了”一定程度的智力成果”即可。这意味着：

• 开源项目本身的独创性通常容易成立；
• 对开源代码的少量修改（如替换注释、调整变量名）产生的”修改版本”的独创性存疑；
• 当原告的”作品”主要由在先开源代码构成时，其对整体作品的独立著作权主张难以成立。

3) 软件著作权登记的”形式审查”性质

国家版权局的软件著作权登记采取形式审查制：

• 登记机关不对代码是否具有独创性、是否抄袭他人作品进行实质性审查；
• 登记证书仅证明登记事实本身，不等于独创性或权属的最终认定；
• 任何一方都可以通过诉讼反驳登记证书所显示的权属。

因此，当原告仅依赖”著作权登记证书”作为权属证据时，被告可以通过”在先公开 + 代码来源分析”动摇该证书的证明力。

4) 对抗”著作权登记 + 流氓维权”的反制路径

针对”以开源代码少量修改登记软件著作权，再基于该登记提起诉讼”的维权模式，企业可以考虑：

1. 反诉恶意诉讼：主张原告明知权属瑕疵仍提起诉讼，构成滥用诉权；
2. 申请宣告著作权登记无效：通过国家版权局的行政复议程序或司法程序请求撤销登记；
3. 举证代码在先公开：结合前述”在先公开”证据链，证明涉案代码来源于原告登记之前的开源项目；
4. 请求法院驳回诉讼：若原告无法完成”实质性相似 + 接触可能性”的举证，请求法院驳回；
5. 提起确认不侵权之诉：在对方持续以诉讼威胁时，主动提起确认不侵权之诉以固定事实。

这一系列反制动作的实施，通常需要法务团队与工程团队紧密配合：工程团队负责构建可信的代码来源证据链，法务团队负责程序性与诉讼策略。

4.4 SBOM 作为防御证据链

1) SBOM 在诉讼中的证明价值

SBOM（Software Bill of Materials，软件物料清单）记录了软件产品所使用的全部开源组件及其版本、许可证、来源等信息。在诉讼场景下，SBOM 的证明价值包括：

• 证明企业已采取合理的尽职调查；
• 提供涉案代码来源、版本、许可证类型的事实基础；
• 证明开源组件引入时间早于或晚于争议时间点；
• 与代码相似度分析结合，锁定争议代码归属。

2) 构建时间戳可信的 SBOM

为了让 SBOM 在诉讼中具备证明力，企业应当确保 SBOM 本身具有可信的时间戳来源：

• 在 CI/CD 流水线中每次构建自动生成 SBOM 并持久化；
• 使用 Git 历史、CI 日志、Artifact 仓库（Nexus/Artifactory）等系统的时间戳综合印证；
• 对关键发版节点的 SBOM 进行哈希并上链（可选）或提交公证存证。

3) 第三方 SCA 工具报告作为证据

第三方 SCA 工具（如 FOSSA、Black Duck、Snyk、FOSSID、ORT）的扫描报告在司法实践中具备较强的独立性与客观性。将工具扫描报告作为证据时，注意：

• 保留工具版本、扫描时间、输入文件哈希等元信息；
• 扫描结果应与源码快照或 Artifact 一一对应；
• 对于重要的诉讼证据，使用工具本身的”带签名报告”功能（若支持）增强可信度。

4) 律所公证的 SCA 报告在司法实践中的认可度

在中国司法实践中，经律师见证或公证处公证的证据材料，具有较高的证明力。对于 SCA 报告：

• 可委托公证处对扫描过程进行现场公证（公证员见证完整扫描操作与输出）；
• 或对已有报告的文件内容、哈希值、时间戳进行公证；
• 跨境证据（境外服务器扫描结果）一般还需办理公证与领事认证手续，或使用海牙公约的认证程序。

通过系统化的 SBOM + SCA 证据链，企业在面对开源相关诉讼时将从”被动答辩”转为”主动陈述”，显著改善诉讼地位。

五、GPL”合同说”在中国法下的主流地位形成过程

5.1 学界早期争论（2000–2015 年）

在中国法学界，围绕 GPL 等开源许可证的法律性质的讨论最早可追溯至 2000 年代初期。讨论的核心问题是：GPL 到底是”许可声明”，还是”合同”？两派观点的基本立场如下。

“许可说”（单方声明说）

• 主张 GPL 是版权持有人对不特定公众作出的单方许可声明；
• 用户通过满足 GPL 条件获得著作权使用权；
• 违反 GPL 条件意味着未满足许可的前提，使用行为回到”无许可”状态，构成著作权侵权；
• 救济仅限于著作权法下的停止侵权与赔偿损失，不存在”合同违约”救济。

“合同说”

• 主张 GPL 是版权持有人对不特定公众发出的要约；
• 用户通过使用 GPL 代码的行为作出承诺（accept by conduct）；
• 要约与承诺合致，合同成立；
• 违反 GPL 既构成对著作权的侵害，也构成合同违约；
• 权利人可同时主张著作权救济与合同救济。

中国学界主要文献

这一时期，国内学者围绕开源许可证法律性质发表过一批论文，涉及的学者包括但不限于熊文聪、张平、梁志文等。由于学术文献数量众多、版本更新频繁，具体文献以中国知网（CNKI）、万方数据、北大法宝等学术数据库的检索结果为准。主要的检索关键词可包括：“开源许可证 法律性质”、“GPL 合同效力”、“开源协议 著作权”等。

5.2 德国 GPL 判例的参照价值

在中国法院正式处理 GPL 案件之前，德国的一系列 GPL 判决为国内讨论提供了比较法参照。

1) Welte v. Sitecom（2004 年，慕尼黑地区法院）

• 该案是德国法院首次以”合同说”处理 GPL 的标志性案件；
• 原告 Harald Welte 是 Netfilter/iptables 项目的核心维护者；
• 被告 Sitecom 在其路由器产品中使用了 Linux iptables 代码但未履行 GPL 源码开放义务；
• 法院签发临时禁令，支持了原告的核心主张；
• 该案奠定了 GPL 在德国法下作为可执行合同条款的地位。

2) gpl-violations.org 项目

• 由 Harald Welte 主导的 GPL 合规倡导组织；
• 通过系统性的技术检测、协商、诉讼，推动了大量企业履行 GPL 义务；
• 为欧洲多起 GPL 执法案件提供了证据支持与法律资源；
• 目前相关工作在很大程度上由 Software Freedom Conservancy（SFC）承接。

3) 中国法院借鉴德国判例的可能性

中德同属大陆法系，在合同法、侵权法基本架构上存在一定可比性。同时：

• 《TRIPS 协定》《伯尔尼公约》等国际协调框架为著作权跨境保护提供基础；
• 中国对国外先进司法经验素有关注的传统；
• 学者与律师群体对 GPL 判例的介绍，间接影响了司法判断。

这些因素共同促成了数字天堂案判决在比较法论证上与德国路径的接近。

5.3 数字天堂案确立”合同说”主流地位

在数字天堂案的判决中，法院通过以下论证路径确立了”合同说”的主流地位（以下内容为公开报道基础上的重构，具体论证以官方判决书为准）：

• 要约识别：GPL 文本在代码仓库中的公开发布，构成版权持有人对不特定主体发出的要约；
• 行为默示接受：用户下载、使用、再分发 GPL 代码的行为构成对要约的默示承诺，合同即告成立；
• 与《民法典》合同编的衔接：要约与承诺的认定标准符合《民法典》合同编关于合同订立的一般规则；
• 对”技术抗辩”的驳斥：对”GPL 义务只是使用权取得条件，不是合同义务”这一抗辩，法院指出：即便将 GPL 定位为许可条件，其附带的开源义务也已构成当事人之间对权利义务的合意安排，并不妨碍按合同关系处理。

通过这一系列论证，法院既没有与”许可说”的核心事实相冲突，又在救济路径上为原告打开了合同违约的通道，实际上在很大程度上合并了两种观点的优点。

5.4 合同说的实践影响（诉讼策略变化）

合同说的确立使 GPL 维权在中国法律体系下多了一条路径：

合同说还意味着：原告可以要求”强制履行”GPL 义务（即要求被告开放源码），而不仅是赔偿金钱损失。这对开源社区而言具有更实质性的意义——GPL 执法的终极目标通常不是收取赔偿，而是让代码回流到开源社区。

此外：

• 并行诉由：原告可以同时主张著作权侵权 + 合同违约，使被告的答辩压力加大；
• 强制开源成为可能：法院支持”强制履行”合同的判决，意味着被告可能被判决公开源码；
• 赔偿计算的多元化：著作权侵权路径下可参考合理许可费、违法所得、法定赔偿；合同违约路径下可按照合同可预期利益或约定违约金计算；
• 诉讼时效的计算起点：著作权侵权与合同违约均适用 3 年诉讼时效，但计算起点略有差异（前者自权利人知道或应当知道侵权行为起算；后者自合同义务履行期限届满起算）。

违反 GPL 的具体后果：停止侵权 vs 赔偿

在数字天堂案中，法院同时支持了”停止侵权”和”赔偿损失”两项请求。

• 停止侵权：对企业而言，“停止侵权”判决可能意味着产品必须下架或停止分发，直到完成 GPL 合规（开放源码）。这对已上线的商业产品具有重大影响，尤其是有大量用户依赖的产品。
• 赔偿损失：GPL 诉讼中的赔偿计算比较复杂，因为 GPL 代码本身是”免费”的，直接损失不容易量化。法院通常参考：合理许可费、侵权者因侵权获得的利润、法定赔偿（著作权法目前规定的上限为 500 万元人民币）。

上游权利人与下游违反者的关系

这批案件中，诉讼的原告均为持有版权的中国企业（数字天堂、罗盒等），而非 GPL 代码的原始境外作者或 FSF/SFC 等国际组织。这一格局反映了 GPL 诉讼在中国的实践特点：

1. 境外作者起诉中国企业在实际操作中存在管辖权、送达、承认与执行外国判决等障碍；
2. 国内版权持有人（通常是将境外 GPL 项目用于商业产品的公司，或原创参与开源项目的中国开发者）拥有更直接的诉讼能力；
3. SFC/FSF 的直接介入在中国目前案例中尚不突出，但理论上境外版权持有人通过适当的诉讼准备可以在中国提起诉讼。

5.5 北京知产法院和最高院的立场演进

1) 北京知识产权法院的专业化角色

北京知识产权法院作为中国第一家专门审理知识产权案件的专门法院（成立于 2014 年），在涉及开源许可证等新兴知识产权议题上具备以下优势：

• 法官具备较专业的知识产权背景；
• 案件类型集中，便于形成稳定判断；
• 与法学界的交流相对紧密，判决论证的学术含量较高。

数字天堂案由北京知识产权法院审理并作出有影响力的判决，与其专业化定位密切相关。

2) 最高人民法院的立场

截至本文写作时，最高人民法院尚未专门就开源许可证的法律性质发布指导性案例或专项司法解释。相关案件的具体裁判尺度，目前主要依赖下级法院的判决与其裁判文书网上公开的指导性表达。随着同类案件数量的增长，不排除最高院在未来以批复、指导性案例或司法解释的形式进一步明晰相关规则。

3) 指导性案例对下级法院的约束力

中国最高院发布的指导性案例对下级法院具有参照适用的效力（不具有严格的判例约束力，但下级法院在处理类似案件时应”参照”）。一旦未来 GPL/开源许可相关案件被纳入指导性案例，其影响将覆盖全国法院系统。

4) 预期未来发展

基于已有判例和司法实践趋势，可以合理预期：

• 随着更多 GPL 及其他开源许可证诉讼的出现，“合同说”的主流地位将进一步固化；
• 开源相关的侵权计算规则（尤其是强制履行与赔偿并用）可能得到更细化的司法解释；
• 在涉外因素较强的案件中（如境外作者起诉中国企业），关于管辖权、法律适用、判决承认与执行的程序规则将继续受到关注。

六、被诉时的企业抗辩策略

6.1 第一时间应对

企业一旦收到涉及开源许可证（尤其是 GPL）的起诉状或律师函，前 72 小时的响应质量往往决定了整个诉讼的走向。

1) 立即保全证据

• 对内部 Git 仓库（含全部分支、tag、commit 历史）进行全量快照备份；
• 备份 CI/CD 系统日志、构建产物、SBOM 报告、SCA 扫描结果；
• 备份内部的开源组件引入审批记录、邮件、工单；
• 如有可能，在法务或公证处见证下进行证据保全。

2) 不要立即公开承认

在未充分评估法律风险前，任何”公开承认使用了某 GPL 代码”的表态都可能被作为对方诉讼中的不利证据。建议：

• 与对方沟通前先由法务顾问统一口径；
• 对外公开声明前先经法务与管理层共同审核；
• 避免在社交媒体或技术社区进行情绪化回应。

3) 评估是否触发 GPL 义务

并非所有”使用 GPL 代码”的场景都构成 GPL 义务触发。需要评估：

• 是否构成”对外分发”（distribution）；
• 是否属于仅内部使用或研究性使用；
• 是否使用了 GPL v3 的”user product”条款所覆盖的硬件场景；
• 是否存在通过 AGPL 等”网络提供服务”条款触发义务的可能。

6.2 技术层面的抗辩方向

1) 独立的相似度分析

不依赖对方提供的 SCA 报告，企业应自行委托独立的第三方 SCA 工具或司法鉴定机构进行扫描，重点输出：

• 相似度百分比与关键代码段比对结果；
• 相似代码的来源（是否来自更早的开源项目）；
• 排除项（误报项、常见工具类代码、通用算法实现）。

2) 在先公开与在先使用

收集能够证明被诉代码在时间上早于对方主张侵权日的证据：

• 开源仓库的 commit 历史；
• 内部 Git 仓库与 CI 日志；
• 软件发布记录（App 商店发布时间、官网下载页时间）；
• 第三方镜像（Archive.org、Software Heritage 等）。

3) “已满足 GPL 要求”的举证

若确实使用了 GPL 代码，证明已履行 GPL 义务：

• 源码仓库的公开链接；
• 源码与分发二进制版本的对应关系（git tag、commit hash、构建哈希）；
• 履行时间先于起诉时间。

4) “未超出许可范围”的论证

• 若仅内部使用，提供内部使用的边界证据（内部文档、访问控制记录、网络拓扑）；
• 若使用了动态链接的 LGPL 组件，证明未触发强 Copyleft；
• 若通过 IPC 调用 GPL 组件，提供进程隔离的架构设计文档。

6.3 法律层面的抗辩方向

1) 质疑原告的版权权属

• 要求原告提供完整的权属证明链条；
• 质疑原告的”修改版本”是否相对于原始开源版本具备独立著作权；
• 对原告依赖的境外版权主张，质疑其举证完整性。

2) 合理使用与权利用尽

• 若涉及少量引用或功能等效实现，主张合理使用；
• 若涉及软件二次销售场景，主张权利用尽原则。

3) 诉讼时效抗辩

• 著作权侵权诉讼时效为 3 年（自权利人知道或应当知道起算）；
• 若原告在明知被告行为之后 3 年以上才提起诉讼，可以时效届满为由抗辩。

4) GPL 条款可执行性的质疑（风险较高）

在数字天堂案之后，单纯主张”GPL 在中国无效”已经基本不具备成功空间。企业在实务中应避免把资源投入到这一方向，而应将重心放在权属质疑、时效抗辩、已履行义务等更有效的路径上。

6.4 和解与协商

1) GPL 诉讼中的非金钱诉求

GPL 权利人的诉讼目标，往往比传统知识产权案件更”非金钱化”：

• 要求被告公开源码；
• 要求被告在产品中显著标注开源组件与许可证；
• 要求被告保证未来持续合规。

基于此，主动合规（开放源码、完善标注）通常是促成和解的最有效手段。

2) 主动开源与合规的时机

• 越早启动合规（甚至在起诉前主动开源），和解空间越大；
• 若已进入一审程序，仍可通过诉中和解实质性缩小争议；
• 一审宣判后再行合规，能起到减轻二审责任的作用，但无法完全消除判决风险。

3) 和解条款的常见要素

• 公开特定版本的源码（明确 commit hash、tag、构建脚本）；
• 停止分发违规版本；
• 支付和解费用（金额通常显著低于法定赔偿上限）；
• 后续合规承诺与监督机制（如引入定期审计）。

6.5 被诉企业的决策树

以下是企业收到开源诉讼后的简化决策路径：

收到起诉状 / 律师函
├── 步骤 1：证据保全（Git、CI、SBOM、SCA）
├── 步骤 2：评估是否使用了 GPL 代码
│   ├── 确认未使用
│   │   └── 启动技术层抗辩
│   │       ├── 独立相似度分析（SCA + 司法鉴定）
│   │       ├── 在先公开证据链
│   │       └── 反诉恶意诉讼（如对方明显滥诉）
│   ├── 确认使用但已完整开源
│   │   └── 举证已履行 GPL 义务
│   │       ├── 源码仓库公开链接
│   │       ├── 源码与二进制版本对应关系
│   │       └── 履行时间早于起诉时间
│   └── 确认使用但未开源
│       ├── 评估和解路径
│       │   ├── 主动开源
│       │   ├── 支付合理和解费用
│       │   └── 签署未来合规承诺
│       ├── 评估立即合规路径
│       │   ├── 发布符合 GPL 的源码版本
│       │   └── 更新产品中的开源声明
│       └── 评估应诉路径
│           ├── 时效抗辩
│           ├── 权属抗辩
│           └── 相似度下限抗辩
└── 步骤 3：对外沟通与公关策略（与法务统一口径）

对于大多数企业而言，“立即合规 + 协商和解”是成本最低、结果最可预期的路径；坚持”全面应诉”往往意味着更大的时间、资源与品牌声誉成本。

七、企业 GPL 合规的内部流程

7.1 为什么要建立内部合规流程

上述案件表明，GPL 在中国是可执行的。“停止侵权”的判决对商业产品的影响极为严重——一旦被判停止分发，产品的运营将被迫中断。建立系统性的开源合规流程，是规避这类风险的基本工程保障。

7.2 合规流程的核心环节

环节一：引入审查（Ingestion Review）

在引入新的开源依赖时，进行许可证扫描和评估：

# 使用 FOSSA、WhiteSource（Mend）、Snyk 等 SCA 工具进行扫描
# 示例：使用 FOSSA CLI 扫描项目
fossa analyze
fossa test  # 检查是否违反自定义策略

# 使用 ort（OSS Review Toolkit）
ort analyze -i . -o ./ort-results
ort report -i ./ort-results -o ./ort-report

评估标准建议参考本系列第 16 篇（SCA/SBOM）的详细工具链说明。

环节二：分发前合规检查（Pre-Distribution Compliance）

每次对外发布产品（含移动端、服务端、嵌入式）前，执行以下检查清单：

## 开源合规发布前检查单

### GPL 组件
- [ ] 列出所有 GPL/LGPL 组件及版本
- [ ] 确认已提供相应源码（或书面要约）
- [ ] 确认源码与实际分发的二进制版本完全一致
- [ ] 确认提供源码的方式符合 GPL 要求（随附 / 可访问的仓库 / 书面要约）

### 其他 Copyleft 组件（AGPL/MulanPubL 等）
- [ ] 评估是否触发网络提供服务条款
- [ ] 若触发，确认相关源码已开放

### 版权声明
- [ ] 确认所有许可证声明已包含在产品中（Android：NOTICE 文件；iOS：致谢页面；桌面端：关于页面或安装目录）

### 专利风险
- [ ] 确认使用的 Apache 2.0/BSD 组件中无已知专利纠纷

环节三：SCA 工具自动化集成

将 SCA 工具集成到 CI/CD 流水线，在代码合并阶段自动检测许可证变更：

# 示例：GitHub Actions 中的 FOSSA 扫描
- name: FOSSA Scan
  uses: fossas/fossa-action@v1
  with:
    api-key: ${{ secrets.FOSSA_API_KEY }}

7.3 发现问题后的处理流程

若在发布前发现 GPL 合规问题，建议按以下优先级处理：

1. 替换依赖：寻找功能等效的非 GPL 替代库（MIT/Apache 2.0），修改代码替换；
2. 隔离封装：将 GPL 组件封装为独立进程，通过 IPC（进程间通信）调用，避免与主程序形成”紧密耦合”——注意：此方法存在争议，动态链接 vs 进程隔离对 GPL Copyleft 的触发条件，在不同 GPL 版本和不同解释下结论不同（详见本系列第 04 篇）；
3. 开放源码：如果使用 GPL 组件是不可回避的，按 GPL 要求完整开放相应代码；
4. 获取商业授权：若 GPL 项目提供双重授权，与版权持有人洽谈商业授权；
5. 法律咨询：对于不确定的边界情况，向专业法律顾问咨询。

7.4 内部开源政策的建议条款

建议将以下条款纳入公司开源使用政策：

## 开源使用政策（要点节选）

1. 强 Copyleft 限制（GPL/AGPL/SSPL/MulanPubL-2.0）
   - 不得在对外分发的商业产品中使用，除非：
     (a) 已按协议要求完整开放相应源码，或
     (b) 已获得版权持有人的商业授权
   - 使用前需提交开源审查申请，由法务确认

2. 弱 Copyleft（LGPL/MPL）
   - 可以使用，但需要遵守相应的源码开放要求（通常限于修改的库文件本身）
   - 使用动态链接方式，避免触发强 Copyleft

3. 宽松协议（Apache 2.0/MIT/BSD）
   - 可以自由使用，需保留版权声明和许可证声明

4. 禁止修改 LICENSE 文件或移除版权声明

5. 每季度或每次重大发版前进行一次全量 SCA 扫描

7.5 三方 SCA 证据链的建立

SCA 报告不仅是合规流程的日常产物，也是面对诉讼或第三方质疑时的关键证据。建立一条”可追溯、可验证、可公证”的 SCA 证据链，对企业长期的开源风险管理具有重要意义。

1) SCA 工具扫描报告的法律证明效力

在司法实践中，SCA 扫描报告的证明力取决于：

• 工具本身的专业性与业内认可度（主流商业工具通常比自研脚本更容易被法院采信）；
• 扫描过程的可重复性（输入源码哈希、工具版本、扫描参数是否记录完整）；
• 扫描结果与最终产品的对应关系（扫描对象是否就是发布版本）；
• 扫描报告的原始性（是否经过人工修改，是否保留了工具输出的原始摘要、哈希、时间戳）。

2) 如何将 SCA 报告公证

常见的公证方式包括：

• 律师见证：由律师在场见证扫描过程，并出具见证书；
• 公证处公证：由公证员现场记录扫描操作、截屏、保存扫描结果，出具公证书；
• 第三方存证：通过时间戳服务（如国家授时中心 TSA、联合信任时间戳服务中心等）或区块链存证服务对扫描报告进行时间戳固化；
• 公证云服务：部分公证机构提供”电子数据公证”服务，可对扫描过程与结果进行云端公证。

3) CI/CD 系统中的 SCA 扫描日志

CI/CD 流水线中集成的 SCA 扫描会持续产出日志，这些日志是日常合规的”事实档案”：

• 每次构建的 SCA 扫描摘要应写入持久化存储（日志平台、对象存储、长期归档库）；
• 关键版本的 SCA 报告应打 tag、加 checksum、与 Git commit 双向绑定；
• 日志保留时间建议不少于 5 年（覆盖典型的诉讼时效周期）。

4) 推荐工具

不同场景下可以选用的主流 SCA 工具（仅列举，具体选择取决于许可预算、支持语言栈、集成需求）：

• FOSSA：侧重许可证合规与 CI/CD 集成；
• Black Duck（Synopsys）：企业级大型部署，覆盖度高；
• FOSSID / Scanoss：侧重代码片段级的相似度检测；
• ORT（OSS Review Toolkit）：开源工具链，可自主部署；
• Snyk：侧重安全漏洞与许可证联合治理；
• Mend（原 WhiteSource）：企业级 SaaS 方案；
• ClearlyDefined：公共数据集，可辅助验证元数据。

在建立证据链时，建议组合使用 2 种以上独立工具，以便在诉讼中形成交叉验证。

八、工程坑点

8.1 “内部使用不触发 GPL”的边界

GPL 的 Copyleft 义务在对外分发（distribution）时触发。如果代码仅在公司内部使用（不分发给外部用户），GPL 不要求开源。但以下情形可能改变这一判断：

• SaaS 产品：通过网络向外部用户提供的服务不属于传统意义上的”分发”（GPLv2 的经典解读），但 AGPLv3 明确将网络提供服务视为分发；MulanPubL-2.0 的网络条款存在解释空间；
• OEM 预装：将含 GPL 组件的软件预装到设备上并销售，属于分发，需要提供源码；
• 子公司或外包：向子公司或外包商提供含 GPL 代码的产品，取决于具体法律关系，存在争议。

8.2 源码提供的形式要求

GPL 对源码提供的形式有具体要求：

• 随附源码（首选）：直接在分发介质中附带源码；
• 书面要约：在产品中附上书面承诺，承诺在三年内向任何要求者提供源码（GPLv2 Section 3b）；
• 在线托管：GPLv3 允许通过网络服务器提供源码，但需确保服务器可访问且托管时间不短于软件分发期间。

常见陷阱：提供了 GitHub 链接，但 GitHub 上的版本与实际分发的二进制版本不一致（版本号不同、有未提交的修改）。GPL 要求的源码必须与实际分发的二进制完全对应。

8.3 著作权登记的局限性

在中国进行软件著作权登记（版权局登记）不能代替开源合规：

• 著作权登记采用形式审查，不验证代码的实质性独创性；
• 若登记的代码包含了 GPL 代码的修改，该登记不能为违反 GPL 提供保护；
• 著作权登记证书只能证明持有人主张某一时间点对该代码的著作权，不涉及上游许可证的合规状态。

8.4 软件购买合同中的开源声明条款

在向客户销售含开源组件的软件时，建议在合同中明确：

1. 产品使用了哪些开源组件（提供 SBOM 或开源声明文件）；
2. 客户有权根据相应开源协议（如 GPL）行使其权利（如获取源码）；
3. 明确哪些功能/组件是开源的，哪些是公司自有知识产权。

这一透明度不仅是合规要求，也是防止客户事后以”未告知开源成分”为由提出纠纷的保障。

九、选型建议

9.1 产品中含 GPL 组件时的合规操作

9.2 发现 GPL 违规时的紧急处置

如果公司产品被发现违反 GPL（无论是通过内部审查还是外部投诉），建议的紧急处置步骤：

1. 立即暂停分发（若正在对外提供下载或通过 App 商店分发）；
2. 查明涉及的具体 GPL 组件版本和对应源码；
3. 与法务确认是否需要准备应诉材料；
4. 联系权利人（若对方尚未提起诉讼），主动协商合规解决方案——绝大多数 GPL 权利人的目标是代码开源，而非索赔；
5. 完成合规修复（开放源码或替换组件），恢复分发。

主动合规比被动应诉的成本通常低一个量级。数字天堂案等案例表明，中国法院对 GPL 侵权的裁定可以包括停止分发和赔偿损失，对商业产品的影响是实质性的。

9.3 长期合规体系的持续演进

一次性合规修复不足以应对开源生态的持续变化。企业的长期合规能力建设建议围绕以下方向：

• 组件生命周期管理：对每个引入的开源组件建立档案，覆盖引入、升级、替换、退役全过程；
• 许可证变更监控：部分项目在版本迭代中变更许可证（如 Redis、MongoDB、Elasticsearch），需持续监控 upstream 的 LICENSE 变更；
• 自动化策略执行：将合规策略编码为 CI/CD 中的强制门禁，违规合并请求自动阻断；
• 合规培训常态化：将开源合规知识纳入新人入职培训与定期复训；
• 外部审计机制：每年进行一次独立的第三方开源合规审计，作为管理层的风险输入；
• 跨部门协同：工程、法务、安全、采购等部门形成闭环协作，统一处理开源相关的商务合同、安全事件、合规投诉。

长期来看，开源合规不是一次性的项目，而是与企业软件工程实践共同演进的治理能力。

本文为工程参考，不构成法律意见。涉及具体法律风险请咨询专业法律顾问。本文所述事件均来自公开报道与公开判决书，如有偏差以官方渠道为准。

参考资料

1. 数字天堂（DCloud/HBuilder）vs 柚子科技（APICloud）GPL 案：Heather Meeker（FOSS 律师）英文分析文章，2018 年 4 月，介绍北京知识产权法院认定 GPL 在中国具有合同效力的核心认定：First GPL Case in China — or Is It?（heathermeeker.com）；原始中文报道可参考 InfoQ 中文站、OSCHINA 社区及法律媒体；具体判决书编号请以中国裁判文书网（wenshu.court.gov.cn）检索为准
2. 不乱买案相关开源社区讨论：开源中国、V2EX 等社区的早期讨论帖；相关法律媒体的案件整理
3. 罗盒（VirtualApp）GPL 争议：VirtualApp GitHub 主仓库（包含关于商业授权要求与已启动诉讼的官方说明）：github.com/asLody/VirtualApp；业内媒体 InfoQ、Solidot 的报道；具体案号请以裁判文书网为准
4. GPL v2 协议原文：gnu.org/licenses/old-licenses/gpl-2.0.html
5. GPL v3 协议原文：gnu.org/licenses/gpl-3.0.html
6. GPL FAQ（FSF 官方）：gnu.org/licenses/gpl-faq.html
7. 中华人民共和国著作权法（2020 年修订版）：全国人大官网公开文本，特别关注第 52 条、第 53 条、第 54 条关于侵权行为与民事责任的规定
8. 中华人民共和国民法典（2021 年施行）合同编：涉及要约、承诺、合同成立与违约责任的基础条款
9. 北京知识产权法院关于知识产权司法保护的公开政策文件与年度工作报告
10. 最高人民法院关于知识产权案件裁判的指导性文件与司法解释（以最高人民法院官网公开文件为准）
11. 熊文聪、张平、梁志文等学者关于开源许可证效力的学术文章（具体文献以中国知网 CNKI、万方数据、北大法宝等学术数据库的检索结果为准）
12. Welte v. Sitecom 案（2004 年，慕尼黑地区法院）：德国 GPL 执法先例，相关资料可参考 gpl-violations.org
13. Software Freedom Conservancy（SFC）GPL 合规实践指南：sfconservancy.org/copyleft-compliance/
14. Free Software Foundation（FSF）GPL 执法原则：fsf.org/licensing/
15. 中国裁判文书网：wenshu.court.gov.cn
16. 国家版权局软件著作权登记说明：ccopyright.com.cn
17. FOSSA 开源合规工具：fossa.com
18. Black Duck（Synopsys）：blackducksoftware.com
19. OSS Review Toolkit（ORT）：oss-review-toolkit.org
20. Snyk Open Source：snyk.io/product/open-source-security-management/
21. GPL 许可证历史与国际执法概述（英文 Wikipedia），含 gpl-violations.org 相关案例列表：en.wikipedia.org/wiki/GNU_General_Public_License
22. ClearlyDefined 开源元数据数据库：clearlydefined.io
23. 本系列第 04 篇：Copyleft 的工程边界：../04-copyleft-engineering/copyleft-engineering.html
24. 本系列第 16 篇：SCA、SBOM 与软件成分分析：../16-sca-sbom/sca-sbom.html

上一篇：中国开源数据库的协议选择：OceanBase、TiDB、Apache Doris

下一篇：SCA、SBOM 与软件成分分析