By Drupal Association on

This post is a follow up on the collaboration between Drupal and other FOSS projects in response to the proposed CRA legislation in the EU. You can read our original joint letter here.

The Drupal Association has continued to participate in weekly calls with other open source projects leaders hosted by Open Forum Europe to discuss the proposed Cyber Resiliency Act (CRA) in the EU. 

The EU legislators are now reconciling several different draft versions of the regulation, and incorporating stakeholder recommendations into a new draft to be advanced through the legislative process.

For the past several months multiple constituent groups within the EU have shared draft versions of the text, soliciting feedback from a variety of stakeholders in government, industry, and the open source community. 

The Open Forum Europe group reviewed several of those draft pieces being reconciled by legislators and offered detailed input and recommendations. One of the major goals was to ensure that the obligations of the CRA don't fall as an undue burden on individuals, non-profits, non-commercial entities, etc., and to forestall unintended consequences that might curtail corporate participation in open source projects. 

The Drupal Association together with the other projects represented in this process strongly believes that Free and Open Source Software is more secure software, and wanted to ensure that this legislation would not stifle the growth of the FOSS movement.

Some of the many areas we focused our recommendations on were: 

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

… and many more recommendations, as well. 

What comes next?

When the draft versions have been reconciled by the EU legislature and the new text is publicly available we'll share with the community. The legislative process will then move form the main body to the standards and implementation details created by the act.