Cyber Resilience Act: regulating a European industry without understanding it can destroy it

EUCLIDIA assisted in the recent Open Source Community exchange of Open Forum Europe on the Cyber Resilience Act (CRA). In it's current form, it is the result of attempting to regulate foreign competitors such as Google or Microsoft (GAFAM), but without having an in-depth understanding of today's common practices in Open Source software development. Continuing without consulting the European open source community may well mean the end to an industry contributing up to 95B€ annually to European GDP.  

CRA status

• Open Source is the main issue going forward, two principal problems: #1 The CRA applies hardware regulation to software and #2 has been done with proprietary software development in mind
• Many lobbies are involved, it is hard to influence parts that many actors pull in different directions, not really applicable for Open Source, so there is some leverage
• Non commercial Open Source will be ok, commercial Open Source not yet, still time to improve. Trilogue participants open to making substantial modifications.

CRA texts

• Council - https://data.consilium.europa.eu/doc/document/ST-11726-2023-INIT/en/pdf
• Commission - Proposal for a Regulation on cybersecurity requirements for products with digital elements - Cyber resilience Act (Annexes)
• Parliament = ITRE https://www.europarl.europa.eu/meetdocs/2014_2019/plmrep/COMMITTEES/ITRE/DV/2023/07-19/11-CA_CRA_EN.pdf

CRA details

• CRA => three texts going to trilogue end of September (scheduled to last for 2 months)

1) Parliament text

• Recital 10a/b are problematic, objective to close loophole for GAFAM by applying CRA if one company alone maintains and profits from a project, but GAFAM have resources and network to do multi-stakeholder development, SMEs don't
• Complexity is bad, goes against SMEs, not aware they may be exempt
• Complexity is good, because Council and Commission are more likely to remove complex phrasings

2) Council text

• Better, splits development and supply, only supply triggers CRA, allows corporate contributions etc.

3) Commission text

• Same as last September, very unlikely text still represents Commission opinion.

Next steps

• Still interest in scenarios how CRA affects software and Open Source, Position paper for trilogue participaints to be done in August
• Show shortcoming eg lack of funding of foundations preventing them to play a role in stewarding projects
• Break down Debian into packages and foundations, show small foundations have no developers for fixes and suggested approach is not practical
• Show unfair advantage for proprietory software (no obligation to disclose bugs etc)

Other policy topics

1. Product Liability Directive (PDL) - follows the CRA, but instead of obligations it has liabilities. It is worse than CRA, because no limit to damages. Corrections go in good direction, Parliament discussion in September, Trilogue in November
2. AI liability directive, only in next legislature likely
3. CRA standards - objective to introduce standards, easier to comply to CRA if following standard. Risk for standardisation body to choose standard not compatible for Open Source, another potential advantage for proprietary software
4. Implementation guideline to determine commercial activity
5. Interoperable Europe Act
6. Standard Essential Patents regulation (SEPA) - objective of more transparence againt patent fraud, determine patent footprints and reduce it over time. Actors are trying to love it to death = no time to come to decision before end of legislature
7. NLF (new legislature framework and blue guide - text terminology to write policies, not well suited for software, up for review end of the year.