“请不要在 GitHub 上传我的代码！”穿浴巾、内衣外露，聂小雨拜师小杨哥，为博流量已经不择手段？

重新整理 | 郑丽媛公司出品 | CSDN（ID：CSDNnews）

对绝大多数开发人员来说，GitHub 是两个奇妙的开放源码街道社区：有多样的自学数据资料、知名的工程项目标识符，初学者阿宝也能和程式设计元老直接沟通交流，徐鼎“填坑”也能提升人格……

因此，可能极难没人Illiers，有一天 GitHub 竟成为了开发人员杯葛的存在——本周一有位开发人员（下列用 “T” 代指）写的该文荣登了 Hacker News 热榜，副标题是：“请千万别在 GitHub 上载我的标识符！”

“元凶”：Copilot

虽说，看见这个副标题，坚信许多人的第三化学反应是：GitHub 怎么了，有什么难题吗？为此，T 在该文“直截了当”地表示：“GitHub 有许多难题，其中

要说，被开发人员视作“AI 代码宝物”的 Copilot，是“元凶”。

根据非官方如是说，GitHub Copilot 是两个 AI 张佩佩开发人员，由 OpenAI 建立的聚合预体能训练 AI 数学模型 Codex 提供全力支持：“可以协助你更快地撰写标识符，增加工作效率，从注解和标识符中抽取语句，即刻提议部分行标识符和整座表达式。”

听起来很智能化，也很高效率，即 AI 能协助聚合标识符——但难题在于，Copilot 是如何专业委员会代码的？

▶ “GitHub Copilot 历经数千万行标识符的体能训练，将语义提示信息转化成为数百种词汇的代码提议。”

▶ “OpenAI Codex 经过了开放源码标识符和语义的培训，因此它适用于程式设计和人类词汇……接受了公共的语义文本和源标识符的体能训练，包括 GitHub 上公共存储库中的标识符。”

简单来说，GitHub Copilot 确实会聚合一些合适的标识符，但追究其根本，其源头可能还是他人写的标识符——而这，显然涉及到了标识符版权难题。

绕过 GPL 协议？

有一件事需要明确：标识符开放源码，并不意味着我们可以自由免费地用这些源标识符来为所欲为，因而衍生出了许多不同的开放源码协议（也称开放源码许可证 / 开放源码 License，如 GPL/LGPL 等），以此规定开放源码标识符免费使用的范围和权利。

以最为知名的开放源码协议 GPL 为例，其要求：只要在两个软件中使用了 GPL 协议的标识符，则该软件产品必须也采用 GPL 协议，既必须也是开放源码和免费。

那么，难题就来了：实际上 Copilot 所自学的数千万行开放源码标识符，以及 GitHub 上公共存储库中的标识符，其中不少都采用了 GPL 协议。而 Copilot 聚合标识符片段时，并不会显示原标识符作者的信息，也没有提醒相关开放源码协议

这会导致部分遵循 GPL 协议的标识符，被写入一些不开放源码的专有工程项目或商业工程项目中——既违反了许可证条款，也侵犯了原标识符作者的知识产权。

因此，作为一名开放源码开发人员，T 在该文呼吁：“我们已经厌倦了这种法律上的滥用，我们希望现在就停止！这也是为什么我们要求你，作为开放源码街道社区的其他开发人员，千万别在 GitHub 上载我们的标识符。简来说之，我们希望保护我们的工作。”

Copilot 的争议一直未断

伴随着近几个月的 AIGC 热潮，MidJourney、Stable Diffusion、Copilot 等聚合式与此同时各种 AI 成果的版权难题也被推上了风口浪尖。事实上，有关 Copilot 的争议自其发布以来就一直没有断绝，其中绝大多数围绕的都是：Copilot 聚合的标识符到底是原生的还是复制的？

据了解，早在 Copilot 刚发布不到一周时，就有开发人员发现了 Copilot “复制标识符”的实锤：Copilot 推荐的标识符，还带着原标识符“WTF”的注解。