Notices by Maarten Aertsen (maarten@techpolicy.social)

@mmu_man @senficon And you believe the CRA has a requirement that conflicts with shipping products that contain functionality based on reverse engineering efforts?

@mmu_man @senficon Reading your responses, I can see you care, a lot. It seems you are scared and/or upset about something the CRA will do. But I still have a hard time understanding what that something is.
What the CRA notably does *not* do, is advance the status quo with respect to proprietary standards, the right to repair or open hardware. And that’s sad, but it’s also not what they set out to achieve.

@mmu_man @senficon
> How can I certify that the software I wrote follows the documentation I never had access to, or that this protocol/hardware is devoid of bugs?

I’m not sure that that’s a claim one needs to make for the CRA, to be honest. But I would like to better understand the problem you are describing.

Is your proposal somewhere public? I’d like to understand what bits in the CRA you believe to be in conflict with what you (or others) are trying to achieve.

@mmu_man @senficon That is/would be bad, but I’m not sure that’s a conclusion I would draw from my own mental model of how the CRA works. But perhaps things are different, let’s find out.
That integrator, should they be involved in a commercial activity, would likely be a manufacturer, regardless of licensing if they put their product on the EU market. At that point, they would need to conform to the CRA. I don’t think that necessarily affects upstream ffmpeg.

@mmu_man @senficon I’m sorry, responsibility for what? From the blog, I see you care about right to repair, open standards, as do I.

But this thread is about the CRA. So what is it that you believe changes? Can you be specific?

@senficon wrote a very accessible guide to the #CyberResilienceAct for #foss developers on the GitHub blog. I recommend it for anyone figuring out what the #CRA means for their #opensource project:
https://github.blog/open-source/maintainers/what-the-eus-new-software-legislation-means-for-developers/

Today, I’ll work on drafting feedback to ENISA’s consultation on their guidance for the #NIS2 implementing act for the digital sector. Once again, the #foss bits could use some love, though I’m happy they did write about it in the first place.
The focus is once again on “supply chain security requirements” with the goal of avoiding undue pressure from regulated entities towards upstream #opensource communities treated as “suppliers”.
Interested? Blog from past summer: https://blog.nlnetlabs.nl/supply-chain-security-obligations-for-nis2-regulated-entities-vs-developers-of-open-source-software/

#CyberResilienceAct published as Regulation EU 2024/2847 in the Official Journal of the EU: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202402847
Full application at 11 December 2027, reporting obligations at 11 September 2026.

I wrote on the implications for #opensource and #foss in the past, based on last year’s FOSDEM content, including resources by others:
https://blog.nlnetlabs.nl/what-i-learned-in-brussels-the-cyber-resilience-act/

Wondering what the #CyberResilienceAct means for #FOSS? I linked to a lot of good content on #CRA and #OpenSource earlier this year: https://blog.nlnetlabs.nl/what-i-learned-in-brussels-the-cyber-resilience-act/

The council of the EU adopted the #CyberResilienceAct earlier today.
“Following today’s adoption, the legislative act will be signed by the presidents of the Council and of the European Parliament and published in the EU’s official journal in the coming weeks. The new regulation will enter into force twenty days after this publication and will apply 36 months after its entry into force with some provisions to apply at an earlier stage.”
https://www.consilium.europa.eu/en/press/press-releases/2024/10/10/cyber-resilience-act-council-adopts-new-law-on-security-requirements-for-digital-products