一位 20 年老开源程序员：GitHub Copilot 就是开源社区的“寄生虫”。
GitHub 面临集体起诉，索赔 647 亿
GitHub 和它的母公司微软，以及 OpenAI，正在面临一项集体诉讼。诉讼案中，广大程序员们指控 OpenAI 涉嫌违反开源许可。程序员们认为，OpenAI 和微软使用他们贡献的代码训练专有 AI 工具 GitHub Copilot。
据悉，该诉讼已提交到美国加州北区地方法院，要求法院批准 90 亿美元（约 649 亿人民币）的法定损害赔偿金。
根据集体诉讼文件：“每当 Copilot 提供非法输出，它就违反第 1202 条三次，即分发没有（1）注明出处，（2）版权通知，（3）许可条款的许可材料。”
“因此，如果每个用户在使用 Copilot 的整个过程中（早期用户使用 Copilot 最多长达 15 个月之久）只收到一个违反第 1202 条的输出，那么 GitHub 和 OpenAI 就违反了 DMCA 360 万次。每次违反的最低法定赔偿金为 2500 美元，换算后相当于 90 亿美元。”
集体诉讼文件：
GitHub Copilot 项目启动于今年 6 月，其功能是向 GitHub 用户提供代码建议和辅助功能。Codex 是由 OpenAI 开发、并获得微软许可的 AI 系统，Copilot 的各项功能正是基于 Codex AI。
OpenAI 声称，Codex 训练自数百万个公共代码仓库，堪称“代码公平应用的变革性案例”。但 GitHub 程序员们却对此嗤之以鼻，认为 Codex 违反了他们的开源许可条款。这些许可证虽然允许各方对代码进行非商业性分发，但却不得修改，而且还有保留原作者姓名在内的其他一些要求。
律师兼程序员Matthew Butterick领导了这场集体诉讼行动。
Matthew Butterick是一位从业 20 多年的老程序员。他的自我介绍显示，Matthew Butterick 从 1998 年起就参与开源软件贡献了，他曾在 Red Hat 工作过两年，发布过不少开源软件，最近，他又成了 Racket 的贡献者。
今年 6 月，Matthew Butterick 写了一篇关于 GitHub Copilot 法律问题的文章，该文直指 GitHub Copilot 对开源许可证处理不当的问题。
近期，他决定再推进下一步行动——他重新激活了自己的加州律师资格证书，并力邀约 Joseph Saveri 律师事务所与他一道组织这次集体诉讼。
Butterick 在一份新闻稿中指出，Copilot 从一开始就明显存在法律问题。“作为拥有多年经验的开源程序员，我在第一次试用时就感受到了其中的问题。而且相信其他很多开发者也跟我一样，发现 Copilot 不对劲。结合自身法律背景，我觉得有必要拿起法律武器支持开源社区。”
其他 Copilot 用户也在自己的社交平台中吐槽，Copilot 在所生成的代码中使用了错误的许可证，而且在未进行来源归因的前提下盲目向用户提供版权代码。
面对关于此次诉讼的置评请求，GitHub 方面一位发言人表示，他们致力于通过 Copilot 开展负责任的创新。
早在 2018 年微软收购 GitHub 时，很多用户就对这个全球规模最大的开源社区将走向何方展开过讨论。微软曾在 2000 年代和 1990 年代向开源操作系统 Linux 发起过一系列攻击，宣称这款系统侵犯了 235 项微软专利。
原告方律师 Joseph Saveri 表示，他感谢程序员和用户们为这起诉讼做出的努力。他还提到，OpenAI、微软和 GitHub 绝不可以用这种毫无公平性可言的方式，从开源贡献者的成果中获利。
“此案是针对 AI 系统在科技行业内引发知识侵权争议的第一步。在本案中，AI 系统利用了程序员们做出的开源编程贡献，并将影响到众多创作者。我们就是要代表这些创作者们的利益，确保 AI 开发企业必须遵照法律要求行事。”
此次诉讼表明，程序员、艺术家等群体越来越关注 AI 系统在未经许可之下使用他们的代码、作品或其他数据的问题。图形生成类 AI 工具（包括 DALL-E 和 Stable Diffusion 等）就在使用算法从互联网上抓取数十亿条数据，且完全没有考虑过任何许可或所有权限制。正是由于这种版权归属争议的存在，Shutterstock 和 Getty Images 等公司才禁止在其平台上使用 AI 生成图像。
Butterick 声称，微软将开源代码训练而成的 Copilot 作为商业产品提供给程序员的行为，不仅侵犯了开源代码版权，也打击了人们参与开源社区的热情。Butterick 因此认为，微软这种将开源代码与开源社区强行割裂的行为，有违开源编程精神。
Copilot 的问题在哪？
此前，Matthew Butterick 还开设了一个专门针对 GitHub Copilot 的调查网站，调查收集 GitHub Copilot 违反其对开源作者和最终用户的法律义务的线索。
Matthew Butterick 认为，总结而言，Copilot 在系统训练与系统使用方面都存在法律问题。
（备注：以下论断仅代表 Matthew Butterick 个人观点）
系统训练
绝大多数开源软件包是在授权许可之下发布的，在授予用户一定权利的同时也要求其承担一定义务（例如保留源代码的精确属性）。而这种授权的合法实现方式，就是由软件作者在代码中声明版权。
因此，要想使用开源软件，大家就必须做出选择：
要么遵守许可证所规定的义务；要么使用那些属于许可证例外的代码（即版权法所规定的「合理使用」情形）。微软和 OpenAI 已经承认，Copilot 和 Codex 就是由 GitHub 上开源软件的公共 repo 训练而成。所以在这两条路里，他们到底要走哪条？
如果微软和 OpenAI 决定基于各 repo 的开源许可来使用这些训练素材，那就得发布大量属性（attribution），这已经算是各类开源许可的底限要求了。但截至目前，我们还没有看到任何属性声明。
这样一来答案就明确了，微软和 OpenAI 必须找到“合理使用”的理由。GitHub 前 CEO Nat Firedman 就曾在 Copilot 的技术预览会上提到，“在公开数据上训练（机器学习）系统属于合理使用的范畴。”
但真这么简单吗？对于这种法律问题，可不是说属于就属于的。当然，微软、OpenAI 和其他多家研究机构一直在强调这种“合理使用”的论点。Nat Firedman 还曾放话说，作为“机器学习社区所广泛依赖的”依据，这种“合理使用”办公室有其“法理基础”。然而，软件自由保护组织（SFC）明显不同意他的观点，并要求微软方面提供能支持其立场的证据。
保护组织负责人 Bradley Kuhn 指出：我们曾在 2021 年 6 月私下询问过 Firedman 和其他几位微软/GitHub 代表，要求他们为 GitHub 的公开法律立场提供可靠的参考依据……但他们什么都拿不出来。
为什么微软拿不出支持立场的法律依据？因为保护组织说得没错：他们根本找不出依据来。尽管一些法院已经考量过相关问题，但目前全美还没有哪个判例能够直接解决 AI 训练中的“合理使用”问题。
另外，所有涉及“合理使用”的案例均权衡了大量相关因素。即使法院最终判定某些类型的 AI 训练属于“合理使用”，也不代表其他类型的训练就能无脑照办、高枕无忧。就目前来看，我们还不知道 Copilot 和 Codex 到底合不合法，微软和 OpenAI 其实也说不准。
系统使用
虽然没法确定“合理使用”最终要怎么在 AI 训练中落地，但可以想见，其结果并不会影响到 Copilot 用户。为什么呢？因为用户只是在使用 Copilot 提供的代码，而这部分代码的版权和许可状态同样模糊不清。
微软倒是有自己的说法。2021 年，Nat Friedman 曾声称 Copilot 的输出结果归属于操作者，其性质与使用编译器一样。但 Copilot 已经暗暗给用户挖好了坑。
微软将 Copilot 输出描述为一系列代码“建议”，并强调不会对这些建议“主张任何权利”。但与此同时，微软也不会对由此生成的代码的正确性、安全性或延伸出的知识产权问题做任何保证。所以只要接纳了 Copilot 的建议，那这些问题就都要由用户自己承担。
“您需要对自己代码的安全性和质量负责。我们建议您在使用由 GitHub Copilot 生成的代码时，采取与使用其他一切非本人所编写代码相同的防范措施，包括严格测试、IP（知识产权）扫描和安全漏洞跟踪。” ....
有观点认为，Copilot 将版权遵循义务留给了用户。随着 Copilot 的不断改进，用户需要承担的责任也将越来越大。
那这些建议真会惹出麻烦来吗？已经有 Copilot 用户控诉，Copilot 可能存在一种设计倾向，会从可识别的 repo 处一字不差地照搬代码。前段时间，得克萨斯农工大学教授 Tim Davis 也列举了不少证据，表明 Copilot 确实原样照抄了他的大段代码，特别是极具个人风格的/Tim Davis 稀疏矩阵转置/。
使用这样的代码，当然会产生相应的许可遵守义务。但从 Copilot 的设计来看，用户完全接触不到代码的来源、作者和许可证。根本无一物，拿什么去遵守？
从这个角度看，Copilot 的代码检索方法就像一颗烟雾弹，下面掩盖的是肮脏的真相：
Copilot 本身，只是连通海量开源代码的一套替代接口。只要用上它，用户可能就需要承担起代码原作者提出的许可义务。意识到这一点，Nat Firedman 所谓 Copilot“不像是编译器”的说法根本不靠谱。毕竟编译器只会改变代码形式，但绝不会注入新的知识产权属性。微软当然也清楚这一点，所以他们并没有嘴硬到底，只是把这些细节用小字“略微”说明了一下。
Copilot 的本质：一只“寄生虫”？
通过将 Copilot 当作海量开源代码的替代接口，微软不仅借此切断了开源作者与用户之间的法律关系，甚至建立起新的“围墙花园”——阻止程序员接触传统开源社区，从而消除了他们为之贡献的可能性。随着时间推移，这势必会让开源社区变得愈发贫乏。用户的注意力和参与方向将逐渐朝着 Copilot 转移，最终彻底告别开源项目本身——告别源代码 repo、告别问题跟踪器、告别邮件列表、告别讨论板。这样的变化必将给开源带来痛苦、甚至永远无法挽回的损失。
就连微软云计算负责人 Scott Guthrie 最近也承认，虽然微软 CEO 纳德拉当初收购 GitHub 时曾承诺“让 GitHub 继续保持开放平台的地位”，但微软一刻也没有放慢过把 GitHub 服务（包括 Copilot）纳入自家 Azure 云平台的脚步。
Matthew Butterick 表示，包括他自己在内的开源开发者之所以提出抗议，所图的绝不是钱，只是不想让自己的努力贡献被白白浪费掉。开源软件的核心在于人，在于由人组成的用户、测试者和贡献者社区。正是因为有了这样的社区，我们才能以超越自身的方式改进软件，让工作充满乐趣。
Copilot 则向开源软件注入了自私的基因：我想要什么，你就得给我什么！Copilot 的建议将开源用户与软件开发者彻底割裂开来，导致他们永远不必与社区互动、更遑论为更多项目做出贡献。
与此同时，开源软件作者也需要注意到，我们的工作成果被掩盖在了 Copilot 这块大布之下。我们成了牧场里的奶牛、成了《黑客帝国》中为母体供电的电池，我们成了不断为 Copilot 注入资源的“人肉矿脉”。
但就连奶牛也能靠劳动换取牧草和牛棚，而 Copilot 不会对我们的个人项目乃至整个开源社区做出丝毫反哺。
Copilot 建立的围墙花园与开源明确对立，而且危害极大。这也是对微软当初收购 GitHub 时所做承诺的赤裸背叛。早期接触过 GitHub 的朋友应该还记得，GitHub 之所以能在受众当中建立起良好的声誉，靠的就是真正服务于开源开发者、培育开源社区的赤子之心。而 Copilot 的出现显然背离了这一路线，也是对 GitHub 立身之本的无情践踏。
也许有人会说，那咱们就听保护组织的建议，把代码搬出 GitHub 吧。但这真的没什么作用。只要微软能把 AI 训练成功规定成“合理使用”，那么不只是 GitHub，互联网上的一切公共代码 repo 都逃不出他们的手掌心。如果坐视一切发展下去，那么 Copilot 不仅会吞噬 GitHub 上的开源代码，更会淹没世界上的每一行开源成果。
另一方面，有些朋友可能对 Copilot 评价不错，觉得 AI 代表着未来方向。拜托，我们这里反对的绝不是 AI 辅助编程工具，而是微软在 Copilot 当中的种种具体行径。其实微软完全可以把 Copilot 做得更开发者友好一些——比如邀请大家自愿参加，或者由编程人员有偿对训练语料库做出贡献。但截至目前，口口声声自称热爱开源的微软根本没做过这方面的尝试。另外，如果大家觉得 Copilot 效果挺好，那主要也是因为底层开源训练数据的质量过硬。Copilot 其实是在从开源项目那边搞生命虹吸，而一旦开源活力枯竭，Copilot 也将失去发展的依凭。
在之前讨论 Copilot 的时候，我曾说“我并不担心它对开源的影响。”现在也是，如果从短期来看，Copilot 还不足以威胁整个开源生态。但回顾自己近 25 年来的开源之旅，我发现这东西的存在本身就是最大的问题。毕竟开源靠的不是一支固定的队伍，而是一种不断成长、不断变化的集体智慧，它需要持续吸引新鲜头脑来完成自我更新。开源参与者们彼此设定新的标准与挑战，也共同拉高了开源成就的期望标杆。
在这场奇妙而盛大的化学反应中，Copilot 横空杀出，想要把整个开源宇宙据为己有。哪怕抛开微软那劣迹斑斑的开源记录，我们也能一眼看出 Copilot 的本质——一只寄生虫。因此在对开源世界造成无法弥补的伤害之前，我们必须质疑 Copilot 的合法性。
参考链接：
InfoQ高级技术编辑
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论