Update on the EU’s Cyber Resilience Act

In July 2023, TYPO3 and fellow free and open-source software CMS projects wrote a joint letter to warn of what we saw as adverse effects of the European Union’s Cyber Resilience Act (CRA). Since then, projects have been meeting regularly. 

Representatives have also participated in weekly calls with other open-source projects hosted by Open Forum Europe (OFE), to discuss the proposed legislation.

The TYPO3 Association is sponsoring and will be attending OFE’s EU Open Source Policy Summit in Brussels, Belgium, 2 February 2024. Read more

Protecting Free and Open-Source Software

The projects represented in the discussions strongly believe that free and open-source software (FOSS) is more secure software, and wanted to ensure that this legislation would not stifle the growth of the FOSS movement.

Multiple groups within the EU have shared draft versions of the CRA text. Several of the drafts being reconciled by legislators were reviewed within the OFE group, and detailed input and recommendations were offered to the EU.

We will update you when the draft version of the CRA becomes publicly available. The legislative process will then move to the standards and implementation details created by the act.

Recommendations Made to the European Union

One of the major goals was to ensure that the obligations of the CRA didn’t become an undue burden for individuals, non-profits, non-commercial entities, etc., and to forestall unintended consequences that might curtail corporate participation in open-source projects.

The article you’re reading now is based on a blog post published by our friends in the Drupal Association. Within their post, they also compiled the following list of some of the many areas where recommendations were made:

Criteria for Obligation Under the Regulation

• Preventing redundant obligations on open-source software caused by use across multiple entities, and ensuring that appropriate obligations for larger entities are not unfairly enforced on smaller ones.
• Avoiding tying obligations to the rate of the release cycle, which could create a chilling effect on innovation.
• Further clarifying that individual contributors as natural persons do not invoke regulatory obligations by participating in open-source projects.
• Encouraging a process that will allow alignment of obligations internationally, so that it will be easier for global communities to meet all their regulatory obligations.

Defining Commerciality

• Improving the text's definition of commerciality, to help ensure that open-source projects and the non-profit foundations that support them are not unintentionally punished for the maturity of their development process or the effectiveness of their fundraising activities. 

Risk Assessment 

• Portions of the regulation depend on the concept of risk assessment and the evaluation of security issues as low or high risk, known vulnerabilities, exploitability, etc. We noted that these definitions must be carefully considered, transparent, standardized, and have room to be refined post-enactment. 
• We also raised examples of why the method of remediation of known vulnerabilities might vary depending on each project’s approach, suggesting that this should not be too rigidly defined.

Open-Source Stewardship

• The regulation introduces the concept of an open-source steward, a legal entity that can be said to hold responsibility and accountability for an open-source project.
• This creates a category for obligations separate from those of software manufacturers with a level of flexibility appropriate for open source.
• However, we noted some potential pitfalls in discrepancies between the definition of stewardship and the authority those steward organizations might have over their projects (see for example, collaborative/decentralized projects).

Collaborative/Decentralized Projects

• Most regulatory language assumes a central entity with responsibility and accountability. Open-source projects are often collaborative and decentralized. We provided several recommendations for defining collaborative projects and flagged some concerns with use of the term decentralized in their regulatory definition. 
• The primary goal of our recommendations was to avoid inducing obligations (or the risk of fines) on entities that do not necessarily have formal legal relationships with each other nor formal ownership of the software projects they are participating in. 

The content of this article is based on content from drupal.org, published by the Drupal Association under the Creative Commons License, Attribution-ShareAlike 2.0.