Opinion There has been considerable worry about the impact of the European Union's Cyber Resilience Act on open source programmers. Linux stable kernel maintainer Greg Kroah-Hartman says, however, that there won't be much of an impact at all.
The Linux Foundation has to abide by these rules. Mozilla has to abide by these rules. Me and Linus, as individuals working for them, don't have to abide by the rules...
When the news of the EU's Cyber Resilience Act (CRA) first emerged, open source software developers and companies were worried sick. As the Python Software Foundation (PSF) executive director Deb Nicholson said at the time, "Under the current language, the PSF could potentially be financially liable for any product that includes Python code, while never having received any monetary gain from any of these products." Ouch!
Since then, however, the EU has made the CRA more open source friendly. How friendly? Well, according to Greg Kroah-Hartman, a top Linux kernel maintainer and member of the CRA working group of experts, "for open source contributors and maintainers, … [the] CRA is a good thing. I think it's gonna help us.
Speaking in Paris at the Linux Kernel Recipes conference, Kroah-Hartman started by saying, "You never expect to be dealing with lawyers and things like that when you start out programming. But here I am. This is all my personal opinion." But, he believes, the CRA has become "something that's actually palatable and can be used" for open source's benefit.
Kroah-Hartman explained that the CRA introduces a legal requirement for producers of products with digital elements (PDE). This is a broad category that includes nearly all software-driven devices and programs to document, secure, and maintain their software supply chain. This means companies must now generate a Software Bill of Materials (SBOM), tracking vulnerabilities, responding to newly discovered issues, and being transparent about security practices. For open source developers, this means, for the first time, companies must publicly acknowledge and document their open source dependencies. That's a win in Kroah-Hartman's book.
A fundamental distinction in the revised CRA's approach is how it separates unpaid, hobbyist developers from legal "people" such as foundations, projects, and companies that commercialize open source software. Specifically, non-commercial open source developers can continue publishing software with minimal worry. As long as a project is not organized as a legal or commercial entity, the CRA requires only a basic "readme" with a security contact. There is no legal risk for individual contributors simply sharing code online or in publications, even when they receive payment for writing an article, as long as the software itself is not monetized or organized.
That readme must say "who to email for security issues and report security issues" to a security monitoring organization. That's it. That's all. "So don't be afraid of the CRA. These are things you should be doing anyway."
Project stewards, such as legal persons, are another matter. They must provide a security contact and a reporting process. If the organization receives or distributes funding or donations, it falls into this category and must follow the stewardship requirements. "So, he continued, "the Linux Foundation has to abide by these rules. Mozilla has to abide by these rules. Me and Linus, as individuals working for them, don't have to abide by the rules." As far as Kroah-Hartman's concerned, "this is a reasonable baseline most responsible projects already meet."
What are these rules? Well, the CRA's focus is on commercial manufacturers and distributors. That means businesses that integrate open source code into EU products must fully comply with documentation, incident response, and lifecycle management requirements. This includes publishing Software Bills Of Materials (SBOMs), patching vulnerabilities within regulated timeframes, and responding proactively to security incident reports.
For the purposes of the CRA, consulting operations monetizing open source work could be considered manufacturers, triggering compliance obligations. Independent consultants or tiny firms may need to form a legal entity, but the workload is "not huge if you're already following good development practice," according to Kroah-Hartman.
The regulations are much more stringent for hardware or device vendors using open source code in their products than for pure software consultancies. For decades, hardware vendors have been using open source code without obeying the open source licensing rules, such as Vizio using Linux in its smart TV. Under the CRA, they'll find it much harder to get away with this or deny they're breaching open source software terms in their products, as Cisco did in 2008 with its Linksys routers. (It ultimately settled the case, appointed a free software director, made source code for products available on its website, and made a donation to the FSF.)
Manufacturers are going to care in September of next year. They're going to start panicking in the summer of next year, and things are going to start hitting the fan...
You may think that since the CRA is an EU law, it won't matter to countries outside the EU. You would be wrong. The CRA effectively extends worldwide. If software is accessible "on the market" in the EU, it falls under the law's scope. Thus, US and Japanese vendors, for example, must pay careful attention to compliance if their products are downloadable or operable from within the EU.
For example, manufacturers must act on vulnerabilities, even if the upstream maintainer does not fix the issue. Manufacturers selecting open source code for their products must understand the code, support it, and respond to regulatory reporting requirements. This may, Kroah-Hartman observed, increase pressure on companies to use actively supported open source projects or stick closer to mainstream, well-resourced communities."
Will this make companies more wary of using open source software? Kroah-Hartman thinks it will have the opposite effect. The CRA also covers proprietary software. Instead of these new requirements creating a "chilling effect" on open source releases by nervous companies or legal departments, he thinks it will actually increase demand for open source, since companies gain more control over code destiny than with closed source vendors.
Businesses that are already using open source code in their programs still haven't realized just what a big deal the CRA will be for them. They will soon enough. Kroah-Hartman predicts, "Companies are coming after you [open source developers]. I will create a little form letter and say, 'Here's what you need to send off.'
"It's going to get worse because it's coming soon for companies. Manufacturers are going to care in September of next year. They're going to start panicking in the summer of next year, and things are going to start hitting the fan."
They'll want developers to shoulder the burden the CRA will place on them. But you don't have to do that. It's their problem, not yours as a programmer.
Of course, developers are encouraged to adopt best practices - eg, secure reporting, clear SBOMs, supply-chain checks - now. Foundations and large community projects are working with the EU to produce checklists and templates to simplify compliance. Kroah-Hartman reports that much of the ambiguity around commercial versus non-commercial obligations will be clarified in the coming year, with accessible implementation resources for projects.
In a Q&A session afterwards, Kroah-Hartman struck a hopeful note, "The goal here and the intent is not to trip up anybody in this room. The goal and intent are also to hold big companies liable when they release open source software, as part of that, because they want it not to be an end run around the CRA.
"Therefore, merging those two things together created a really wiggly line in the middle. But they are on our side. I've spoken with representatives from the different countries that created this law. They understand open source. They understand how the world runs in open source. They don't want to see it harmed by this at all. So have faith in that." ®