Copilot是开源社区的「寄⽣⾍」？作为⼀名开发者，或许你不介意GitHub Copilot未经询问就使⽤了你的开源代码。但如果，Copilot逐渐抹去整个开源社区，你会有什么感受？近⽇，程序员Matthew Butterick（同时他也拥有作家和律师身份）在个⼈博客中控诉了Copilot，并宣布开展诉讼调查。
2022年6月，我写了⼀篇关于GitHub Copilot法律问题的⽂章，特别是它对开源许可证的处理不当。
最近，我采取了下⼀步⾏动：我重新激活了我的加州律师资格，与Joseph Saveri律师事务所的优秀集体诉讼律师Joseph Saveri、Cadio Zirpoli和Travis Manfredi合作开展⼀个新项⽬——我们正在调查针对GitHub Copilot违反其对开源作者和最终⽤户法律义务的潜在诉讼。GitHub Copilot是微软在经过⼀年的技术预览后于2022年6月正式发布的产品。
Copilot是Visual Studio和其他IDE的插件，可根据在编辑器中键⼊的内容⽣成所谓的「建议」。那么，Copilot与传统的⾃动补全功能有什么不同？Copilot由Codex提供⽀持，这是⼀个由OpenAI开发并授权给微软的AI系统。（尽管微软也被称为「OpenAI的⾮官⽅所有者」。
）Copilot会根据⽤户输⼊的⽂本prompt提供建议，⼀般可⽤于提出⼩的建议，但微软强调Copilot能够建议更⼤的代码块，例如函数的整个主体。但是其底层AI系统Codex是如何训练的呢？据OpenAI称，Codex接受了「数以千万计的公共存储库」的训练，包括GitHub上的代码。微软⾃⼰含糊地描述为「数⼗亿⾏公共代码」。
但Copilot研究员Eddie Aftandilian在最近的播客中证实，Copilot是「在GitHub上的公共存储库上训练的」。Copilot有什么问题？本⽂作者Matthew Butterick认为，⽆论是训练还是使⽤，Copilot都存在法律问题。训练中的法律问题绝⼤多数的开源软件包是在授权许可下发布的，授予⽤户⼀定的权利并强加⼀定的义务（例如保留源代码的精确属性）。
这些授权的合法实现⽅式是作者在他们的代码中声明他们的版权（copy-right）。因此，那些希望使⽤开源软件的⼈必须做出⼀个选择，要么遵守许可证上规定的义务，要么使⽤从属于「许可证例外」的代码（如版权法下的「合理使⽤」）。微软和OpenAI已经承认Copilot和Codex是在GitHub上公开repo中的开源软件上训练的。那么，他们选的是哪条路呢？
如果微软和OpenAI选择在每个repo的开源许可下使⽤这些repo，那么他们将需要发布⼤量的attri-bu-tion，因为这⼏乎是每个开源许可的最低要求。然⽽，我们现在看不到任何attri-bu-tion。因此，微软和OpenAI必须找到⼀个「合理使⽤（fair-use）」的理由。
GitHub前CEO Nat Fried-man在Copilot的技术预览会上曾经说过，「在公开数据上训练（机器学习）系统属于合理使⽤。」事实真就如他所说吗？这是⼀个法律问题，不是谁说了就算的。当然，微软、OpenAI和其他研究机构⼀直在⽀持「合理使⽤」的论点。Nat Fried-man曾进⼀步断⾔，「机器学习社区所⼴泛依赖的」关于「合理使⽤」的「法理」是存在的。
但是软件⾃由保护组织（Software Freedom Conservancy，SFC）不同意他的观点，并要求微软提供证据来⽀持其⽴场。SFC负责⼈曾透露：我们在2021年6月私下询问了Fried-man和其他微软、GitHub的代表，要求他们为GitHub的公开法律⽴场提供可靠的法律参考……但他们什么都没有提供。为什么微软不能为他们的⽴场提供⼀些法律依据？因为SFC是对的：他们根本就没有依据。
尽管⼀些法院已经考虑了相关问题，但⽬前还没有⼀个美国的判例直接去解决AI训练的「合理使⽤」问题。此外，那些涉及「合理使⽤」的案例也是平衡了多重因素。即使法院最终裁定某些类型的AI训练是「合理使⽤」的（这似乎是有可能的），它也可能将其他类型的训练排除在外。到今天为⽌，我们还不知道Copi-lot或Codex在这个范围内处于什么位置。微软和OpenAI也不知道。
使⽤中的法律问题我们还不能说「合理使⽤」最终将以何种⽅式应⽤于AI训练。但我们知道，这⼀发现完全不会影响Copi-lot⽤户。为什么？因为他们只是使⽤Copi-lot来给出代码。那么，这部分代码的版权和许可状态是怎样的呢？2021年，Nat Fredman声称，Copilot的输出属于操作者，就像他们在使⽤编译器⼀样。但Copilot为粗⼼的⼈设置了新的陷阱。
微软将Copilot的输出描述为⼀系列代码「建议」。微软在这些建议中「不主张任何权利」。但同时，微软也没有对这样⽣成的代码的正确性、安全性或扩展出的知识产权问题提供任何保证。⼀旦你接受了Copilot的建议，所有这⼀切都成了你的问题。你要对你代码的安全性和质量负责。
我们建议您在使⽤由GitHub Copilot⽣成的代码时采取与使⽤其他任何⾮本⼈所写代码时相同的预防措施，包括严格的测试、IP扫描和安全漏洞跟踪。这些建议的代码会有什么问题？已经有Copilot⽤户指出，Copilot可能会被诱导从可识别的repo中⼀字不差地复制代码。前段时间，得克萨斯农⼯⼤学教授Tim Davis给出了很多例⼦来说明Copilot确实逐字复制了他的代码。
使⽤此代码显然就产⽣了遵守其许可的义务。但是根据Copilot的设计，⽤户根本看不到代码的来源、作者、许可等信息，⼜怎么去遵守呢？本⽂作者Matthew Butterick认为，Copilot的快速代码检索⽅法就是⼀种烟雾弹，⽬的是掩盖⼀个肮脏的真相：Copi-lot只是⼀个连接⼤量开源代码的⽅便的替代界⾯。因此，Copilot⽤户可能会承担代码原作者施加给他们的许可义务。
在这种背景下，Natfredman声称Copilot的操作「就像……⼀个编译器」是相当站不住脚的，因为编译器改变了代码的形式，但它们不注⼊新的知识产权属性。公平地说，微软并没有对此提出异议。他们只是把它埋在了⼩字⾥。Copilot对开源社区意味着什么？Matthew Butterick指出，通过提供Copilot作为⼤量开源代码的替代接⼝，微软所做的不仅仅是切断开源作者和⽤户之间的法律关系。
可以说，微软正在创建⼀个新的「围墙花园」，它将阻⽌程序员去发现传统的开源社区，或者⾄少，消除⼀切这样做的动机。随着时间的推移，这个过程将使这些社区变得贫乏。⽤户的注意⼒和参与度会逐渐转移到Copilot的围墙花园，远离开源项⽬本身——远离他们的source repo、他们的issue track-er、他们的邮件列表、他们的dis-cus-sion board。
这种能量的转变对于开源来说将是痛苦的、永久的损失。微软云计算执⾏官Scott Guthrie最近承认，尽管微软CEO Satya Nadella在收购GitHub时做出了「GitHub仍将是⼀个开放平台」的乐观承诺，但微软⼀直在推动更多GitHub服务（包括Copilot）进⼊其Azure云平台。Matthew Butterick表示，他们并不是⽆缘⽆故向GitHub发起诉讼。
他认为，发布开源软件的⼀⼤好处是「⼈」：围绕我们⼯作的⽤户、测试⼈员和贡献者社区。「我们的社区帮助我们以⽆需靠⾃⼰的⽅式改进软件，这使⼯作变得有趣」。Copilot向开源软件引⼊了更「⾃私」的界⾯：只给我想要的（just give me what I want）！使⽤Copilot，开源⽤户永远不必知道谁制作了他们的软件，永远不必与社区互动，永远不必做出贡献。
同时，Matthew Butterick提醒说，开源作者必须注意到，我们的⼯作被隐藏在⼀个名为Copilot的⼤型代码库中。就像农场中的⼀头奶⽜，Copilot只想将我们转变为要开采的资源的⽣产者。「即使是奶⽜也能从交易中获得⻝物和住所，⽽Copilot对我们的个⼈项⽬没有任何贡献。」Matthew Butterick认为，Copilot的围墙花园与开源是对⽴的，且存在危害。
因此，这也是对GitHub在被微软收购之前所代表的⼀切的背叛。如果你出⽣于2005年之前，肯定会记得GitHub的声誉是建⽴在其为开源开发⼈员提供好东⻄和培育开源社区的基础上的。相⽐之下，Copilot是这个想法的多重疯狂反转。换个⻆度说，也许你是Copilot的粉丝，认为AI是未来。⾸先，这⾥反对的不是⼀般的⼈⼯智能辅助编程⼯具，⽽是微软对Copilot的具体选择。
我们可以很容易地想象⼀个对开源开发⼈员更友好的Copilot版本——例如，参与是⾃愿的，或者编码⼈员有偿为训练语料库做出贡献。⽬前看来，尽管⾃称热爱开源，但微软没有选择这些选项。其次，如果你发现Copilot有价值，很⼤程度上是因为底层开源训练数据的质量。Copilot从开源项⽬中汲取⽣命，最直接的影响将是让Copilot变得更糟。
Matthew Butterick表示，「当我第⼀次写Copilot时，我说过：『我不担⼼它对开源的影响。』短期内，我仍然不担⼼。但当我回顾⾃⼰近25年的开源之旅时，我意识到我错过了更⼤的图景。毕竟，开源不是固定的⼀群⼈。这是⼀种不断增⻓、不断变化的集体智慧，不断被新鲜的思想更新。我们为彼此设定了新的标准和挑战，从⽽提⾼了我们对取得成就的期望。在这场盛⼤的炼⾦术中，Copilot闯⼊了。
它的⽬标是把开源的能量据为⼰有。我们⽆需深⼊研究微软在开源⽅⾯的曲折历史，就可以了解Copilot的本质——寄⽣⾍。在对开源的损害变得⽆法弥补之前，我们必须测试Copilot的合法性。这就是我想申明的原因。」