What's Wrong with GitHub

本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

What’s Wrong with GitHub

软件开发者们，GNU 项目敦促你们避免将代码仓库托管在 GitHub 上。这样做是为了避免成为有害行为的受害者，并防止引导他人也陷入同样的境地。本文重点讨论 GitHub 的几个最严重的问题，以及它们可能造成的错误和伤害：(1) GitHub 推广模糊且令人困惑的许可实践；(2) 它要求访问者在进行大多数操作时运行非自由的 JavaScript；(3) 它提供的某些“服务”实际上是 SaaSS（软件替代服务）弊端；(4) 它试图颠覆 Git 的分布式架构。

While Git is free software, GitHub is not software at all. It is a website that provides a range of features, from a simple repository-hosting service to a variety of SaaSS dis-services. The sheer variety of features GitHub offers makes writing a fair critique of the site difficult, because each one calls for an evaluation on moral grounds—both for the job it does, and for the implementation of that job.

虽然 Git 是自由软件，但 GitHub 根本不是软件。它是一个提供各种功能的网站，从简单的仓库托管服务到各种 SaaSS 弊端服务应有尽有。GitHub 提供的功能种类繁多，使得撰写一篇公正的评论变得困难，因为每一项功能都需要从道德层面进行评估——既要评估其所做的工作，也要评估其实现方式。

This article focuses on a few of GitHub’s worst problems, beginning with an area where GitHub has shown at least some improvement over the years, mentioning the website’s near-uselessness for users who refuse the JavaScript Trap and the SaaSS “AI” [1] dis-services, and ending on GitHub’s model of being a central hub in a distributed system. GitHub seems to operate as much like a walled garden as it can without outright breaking compatibility with Git.

本文重点讨论 GitHub 的几个最严重的问题，首先从 GitHub 多年来表现出一定改进的领域入手，提到该网站对于拒绝“JavaScript 陷阱”和 SaaSS “人工智能”[1] 弊端服务的用户来说几乎毫无用处，最后以 GitHub 作为分布式系统中中心枢纽的模式作为结尾。GitHub 似乎在不完全破坏与 Git 兼容性的前提下，尽可能地像“围墙花园”一样运作。

Because Git is free software, GitHub cannot forcibly tether Git to itself, but it can bait users to adopt workflows that nonetheless tie the users to GitHub. Sometimes the worst handcuffs are not iron, but silk. GitHub offers convenience in centralization, and this makes little frictions insidious: one-click merge only works from a pull request, which can only be made from a “fork” hosted on GitHub; links to GitHub accounts replace email addresses in the web UI; continuous integration runs on GitHub servers by default. Little by little, the Internet-spanning plains of Git become the walled garden of GitHub.

由于 Git 是自由软件，GitHub 无法强行将 Git 绑定到自身，但它可以诱导用户采用那些最终将用户束缚在 GitHub 上的工作流程。有时，最糟糕的手铐不是铁做的，而是丝绸做的。GitHub 提供了中心化的便利，这使得一些细微的摩擦变得阴险：一键合并功能仅适用于拉取请求（pull request），而拉取请求只能从托管在 GitHub 上的“分支”（fork）中发起；网页界面中的 GitHub 账户链接取代了电子邮件地址；持续集成默认在 GitHub 服务器上运行。一点一点地，跨越互联网的 Git 平原变成了 GitHub 的围墙花园。

The full solution to the problems caused by hosting your package on GitHub is to host your package on a site that doesn’t have those problems. But if you can’t do that right away, at least publish an email address in your README so people who don’t use GitHub can communicate with you about your program, host the web pages about using your program on a website that doesn’t require nonfree software to read those pages, and always refer to the web pages there.

解决因在 GitHub 上托管软件包而引发问题的根本办法，是将你的软件包托管在没有这些问题的网站上。但如果你无法立即做到这一点，至少要在 README 文件中公布一个电子邮件地址，以便不使用 GitHub 的人能就你的程序与你沟通；将关于使用你程序的网页托管在不需要非自由软件即可阅读的网站上，并始终引用那里的网页。

Promotion of Vague and Unclear Licensing Practices

推广模糊且不明确的许可实践

When GitHub first began offering repository hosting in early 2008, it was completely silent on the matter of properly licensing free software, and this silence led to a proliferation of public repositories with no declared license whatsoever. In 2013, GitHub set up a “Choose a License” site to help users select free licenses for new software. As of this writing in 2026, that site gives ill-advised advice for the application of the GPL, stating that merely copying the text of the license into a file in a repository is sufficient.

当 GitHub 在 2008 年初开始提供仓库托管服务时，它对自由软件的正确许可问题完全保持沉默，这种沉默导致了大量没有任何声明许可的公共仓库泛滥。2013 年，GitHub 设立了一个“选择许可”（Choose a License）网站，帮助用户为新软件选择自由许可。截至 2026 年撰写本文时，该网站对 GPL 的应用给出了欠妥的建议，声称只需将许可文本复制到仓库的文件中就足够了。

The FSF’s lawyers recommend to us, and in turn we recommend to developers, to put a license notice in each substantive file, to ensure that users are aware of their rights and obligations under the GPL. GitHub mentions this only as an “optional step.” Without the standard GPL notice, there is nothing to say whether the program is licensed under GPL version N only, or under GPL version N-or-later. GitHub mentions this only in an aside about SPDX license identifiers.

自由软件基金会（FSF）的律师建议我们，我们也转而建议开发者，在每个实质性文件中加入许可声明，以确保用户了解他们在 GPL 下的权利和义务。GitHub 仅将其作为“可选步骤”提及。如果没有标准的 GPL 声明，就无法说明该程序是仅在 GPL 第 N 版下许可，还是在 GPL 第 N 版或后续版本下许可。GitHub 仅在关于 SPDX 许可标识符的旁注中提到了这一点。

Extensive Use of Nonfree JavaScript

大量使用非自由 JavaScript

GitHub’s website sends lots of JavaScript code to the browser, and much of that code is nonfree. Because the site fails to gracefully degrade, users who refuse the JavaScript Trap find that any interaction beyond simply viewing repositories is impossible, and even many of the file-viewing links no longer work. There are workarounds for this. The standard free Git command-line tools can clone repositories from GitHub, and there is a public REST API and free command-line tool that can handle at least some interaction with the site.

GitHub 的网站向浏览器发送了大量的 JavaScript 代码，其中许多代码是非自由的。由于该网站无法实现优雅降级，拒绝“JavaScript 陷阱”的用户会发现，除了简单查看仓库外，任何交互都是不可能的，甚至许多文件查看链接也无法工作。对此有一些变通方法。标准的自由 Git 命令行工具可以从 GitHub 克隆仓库，此外还有一个公共 REST API 和自由命令行工具，可以处理与该网站的部分交互。

However, the command-line tool GitHub provides for that REST API, while technically free software under Expat license terms, nonetheless cannot be recommended because GitHub has decided to add spyware features in the form of “telemetry” to it. This is exceptionally ridiculous, because the tool’s main purpose is to use a web-based API; GitHub could obtain usage information from their own server logs rather than from users’ computers.

然而，GitHub 为该 REST API 提供的命令行工具，虽然在 Expat 许可条款下从技术上讲是自由软件，但仍然不推荐使用，因为 GitHub 决定在其中以“遥测”的形式添加间谍软件功能。这极其荒谬，因为该工具的主要目的是使用基于 Web 的 API；GitHub 完全可以从他们自己的服务器日志中获取使用信息，而不是从用户的计算机中获取。

GitHub Copilot is SaaSS

GitHub Copilot 是 SaaSS

GitHub started a controversy with the introduction of “GitHub Copilot” that has only grown with the capabilities of the tool. GitHub Copilot began as an “AI” [1] code-completion tool, with an early demonstration of producing the body of a function given only its header comment, and has grown into an “AI” “agent” claimed to be able to function as a development team member. Copilot has always been controversial.

GitHub 引入“GitHub Copilot”引发了争议，且随着该工具功能的增强，争议愈演愈烈。GitHub Copilot 最初是一个“人工智能”[1] 代码补全工具，早期的演示展示了仅根据函数头注释就能生成函数体，如今它已发展成为一个声称能够作为开发团队成员运作的“人工智能”“代理”。Copilot 一直备受争议。

The initial code-completion tool used a model that had been trained on a wide variety of code, under a wide variety of licenses, and was quickly found to be able to reproduce lengthy sections of well-known text verbatim, including the preamble of the GNU General Public License and the Zen of Python. This ability to regurgitate its training material has led to doubts about the legal status of code suggested by Copilot. GitHub offers indemnification to higher-tier Copilot subscribers, although it remains uncle

最初的代码补全工具使用了一个模型，该模型是在各种许可下的大量代码上训练出来的，很快人们发现它能够逐字重现知名文本的长篇片段，包括《GNU 通用公共许可协议》的前言和《Python 之禅》。这种吐出训练材料的能力引发了人们对 Copilot 建议代码法律地位的质疑。GitHub 为高级 Copilot 订阅者提供赔偿，尽管目前尚不清楚……