#HumansOfCopyright: Bas Peters from GitHub
Bas Peters is Solutions Engineer at GitHub, where he helps organisations to use the GitHub development platform to “learn, share and work together” to build software. He has been a software developer and consultant for over 15 years, and is particularly interested in the impact of open source software. Before joining GitHub, he worked for several software companies and business consultancies. He is based out of Amsterdam. Here he talks about the harmful effects the proposed Copyright Directive’s upload filter – Article 13 – would have on the software world, particularly in the EU.
GM: Could you please introduce GitHub – its history, who its users are, and its general business model?
BP: GitHub is the largest software development platform in the world, supporting a community where more than 27 million people learn, share, and work together to build software. Microsoft, Google, SAP, PayPal, Netflix, Spotify, and Zalando all use GitHub.
GitHub launched in 2008 and continues to connect people from all over the world. Developers, students, researchers, scientists, and hobbyists all work together to share ideas and contribute and discuss code changes. Projects can be small, but they can also have thousands of contributors. At the same time, countless startups, small and medium businesses, and large enterprises use GitHub.
Not all projects involve software code. GitHub is also used to develop content collaboratively, with version control helping to track who made changes, when, and why. Documentation for [the cloud computing service] Amazon AWS, and [the software development platform] Microsoft .NET, for example, are maintained and hosted on GitHub.
GitHub is free to use for public and open source projects and we offer paid plans to allow individual developers and organizations to work together across private repositories [collections of material]. For customers that need complete control over repository and project information, we also provide an on-premises version, GitHub Enterprise.
GM: For people who may not be familiar with GitHub, could you please explain how programmers typically use it, and why it is so useful?
BP: GitHub allows people to build software in a collaborative way. The platform is built on top of Git, the most widely used version control system [for managing the software development process]. To contribute to public or open source projects, developers typically first create a “fork”, a copy of the project, to freely experiment with changes without affecting the original project. They can then propose improvements back to the original project using a “pull request” where the contribution is reviewed by the owners of the project. If they like the changes, they can pull them into the original project.
By sharing code, people build better and more reliable software. Rather than only logging issues they find, developers can study the code and propose bug fixes and improvements. This way of working also drives innovation as developers can focus on the more interesting parts of software development rather than re-inventing the wheel. Organizations also share code to build a strong developer community for their products and services and to attract and retain talent.
Apart from a community of developers, GitHub is also a network. Most software nowadays builds on other software packages and these packages have their own dependencies [other pieces of programming code that are needed to work properly]. Together they constitute an immense network of interrelated software solutions maintained by communities of developers. Major software innovations like cloud computing or data science and machine learning are developed this way.
GM: How does copyright affect programmers working collaboratively? What are the particular issues they face? How does GitHub deal with those currently?
BP: Software code is copyrightable. Software code shared publicly on GitHub.com is often under an open source license, which gives anyone the freedom to run, copy, distribute, study, change, and improve the software. This means organizations and individual developers share code with the intention that other people will use it, modify it, share it and contribute back any bug fixes and improvements.
However, a given project can easily have tens or even hundreds of dependencies, and those dependencies can have different license requirements, so it is not always easy for developers to know how particular code is licensed. Some licenses, for example, require anyone who distributes the code or a derivative work to make the source available under the same terms.
To help developers understand some aspects of open source licensing (without offering legal advice), we created resources like choosealicense.com and The Legal Side of Open Source. In addition, when you create a new project on GitHub, you are encouraged to select a license. If a rightsholder notifies us about alleged non-compliance with a license on our site, GitHub follows the US Digital Millennium Copyright Act (DMCA) process, which is compliant with current EU law. We also post takedown requests to a public repository.
GM: What are the problems of Article 13’s upload filters for GitHub?
BP: Article 13 would undermine software developers’ rights to their creative works: software code. By requiring platforms like GitHub to take preventive measures like filters to scan for copyright infringement, Article 13 would mean a lot of that source code would become unavailable, for example, where filters detect false positives. False positives are likely because code can have thousands of contributors and many layers, which makes it very difficult to properly determine infringement. Thus, Article 13 would undermine the ability to discover, share, and develop code together, which is fundamental to software development.
GM: What would happen if upload filters were made obligatory for sites like GitHub?
BP: When filters catch false positives, code will disappear, breaking the projects developers are building and all of the other products and services that incorporate the same code, and are built on top of it.
Upload filters will also have a negative impact on the developer community as they would introduce a kind of surveillance and would stifle creativity.
GM: What do you think might happen to open source and the software industry in the EU, if these problems aren’t resolved?
BP: Upload filters would make software less reliable and more expensive. They would discourage industry-wide collaboration and encourage developers to move projects behind the firewall [making them private, not public] where upload filters are not in play, disconnecting them from a vibrant community of collaborators and bug-fixers.
Undermining incentives to develop in the open at a time of concern about consolidation and inequality is precisely the wrong move. It is harmful to developers’ ability to launch new products and erodes trust that the internet is a force for innovation and opportunity.
The EU software industry would be especially harmed because it is disproportionately reliant on open source, cross-border, and cross-firm collaboration. By contrast, the very largest U.S. firms have some ability to maintain large amounts of the open source code they rely on, without sharing.
GM: Any other comments?
BP: Upload filters are problematic for all kinds of content. We focused on software, because that’s where GitHub and software developers can speak with authority.
And software developers really care. In March we wrote a blog post about Article 13 and received a huge response. Our call to action was discussed extensively across the web, and developers wrote to us to ask how to reach EU policymakers.
We’ve seen some positive developments in response to these developers. Some key policymakers who were not previously aware of the harm upload filters pose to software development are now eager to ensure that this crucial economic sector in the EU is not inadvertently covered by Article 13. In fact, in their latest proposals, the EU Council and EU Parliament each attempts to exclude platforms like GitHub: as “open source software development platforms” in the Council proposal and “code sharing services” in Parliament’s. However, each qualifies the language in a way that fails to unambiguously exclude the bulk of open source software development. We’re continuing to work with policymakers to help them find language that would effectively exclude software development and include only platforms plausibly contributing to the remuneration problem the copyright proposal aims to address.
Featured CC0 image by Delmi Alvarez.