重新整理 | 彭慧中白眉林 | 屠敏

公司出品 | CSDN（ID：CSDNnews）

问世 14 年来，凭借着完备协定全力支持、Git文件格式的版库代销等竞争优势，GitHub成为了倍受开发人员热烈欢迎的标识符代销网络平台。

但是，近几年来，随著GitHub的许多变革，引起了金融行业内许多组织机构的反感。6月30日，应用软件民主自由为保护联合会（下列全称SFC）在官方网站刊登了一则专文《舍弃 GitHub，徐高》的专文，怒称：由于GitHub的失当行为，SFC将完结自己对GitHub的大部份采用，并将帮助其它开源工程项目从GitHub北迁。尽管SFC现在不能强制性明确要求原有团体会员北迁工程项目，但他们将无须拒绝接受不急于从GitHub北迁的入会工程项目。

SFC婉拒GitHub的服务项目是开源开发人员向GitHub和谷歌示威其这些犯罪行为而收到的两极化讯号。

所以GitHub到底是怎样“惹怒”了SFC呢？

图源SFC官方网站

GitHub真在为开源“好”么？

在往后的二十年里，GitHub发生改变了现代人的程式结构设计形式。不但让程式结构设计显得更单纯，还发生改变了应用软件开发人员对程式结构设计的观点。它找出了在世界上上百万人已经开始不懈努力化解的一个大问题——怎样在标识符上协同，并结构设计出了市场亟需的的软件系统，同时实现了更让人无法置信的增长和成功。

通过围绕开源工程项目Git构建SaaS服务项目，GitHub为开源生态系统提供价值并从中获利。具体来说，GitHub的利润主要来自那些希望采用GitHub工具进行内部专有应用软件开发的人。

然而，SFC认为，尽管GitHub一直标榜自己为这么多开源提供了大量的服务项目，但从大科技公司的许多免费服务项目中可以看到：如果你不是GitHub的客户，所以你就是其产品。科技公司用开源的开发方法开发成了GitHub的产品，而GitHub常常在对方不知情的情况下将其私有化并重新包装。

FOSS的开发人员长期以来对于GitHub的这类犯罪行为一直以“温水煮青蛙”的心态。应用软件民主自由为保护联合会也意识到自己的包容造就了这个问题的一部分，当GitHub的犯罪行为显得越来越糟糕，而他们一直在原谅、忽视、默许……直到最近，终于该“秋后算账”了。

SFC和GitHub长达一年的持久战

具体“引爆”SFC此次大动作的事件，则是GitHub在长达一年的时间内婉拒回应SFC对于Copilot（AI自动程式结构设计工具）在公开标识符上进行训练的合法性的质疑。而就在上周，GitHub宣布Copilot成为一个商业化的盈利性产品，彻底激怒SFC。

事件经过如下：

2021年7月，SFC就曾与谷歌和GitHub的代表进行了视频通话，提出了几个问题，他们说当时无法回答，但会“很快回答”。在六个月没有回应之后，SFC在其文章《如果应用软件是我的副驾驶，谁给我的应用软件程式结构设计？》（https://sfconservancy.org/blog/2022/feb/03/github-copilot-copyleft-gpl/）一文中公开提出了这些问题，但GitHub仍然没回应。三周后，SFC成立了一个专家委员会，讨论“人工智能辅助应用软件的产生的伦理道德问题”（https://sfconservancy.org/news/2022/feb/23/committee-ai-assisted-software-github-copilot/），并同时进行公开讨论（https://lists.copyleft.org/mailman/listinfo/ai-assist）。他们邀请谷歌和GitHub的代表参加公开讨论，但谷歌和GitHub无视SFC的邀请。2022年6月下旬，在SFC提醒GitHub关于下列2点：“1.这几个悬而未决的问题我们已经等了一年；2.你们为何婉拒加入关于这个话题的公开讨论？”然而GitHub在一周后回应：他们不能加入关于这个问题的任何公开或私下讨论，因为“关于人工智能辅助应用软件的伦理”的讨论似乎不太可能发生改变SFC的立场，这就是为什么GitHub没有回应SFC的原因。2022年6月22日，不但婉拒回应SFC的GitHub还宣布将Copilot商业化，SFC的底线终于被突破。

由此可见，GitHub对Copilot的最终立场是：如果SF这个答案谷歌和GitHub会时隔一年才告知！在这期间，GitHub还在一直不懈努力推进Copilot的商业化！

而SFC一直希望谷歌/GitHub回应的关于Copilot的三个主要问题是：

1. 在谷歌和GitHub的公开声明中，依据的是什么判例法（如果有的话）。GitHub当时的CEO说：“（1）在公共数据上训练ML系统是合理采用（2）输出的标识符版权属于操作者，就像编译器一样。”为了透明和尊重民主自由和开放源码应用软件社区，也请向社区提供你们完备的法律分析来证明你们这些说法是有理有据的。

SFC认为，谷歌和GitHub的婉拒回答，表示他们仍然坚持他们的前CEO的声明（这也是他们在这个问题上的唯一声明），但事实上他们没有相应的法律理论来支撑。

2. 如果像谷歌/GitHub所说的那样，允许在任何标识符上训练模型（并允许用户基于该模型生成标识符）而不受任何许可条款的约束，你们为什么只选择在开源上训练Copilot的模型？例如，为什么谷歌Windows和Office标识符库不在你的训练集中？

SFC认为，谷歌和GitHub的婉拒回答也暗示了这个问题的真正答案。尽管GitHub很乐意利用FOSS，但他们对自己的知识产权的重视程度远远超过FOSS，并且满足于忽视和侵蚀FOSS用户的权利，而不是自己的。

3.谷歌/GitHub能否提供一份用于Copilot的训练集的许可证的清单，包括版权人的名字和/或Git存储库的名字？如果不能，所以为什么不向社区提供这些信息呢？

SFC认为，GitHub婉拒回答的原因是他们没有仔细复制他们的模型，所以他们实际上不知道他们侵犯了谁的版权，以及何时和怎样侵犯。

综上，这些不但问题被挡了回来，最终，GitHub的做法，导致SFC愤而“暴走”。

Copilot的合法性是值得商榷的吗？

在宣布“离家出走”后，SFC的最新声明也在Hacker News上引来了400多位开发人员的热评，针对SFC铿锵有力的指责，GitHub推出商业化的Copilot，其合法性是否真的有待商榷呢？

一名开发人员指出，SFC提出的关于“为什么谷歌Windows和Office标识符库不在你的训练集里？”是他最喜欢的问题。

还有开发人员对于人工智能生产标识符的知识产权问题报以同样的担忧：“人工智能有可能复制出与原作非常接近的东西，从而被认为是对原作的侵犯。”

然而，却另有开发人员表示：“我想知道你们为什么把标识符放在公开的GitHub FOSS仓库里，却不希望以任何形式复制……我还想知道为什么现代人认为他们的标识符是如此特别，以至于没有人能够独立地想出它。我想，Copilot的每一个“对手”都是有史以来最好的开发人员吧？”

并且他指出：“如果有人在一个闭源的商业应用软件工程项目中采用你的（例如MIT许可的）标识符，并没有解除你的标识符被发布的民主自由，你的标识符仍然和以前一样开放和可用，任何人都没有失去任何民主自由。”

这位开发人员“阴阳怪气”的发言也遭到了一众人的反驳，其中一位开发人员表示：“没有人声称他们不想让自己的标识符被复制。现代人只是想让自己标识符的衍生产品遵守他们为自己的工程项目选择的许可证。而根据你的发言和总体语气，我认为你只是对开源有偏见，仅仅是因为你不理解，但这并不意味着这些想法是无脑的。我也很好奇，为什么版权法应该为保护专利应用软件、音乐、游戏、写作等，而不适用于我的应用软件，即使它不是最高质量的作品？”