Four Freedoms of free software

Software, access, and realpolitik — How should open source communities respond to the GitHub restrictions?

Matt Yonkovit
© Shutterstock / Piotr Swat

What happens when open source isn’t open to all? GitHub made headlines recently when it made it difficult for developers in Cuba, Iran, North Korea, and Syria to access private repository services. This has opened up a conversation that needs to happen regarding free and open source software.

At the end of July, GitHub enforced access blocks for its software repositories in line with United States trade controls, including U.S. Export Administration Regulations, on sanctioned countries. Instantly this made it difficult for developers based in countries such as Cuba, Iran, North Korea, and Syria to access private repository services, private organisational accounts or GitHub Marketplace Services. However, this also limited access to public repository services for personal communications only.

It’s important to stress that the individual developers themselves had no say over this decision. GitHub has to follow the rules around selling software to specific countries, yet the software itself is neither sold or bought. For open source projects, copying and distribution are important for building up community and use of the software. Blocking GitHub access – one of the main distribution methods for these software assets – therefore has an impact on the community building activity and makes it more difficult over time.

GitHub has become a central resource for downloading the latest official release code for projects and developers who use these repositories for building their own applications. Suddenly blocking access to GitHub repositories has meant that developers based in those countries were cut off and unable to work with many components, which highlights a key issue for open source software developers: if you don’t want your software to be restricted by international politics you had better choose self-hosted solutions, such as GitLab.

This is a consideration that many open source projects have had to tackle, for example, the PostgreSQL community decided that it did not want to host its software on GitHub or similar online services for this exact reason.

SEE ALSO: Impostor syndrome: How to accept your achievements

For those developers in embargoed countries, this is not the end of the world. It should be possible to get access to the latest versions via mirror sites in countries not covered by the US rules on access. In this case, the prohibition on GitHub does not stop access completely, but it does make that access harder and less convenient.

This situation will lead us to an important conversation that needs to happen in open source and will, hopefully, provoke open source projects to consider whether their software is truly free and open to everyone. If it isn’t, project communities will need to go beyond ensuring they supply their source code to carefully considering the practical ways in which all users can gain access to it. This could lead to new, disruptive approaches to access and distribution, and include those in the world that are heavily reliant on sneakernet for ‘walking in’ new code updates and releases.

Planning ahead around an open software world

The business model for open source is still not that well understood outside of technology circles. Companies like Red Hat and Percona have built businesses on offering support, and others have designed products that expand on open source projects at their core. These approaches are much more complex than the traditional approach of selling a software licence. When you give away a product for free and generate revenue in other ways such as through production support or consultancy, a ban on access does not necessarily accomplish the goals these laws or regulations might intend.

The Internet can cope with issues in specific networks, routing around the problem to ensure that packets are delivered. Similarly, the world of open source software will route around this problem to find a solution. Open source software is increasingly becoming the backbone of many of the world’s largest companies, from teams at Microsoft joining open source security and kernel support distribution lists, through to more general adoption of open source technologies within Internet giants like AWS, Google and Microsoft.

This represents a potential problem for the future. Open source projects may be used as part of programs or applications that are put together in restricted countries and the vast majority of these implementations are not risks to security. Similarly, those responsible for making the laws and regulations often do not understand the model for free and open source software as it does not follow traditional sales and export models.

Therefore, what might happen? Will regulators and lawmakers start to understand the free and open source model, and apply stricter rules specifically targeting how software packages are accessed? Will the open source movement continue to work on principles of encouraging access as far and wide geographically as possible?

SEE ALSO: Women in tech: “Be good at what you do.”

Along with the theoretical side – which will support open access to software for community members, wherever they happen to be – there will be the practical side as well. If and when laws get tightened, increasingly we are likely to see large US companies taking a more cautious path towards supporting access or risk being in violation of this legislature. The evolution of cloud services based on open source projects will continue to grow, and US-based cloud operators will have to continue to monitor where users are based.

There may be more change around open source licenses over time in response to these situations. However, this is not likely to entirely restrict use in these embargoed locations. There is more of a risk from licence change as a commercial restriction, as we have seen from companies updating their licenses to stop the usage of open source projects by cloud companies without paying back into the community as a whole.

Overall, open source itself should not be affected by international rules on software access and how they are enforced. For users, there may be more inconvenience involved in the processes around open source access. This might be antithetical to modern application design, which is based on on-demand application components that are assembled to accomplish goals. Instead, we should see open source continue to expand and support communities wherever they happen to be.

Lest we forget, access to the source code is a precondition of one of the ‘Four Freedoms’ that define the Free Software movement, and which is echoed by the Open Source Initiative’s own definition. Whatever happens in the world of politics, this freedom of access is worth fighting for.


Update, August 15th 2019:

GitHub statement

We received the following statement from GitHub regarding the content in this article.

“GitHub is subject to U.S. trade control laws, and is committed to full compliance with applicable law. At the same time, GitHub’s vision is to be the global platform for developer collaboration, no matter where developers reside. As a result, we take seriously our responsibility to examine government mandates thoroughly to be certain that users and customers are not impacted beyond what is required by law. This includes keeping public repositories services, including those for open source projects, available and accessible to support personal communications involving developers in sanctioned regions.”

  • GitHub is subject to certain restrictions under U.S. law, just like any company that does business in the U.S., with respect to users and customers who are in the following countries or territories: Crimea, Cuba, Iran, North Korea, and Syria, or who are otherwise restricted under U.S. economic sanctions.
  • Certain GitHub services may be available for free individual and free organizational accounts in these countries or territories. This includes limited access to GitHub public repository services (such as public repositories for open source projects and associated GitHub Pages and Gists), for personal communications only, and not for commercial purposes. The restriction also includes suspended access to private repository services and paid services (such as availability of private organizational accounts and GitHub Marketplace services).
  • GitHub has always strived to ensure our service is used in compliance with trade control laws and U.S. sanctions programs.
  • In the rare instance that an account is affected unintentionally or unnecessarily, we’ve created an appeal process to address such matters.
  • If a user 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 restrictions.
  • 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.
  • Please read about GitHub and Trade Controls for more information.
Matt Yonkovit
Matt Yonkovit is the Chief Experience Officer at Percona and oversees the company strategy and marketing functions. Matt has over 20 years in the open source database industry. Before joining Percona in 2009, Matt worked at MySQL AB and Sun Microsystems as a Solutions Architect, building out and optimising high performance, scalable and always available infrastructure for Fortune 500 and many other web properties. Matt lives in Raleigh, North Carolina with his wife, daughter, cat, and dog, where he enjoys fantasy sports, playing video games, listening to rock music, as well as taking things apart to figure out how they work.

Inline Feedbacks
View all comments