The IASGE team is deviating from our regularly scheduled program of research to talk about restrictions being placed on members of our community. And disclaimer, the opinions expressed here do not necessarily reflect those of NYU or the Sloan Foundation. On July 20, 2019, Shahin Sorkh, a computer engineering student and full-time developer, was trending on HackerNews, where someone had linked his blog post about what is it like to be a dev in Iran. This post, previously hosted on GitHub pages, 404'd on July 25th when GitHub decided to comply with U.S. export control laws, implemented on "Specially Designated Nationals (SDNs) and other denied or blocked parties under U.S. and other applicable law [...] including prohibited end uses described in 17 CFR 744", as mentioned in the Trade Controls page on GitHub Help. Users with IP addresses originating in Crimea, Sudan, Cuba, Iran, North Korea, and Syria or whose payment history or other information linked to those locations were affected.
And when we say affected...we mean that users received emails from GitHub saying that their accounts were blocked. Little-to-no advance notice was given, and no option to back up their repositories.
We, the IASGE team, have chosen to write about this because restriction to members of the Git community—even when authorized by Federal Law—has far-reaching and chilling consequences for open source, open scholarship, and for the open exchange of information and ideas.
The restrictions on GitHub came to light when users found that they were unable to access their private GitHub repositories, and could not access some common GitHub features for their public repos (e.g. deleting them). Hamed Saeedi's July 25th tweet announcing that his account had been blocked was the first indication for many that GitHub would use its Terms of Service to restrict access to people in, or from, sanctioned countries. The ToS specifically states: "You may not use GitHub in violation of export control or sanctions laws of the United States or any other applicable jurisdiction. You may not use GitHub if you are or are working on behalf of a Specially Designated National (SDN) or a person subject to similar blocking or denied party prohibitions administered by a U.S. government agency." Further, a notification on GitHub's Trade Controls page states that "Users are responsible for ensuring that the content they develop and share on GitHub.com complies with the U.S. export control laws, including the EAR [U.S. Export Administration Regulations] and the U.S. International Traffic in Arms Regulations (ITAR)." This message is encapsulated in the banner across blocked users' GitHub homepages.
Ostensibly, the move to deny access to users from certain countries resulted from GitHub, and its parent company Microsoft (currently competing with Amazon for a Department of Defense cloud hosting contract), choosing when and how to comply with an export control law that affects various countries put under sanction by the U.S. government as well as SDNs. According to the Trade Controls page on GitHub's site, the service may allow users in sanctioned countries and territories access to certain free services as long as those users are not SDNs. According to the same page, GitHub explains the mechanism by which restrictions occur:
"If GitHub determines that a user or customer is located in a region that is subject to U.S. trade control restrictions, or a user is otherwise restricted under U.S. economic sanctions, then the affiliated account has been restricted to comply with those legal requirements. The determination of user and customer location to implement these legal restrictions are derived from a number of sources, including IP addresses and payment history. Nationality and ethnicity are not used to flag users for sanctions restrictions."
Parsing this information is crucial because by GitHub's own policies it "[...] may allow users in or ordinarily resident in countries and territories subject to U.S. sanctions to access certain free GitHub.com services [...]" According to Saeedi's tweet, his blocked accounts were of this free variety, which raises questions regarding this current enforcement action and how blocks were rolled out. Even more questions arise from the case of Farzad YZ, a software engineer for Futurice, who tweeted that he lives and works in Finland yet his account was restricted. He has filed an appeal but the process of vetting images of non-expired government-issued photo identification will take a while.
Meanwhile, other Git hosting platforms like GitLab, SourceForge, and Bitbucket are subject to the law (read their approaches: GitLab, Bitbucket, and SourceForge) but have taken different approaches to enforcement. When GitLab moved its infrastructure from Microsoft Azure to Google Cloud Platform (GCP), Google informed them of the legal restrictions described above. GitLab chose not to disable any repositories immediately but rolled out a timeline that would allow users to migrate their repositories to a different platform. Rather than locking users out en masse with no warning, GitLab worked with the community to ensure that everyone could keep their data and voice their concerns. Their blog post on the migration started with this note:
"NOTE to users in Crimea, Cuba, Iran, North Korea, Sudan, and Syria: GitLab.com may not be accessible after the migration to Google. Google has informed us that there are legal restrictions that are imposed for those countries. See this U.S. Department of the Treasury link for more details. At this time, we can only recommend that you download your code or export relevant projects as a backup. See this issue for more discussion."
So what can be done when the open source communities, valuing discovery, have invested in so much centralized infrastructure? Questions like this take on an even more urgent tone when we consider that this is not the first time that something like this has happened.
On December 20, 2018, Slack banned all users from Cuba, Iran, Sudan, North Korea, Syria and the Crimea region of Ukraine in a manner similar to that used by GitHub: providing no prior warning about the enforcement of these laws and providing no mechanisms by which they can appeal the decision. The only avenue available to many was to turn to social media. Communication from Slack to the banned users simply said that their accounts were deactivated due to compliance with a U.S. embargo, stating that "in order to comply with export control and economic sanctions laws and regulations promulgated by the U.S. Department of Commerce and the U.S. Department of Treasury, Slack prohibits unauthorized use of its products and services in certain sanctioned countries [...]" GitHub's current denial of access also cites content and usage while also looking at geolocation of IPs and other information (e.g. payment history) linked to those six countries.
Oxford researcher Mahsa Alimardani spoke to The Verge about Slack's ban, which she believes goes beyond the mandate of the law. According to Alimardani, "They [Slack] are either incompetent at OFAC interpretation or racist." On December 21st, Slack published a public apology and update for their poor implementation, focusing on the lack of communication as a key issue. As part of their apology, the service noted that they would continue to block embargoed countries (to comply with the law) but would not deactivate user accounts. Individuals are able to access their accounts once they are no longer in sanctioned countries.
Emaad Ghorbani initially reported that his personal public GitHub account also blocked him from deleting his public repos. He noticed this after he received an email from GitHub (email@example.com) notifying him that his account "... has been restricted [with] limited access free GitHub repository services for personal communication only." These email notifications redirected restricted users to more details on the GitHub and Trade Controls page and a private appeal form hosted on Airtable.
On July 27th, two days after users scrambled to understand the unexpected restrictions, GitHub CEO Nat Friedman finally replied on Twitter. Despite other hosting platforms communicating with their users before taking any action, Friedman asserted that "our understanding of the law does not give us the option to give anyone advance notice of restrictions," as well as "We're not doing this because we want to; we're doing it because we have to. GitHub will continue to advocate vigorously with governments around the world for policies that protect software developers and the global open source community."
Soon following Friedman's Twitter thread, GitHub has been quietly rolling back some of their restrictions for users experiencing the block. Blocked users can choose to make their private repositories public and delete any repository under their account (these options did not exist prior), and GitHub pages are now building again. GitHub's lack of communication to their users at the beginning of this debacle, and continuing through it has left many to wonder if they'll ever be able to recover their repositories again. At the very least, GitHub's lack of communication has overly complicated an already bad situation and has raised questions about its ability to act as a fair keeper of other people's work.
The bottom line is: users from these six countries had no notice this was happening, and so couldn't transfer, make public or private, archive, or get their data out. Saeedi also reported in his latest blog update on the situation that GitHub said that they were not legally able to send an export of disabled repositories (disclaimer: while we agree with these issues, we do not condone the use of symbols of Jewish oppression, such as the yellow badge, in this latest post). With no public-facing announcements, roadmaps, or advocacy campaigns planned, the most relevant questions still need answering:
As librarians and researchers committed to openness and the preservation of the scholarly record that is distributed on these hosting platforms, we want to affirm our commitment to supporting scholars in the six affected countries (and globally!). We also want to say that we think the enforcement actions of GitHub are particularly problematic, especially when taken in the context of other hosting platforms' actions.
There's a widespread perception in certain circles of the academy that these hosting platforms are secure, but we see clearly here that some portions of our community are more susceptible to the effects of geopolitical instability than others. GitHub has never been, and will never be, the long-term access solution. Users with 10+ years of history on GitHub woke up one day locked out of their work on the 25th, confused and frustrated. We need more resilient infrastructure for scholarship.
For our IASGE project, we host the majority of our research on GitLab. What does this mean for Iranian or Cuban scholars or collaborators who would want to make a merge request on this post? It might be time for us to start looking at self-hosting our open source platform. In any case, IASGE is a grant-funded project wherein the first stage we are dedicated to researching how scholars use the features of platforms like GitHub and how we can preserve the repos for long-term, sustainable, and open accessibility. As Muneedb Ali simply put it, "Git protocol is already decentralized. All we need is decentralized login, storage, and social graph on top." We would like to see more opportunities to make use of and contribute to protocols like ActivityPub. While there are only the beginning of Git-friendly platforms based on that protocol, there are several decentralized hosting platforms that supposedly offer the same scholarly outcomes like version control (obviously), community, collaboration, method tracking, publishing, education, reproducibility, continuous integration, and data management.
For those who are startled or upset by these events and want to host their Git repositories on their own server (Kimsufi, Ionos, and Online.net are potential places to rent servers outside the U.S.), here's a non-exhaustive list of open source hosting platforms that you could run on a minimal server (depending on your data and users, of course!):