By Jacob Bachmeyer and Richard Stallman\nSoftware developers, the GNU Project urges you to avoid hosting your\nrepositories on GitHub. This is to avoid being on the receiving end of\nharmful practices, and avoid leading others to be victims too. This article\nfocuses on a few of GitHub's worst problems, and the wrongs and harm they\ncan do:\n(1) GitHub promotes vague and confusing\nlicensing practices;\n(2) it demands that visitors run nonfree\nJavaScript for most operations;\n(3) some of the “services” it offers\nare actually SaaSS (Service as a Software Substitute) dis-services;\n(4) it attempts to subvert the\ndistributed architecture of Git.
\nWhile Git is free software, GitHub is not software at all. It is a\nwebsite that provides a range of features, from a simple repository-hosting\nservice to a variety of SaaSS\ndis-services. The sheer variety of features GitHub offers makes writing a\nfair critique of the site difficult, because each one calls for an\nevaluation on moral grounds—both for the job it does, and for the\nimplementation of that job.
\nThis article focuses on a few of GitHub's worst problems, beginning with\nan area where GitHub has shown at least some improvement over the years,\nmentioning the website's near-uselessness for users who refuse the JavaScript Trap and the SaaSS\n“AI” [1] dis-services, and ending on\nGitHub's model of being a central hub in a distributed system.
\nGitHub seems to operate as much like a walled garden as it can without\noutright breaking compatibility with Git. Because Git is free software,\nGitHub cannot forcibly tether Git to itself, but\nit can bait users to adopt workflows that nonetheless tie the users to\nGitHub.
\nSometimes 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.
\nThe full solution to the problems caused by hosting your package on\nGitHub is to host your package on a site that doesn't have those\nproblems. But if you can't do that right away, at least publish an\nemail address in your README so people who don't use GitHub can communicate\nwith you about your program, host the web pages about using your program on\na website that doesn't require nonfree software to read those pages, and\nalways refer to the web pages there.
\nWhen GitHub first began offering repository hosting in early 2008, it was\ncompletely silent on the matter of properly licensing free software, and\nthis silence led to a proliferation of public repositories with no declared\nlicense whatsoever. In 2013, GitHub set up a “Choose a License” site to help\nusers select free licenses for new software.
\nAs 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.
\nThe FSF's lawyers recommend to us, and in turn we recommend to\ndevelopers, to put a\nlicense notice in each substantive file, to ensure that users are aware\nof their rights and obligations under the GPL. GitHub mentions this only as\nan “optional step.”
\nWithout the standard GPL notice, there is nothing to say whether the\nprogram is licensed under GPL version N only, or under GPL \nversion N-or-later. GitHub mentions this only in an aside about\nSPDX license identifiers.
\nGitHub's website sends lots of JavaScript code to the browser, and much\nof that code is nonfree. Because the site fails to gracefully degrade, users\nwho refuse the JavaScript\nTrap find that any interaction beyond simply viewing repositories is\nimpossible, and even many of the file-viewing links no longer work.
\nThere 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.
\nHowever, the command-line tool GitHub provides for that REST API, while\ntechnically free software under Expat license terms,\nnonetheless cannot be recommended because GitHub has decided to add spyware\nfeatures in the form of “telemetry” to it. This is exceptionally\nridiculous, because the tool's main purpose is to use a web-based API;\nGitHub could obtain usage information from their own server logs rather than\nfrom users' computers.
\nGitHub started a controversy with the introduction of “GitHub\nCopilot” that has only grown with the capabilities of the tool.\nGitHub Copilot began as an “AI” [1]\ncode-completion tool, with an early demonstration of producing the body of\na function given only its header comment, and has grown into an\n“AI” “agent” claimed to be able to function as a\ndevelopment team member.
\nCopilot has always been controversial. 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 unclear how indemnity would work if the demand were to be GPL compliance rather than money.
\nLater expansions of Copilot's capabilities have brought more controversy. GitHub added a “feature” allowing users to have Copilot write a bug report, which is then submitted as an issue with minimal indication that Copilot was used to generate it. These Copilot-assisted issues have been drowning maintainers of projects on GitHub in slop when users fail to proofread their issues and correct Copilot's errors. GitHub, of course, refuses to allow maintainers to block Copilot-generated issues from being submitted.
\nThe legal risks of using LLM code suggestions and the social harms of\nburying maintainers in slop are universal, applying even to free models run\nlocally, but what GitHub does is bad in another way: Copilot is SaaSS, and its\nmodels run on remote servers where users have no control over them. This has\nproduced some of the usual SaaSS abuses: forced “upgrades” that\nusers find to be inferior to the previous versions, and price increases at\nthe whim of the vendor.
\nCopilot subscriptions originally provided access to basic features (mostly the code suggestions) and a certain number of “premium requests” (other interactions and more complex agentic tasks) each month. In early 2026, GitHub announced a policy change: all subscriptions would be forced to move to a token-based billing model that charges for the actual computing resources used, which is only loosely under the user's control. GitHub could impose this change on users because Copilot is SaaSS.
\nThe above practices are directly inimical to software freedom, but GitHub also undermines the community in deeper, long-term ways that are less immediately evident.
\nGit was designed as a distributed version-control system, with no central\npoints-of-failure anywhere in its architecture. This decision was in part\nsimply making Git as different as possible from CVS, in part a reflection\nof the bazaar development process around the kernel Linux, and possibly\nin part a lesson learned from the BitKeeper\nfiasco [2]. GitHub seeks to reintroduce\nelements of centralization that Torvalds explicitly rejected when designing\nGit, and then encourages users to build workflows around that\ncentralization.
\nGitHub has a system of profile badges that can be earned by various\nactivities on the site, analogous to achievements in newer video games. In\nfact, they are called “achievements” in the documentation. This\nsystem is another example of gamification where software (or\n“services”) attempt to addict users.
\nOf course, most of GitHub's “achievements” only recognize activities associated with the site, a nudge to increase users' dependency upon GitHub.
\nGitHub started with a simple premise of providing Git repository hosting. Aligned with this, GitHub organizes repositories under user accounts, and allows all users to make repositories. This is a simple bulletin-board model where users can freely publish their own versions of free packages, and submit changes upstream by asking package maintainers to pull from their copies. This is how Git was designed to work, and this early form of GitHub made that workflow accessible to users lacking the skills or resources to set up their own Git servers.
\nThe problem with a bulletin-board model is that it can make locating a canonical version of a package needlessly difficult, in contrast to traditional forges organized around projects with designated maintainers. Designating a maintainer at a forge can be as anarchic as “whoever registers it first,” as carefully managed as the GNU Project, or anywhere in between.
\nThis was not a problem for Linux because Linus' repository is widely known to be the central canonical reference in that project. Remember that Git was originally designed specifically to support developing the kernel Linux. Its usefulness elsewhere was a bonus.
\nThere is also a problem inherent to Git's distributed model that GitHub makes worse: the bulletin-board model leads to a proliferation of forks, since even the simplest patch must be prepared by first cloning the repository, thereby creating a fork of the package. These forks are often unmaintained or even abandoned after their original purpose is served.
\nThe opportunities for confusion led to a tendency to create “organization” accounts at GitHub, a practice now explicitly supported. However, for historical reasons, organizations and users share the same namespace at GitHub, and this leaves considerable room for confusion, made worse by…
\nWhile Git was originally designed to support this model of distributed\ndevelopment, GitHub insidiously inserts itself in the middle. Git allows\nthe mirror from which a pull is drawn to be anywhere on the Internet, but\nGitHub only supports pulling from… GitHub. While it is\npossible to use Git to pull from elsewhere, perform a merge locally, and\npush to GitHub, GitHub carefully creates a path of least resistance entirely\ndependent on GitHub.
\nThere is no technical reason why GitHub could not allow pull requests to reference remote Git servers, or even accept pull requests referencing remote servers by email, which is the traditional “Git way” of handling them. GitHub chooses to tie GitHub pull requests exclusively to itself.
\nGitHub further worsens these problems with its concept of “forks,” distinct from Git's basic feature of cloned repositories. GitHub displays the number of forks of a repository as a sort of popularity-contest badge, and implements forks in a way that renders repositories at GitHub questionably trustworthy, as material that appears only in a fork can nonetheless be retrieved using the parent repository's URL, enabling malicious parties to confuse users.
\nGitHub offers a modular automated workflow system called GitHub Actions, another way to make your package dependent on GitHub. GitHub Actions can be used to run arbitrary scripts in response to commits or pull requests. The scripts by default run on GitHub's virtual servers, although repository owners can specify to run their scripts on their own servers.
\nWhile repository owners can self-host runners for their own actions, the standard runner, despite being free software, nonetheless contains a universal backdoor in the form of an automatic update feature, and depends on SaaSS infrastructure controlled by GitHub to tell it what to run.
\nGitHub's action-dispatch infrastructure makes some attempt to enforce the universal backdoor by refusing to dispatch actions to runners that it considers to be running out-of-date software.
\nWhile the dispatch infrastructure that coordinates running actions is SaaSS, the actions themselves are not SaaSS because users control which actions are run. Even though some actions are nonfree, repository owners can simply refuse to attach nonfree actions to their repositories.
\nGitHub Actions can be used to build very complex automated workflows,\nensnaring users deeper into GitHub's web, but there is a free tool\navailable that can help users break out of this trap. Published at nektosact.com, the act program\nis free software that can run workflows using GitHub Actions locally on\ndemand without depending on GitHub's infrastructure.
GitHub attempts to draw in and centralize as much of the community around a package as possible. While any software forge can be expected to offer trackers for bugs, issues, patches, etc., and to require an account at the site to participate in those web-based discussions, previous forges such as SourceForge and GNU Savannah also offer mailing lists to facilitate collaboration by email with minimal interaction with the forge itself.
\nGit was designed to support the Internet-spanning development project that maintains the kernel Linux. Therefore, Git needs a concept of user identity that also spans the Internet, and the Git developers found a simple solution: email addresses, including an optional name.
\nThis was an obvious choice for another reason: development of the kernel Linux is primarily coordinated using mailing lists. That project has its own mailing list infrastructure, and Git was also originally designed to facilitate processing patches exchanged by email.
\nGitHub evidently disagrees with these design decisions, because it not only fails to provide mailing lists, but also absolutely refuses to display email addresses in its main web UI. If a commit has an email address associated with a GitHub account, a link to that account is shown, otherwise only a name is shown with no link at all.
\nOne of the moral principles of the free software movement is that the barriers to users becoming developers themselves should be minimal and only technical (and those are acceptable only because barriers such as requiring knowledge of programming fundamentally cannot be eliminated). Obscuring email addresses as GitHub does has the effect of isolating users from existing developers. The requirement to create an account at GitHub to participate in discussions is also a subtle social barrier to users who do not yet think of themselves as developers.
\nThe term “AI” is placed in quotes because it has
become a marketing term for “Artificial\nIntelligence ” using LLMs, and while those systems are certainly\nartificial, they are far from intelligent.
BitKeeper was a nonfree version control system used from 2002
to 2005 for developing the kernel, Linux, that is used in\nthe GNU/Linux operating system.