Diverse Open Source uses highlight need for precision in Cyber Resilience Act

As the European Cyber Resilience Act (CRA) is entering into the final legislative phase, it still has some needs arising from framing by the Commission or Parliament that result in breakage no matter how issues within its scope are “fixed”. 

Here’s a short list to help the co-legislators understand the engagement from the Open Source community.

• OSI and the experts with whom they engage are not trying to get all of Open Source out of scope as maximalist lobbyists do for other aspects of technology. An exclusion from the regulation for Open Source software per se would open a significant loophole for openwashing. But the development of Open Source software in the open needs to be excluded from scope just as the development of software in private is. Our goal in engaging is just to prevent unintentional breakage while largely embracing the new regulation.
• There is no one way to use Open Source. Many of the policymakers we’ve spoken to think of Open Source components in supply chains under the care of foundations like the Eclipse Foundation that are used essentially as-is. But the freedoms of Open Source are also used for stack building, consumer tools, enabling research, hobbyist tinkering, as the basis for European small businesses like XWiki, Open-Xchange, Abilian, and more. All these many other uses exist and are broken differently by the CRA. Software is primarily a cultural artifact and that aspect must be prioritized.
• There is no single Open Source business model. People make money from Open Source (by charging for it, running it as a service and supporting it) and with Open Source (by simplifying their businesses and reducing costs); they shape markets via Open Source by enabling adjacent businesses, commoditising competitors without then monetising their customers, and more – there are a significant number of business models made possible by software freedom. So any attempt to identify commerciality is sure to be model-specific and consequently have unintended consequences for other models.
• Even larger foundations like Linux Foundation do not actually employ the sort of staff who ensure code compliance – Open Source is conceptually disjoint from proprietary software. To comply with the CRA – if they find themselves in-scope – they will need them to hire a whole new operating unit. To them, the burden of compliance is not a cost of development funded by revenue as it would be for a manufactured physical good where staffing exists and just needs adapting.

As we did in January, OSI still recommends the Cyber Resilience Act should exclude all activities prior to commercial deployment of software and clearly ensure that responsibility for CE marks does not rest with any actor who is not a direct commercial beneficiary of deployment.