Update on EU Software Regulation: Lots of improvements & good news

Dirk-Willem van Gulik, VP Public Affairs, Apache Software Foundation

Over the last two years, The Apache Software Foundation (ASF) and many other open source organizations raised concerns around upcoming software regulation in general, and the Cyber Resilience Act (CRA)/Product Liability Directive (PLD) in particular.

Both acts will have an enormous impact on our Software industry. By and large it means that software released on the internet, that is sold, and so on — needs to be known ‘’to be fit for purpose’.’ It needs to be kept secure for reasonable periods of time. And this regulation trumps or voids, most of our beloved ‘if it breaks you get the pieces’ disclaimers. 

The CRA is now essentially final, with only legal translations into the 24 official languages and, what is normally a rubber stamp approval, awaiting. This was the act that concerned the ASF and many in the open source community the most, and where there is quite a bit of good news.

To recap the situation in summer of 2023: the CRA cleared the European Parliament (part of a convoluted process) with a whole raft of requirements. And it was an understatement to say that these requirements were not a good fit for open source and just about every piece of software the internet is based upon. 

This ranged from complex certification too early in the supply chain  to unrealistic regulatory requirements on releases and contributions. Most of these requirements appeared more likely to reduce the level of overall software security and cyber resilience, as opposed to the laudable goal of the CRA – making things more secure and reliable.

One of the key issues was that the CRA, as then written, did not really acknowledge the fact that well-managed open source software is by and large the basis for pretty much the entire software industry (to the tune of €65 billion in Europe, according to the EU).The ability to collaborate around open source is also the main driver of innovation in our industry (as the EU confirms).  And these are not small (economic) matters: our industry, while small, has an oversized impact on just about every other industry.

So, over the past months; the ASF, Eclipse, FSF Europe, the Linux Foundation Europe, the Python folks, the Open Source Initiative, Mozilla, NLNet-labs, the Internet Society (and countless others), as well as many industrial groups that use open source, spent inordinate amounts of time and energy to talk to policy makers, the Spanish EU Presidency, the European Parliament, the Commission, and 25-odd European national governments. To explain not just the impact on open source software but to explain what open source is – and why it is crucial to, and at the core, of the industry’s ability to innovate. Also, as our code is the basis for so much other software why it is important for the goals of the CRA (better security), to get things right.

We also spent a lot of time explaining open source – and why it is a somewhat odd and different economic beast – almost an extra factor of production (besides things like labor, land, capital, etc.). Much like knowledge, source code can freely be copied without loss or detriment to the donor. Yet, unlike knowledge, source code is both the description and the actual thing itself.

And that paid off, in several ways

First, the policy makers introduced a whole new concept: that of an “open source steward.” In essence, they created a whole new class of economic actors for the software industry, separate from those that “place software onto the market,” with the CRA focusing on the latter.  

Secondly, the CRA in its current form is much more aligned with how the modern software industry is actually structured. For example, it now recognizes that development- and distribution-platforms are not economic actors that “sell” a product, or parties that are meaningfully involved with placing whatever people put on their platforms on the market. And likewise, the CRA recognizes that there is a wide swath of humans that work with code, and may even disclose it to others, but who are not quite “economic actors” that “place a product” into the market.

So, all in all, this is mostly good news for volunteers who run and innovate with open source software.  Or, more accurately, much better than most of us could have imagined at the end of last summer. 

That said, it is important to note here that the politicians and policy makers did not in any way water down the CRA, or let go of the goal of the CRA: improving the resilience of society and the current (sorry) state of software security. That part of the CRA is unchanged – software that is made available on the European market is to be regulated – and must meet minimal (and in the case of `critical software’ quite extensive) security standards.

So the CRA (PLD and many others, such as the data act, DSA, DORA, NIS2 and its financial variants, interoperability, and the SEP regulation) will have a massive impact on the software industry. Our industry as a whole will have to learn how to be a regulated industry. And we will need to learn how to comply with CE regulation and marks. And that is a lot of work: impact analysis estimates the extra development cost at around 30% (much in line with earlier regulation; such as MDD/MDR).

And that will affect us, the open source community just as much, if not more, than the commercial players. Because at the end of the day, it is common for over 90 percent of any software package that a commercial company places on the market to be reliant on open source. Often this is open source software that the company does not quite know very much about — their domain knowledge is with the 10% they write on top. The actual implementation. But the bottom 90% is somewhat of a black box. Yet that company will need to get a CE mark on the whole 100%.

So it is fair to expect that virtually everyone in our community will be working at companies that will have a similar, serious challenge.And a challenge that, once mastered, simply means you can enter the European Market, but you will not derive any competitive advantage from it. 

It seems likely that, once more, a lot of these itches will be scratched collectively within the open source communities. Because that is win-win for everyone involved.  I am expecting that soon we will not just see release notes, documentation, and lists of fixed CVEs to be part of our releases, but also some of our communities will be collectively creating and maintaining the rough building blocks they can then individually use in their companies to secure their companies’ products. And do that in typical open source, collaborative fashion.

There is also a lot of work for us, the open source community, to do directly with the policy makers. First, the concept of “‘”open source stewards” is an entirely new one (where they did try to avoid giving single vendors, corporate- rather than community-led, “open source” a free pass). This stewardship will require a lot of work to actually define.  And all this will be in addition to setting all the international standards (some forty plus), with international standards bodies whose processes are not always easy for volunteer-led open source project to effectively participate. 

There is also a complex area around “critical software” where there is not-so-good news. This is intended for applications such as firewalls, (hardware) security modules, low-level kernels, and single-sign on systems. That is, software that is very exposed and very critical; with potentially systematic risks and impacts. The puzzle here is that, when taken at face value, this category can be quite broad once you go down the stack and hit basic building blocks that are open source. For example, does something as arcane as a C portability library such as APR or some LDAP connector fall in this category ? 

And that matters: as the level of certification required for those critical products at the place it enters the market (i.e., the point where you get your mittens on the actual security fix) requires a lot of work. There is a hard balance to strike with getting the fixes (and reducing the friction in the community to create good ones, with enough inclusion of skills) with ease and having them well-certified fast enough. Helping international standards organizations through this will be important.

The other positive news with regard to all of this is that the implementation period has been extended with an extra year, with all aspects of the CRA now applying in full at the start of 2027. 

A lot of thanks and credit for this good news should go  to all the open source foundations (and the massive help and coordination of Open Forum Europe), the industry players, but also to all the policy makers and politicians at National and EU level that kept open-minded and were genuinely trying to understand open source and fix things.

If you are interested, your next best source of information will be the policy track at the veritable FOSDEM early next month. Hope to see you all there!