When Luis Villa said he was willing to talk to me about the CRA I knew it would be a great conversation. The number of actual lawyers who also work on open source issues isn’t a large number. Luis is one of those people and he has a ton of knowledge and insight he’s willing to share. Open source legal issues are especially weird because the very nature of the open source license was to hack copyright to give us more rights instead of less. So what did Luis have to tell us about the CRA?
This episode is also available as a podcast, search for “Open Source Security” on your favorite podcast player.
The CRA: A Foundation for Digital Infrastructure
The name “Cyber Resilience Act” is sort of a meaningless term. As Luis pointed out during our chat, open source ahs become as fundamental to modern civilization as roads, aqueducts, and electrical grids. Open source is now critical infrastructure for modern society. We have extensive regulations for how to build physical infrastructure safely, but until the CRA, software has largely operated without similar guardrails. It should be noted, the actual law behind the CRA doesn’t exist yet, so it’s easy to speculate what it will or won’t be. But there are some things we do know.
The CRA aims to establish baseline security practices for software development, focusing not necessarily on making everything perfectly secure, but rather on making systems “fixable” when vulnerabilities are discovered. We know we can’t write secure software, but we probably can write fixable software.
Think of it as establishing building codes for the software we create. Just as we expect buildings to have fire exits and electrical systems to meet safety standards, the CRA is meant to help software meet basic security requirements.
The Current State: A Work in Progress
One of the most important takeaways from my conversation with Luis is that while the CRA has been passed at a high level, the details of implementation are still being worked out. The European Union has given the lawmakers and industry about three years to figure out what compliance will actually look like.
Right now, we’re in an intermediate phase which is mostly speculation and guessing." For example, we know Software Bills of Materials (SBOMs) will be required, but exactly what constitutes a compliant SBOM hasn’t been defined yet. It might be as specific as saying you need to use SPDX 3.0, or it might be so loose a text file listing package names will suffice (let’s hope it’s not the later).
An iterative approach is how we build software, it’s not how we make laws and regulation. This will likely be a learning experience for the lawmakers and industry as things progress for the next few years and current problems are solved. Usually we expect the government to tell us what to do in clear terms. This probably won’t happen with the CRA.
Open Source Carve-Outs: What Individual Contributors Need to Know
Luis points out when the CRA was initially drafted, it would have inadvertently made it impossible to comply with the GPL inside Europe. This was clearly not the intention, and to their credit, the EU has since worked with the open source community to create “carve-outs” for open source projects.
If you’re an individual open source contributor maintaining a package, you’re likely exempt from the strictest CRA requirements. The EU has made it clear they don’t want individual contributors caught up in compliance burdens. The devil will be in the details, but there seems to be positive intent here which is good.
Luis explains us all about how open source foundations like Eclipse, Apache, and Linux Foundation have been actively working to ensure carve-outs protect open source developers and projects. There’s a thing being called a “steward” - which is probably going to be a foundation that helps manage projects.
But what if you’re not part of a major foundation? We don’t really know yet. Luis is helping to try and figure that question out. And the reality is most open source projects are not part of a foundation.
The Challenge of Awareness and Potential Burnout
One concern I have, and mention to Luis, is that many open source developers are completely unaware of the CRA. They’ll likely first hear about it when someone opens an issue on their GitHub repository asking for compliance. This could lead to what Luis called “the final straw” for maintainers already experiencing burnout. Some might abandon projects entirely or switch to non-commercial licenses to avoid compliance requirements.
Luis is hopeful this might encourage more collaboration between maintainers. It’s hard to say what will happen. It’s pretty clear the CRA is going to change some aspects of how open source works today. We don’t know what, hopefully it will be for the better.
The Connection Between Security and Sustainability
Perhaps the most important insight from our conversation was how the CRA highlights the connection between security and sustainability in open source. Luis had a really good quote: “Sustainability and security go hand in hand. You cannot have security without figuring out that sustainability story”.
I do think there is more sustainability discussion now than there has ever been, but it’s still early days and a really complicated topic. There’s more we don’t know than we do know, but things are starting to feel more positive than they ever have in the past.
What Should You Do Right Now?
If you’re an individual maintainer worried about the CRA, Luis has some great advice: Hit snooze, come back in a year. The details are still being worked out, and even once they’re finalized, there will be a couple of years before enforcement begins. There are some links at the top of this post you might want to review while we wait with great anticipation.
For companies using open source, it’s worth beginning to think about how you’ll approach compliance, particularly around SBOMs and security practices. The tools and practices you build now will likely pay dividends when the CRA takes full effect.
A Moment of Transformation
The CRA represents a significant shift in how we think about open source software - recognizing both its critical importance to society and the need for sustainable security practices.
While the details are still evolving, the direction is clear: open source is moving from the periphery to the center of regulatory attention. Rather than seeing this as a threat, we have an opportunity to use this moment to build more sustainable, secure, and collaborative open source ecosystems. We also have the opportunity to screw it up, but it seems like we’re currently doing OK.
I’m cautiously optimistic. The path won’t be smooth, but the recognition of open source’s importance and the potential for increased sustainability funding might just help us build stronger foundations to support open source projects.