How the EU’s Cyber Act Burdens Lone Open Source Developers  ## Metadata - Author: [[The New Stack Podcast]] - Full Title: How the EU’s Cyber Act Burdens Lone Open Source Developers - Category: #podcasts - URL: https://share.snipd.com/episode/dfac23f2-d9de-4a5d-afdc-a9f3b8d43c3b ## Document Notes ## Highlights - **Open Source Permeates Commercial Software** - Open source projects often start as personal solutions and unintentionally become critical parts of commercial products. - Christopher Robinson notes up to 97% of commercial software includes open source components, creating broad exposure. Transcript: Christopher Robinson Wants to contribute and kind of give up their creativity in the world. So if it's financial, a lot of it is, you know, they have a problem they're trying to solve. Yeah. Almost never is it, I want to sell a product to somebody in Greenland or Australia or wherever. So what they're thinking about, I have this problem, so I'm going to write this application or this utility or framework or whatever it is. And they recognize that other people might have the same problem. So they give it up to the open source community. And ideally, they get more contributors and people use it. They get a lot of pride and affirmation that their work is great. Well, a lot of manufacturers leverage open source. Depending on what study you read, I've read between 80 and 97% of commercial offerings contain substantial amounts of open source software. And that's, you know, Sonatype and others constantly look at this every year. Well, with all this open source software, so these commercial entities, they're selling to customers, selling within different geopolitical regions. And these governments, whether it's the US or the EU or China or India, they will institute laws to protect their citizenry. Over the last few years, the European Union was working on legislation called the Cyber Resilience Act or the CRA. And they were focused on protecting their citizens from cybersecurity incidents. So like log for shell, XZ utilities type things. They want to make sure that their citizens are protected and their data is kept safe. And they've put together a collection of cybersecurity requirements and have codified this into law that will be coming into effect both October 26th, I'm sorry, October 11th, 2026 For some of the reporting obligations. But then December 11th, 27 is when the law goes into full effect. And for a commercial enterprise, there are some fairly burdensome things they have to do and some very large consequences, like on the magnitude of billions of euros and fines and penalties If they're found negligent or they harm customers within the union. ([Time 0:01:20](https://share.snipd.com/snip/aa94701c-9b90-4391-9e52-26def8863780)) - **Downstream Bears Regulatory Burden** - Downstream manufacturers must meet CRA reporting and security obligations even when they include upstream open source code. - Robinson highlights that upstream maintainers typically lack visibility into how their code is used and aren't required to comply. Transcript: Christopher Robinson Yeah. Like the infrastructure to run the software. Absolutely. And looking at like an average open source project has like on average around 160 dependencies. So the developer made this software and you've got so many lines of code, but then they have frameworks or SDKs or other dependencies that they're bringing in so that the project you're Using, the sum is much greater than just what the developer did. And it's these manufacturers, it's the turbine company that has the obligation to the union to do the reporting, to make sure that they're compliant, they're doing secure by design, Secure by default practices. It's not the upstream maintainer. It's not that engineer that's hacking away on the keyboard on their nights and weekends. What Daniel's keynote noted is that upstream very rarely has an understanding of how their software is actually used. Right. Again, they're looking at, I'm solving this problem. Right. Well, commercial enterprises will say, that's great. That helps me save engineering costs. Right. That helps me lower my operating costs, whatever it is. And so they'll grab that and package it as part of their solution. And those commercial entities have some pretty strict requirements around like reporting of vulnerabilities and kind of documentation and process that upstream has no idea of, And they're not required to do. ([Time 0:04:11](https://share.snipd.com/snip/8b356a50-bcb5-4cef-bc50-4ea9eb965a6b)) - **Curl Maintainer Faced Legal Demands** - Daniel (curl) received aggressive requests from commercial lawyers and agencies demanding SBOMs and conformity assessments. - Robinson recounts Daniel's keynote to show how maintainers face relentless downstream pressure they never expected. Transcript: Christopher Robinson So what Daniel noted in his keynote is the constant pressure and requests and demand from downstream that he has no relationship to. He showcased letters from commercial lawyers or different governmental agencies demanding, give me your S-bomb. Give me your market surveillance conformity assessment. And that's not necessarily the role of those engineers upstream. Alex Williams Let's talk about the responsibilities of the engineer upstream right dan went through them pretty clearly you know he might have to be responsible for a mailing list he has to review All the contributions he he approves a pull request he does uh he writes a blog post and he might as he said, kind of jokingly, do some feature upgrades. That's kind of something that people do all the time in these up-stair engineering communities. And it seems to me that that's a great burden on them already. It is. And so what are you thinking about what the added burden will be to these people? Christopher Robinson So legally, the burden is zero. Zero. Zero asterisks. There's certain situations. But there is toil. So in the law, they talk about an open source project is allowed to receive donations and grants, but they can't make a profit. They can only cover kind of their operating expenses. So that's kind of a gray area we're working with the commission to iron out. But beyond those people that sell support or get donations or whatever, the normal upstream maintainer has no obligations. They may feel a civic duty or kind of a community duty that I want my software to be held in high regard and kind of has high quality, but there's no legal obligation for them. And as Daniel pointed out, and the majority of upstream projects are single maintainers. It's the Linux kernel, Kubernetes, the Apache projects. Those are the anomaly within open source where you have a large security team, a big group of contributors. Daniel for curl is the maintainer. He has a lot of other contributors, but because you have that role, you're doing infrastructure makings, the blog, all these other stuff. And again, you're right. He was joking. Maybe I get to actually develop once in a while. Well, these downstream customers that have potential billions of euros of penalties looming over them, they're not kind to these developers that are providing their work for free. ([Time 0:05:33](https://share.snipd.com/snip/676b1369-104e-43f1-842e-2a54b4fb33c2)) - **Legal Risk Vs. Practical Toil** - Legally, most individual upstream maintainers have zero obligations under the CRA, but they still face heavy operational toil. - Robinson stresses the law allows donations/grants but keeps profit-making limited, creating ambiguity for maintainers. Transcript: Christopher Robinson So legally, the burden is zero. Zero. Zero asterisks. There's certain situations. But there is toil. So in the law, they talk about an open source project is allowed to receive donations and grants, but they can't make a profit. They can only cover kind of their operating expenses. So that's kind of a gray area we're working with the commission to iron out. But beyond those people that sell support or get donations or whatever, the normal upstream maintainer has no obligations. They may feel a civic duty or kind of a community duty that I want my software to be held in high regard and kind of has high quality, but there's no legal obligation for them. ([Time 0:06:47](https://share.snipd.com/snip/cd7865ad-bc0c-44ba-a8e5-54d12e0f0891)) - **Maintainers Treated Like Corporations** - Business people often treat lone maintainers like formal vendors, despite many being single volunteers working nights and weekends. - Robinson describes the communication gap where businesses expect documentation and processes maintainers typically don't provide. Transcript: Alex Williams Right there? And that's a funding gap too. It is also. Can you talk about that funding gap? Because we talk all the time about funding open source developers, these single projects. But when you're talking about a business entity talking to an individual, there's no entity on the other side to support. No. So it becomes a very kind of complex way because then it's like, well, do I incorporate myself as an LLC? But if I do that as an engineer, I'm facing my own liabilities. Christopher Robinson Exactly. Well, and there's also additional cost. It's hassle. It's not related to developing and creating software. So ([Time 0:09:40](https://share.snipd.com/snip/cb98da32-7cc8-4c05-a6b1-765fe6d65080)) - **Steward Role Aims To Fill Support Gap** - The CRA introduced an 'open source steward' role to encourage foundations to support maintainers with funding and services. - Robinson highlights support can include cloud credits, test harnesses, and security experts, not just direct money. Transcript: Christopher Robinson Exactly. And that's why within the CRA law, they created this category called open source steward. And broadly, that equates to foundations like the Linux Foundation or Apache Eclipse, these other Rust broadly. There's some other people that can kind of qualify as a steward. But the creation of this role is to help encourage industry and nonprofit foundations to help support these developers. And funding, you know, grants or donations are always welcome, but that's not the only way you could support. But how do you fund them if they're individuals? Sometimes you can't. They might maybe they work at a university. So it's part of a university research study. So they're legally not allowed to take funding, and you have to go through some different path. But when we talk about funding, we look at it as several different paths forward, and money is always nice. But that's not the primary driver for upstream. But providing support infrastructure, giving them cloud credits so they can do tests, helping them write test harnesses. ([Time 0:10:22](https://share.snipd.com/snip/6a0c718d-06df-4e98-b971-955ed966e89e)) - **Digital Sovereignty's Double-Edged Sword** - Digital sovereignty efforts can strengthen regional ecosystems but risk fragmenting global open source collaboration. - Robinson warns that siloing leads back to incompatible standards and lost efficiencies from global sharing. Transcript: Christopher Robinson It does. And actually, European Union has been talking about digital sovereignty for many years before it came up in the US. But it's accelerated. It's absolutely. They put stomp down on the gas pedal. Broadly, our perspective is open source is a global asset. We need to work. It's foundational to everything, whether it's your phone, it's a toy, your social media whatever however you interact with software and hardware it's a digital public good but certain Areas of the world are looking to you know increase their market share for their uh commercial entities and it's you know it's kind of your patriotic duty like i want to do my civic duty To help the region that I live in. So it's very compelling. But the trap from my perspective is if you pivot too far that way, you create these silos and we get back into 70s, 80s, 90s where we had incompatible standards and you erase all those efficiencies You've gained with open source. Open source, we're agile, we're fast, we're able to quickly find and fix problems and react to downstream feedback. And if you silo these things that you have just an Australia stack or a Greenland stack or a Brazil stack. You have these people that are working on the same problems, but they're doing it in isolation. They're not able to benefit from sharing and getting this feedback from this global community. So digital sovereignty is important, and you should try to groom the next generation of developers and try to make the manufacturers in your region strong and competitive. That's a great aspect. But we ask that we don't go back to this quagmire of all these silos. We want to advocate for open standards, open protocols, open models, whatever it might be. Kind of keep the foundation open at the top. ([Time 0:13:43](https://share.snipd.com/snip/89223bee-d38c-48e8-a105-eeb14e4988d2)) - **Learn The CRA Basics** - Educate yourself about the CRA by taking available courses and guidance to understand reporting timelines and obligations. - Robinson advises maintainers to prepare documentation like SBOMs to reduce downstream legal demands. Transcript: Christopher Robinson So three items. First and foremost, we issued a free class teaching different personas about the CRA. It's a 90-minute class. If you're a developer, you only have to watch about five minutes of it because there isn't a lot in there for you. But if you want to, you can listen to the whole thing. But we also provide guidance and instructions for stewards and manufacturers. So take that class. Educate on what this law is about. Alex Williams So number one, educate yourself. Educate yourself. Christopher Robinson Right. Secondarily, we have a project called the Open Source Project Security Baseline. It's a catalog of global compliance, whether it's law or it's a framework like the NIST SSDF, the Secure Software Development Framework. And we take these common application security practices, and then we map that to international regulation and cybersecurity frameworks. So take a look at the baseline. If you are able to fulfill some of those baseline requirements, you're ideally giving downstream what they need. And they won't bother you with letters from their lawyer. You can say, I understand that you want an SBOM. My SBOM exists in this Git repo. ([Time 0:16:21](https://share.snipd.com/snip/03dcec8f-374b-4d6e-a01a-674600db21f1)) - **Use The Security Baseline** - Use the Open Source Project Security Baseline to map common AppSec practices to regulatory requirements. - Robinson says meeting baseline items like SBOM publication can prevent downstream nagging and legal letters. Transcript: Christopher Robinson Right. Secondarily, we have a project called the Open Source Project Security Baseline. It's a catalog of global compliance, whether it's law or it's a framework like the NIST SSDF, the Secure Software Development Framework. And we take these common application security practices, and then we map that to international regulation and cybersecurity frameworks. So take a look at the baseline. If you are able to fulfill some of those baseline requirements, you're ideally giving downstream what they need. And they won't bother you with letters from their lawyer. ([Time 0:16:50](https://share.snipd.com/snip/678d1c08-dd42-4914-a5a0-164bcc001ef1)) - **Partner With A Steward Foundation** - Join or affiliate with a steward foundation (Linux Foundation, Apache, etc.) to gain institutional support and resources. - Robinson recommends contacting foundations to offload enterprise-style obligations and access funding or infrastructure. Transcript: Christopher Robinson Then the last one, I love the fact that Europe created this steward role. Right. And the majority of open source projects are not affiliated with a foundation like LF or OpenSF or Apache. So if you are concerned about regulations like this, phone a friend. Potentially investigate finding a foundation that meets your kind of philosophical goals. It's a community that can support you. Consider working with these foundations, these stewards, because generally these stewards have funding and they have the ability to do some of these enterprise type things that A single maintainer don't. ([Time 0:17:43](https://share.snipd.com/snip/cb039fb0-0d65-4635-8e82-36cab3150888))