学习笔记:从GitHub Copilot 百亿集体诉讼案(Doe v. GitHub)学习开源软件风险识别
案件概览
| |
|---|
| 案号 | 4:22-cv-06823-JST（地区法院）；24-7700（Ninth Circuit上诉） |
| 诉讼法院 | |
| 审理法官 | Jon Steven Tigar（地区法院）；Ninth Circuit Panel（上诉法院） |
| 诉讼类型 | |
| 被告 | GitHub, Inc.、Microsoft Corporation、OpenAI, Inc.、OpenAI, L.P.等 |
| 原告代表 | |
| 原告律师 | Joseph Saveri Law Firm、Matthew Butterick |
| 起诉日期 | |
| 现阶段 | |
一、案件背景与当事人
核心事实：
GitHub Copilot 是由 GitHub 开发、OpenAI 提供技术支持的 AI 代码生成工具。原告指控该工具利用 GitHub 上托管的大量公开代码库进行训练，其中包括受著作权保护且以多种开源许可（如 MIT、GPL、Apache 等）发布的源代码。
原告主张：
Copilot 在生成代码建议时，往往直接再现或几乎完全复制了受许可的代码，但并未履行开源许可协议要求的署名/归属义务，也未保留原始代码中的版权管理信息。
诉讼当事人：
原告： 5名化名的软件开发者（Doe 1-5），代表一个可能包含数百万GitHub用户的“拟议集体”
二、案件争议焦点
该案的争议核心在于 AI 时代的著作权保护边界，主要聚焦于以下三个维度：
DMCA 的“同一性要求”：DMCA 第 1202(b) 条禁止故意移除或修改版权管理信息。目前最大的争议在于，AI 输出的代码是否必须与原件完全相同才能触发该条款。
开源许可证的法律效力：开源许可证是仅仅作为指引性声明，还是具有强制约束力的合同？违反这些条件是否构成著作权侵权？
AI 训练的“合理使用”：将海量代码用于机器学习是否属于“转换性使用”，从而免除侵权责任？
三、双方主张及其法律依据
原告（开发者）的主张与理由
违反 DMCA 第 1202 条：代码头部的版权声明、作者姓名、许可条款链接均属于 CMI。Copilot 在训练中摄取这些信息，但在输出代码时将其“剥离”，属于故意隐瞒侵权行为。合同违约：开源许可证是开发者在 GitHub 发布代码时形成的单方面合同要约，被告通过使用这些代码即接受了要约。被告未能履行署名和保留许可声明的义务，属于严重的合同违约。依据判例：引用 Jacobsen v. Katzer (2008)，主张违反开源许可条款等同于失去许可，从而构成著作权侵权，许可证条款具有强制执行力。:::被告（GitHub/微软/OpenAI）的主张与理由
缺乏诉讼资格：原告匿名，且未能证明其代码确实被 Copilot 实际重现，因此没有受到“具体且个性化”的伤害。支持“同一性要求”：只有当 CMI 被移除的作品副本与原件完全相同时才构成违法。AI 输出往往是“衍生作品”或经过修改的，不符合 DMCA 针对“副本”的定义。著作权抢占：原告提出的许多州法索赔本质上是在寻求著作权法的保护，应被联邦著作权法“抢占”或排除。合理使用辩护：AI 训练是为了学习编程模式而非使用代码本身，具有高度的转换性，且不会损害原始免费开源代码的市场。
四、法院立场与案件现状
地区法院裁定（Tigar 法官）
上诉法院现状（Ninth Circuit）
争议焦点： “同一性标准”在 AI 时代是否应被放宽五、本案的核心合规启示
tip 1. 重新认知开源许可证的法律地位
许可证即条件： 违反许可证条款不仅是合同违约，更会导致许可自动终止。一旦失去许可，企业的行为将直接转为著作权侵权，面临禁令或高额赔偿。“免费”不等于“弃权”： 即使代码是开源的，其著作权依然属于原作者，许可证只是“有条件”的授权。tip 2. 核心风险维度的识别：DMCA 与 CMI 的完整性
CMI 的构成： 包括作者姓名、版权所有者标识、使用条款以及指向许可证的链接。故意移除的风险： 根据 DMCA § 1202(b)，故意移除或修改 CMI，且明知该行为将诱导或掩盖侵权，即构成违法。tip 3. 区分“训练”与“输出”的法律责任
生成/输出阶段： 当 AI 输出与受许可代码高度相似时，被告必须履行原始许可义务。合规启示： 不仅要关注模型是怎么训练的，更要关注 AI 辅助生成的代码是否“内化”了高风险许可证的逻辑。tip 4. 复杂协议下的“传染性”与兼容性识别
Copyleft 义务的触发： 强传染性协议要求基于其开发的衍生作品必须以相同协议开源。协议兼容性冲突： 当项目混合使用多种协议的代码时，需评估其法律风险。tip 5. 合规管理的技术手段与标准
技术工具： 引入 SCA 工具自动识别代码库中的第三方依赖及许可证。通过 SBOM 标准记录组件来源和版本。国际标准： 参考 ISO/IEC 5230 (OpenChain) 标准建立合规政策。
扩展学习：
Q1：了解了开源协议的三种主要类别及其风险，是不是就够了？还有哪些认知误区？
A：只了解三大类协议类型（宽松型 Permissive、弱传染型 Weak Copyleft、强传染型 Strong Copyleft），相当于只认识了“红绿灯”，但还没学会“开车上路”。还需要认识到以下问题：
1.1许可证兼容性问题（License Compatibility）很多时候，风险不来自于单一开源组件，而来自于多个组件的组合。如果软件同时使用了遵循 Apache 2.0 的代码和遵循GPL v2 的代码，它们能合并在一起发布吗？答案是不能（GPL v2 与Apache 2.0 不兼容）。所以合规不仅要看单个协议的风险，还要审查项目中不同开源协议之间是否会发生“排异反应”（冲突）。认知误区：
A.误以为协议是一成不变的
同一个项目，版本升级可能换协议。比如从GPLv2升到GPLv3，多了专利条款和反DRM条款。原来合规的版本，升级后可能直接违规。
B.只看主代码，不看依赖性传导问题项目表面用的是MIT协议，但它依赖的一个底层库是GPL。结果：整个项目被传染。
C.把“开源协议”等同于“商业合同”开源协议是单方要约，不是双方谈判签的合同。用了就是同意，没有商量余地。违反条款不是违约，是侵权——许可直接失效。
D.以为开源=免费=放弃权利开源是基于版权法的授权行为，不是放弃版权。原作者保留着著作权，只是通过许可证给了你使用权限。不遵守条件，权限收回。
E.Apache 2.0 和 GPL v2 具体是什么？为什么说它们不兼容？用两个比喻来解释：
Apache 2.0：像一位慷慨的富翁
规则：代码可以随便用、随便改，改了以后不想公开也行，做成商业软件卖钱也行GPL v2：像一位严格的共享主义者
规则：代码可以免费用，但如果把这段代码和你的代码混在一起做成新软件分发出去，你的代码也必须免费公开冲突原因：假设一碗饭里同时有两个人定的规矩——A说“你可以把配方藏起来”，B说“你必须公开配方”。这两个指令相互矛盾，没法同时遵守。所以法律上不允许把这两种代码混在一起发布。
1.2“分发”的界定与 SaaS 模式的挑战（The "Distribution" Trigger）
绝大多数开源协议（尤其是 GPL 等传染型协议）的义务触发条件是分发（Distribution）问题在于：在传统的软件售卖时代，“分发”很容易界定（卖光盘、提供下载）。但在 SaaS（软件即服务）时代，用户通过浏览器使用软件，代码并没有下载到用户电脑上。这在传统 GPL 看来不属于分发，从而规避了开源义务（被称为 SaaS 漏洞）。所以要必须特别警惕 AGPL (Affero GPL) 协议。AGPL 专门堵上了这个漏洞，规定通过网络提供服务也视同分发，必须开源后端代码。1.2.1AGPL 协议是什么意思？卖软件安装包和做云服务这两种商业模式，对合规有什么不同影响？
A：先理解绝大多数开源协议的触发开关：“分发”。
商业模式A：卖软件安装包（传统模式）场景：开发了一个软件，打包成.exe或.app，让用户下载安装到自己的电脑/手机上。后果：代码实实在在地到了用户手里，这构成了“分发”。如果用了GPL代码，必须把源代码也给用户。
商业模式B：做云服务/SaaS（现代模式）场景：开发了一个在线系统，软件运行在公司自己的服务器上。用户通过网页浏览器使用，代码没下载到用户电脑。后果：代码没给用户，传统GPL认为这不属于“分发”。这就是著名的“SaaS漏洞”——云厂商可以白嫖开源代码做服务赚钱，却不用开源自己的代码。
AGPL 的诞生：开源社区为了堵这个漏洞，制定了AGPL。规定：只要用户通过网络连上服务器使用这个软件，就视同分发。
致命后果：做云服务的公司，如果后端服务器不小心用了AGPL代码，整个后端核心商业代码都必须开源。对SaaS公司来说，这是核心资产被强制公开的风险。
1.3 传递依赖与 SBOM（软件物料清单）
问题所在：研发同学告诉你：“我只引入了 A 组件（MIT协议），没风险。” 但 A 组件在底层可能依赖了 B，B 又依赖了 C（GPL协议）。这种“拔出萝卜带出泥”的现象叫传递依赖。所以，合规审查不能只看直接引入的库。必须要求研发提供完整的SBOM（软件物料清单），并借助 SCA（软件成分分析）工具进行自动化扫描。1.3.1传递依赖问题怎么识别？研发不提供SBOM怎么办？A：传递依赖是什么：研发说“我只引入了A组件，MIT协议”。但A组件底层依赖了B，B又依赖了C——C是GPL协议。结果：整个项目被GPL传染。
SCA工具能解决吗：能。只要代码进了仓库，SCA工具会自动扫描，顺藤摸瓜把底层隐藏的“毒药”全扫出来。
研发不提供SBOM怎么办：不需要指望研发手工填写——他们自己都不知道底层依赖了啥。
正确做法：
研发一提交代码，工具自动扫描，自动生成SBOM，自动报警这是用技术手段管合规，不是用人情求研发配合。
1.4“伪开源”与商业源码可用协议（Source-Available）
问题在于：近年来，很多知名开源项目（如 MongoDB, ElasticSearch,Redis, HashiCorp Terraform）为了防止云厂商“白嫖”，纷纷修改了协议（如 SSPL, BSL, RSAL）。
这些协议不是 OSI（开源促进会）认可的真正开源协议，它们通常对商业化使用有极其严格的限制。合规同学看到这些项目时，必须当做商业软件来审查，绝不能当成普通开源软件。
1.4.1 SSPL、BSL、RSAL 这些协议是什么意思？A：这三个都不是OSI认证的真正开源协议，叫“商业源码可用协议”。诞生的目的只有一个：防止云厂商白嫖。
SSPL（服务器端公共许可证）代表项目：MongoDB核心条款：代码可以免费用。但如果把MongoDB包装成云服务卖给别人，不仅要把修改的MongoDB代码开源，还要把所有用于管理、备份、监控这个云服务的周边代码全部开源。效果：基本断绝了别人拿它做云服务的可能性。
BSL（商业源码许可证）代表项目：Elasticsearch、Terraform核心条款：测试环境或非商业用途，免费。但如果在生产环境用它赚钱，且跟原作者构成商业竞争，必须买商业授权。特殊机制：代码发布几年后（通常3-4年），自动变成真正的开源协议（如GPL）。
RSAL（Redis源码可用许可证）代表项目：Redis核心条款：可以内部使用。但不能用它开发与Redis竞争的数据库产品、缓存引擎或云服务。
审查要点：看到这三个协议，直接当商业软件对待——仔细评估使用场景是否触碰红线。
2.是不是“发现发现使用的开源软件违规了，删掉换一个就行”A：“没出事”不代表“没风险”，这叫幸存者偏差。
后果1：上市/融资失败IPO或被收购时，投资人会做技术尽职调查。一旦扫出核心产品侵犯GPL，投资人会认为产品有被强制开源或下架的风险。结果：融资失败或估值大跌。
后果2：版权流氓敲诈国外有专门盯着大公司的“版权流氓”。发现违规直接发律师函，索赔几百万美金，甚至申请禁令让产品立即停售。
3.公司内部用是否也会触发GPL？GPL只在“对外分发”时才触发。如果公司只是拿GPL软件做内部的考勤系统、内部测试工具——基本没有风险，不需要被迫开源。
不懂这个的后果：合规人员如果把内部使用的GPL软件也禁掉，会导致研发无法使用大量免费工具，严重降低开发效率。法务和研发的矛盾，往往就是这么来的。
4.静态链接、动态链接、API调用、容器化、依赖包管理，这些技术名词是什么意思？A：
静态链接（像榨果汁）场景：把草莓（开源代码）和香蕉（你的代码）放进榨汁机打碎混在一起。合规意义：两者彻底融为一体。如果草莓是GPL，整杯果汁都被传染，必须全部开源。风险极高。
动态链接（像水果沙拉）场景：草莓（开源代码）和香蕉（你的代码）放在同一个碗里，但它们是独立的块，可以把草莓挑出来换成苹果。合规意义：两者相对独立。在LGPL等协议下，只要动态链接，香蕉（专有代码）就不会被传染，不需要开源。
API调用（像去餐厅点菜）场景：你的代码（顾客）对开源软件（厨房）喊“来盘鱼香肉丝”（发请求），厨房做好后端出来（返回结果）。没进厨房，没交换菜谱。合规意义：最松散的结合方式。通常不会触发传染性，风险极低。
容器化（像海运集装箱）场景：以前软件搬家很麻烦。Docker就是把软件和它需要的所有环境，打包进一个标准化“集装箱”，放哪都能跑。合规意义：Docker镜像里往往打包了成百上千个底层开源组件（甚至整个操作系统）。合规扫描不能只看写的代码，必须扫整个镜像。
依赖包管理（像自动代购机器人）场景：研发写代码需要工具A。不用自己去找，只要在清单里写一行“我要工具A”。Maven（Java用的）、npm（前端用的）、pip（Python用的）——这些工具会自动去网上下载工具A，以及工具A需要的所有其他工具。合规意义：自动代购的过程，可能会拉进来一堆意想不到的“赠品”（底层依赖）。这些赠品里，可能藏着GPL。
