Policy


Developers on the world stage—global commitments on building an internet of trust

The Internet of Trust: Internet Governance Forum

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.

Collective action on cybersecurity

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.

Open source as a model for community 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:

  • Be clear about the rules governing behavior and content
  • Make sure those rules reflect the community’s norms
  • Moderate respectfully and effectively using appropriate tools
  • Establish penalties for violations, and enforce them

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.

Effective regulation matters: Join us in the GPL Cooperation Commitment

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.

What is effective regulation?

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 current state of the GPL as private software regulation

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.

How the GPL Cooperation Commitment can help

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.

Why we support the GPL Cooperation Commitment

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.

How you can get involved

You can join us in making the GPL Cooperation Commitment as a company or individual. GPLv2 projects can add the GPL Cooperation Commitment as an additional permission.

EU copyright update—GitHub goes to Brussels

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:

  • Policy: For GitHub, I shared how developers have been especially effective in getting policymakers to respond to problems with the copyright proposal and asked them to continue reaching out to policymakers about a technical fix to protect open source.
  • Developers: Speaking from a developer’s perspective, Evis Barbullushi (Red Hat) explained why open source is so fundamental to software and critical to the EU, using examples of what open source powers every day, as well as underscoring the world-class and commercially mainstream nature of open source.
  • SMEs: Sebastiano Toffaletti (European Digital SME Alliance) described concerns about the copyright proposal from the perspective of SMEs, including how efforts to regulate large platforms can end up harming SMEs even if they’re not the target.
  • Research, academia: Roberto Di Cosmo (Software Heritage) wrapped up the talks by noting that he “should not be here,” because in a world in which software was better understood and valued, policymakers would never introduce a proposal that inadvertently puts software at great risk, and motivated developers to fix this underlying problem.

GitHub's Abby Vollmer discusses open source and copyright in Brussels
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!

Status of open source in the negotiations

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:

Article 2 (related to Article 13)

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:

  • The Council’s attempt to exclude open source software development platforms from the definition is currently ineffective because it would only apply to non-for-profit platforms.
  • The Parliament’s version of the definition would exclude all “open source software developing platforms.” To more effectively protect software development, Member States in the Council just need to make this technical fix: “~not-for-profit~ open source software developing platforms.”

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:

  • How you collaboratively build software
  • Why it’s useful to be able to use software that’s licensed as open source
  • That developers who license their code under an open source license understand they aren’t going to earn money from licensing fees or royalties on that code
  • Whether a platform is a non-for-profit isn’t the same as whether a platform is monetizing or otherwise profiting from publicly posted code under an open source license

Article 3

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?

  • EU developers will need the protection of a broader, mandatory exception to keep up with countries like the U.S. that don’t require the kinds of licenses proposed in the EU Copyright Directive.
  • A mandatory exception also makes more sense in the spirit of harmonizing standards across the EU and creating a predictable legal environment for developers.

How you can help

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.

What’s next for the EU copyright proposal?

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.)

What Parliament decided

On September 12, the EU Parliament voted to:

  • Make content-sharing platforms directly liable for copyrighted content that users upload, which could lead to use of upload filters (Article 13)
  • Exclude “open source software developing platforms” from that liability and need for upload filters (Article 2)
  • Allow an exception for text and data mining only by research institutions for scientific purposes on a “non-for-profit” basis, with only an “optional” exception for others (Article 3)
  • Create a new right for press publishers to require a license to use content of news articles except for “mere hyperlinks, which are accompanied by individual words” (Article 11)

What this means for software

If Parliament’s version of the Copyright Directive becomes the law:

  • Sites that host user-generated content may need to filter content that users upload, but “open source software developing platforms” (like GitHub) wouldn’t need to. We supported a broader exclusion for software development platforms, archives, and repositories, as it would have protected more of the software development community. However, Parliament adopted the narrower language. Since elements of software development happen beyond that narrow exclusion, developers would need to consider whether they might be subject to liability for the content they host and resort to measures like filtering.
  • Developers may need licenses to mine content—including for artificial intelligence and machine learning—unless individual EU countries decide to adopt an exception from text and data mining that would cover them. Without a mandatory broader exception, developers would be subject to a patchwork of regulations across different EU countries.
  • Developers who link to news articles may need to pay to use content like article headlines or snippets. It may take a judge to interpret what the phrase “individual words” means exactly in the hyperlinks press exception we called out above. In the meantime, developers would need to be careful about what content they include to describe links.

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.

What we can do next

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.

How developers can defend open source from the EU copyright proposal

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.

What Parliament will decide on September 12

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

  • The IMCO/LIBE committee amendments are most effective in promoting openness by focusing on active platforms and only requiring licensing agreements, not upload filters.
  • The latest European People’s Party (EPP) (MEP Voss) amendments no longer talk about “measures” (which, in previous drafts, meant upload filters) but would still require filters unless platforms obtain licenses for copyrighted content.

For software development

  • Article 13 (based on Article 2’s definition of what is in scope)
    • MEP Schaake’s amendments are the most protective of software development by more narrowly defining who is in scope for Article 13 (platforms where people upload music or video) and more broadly excluding software (archives and repositories, along with open source software development platforms).
    • The JURI Committee, ALDE party and latest EPP amendments all contain the same exclusion for “open source software developing platforms.”
  • Article 3
    • Both the IMCO/LIBE and Schaake amendments benefit developers by creating exceptions for text and data mining (TDM) wherever the beneficiary has lawful access (rather than only for research organizations conducting TDM on a not-for-profit basis).
  • Article 11
    • The IMCO/LIBE amendments also protect developers by prohibiting a link tax (meaning a press publisher cannot require a license to use a link needed to identify or request a source’s contents). They also give press publishers named in a publication the ability to conclude licensing agreements, rather than granting them rights by default.

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.

Newer

Changelog

Subscribe

Discover new ways to build better

Try Marketplace apps free for 14 days

Learn more