GitHub represented developers at two events during Paris Digital Week: the Paris Peace Forum, coinciding with the 100th anniversary of the World War I Armistice, and the United Nations Internet Governance Forum (IGF), themed the “Internet of Trust.”
As part of our work there, we committed to a cybersecurity initiative and spoke about open source projects as a model for community governance. Developers have the most to gain from building an internet of trust—and the most to contribute.
On November 12, GitHub joined 370 governments, businesses, and civil society groups in the Paris Call for Trust and Security in Cyberspace—a commitment to support principles and norms to protect people and critical infrastructure.
We joined this effort recognizing that cyberspace is built by developers, and it’s susceptible to attacks in ways that developers can help prevent, anticipate, or combat. Coordinated efforts to protect people and the digital infrastructure they rely on from systemic or indiscriminate cyberattacks certainly benefit developers, who are on the front lines of these attacks. Developers can help by prioritizing security and resilience in their projects. This is not solely a technical task—cooperation is required, and to sustain cooperation, governance.
When he launched the Paris Call at the IGF on November 12, French President Emmanuel Macron spoke about a range of other internet-related topics, including content moderation. This is another area where open source project maintainers can help—by showing how community-run projects can be effective to create welcoming, inclusive, safe spaces for online collaboration.
GitHub strongly champions community self-management because communities can have the ability to be constructive and nuanced—contributing to rebuilding trust online, and lessening the need for other layers of regulation, from companies enforcing their Terms of Service to action by government regulators.
We presented on open source projects at IGF in a session on community governance. Open source communities are built on shared goals and objectives (like building software). Open source maintainers also share goals with the platforms they collaborate on: promoting positive participation and fending off abuse. We emphasized best practices:
We described resources, such as Open Source Guides, that GitHub provides for maintainers seeking ideas on how to write a Code of Conduct, build welcoming communities, and resolve conflicts. Participants were interested to hear about how open source projects work. Several left the discussion expressly recognizing how community moderation practices in open source could be used in other contexts.
We want to give a big thanks to Wikimedia for organizing and moderating the session, and to Collaboration on International ICT Policy for East and Southern Africa (CIPESA), Mozilla, and the United Nations Educational, Scientific, and Cultural Organisation (UNESCO) who joined GitHub as speakers.
We are also thankful to our community. We’re happy to see governments join companies in committing to peace, security, and trust on the internet. This couldn’t happen without you! Developers are central to making these commitments a reality: as programmers creating secure code, as leaders creating inclusive communities, and as citizens creating technically informed policy.
Today, we’re excited to announce that GitHub has joined 40 other software companies in supporting the GPL Cooperation Commitment. Our hope is that this change will improve fairness and certainty for users of key projects that the developer ecosystem relies on, including Git and the Linux kernel. More broadly, the GPL Cooperation Commitment provides an example of evolving software regulation to better align with social goals, which is urgently needed as developers and policymakers grapple with the opportunities and risks of the software revolution.
Regulations are put in place in order to achieve social goals—like reducing pollution or protecting consumers—but those goals aren’t automatically achieved. An “effective” regulation must direct behavior that will actually further intended goals and not cause too much unintended collateral damage.
But that’s not all: an effective regulation would also have an enforcement mechanism that encourages compliance rather than creates an opportunity to shake businesses down. Under effective regulation, the most severe penalties for non-compliance, like shutting down a line of business, would be reserved for repeat and intentional violators. Less serious failures to comply, or accidental non-compliance, may only result in warnings—if the violation is promptly corrected.
The GNU General Public License (GPL) is a tool for a private regulator (copyright holder) to achieve a social goal: under the license, anyone who receives a covered program has the freedom to run, modify, and share that program. (In contrast, a license like MIT does not regulate what freedoms downstream recipients must be offered. Whether to regulate in this manner or not is up to the developer of a program.)
However, if the developer does want to regulate, version 2 of the GPL (GPLv2) has one bug from the perspective of an effective regulator: non-compliance results in termination of the license, with no provision for reinstatement—making the license marginally more useful to copyright “trolls” who want to force companies to pay rather than come into compliance.
In contrast, version 3 of the GPL (GPLv3) fixed this bug by introducing a “cure provision” under which a violator can usually have their license reinstated—if the violation is promptly corrected. On choosealicense.com, we recommend GPLv3 when developers want to use a regulatory license.
Still, GPLv2 has served the Linux kernel, Git, and other developer communities well since 1991, many of which are unlikely to ever switch to GPLv3, as this would require agreement from all copyright holders, and not everyone agrees with all of GPLv3’s changes. But GPLv3’s cure provision is uncontroversial: could it be backported to GPLv2 licensed projects? In a sense yes, to the extent GPLv2 copyright holders agree.
The GPL Cooperation Commitment is a way for a copyright holder to agree to extend GPLv3’s cure provision to all GPLv2 (also LGPLv2 and LGPLv2.1, which have the same bug) licenses offered, giving violators a fair chance to come into compliance and have their licenses reinstated.
And importantly, the GPL Cooperation Commitment is an example of making regulation more effective in advancing a social good, like we discussed above. It also incorporates one of several principles (the others do not relate directly to license terms) for enforcing compliance with the GPL and other copyleft licenses as effective private regulation.
We’re happy to agree to the GPL Cooperation Commitment because it aligns with GitHub’s core values. Everything we build and support is grounded in empowering the people–and the community–behind the technology. We know GPLv2 will likely remain an important private software regulation for decades to come. It’s important to ensure that GPLv2 licensees have the ability to fairly correct license violations, and to support effective regulation that improves open source licensing for everyone. We also want to encourage both private and public policymakers to take similar care for effectiveness when considering regulation that will shape the future of software.
Continuing our work on EU copyright reform, last week GitHub visited Brussels to host an event for developers and policymakers about open source and copyright. During our trip, we also met with EU policymakers who are negotiating the final details of the EU Copyright Directive. Read on for a full event recap and to get the latest on where things stand for open source in the current negotiations.
Since GitHub’s first trip to Brussels in February, we’ve worked alongside other companies, organizations, and developers in the open source software community to raise awareness about the EU Copyright Directive. While we recognize that current copyright laws are outdated in many respects and need modernization, we are concerned that some aspects of the EU’s proposed copyright reform package would inadvertently affect software.
As part of our ongoing efforts to mobilize developers and educate policymakers about this, GitHub hosted an event last Tuesday in Brussels with OpenForum Europe and Red Hat. We invited EU developers, policymakers, researchers and more to join us for Open Source and Copyright: from Industry 4.0 to SMEs.
OpenForum Europe’s Astor Nummelin Carlberg welcomed the crowd, and then James Lovegrove from Red Hat moderated a round of lightning talks on different topics:
GitHub’s Abby Vollmer shares what developers can do to help with the EU copyright negotiations.
After the formal discussion, we finished out the evening with drinks and great conversations among developers, policy wonks, reporters, researchers, and policymakers alike. A big thank you to everyone who came out for the event and participated!
But our work isn’t over yet. In our last update, we explained that the EU Council, Parliament, and Commission were ready to begin final-stage negotiations of the copyright proposal. They’ll resume negotiations this Thursday. Of the parts most relevant to developers, negotiators from those three institutions are now working on exceptions to copyright for text and data mining (Article 3), among other “technical” elements of the proposal.
Article 13 (which would likely drive many platforms to use upload filters on user-generated content) is expected to be a thornier discussion, so negotiators are trying to get the technical elements resolved first. And since Article 2 defines which services are in the scope of Article 13, Articles 2 and 13 will be discussed together.
This means it’s not too late to contact these policymakers with your thoughts on what outcomes are best for software development. Here’s our take:
tl;dr = Council, adopt the Parliament’s language in Article 2.
Article 2 is important because it determines which services need to comply with Article 13. As an overall note, the language Article 2 uses to define what those services are could use some clarity, especially around what words like “organises,” “optimises,” and “promotes” mean. However, there are a few outstanding issues with the definition that are more directly relevant for software development:
We believe we’ve made some headway in our meetings last week in Brussels by describing how many software development platforms run as a business, but do not profit from content posted under an open source license.
This distinction isn’t intuitive, and developers can help educate policymakers about:
tl;dr = Adopt Article 3a as a mandatory exception.
On Article 3, including a broader exception for text and data mining that extends beyond only research organizations for scientific, non-profit purposes will be crucial for EU developers. However, that’s currently proposed as an optional exception (Article 3a). So why should the exception be mandatory, not just optional?
Contact your Council members to explain that limiting the software exclusion to only non-for-profits in Article 2 would fail to protect open source software in Europe. On Article 3, tell them why a broad, mandatory exception for text and data mining will help EU developers and businesses stay competitive. Make it clear how important this exception will be—especially where artificial intelligence and machine learning are at play.
Developers, let’s help policymakers get these parts of the proposal right.
Last week, we put out a call to action leading up to the EU Parliament’s vote on the Copyright Directive. Read on to learn what they decided, how this affects software, and what’s next in the process. (It’s not over.)
On September 12, the EU Parliament voted to:
If Parliament’s version of the Copyright Directive becomes the law:
But remember, Parliament doesn’t have the final word. We still need to keep an eye on the negotiations as they move to the next stage with the Council and Commission—and continue advocating to protect software.
There’s a lot to fix in the current copyright proposal. We’re looking at software because that’s where developers can speak with authority. Our focus now is on the negotiations among Parliament, Council, and the Commission (trilogues) to ensure exclusion for “open source software developing platforms” isn’t only limited to “non-for-profit” platforms. This was our goal back in April too, when both Council and Parliament proposed excluding only “non-for-profit open source software developing platforms.” With your help, we were able to show Parliament why a non-for-profit limitation would undermine their effort to protect software because most open source software development is built on platforms, like GitHub, that aren’t non-for-profit.
Now it’s time to make this clear for the Council. After hearing from developers, Parliament realized it didn’t make sense to limit the software exclusion to only non-for-profit software development platforms. We need to make sure the Council understands this, too. EU developers, contact your Council members and explain why they need to exclude all open source software development platforms from filtering obligations—not only non-for-profit ones—if they want to effectively protect software development in the EU.
Copyright law hasn’t kept up with the digital age, and we support greater copyright reform that protects how software development happens around the world today. But as we’re fixing copyright law, it’s important to make sure that we aren’t actually creating more problems. Although the Copyright Directive may be a step forward, we have to continue advocating for fair and balanced change that protects software—and the economy it powers—in the process.
On September 12 the European Parliament will vote on amendments to the EU Copyright Directive, which will greatly impact the future of open source, European competitiveness, and software development in general. We urge you in the EU to contact your Members of European Parliament (MEPs) to tell them how important open source is to all software development and to the EU. Check out our previous post for background and talking points.
Read on for details on the implications for software and society, key amendments being voted on, and how you can make a difference.
On September 5, we hosted HackerOne, Wikimedia, Reddit, and the Electronic Frontier Foundation (EFF) at our San Francisco office for the event How developers can defend open source from the EU copyright proposal, addressing the many EU developers working in the Bay Area.
We kicked off the event with our own Julio Avalos giving a big-picture look at where this proposal fits into the tech policy landscape. We explained that the copyright proposal would affect developers by requiring upload filters (Article 13), imposing a “link tax” (Article 11), and leaving text and data mining restricted (Article 3). Mårten Mickos, CEO of HackerOne, emphasized the proposal’s impacts on open source software for HackerOne and in the EU. Then, we moderated a panel with Wikimedia Foundation’s Senior Public Policy Manager, Jan Gerlach, Reddit’s Director of Policy, Jessica Ashooh, and EFF’s International Director, Danny O’Brien covering their communities’ involvement in advocacy and their thoughts on future implications of the proposal.
For example, recognizing that copyright law in many ways hasn’t kept up with the digital age, Wikimedia identified priorities for copyright reform, including protecting the public domain and freedom of panorama, as well as allowing sufficiently broad exceptions to copyright for user-generated content and for text and data mining. Learn more on their Fix Copyright landing page.
Our call to action at the event was the same as it is here: Developers, tell your MEPs to protect software.
So what exactly is Parliament voting on? The September 12 vote is not a simple yes or no—it’s actually quite complex. MEPs will vote on a number of amendments to the full directive that the EU Commission proposed two years ago. From the perspective of protecting software development, we offered our thoughts on what developers could tell MEPs that might be useful.
Details about key amendments MEPs will consider:
For an open internet
For software development
While there’s a lot to be concerned about in the Copyright Directive, it’s important to recognize the need for positive copyright reform that reflects the digital world developers are creating. Some amendments reflect this reality, like articles on freedom of panorama and exclusion of user-generated content, which are in the IMCO/LIBE and Schaake amendments.
There’s still time to contact your MEPs before they vote on Wednesday! Developers have an important role to play in explaining how software works and what’s at stake. Contact us if you need more information about the EU Copyright Directive.