This article is more than 1 year old

EU's Cyber Resilience Act contains a poison pill for open source developers

The road to hell is paved with good intentions

Opinion We can all agree that securing our software is a good thing. Thanks to one security fiasco after another – the SolarWinds software supply chain attack, the perpetual Log4j vulnerability, and the npm maintainer protest code gone wrong – we know we must secure our code. But the European Union's proposed Cyber Resilience Act (CRA) goes way, way too far in trying to regulate software security.

At the top level, it looks good. Brussels states that before "products with digital elements" are allowed on the EU market, manufacturers must follow best practices in four areas. Secure the product over its whole life; follow a coherent cybersecurity framework; show cybersecurity transparency; and ensure customers can use products securely.

Sounds great, doesn't it? But the road to hell is paved with good intentions. The devil, as always, is in the details. Some of this has nothing to do with open source software. Good luck creating any program in any way that a clueless user can't screw up.

But the EU commissioners don't have a clue about how open source software works. Or, frankly, what it is. They think that open source is the same as proprietary software with a single company behind it that's responsible for the work and then monetizes it. Nope.

Open source, as I've said over and over again, is not a business model. Sure, you can build businesses around it. Who doesn't these days? But just as the AWSes, Googles, and Facebooks of the world depend on open source software, they also use programs written by Tom, Denise, and Harry from around the world.

The CRA's underlying assumption is that you can just add security to software, like adding a new color option to your car's paint job. We wish!

Securing software is a long, painful process. Many open source developers have neither the revenue nor resources to secure their programs to a government standard. The notional open source developer in Nebraska, thanklessly maintaining a vital small program, may not even know where Brussels is in Europe (it's in Belgium). They can't afford to secure their software to meet EU specifications. They often have no revenue. They certainly have no control over who uses their software. It's open source, for pity's sake!

As open source developer Thomas Depierre recently blogged: "We are not suppliers. All the people writing and maintaining these projects, we are not suppliers. We do not have a business relationship with all these organizations. We are volunteers, writing code and putting it online under these Licenses." Exactly.

Gabriele Columbro, Linux Foundation Europe's General Manager, addressed these concerns in his KubeCon CloudNativeCon Europe 2023 keynote speech. Columbro urged the open source community to actively help refine the CRA to better protect their interests. "The current form of the CRA could fragment open source and put developers at risk," he said.

How? The OpenForum Europe (OFE), Eclipse Foundation, Open Source Initiative (OSI), APELL, CNLL, and The OSB Alliance stated in a letter to the EC: "The current formulation of the CRA interferes with almost every software development model other than the case of a single company developing the entire code-base behind closed doors and making periodical releases." And who does these days? Apple maybe, but no one else of any importance comes to mind.

Everyone else, including open source developers from our guy in Nebraska to someone working at the non-profit OpenSSF to an IBM developer, are potentially vulnerable. The OSI is concerned, with reason, that unless the act clearly excludes developers whose activities aren't tied to commercial software deployment, the CRA "could chill or even prevent the availability of globally maintained open source software in Europe."

Besides, GitHub pointed out that some of the CRA's other requirements are flatly unattainable. "Annex I requires delivery 'without any known exploitable vulnerabilities,' but this risks an unobtainable objective, as manufacturers regularly learn of new vulnerabilities and make risk-based assessments on the need to prioritize fixes for timely delivery of product updates."

Just how bad is this? Simon Phipps, Director of EU Policy and Standards at the Open Source Initiative, suggests that to protect themselves, developers "might decide to erect geo-blocks and not deliver their work to European IP addresses." Sounds crazy? He's far from the only one. No open source developer wants to deal with international liability issues. Heck, who does!?

As the Python Software Foundation notes: "Many modern software companies rely on open source software from public repositories without notifying the author, and certainly without entering into any kind of commercial or contractual relationship with them. If the proposed law is enforced as currently written, the authors of open source components might bear legal and financial responsibility for the way their components are applied in someone else's commercial product."

It's not that the EU wants to hurt the open source development community. It doesn't. It's that it doesn't know any better. So many open source community members are calling on people to participate in this discussion by reaching out to Linux Foundation Europe or joining the LF Europe CRA Discord Server channel. We must educate them. If not, we may end up with an ugly legal mess that will hinder open source development for years to come. ®

More about

TIP US OFF

Send us news


Other stories you might like