The European Union (EU) is currently considering approval of the Cyber Resilience Act (CRA), a proposed regulation that is a major threat to the future of the global open source industry. While the intention of the act is to enhance cybersecurity (which is extremely welcome), its current form lacks clear liability exemptions for many open source developers and maintainers, which could be a death knell for open source in the EU and which could spark additional, global implications.
The CRA regulation for the EU was proposed on September 15, 2022, by the European Commission. The intent is to improve cybersecurity and cyberresilience in the EU through common cybersecurity standards for products with digital elements. In theory, this is welcome. But there are some notable areas that many open source developers and industry organizations are concerned about.
Modern applications are comprised of 90% open source code; penalizing open source developers would lead to a fragmented community and hinder important projects across various sectors, including critical infrastructure, health care and even military systems.
The seemingly purposeful omission of exemptions for open source would put undue onus on open source foundations and maintainers and poses a serious risk to not just EU innovation and security but global collaboration. Something we, and many others in the industry, have tried to raise awareness about over the past six months. Unfortunately, the EU has largely ignored the industry’s voice. Holding open source developers whose components end up in commercial products liable for security issues will stifle innovation and harm the EU economy without providing a substantive improvement in security.
This legislation is slated for a vote on July 19 in the parliament’s Industry, Research and Energy (ITRE) committee, where it will then be sent on to the full parliament. And, if nothing is done, it could be adopted without even a vote in a plenary session by the Parliament itself. I feel strongly that if the open source industry doesn’t take a stand now, it will become law and the open source community as we know it will be no more.
There are two main problems with the proposed CRA: It discourages commercial support of open source and imperils vulnerability disclosure.
CRA Discourages Commercial Support of Open Source
The revised CRA offers new cybersecurity requirements for hardware and software products, much like the U.S.’s National Cybersecurity Strategy does. It calls for software vendors and producers to understand what components are in their software and to be able to recall software that is affected by a vulnerability. But, unlike the recently released details for the U.S. strategy, it seems to be trying to call out certain open source projects from foundations and large companies. By doing so, it potentially impacts every open source project, which creates a web of issues.
It goes without saying that open source projects rely heavily on volunteers, individual contributors and small teams who often work without significant resources or financial support. The support that foundations and contributors do get often comes from commercial entities who have adequate resources to provide developer time to give back to the community.
The current CRA text only excludes OSS software that has no commercial activity around it. Unfortunately, it defines commercial activity in part, this way:
“where the main contributors to free and open-source projects are developers employed by commercial entities and when such developers or the employer can exercise control as to which modifications are accepted in the code base, the project should generally be considered to be of a commercial nature.”
This can be read to mean that if the main contributors are not unemployed, then the project is commercially tainted. It does not clarify what was probably intended—that the employer fully controls the project here.
Additionally, it says:
“Accepting donations without the intention of making a profit should not count as a commercial activity, unless such donations are made by commercial entities and are recurring in nature.”
The first part is acceptable, but recurring donations from commercial entities are the upside of contributing back to open source. This may force the projects to reject large contributions to avoid becoming “tainted,” and will likely cause commercial entities to enact further bans on OSS contributions and pull their support entirely.
Further, if the CRA is passed without proper exemptions, these developers and maintainers may face legal risks and liabilities for vulnerabilities found in code used in commercial products. The OSS developers have no visibility into how and in what instances their components are used; only the final manufacturer of the product has this visibility.
The potential legal risk, without an upside, would discourage OSS developers from contributing to and maintaining open source projects. This situation not only undermines the spirit of open source but could bring about an open source crisis and isolate the EU from the rest of the world. Non-EU open source producers will avoid the EU market, meaning no access to Linux, Apache, Kubernetes and many other projects. Repositories like Maven Central, npm and PyPi may be prompted to ban EU consumption to avoid being considered a distributor. EU projects concerned about liability could pull their source code off the internet, and EU businesses may be forced to halt contributions to open source projects.
CRA Imperils Vulnerability Disclosure
The regulation also would require that vulnerabilities be disclosed to the European Union Agency for Cybersecurity (ENISA) within hours of discovery, whether or not a fix is available. This would make it difficult to conduct coordinated disclosure—where researchers give vendors time to develop security patches before vulnerabilities are disclosed publicly. This would increase the chances that bad actors will develop exploits for the vulnerabilities before they are fixed, putting every company that uses that software at risk. This would be an unfortunate outcome for a law whose purpose is to improve security of software.
What Can we Do?
As I mentioned earlier, time is of the essence since this measure is moving quickly and faces a vote this week. We need the community to take immediate action. GitHub and other industry bodies need to publicly oppose the proposed measure. EU developers, maintainers and others need to ask their European Parliament Members (MEPs) to investigate further and bring the voices of the open source community to the discussion.
Legislators need to understand the importance of collaboration and the role of the global developer community in driving open source innovation. Open source projects underpin much of the software we use every day. It’s the lifeblood of the internet. Legislation that deters contributors would interfere with the open source community’s ability to maintain existing projects and deliver new software, impacting the tech industry, hurting the EU economy and compromising overall software security.
