The Cyber Resilience Act introduces uncertainty and risk leaving Open Source projects confused

What might happen if the uncertainty persists around who is held responsible under the Cyber Resilience Act (CRA)? The global Open Source community is averse to legal risks and generally lacks access to counsel, so it’s very possible offers of source code will simply be withdrawn rather than seeking to resolve the uncertainty.

The CRA rightly addresses the need for commercial suppliers to protect their customers from exploits and cyber attacks. But legislators have exposed the open development of software itself to the regulations rather than just the for-profit use of Open Source artifacts in the marketplace. They are incorrectly assuming that Dirk Riehle’s terminology calling single-company projects “commercial Open Source” means it’s possible to use the “commerciality” of an application to distinguish single-company activity from community projects, and by using the concepts of proprietary software to then define boundaries.

There will be no escape from this for European projects like the Eclipse Foundation, but projects outside Europe — especially smaller projects — may just decide to erect geo-blocks and not deliver their work to European IP addresses. CRA-motivated geo-blocks start with needing to seek legal advice because it’s so confusing/unclear, only then to be told “maybe,” leaving you to make the decision on your own.

One response when I raised this was to say that the European Union is a massive and valuable market, and projects would not risk being excluded from it by geo-blocking. But this argument ignores the fact that just because Alice deploys some code profitably in Europe, it doesn’t mean Bob in Nebraska who wrote the code will share in the profit, whether he’s in business or not where he lives. Open Source licenses do not create a relationship in which financial reward is guaranteed.

Geo-blocks have happened before. Many small global publications block access from the EU rather than resolve legal uncertainties with GDPR. But the risk of CRA-related geo-blocks is much more consequential because reading those sites is optional whereas much Open Source software maintained internationally is woven into the fabric of Europe’s infrastructure.

In addition, those avoiding evaluating their GDPR responsibilities (or evading them after evaluating them) are likely to fear compliance will impact the benefit they gain from surveillance advertising, while for Open Source developers the perceived risk is of being the target of a punitive bureaucracy for failing to complete paperwork that adds nothing to their work.

If the confusion persists, Open Source projects will need to thoughtfully consider how to proceed. Disentangling dependencies that choose to pragmatically block Europe will be traumatic; should they be forked or substituted? Things could get very messy. Let’s hope the co-legislators see sense, finally talk to the Open Source community and address the issues.

This article first appeared on Webmink in Draft.

Image created by Simon Phipps featured on Webmink in Draft.