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

Source: jaxenter.com

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.

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?

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.