 Welcome to Open Infralive. Open Infralive is an interactive show where we dive into topics at the intersection of open source and infrastructure software. And today we'll talk about the Cyber Resonance Act, or CRA. I am Thierry Cares and I'll be your host for today's show. We're streaming live on YouTube and LinkedIn and we'll be answering your questions throughout the show, so feel free to drop questions into the comments section and we'll answer as many as we can. Before we get started, I want to thank all member organizations of the Open Infra Foundation. Their support makes this show possible. Now, let me introduce our guests for today's episode. Alison Randall, who is involved with many organizations, but also the vice chair of the Open Infra Foundation Board. Kiaran O'Riordan from Open Forum Europe and Mike Milinkovic from the Eclipse Foundation. Thank you all for joining. It's really a pleasure to have you all here today. So let's start with a quick round of introductions. Could you please quickly introduce yourself, the organization you're working for, and also when did you first hear about this CRA thing? Let's start with Alison. So I've been an open source developer since the 90s. I'm currently most active in Debian and RISC-5 projects, so kind of broadened into open hardware and open silicon. And in addition to Open Infra Foundation, I'm also chair of the Board of Software Freedom Conservancy and on the Board of Open Usage Comments. I first heard of the CRA in November last year when I asked her from Open Forum Europe, posted on it, about it on a shared mailing list that we have. It's like Cross Foundation. But I saw people like Mike and Open Forum Europe working on it, and I didn't really dive into it very hard until June when I noticed that no one was talking about open hardware and the impact there. So I was kind of distantly aware of it quite a while before I looked at it closely. How about you, Mike? Similar to Alison. Sorry, let me start off with my introduction. So Mike Linkvitch, I've been the executive director of the Eclipse Foundation for almost 20 years now. And so I've been around in open source for that long. Before that, I was on the proprietary side of the software world. And I should mention that part of the reason why this whole topic is so near and dear to my heart is because four years ago, the Eclipse Foundation moved its legal domicile to Europe and we're now the leading open source organization from Europe. And so as a result, we are committed to dealing with these laws and regulations in Europe and we're very obviously vested in making sure that they're done correctly. So that's something we're very, very interested in. And when I first heard of the CRA was over a late October, early November of last year. And one of the things I'd like to point out is that we wished we had heard of it far earlier. And I think that's one of the things that we are learning at the Eclipse Foundation is that becoming more engaged at a far earlier spot in the policy making apparatus around the world is something that's important to us. And so we've actually just hired our first policy director in Europe and in Brussels and so we're going to be keeping a closer eye on all of these developments over time to become more directly involved at a far earlier stage. Perfect. How about you, Kieran? Yeah, so my name is Kieran O'Rourden. I've been working with Open Forum Europe a little over a year but I'm 20 years now in Brussels doing general free and open source policy on EU topics. So we started working on the CRA in April of 2022 and this was back when the European Commission was seeking input and so it was good that we were able to come into that stage but the real work really started in October and November last year when we realised how difficult the text was going to be to work with. And so the CRA that we're working on now is very different to the thing we thought we were giving comments to in April of 2022. But that is what Open Forum Europe tries to do. We try to stay aware of the things that are coming up in the coming 12 months, 5 years even. And so although there's a lot of things that we find difficult in the CRA there's one or two nice things that were there when the text was published and so we hope that the input we gave was one of the inspirations for that but the work really exploded then in October and November. Okay, so let's dive right in. For those who are not familiar with it the CRA is a proposed European Union legislation that aims at increasing security of digital products by applying some of the CE Mark framework to it which sounds like a desirable thing like from a consumer protection perspective and it is a desirable thing but we open source folks object to the CRA because it does not take the open source development model into account in the details of the text with potentially dire consequences and cheating effects. And yet the legislation continues to march forward as of last month EU Parliament Committee approving the text. So I guess my first question is what's the current state of this proposal? How far down the process are we? And I'll ask Claren first since you're pretty intimate with the intricacies of the EU legislation process. Yeah, so the process is difficult to understand for people who do some research online because there's a detailed series of events that's meant to happen but in reality there's a lot of negotiations in small rooms and that's how the actual text is written. So the formal status now is that the Commission has a text, the Parliament has a text and the Council have a text. There are the three institutions of the European Union and they now go to a series of meetings, trilogues and they will try to merge or find a compromise between these three texts. However, the three texts are quite different. So the final text will not resemble any of these individual texts which on one hand makes us a little bit nervous because we don't really know what's going to come out of the room when the negotiations are finished but it also means that there is still quite a lot of margin for improving the text even at this stage. So the trilogues should start at the end of September and finish at the end of November. So this is the last big push we have now. And so there's different texts from the Commission, the Parliament and the Council, is that right? Yeah, so the Parliament are the people that are elected directly, the 705 members of Parliament. Then the Council is one representative from the governments of each of the 27 member states and then the Commission is, you could call them civil servants, they're people who are employed by the European Union. And so the Commission writes the original proposal and then hands it to the Parliament and to the Council and the Parliament and the Council then in parallel they go through their own procedures to say how they think it should be changed and then at the end, when they have their positions which they have now, the Parliament and the Council start talking together and they bring the Commission in as well and they all see if they can find something that they can all agree on. And if I could add some colour for the audience. I mean, so we have three different versions and we could, at the risk of bringing Clint Eastwood into it, there's the good, the bad and the ugly. So, and I would say that the good version is the draft that's from the Council. That's I think closest, it's not perfect, but it's closest to I think what we would want to see in terms of exemptions for open source and a structure that I think that we could work within. And the bad is the original Commission version because it had some problematic stuff in it problematic stuff in there first and foremost, I think a worrisome exemption for open source that was based on a definition of commercial activity which would encompass pretty much all interesting open source projects. And then I think the worst is unfortunately the Parliament the Parliament version because it actually went even further in terms of its explicit definitions for what kind of open source projects would fall within the scope of the legislation and the regulation and that would make it very, very clear and explicit that pretty much all of the major open source projects that we would all recognize by name would fall within the regulation. And so there's in addition to that, then there's some other things as well with relationship to the disclosure requirements. Yeah, I guess probably jumping ahead here in terms of the actual content, but some of the disclosure requirements in those drafts are very worrisome as well in the sense that they don't conform with what we generally consider industry best practice in terms of responsible disclosure of vulnerabilities. And I think that's actually something that's just as concerning in many ways as the open source aspects. And we'll dive deeper into that aspect. I guess my additional question then is, is there extra steps after the legislation is approved for like translation into local laws that also gives us an angle or is it like mostly transposition and there's nothing else, nothing more to do at that stage once it's approved by the full twilight process where there's not much can be done between there and actual judges starting. Let me try and cure and can correct my mistakes. So I believe that once this is an act. So once it's passed and completes the trilog process, it's long. And so there's going to be some transposition into national regulations as well, but it's largely done at that point. There's two aspects of the implementation process that are still up in the air that will, I think in the end have a significant impact on how this rules out in practice. The first is what is the period of time from the moment it becomes law to when it comes into effect. And I think the original was 24 months. And then I think a month, there's been some discussion of standing at the 30. I've even seen suggestions of going as far as 48. I think those are some people have suggested that. I don't think anyone's accepted it, but there was going to be some period of time between when it becomes law and when it comes into effect. And so that duration can mean quite a bit in terms of what the impact is on both the open source community but industry in general. And then the second thing is, is there needs to be a European harmonized standard for doing secure software development where if you follow that standard, you have a presumption of conformance and can affix the CE mark reliably to your output. And the development of that standard is going to be starting sometime soon. But for those of us who's ever been in the industry for a long time, the development of a standard for doing secure software development basically across all elements of the software industry, there seems to be an expectation that that can be done in something on the order of 12 to 18 months so that people can actually implement it in terms of being able to produce products in a 24 month time horizon. Personally, based on my experience, the idea that such a standard could be developed in that kind of timeframe seems, shall we say, optimistic at best. That is a whole topic on its own in terms of what is that standard going to look like, who is going to control that standard, who is going to be in the room and developing that standard? Is it going to be entirely focused on proprietary development models? Is it going to reflect the differences and nuances of doing open community development? There's a ton of stuff in there that could significantly impact the implementation of this app. So Kieran, what did I get wrong there? No, I'd agree with that. The delay, whether it's going to be 24 months or 36 months, the only thing I'd say is we have to keep in mind that this is a delay, a period of time for us to get ready so it would not be the case that the law will exist in three years' time and we can wait until then. If they give you two years, it's because they think you're going to need two years to fix your supply chain procedures and your documentation. So even if we have a delay, this is still something that you have to start preparing already. So the standards can be a lot of work. I've heard that the harmony standards can be split into 44 substandards and so this is looking at each requirement in the CRA and for example, there's a requirement for personal data to be encrypted. They'll develop a standard to say what does this mean and for each requirement there will be a separate substandard and that can take a long time to work out and standardization is generally controlled by... The participation is usually by people who have been in the old software industry and so our development models are not well represented usually and that's something we're trying to address and we'll have to deal with. And Lysanne, did you want to add anything to this segment? Okay, so let's look deeper into what's in the current text. I mean, our concerns seem to revolve around requirements that this situation places on release certification and vulnerability management processes. So I want to ask you what are the potential consequences if the text was to be adopted as currently drafted? I understand that the process is still pretty long and the text is going to probably look a lot different in the end than what we currently have but what's the worst-case scenario in practice? And maybe Mike, you can talk to the worst-case scenario of the consequences. Well, let me start off by saying that there's... Before we get to the worst-case consequences, let's remind ourselves that the purpose of the CRA, there are good intentions here. The reason why this is happening is because of, frankly, shoddy software and shoddy devices and there is a perfectly legitimate interest in protecting European consumers and European businesses and improving... And I think there's actually a valid point to be made is that cybersecurity across the industry is never going to be improved without some form of regulation because time-to-market pressures and move fast and break things kind of attitude can never be mitigated without any absence of regulation in my view. So there's really good reasons why there's an interest in providing these regulations. And the second thing I want to mention is that we should never think of this as the CRA is here to regulate open source. That's not what the CRA is doing. The CRA is here to regulate the software industry. And now open source and the technology industry to the degree that you talk about IoT devices and industrial machinery and so on that embed software. But the idea here is to regulate the software industry and of course open source is a huge part of the software industry. And the question is to which can we continue to keep the pace of innovation that we see in open source and the freedoms that we've enjoyed for so many years while building open source but at the same time improving the level of cybersecurity that is delivered to consumers and products. So now in terms of the consequences of the CRA as it's currently drafted there's a couple of different things in there that I think are quite important to call out. This first is the simple idea of applying a CE mark to an open source software product is inherently problematic in the sense that cybersecurity always start the very first thing you do when you're doing a security analysis for a software product is you start off with what is the intended purpose and from there you derive okay what are the potential risks and then you can do a risk mitigation strategy for a piece of software. That is like standard industry practice on how you do this. Well by definition anything that's produced under an open source license does not have a field of use restriction. And so the very first step of what is the intended purpose is broken and just to give you some examples I mean really trivial example you know clips you know our original project was the eclipse IDE actually predates even the existence of the eclipse foundation that was designed to be a desktop development environment and components from that desktop development environment are doing ground control software for the European space agency. There are devices on the international space station that embed that software. So how would you ever write an intended purpose for an integrated development environment and put in you know mission control software and you know embedded devices on space stations you just can't map all the security implications to any piece of software. Which then of course puts you know people that affix a CE mark on a product and then something bad happens then there's an additional liability attached to it. And that's by the way you know even without getting into the sheer amount of effort that is required to follow all the practices necessary to get the CE mark onto a software product. So you know there's a significant increase in the amount of effort that's required and then there's a significant increase in the potential liability of to any organization that's producing open source software that could come out of the CRA. On top of that then there's you know there's a couple of other things in there and you know very problematically the disclosure requirements where you know you have to disclose to government agencies within 24 hours if you know an exploited vulnerability whether you have a fix or not you know runs counter to what is considered industry best practice for responsible disclosure of vulnerabilities and you know disclosing this to government agencies you know not all governments are benign and I think in addition to you know what might happen in within Europe in terms of government agencies exploiting exploiting vulnerabilities if Europe sets a precedent that this is you know the accepted practice then other governments around the world are going to insist on similar on similar disclosures and so if you're in a situation where you have a software product that's sold around the world and you have to disclose to every government and an unpatched vulnerability you're basically you know inviting all kinds of nefarious potential activities. Another thing that's one of my pet peeves is article four in the CRA basically if open source is not completely exempted article four would prevent us from doing what we consider standard CI CD pipeline production of open source software because it prevents producing you know intermediate and beta releases for testing purposes unless it's scoped in time and unless it's restricted in use and actually even in restricted in geographical distribution and all three of those things are problematic for you know we've considered for many years as best practice in open source where you publish all your nightly and in integration builds and they stay up there for a very long time and people can people can try them out and use them so those are anyways those are those are definitely a couple of the real problem areas that we see in the CRA and looks like Kieran's got something to add there as well. Yeah I was going to describe you know very similar but maybe just from a different from the point of view of the general approach of our development model and the revenue streams that support a business ecosystem and so to get to the worst case scenario idea I think the CRA text seems to have been written with a proprietary software model in mind and there's two ways that this doesn't work for us the first is that the proprietary software model usually the development all happens behind closed doors in one company and then at a time of their choosing they make a release and they hand the software to a user and they cut this one to one relationship between you know a collective entity that does the development supply and the user and in that situation you know it's much simpler whereas we have a group of four or sixteen or forty companies, individuals, universities, governments contributing to a software project sending these packages and modules and patches back and forth over you know by gate or by email and you know so we've a lot more acts of distributing the software and so we don't know where the line is drawn between you know have I placed the software on the market or have I just uploaded it to a delivery and then for the distributor we've got usually multiple companies distributing the same software package so we because we have this complex system of contributors we grow our development community and our business community by having very low friction and having very low barrier to entries and trying to get people to contribute as much as possible and so then with the CRA which changes software from being treated like literature where there's something that you can publish if increases the friction and this makes it quite difficult for us to continue with our usual approach to growing our community and so what will happen in the worst case scenario would be that people working for companies when they are thinking about contributing to a project they'd have to get approval from their boss and their boss might say you know well I don't know anything about this CRA procedure and I don't want to take the risk so if companies employees or people working for a government even if they get approval then on the project side the project will have to think do I want to accept this patch because if I accept the patch then I have to take on responsibility when I distribute the software and so from both sides then it becomes difficult for people to contribute and to accept contributions to projects and then when somebody does distribute the software once it's ready for use you know you will have multiple people distributing the software and none of these entities will be the developer because a company who is distributing software a lot of the time they have developed maybe 20% maybe 0% of the software and so this is this makes the the review much more difficult because if you're asked to certify that the development has done a secure way and that the development has done a lot of things into account but you weren't involved in the development well then this makes compliance very difficult so this is just how I think that it's it's a difficult lot to comply with and for free and open source software it all these different factors multiply with each other and then making a situation that could be extremely difficult and could really slow down the way the software and so that's the worst case scenario hopefully we can we can improve it and so actually I think the to a large degree the worst case scenario is in some ways that simply a lot of open source projects simply decide that their software is not made available in Europe so we if you've been involved in the open source the governance of open source projects for a while one of the things that you will encounter is that US export controls are basically extra territorial so even regardless of where you are in the Europe if it ever goes through a GitHub repo or there's many many many instances where US export laws will comply to be complied with one of the ways to think of the CRA is that it basically sets up this is not perfectly accurate but think is almost like an import control the way the law is written you have to conform to the requirements of the CRA if you make your software available in Europe and so if you're an open source project and you're looking at the requirements of the CRA that you have to do to fulfill the work you have to do to fulfill the requirements and make your software available in Europe a rational decision for a lot of open source projects would be to simply say I know this is available under the Apache license or the eclipse license or whatever but due to you cannot license away the law so I've met a bunch of people who say that open source licenses don't permit you to prevent distribution to a particular region or whatever but that's actually not correct the question of how you interpret field of endeavor yeah it's like is an entire group of countries a field of endeavor that you're restricting it against I think the answer is simply the European law says you must conform to the CRA in order to make this software available in Europe we do not conform to the CRA therefore we do not make this code available in Europe done it's an orthogonal topic and I think it's a rational economic decision for a lot of projects and communities to simply say we can't comply with the CRA so we don't make our software available in Europe and I think that is going to not only does that outcome harm the pace of innovation but ultimately the economic prosperity of Europe but it also harms other key objectives that they have in Europe for things like digital sovereignty because ultimately digital sovereignty is around freedom of action and open source is one of the technology tools that you have at your disposal to give you your society and your economy the ability to have that freedom of action and if Europe cuts itself off from as much of open sources they can get, ultimately they're harming not only their own innovation and economic prosperity but they're also harming their own digital sovereignty and I think those are all counterproductive outcomes from the CRA potentially depending on which version ends up winning so one question I had for Alison is the legislation aims at protecting for against defects in digital products but that's a pretty vague, it's usually equates to software but what about open hardware and I know it's a topic that you care a lot about, do you think it's going to be affected or would you like it to be inside the scope of the law in order to actually be considered? I would like it not to be I followed the CRA for many months through various posts going across I was following the discussion around open source and I thought it was only open source and then I actually sat down and read the CRA from the very beginning it says hardware and software, hardware and software all of these regulations apply to hardware and software and I didn't see anyone talking about hardware and so open hardware and open silicon are much younger than open source so open source when you really get down to it has been around since the 70s with BSD free software was a term that came along in the 80s and the term open source didn't come along until the late 90s but as a concept of freely licensed software it's been around since the 70s hardware is much much younger and I would say also as a community the open hardware community is much much younger you know we have these active dialogues across open source foundations but hardware doesn't really have that so you know after reading it I started picking it apart and I think it's important to realize that every single thing that Mike and Kieran mentioned as a risk to open source is also a risk to open hardware and it's for the exact same reasons with open hardware we distribute multiple versions of what you would call source code and they're all available all at the same time and you know you do have a slight difference in that for hardware instead of just a compiled code block you know you have compiled it down to silicon so there is a physical product at the end but the way the regulations are all drafted it doesn't just capture the physical product at the end it counts as distribution even if you're distributing designs or source code or it makes a tweak it's like anything if you're distributing a digital product with digital elements under your trademark then it becomes something that's subject to the regulations which means you know like it's complicated for large foundations like risk five is a large foundation like Eclipse but for hardware it becomes problematic for even the small hobbyists because unlike open source which got this exemption built in that covers at least the hobbyists and you know like non-commercial stuff for hardware it doesn't even have that which means like any random hobbyist kind of creating a little toy board is suddenly subject to this whole weight of regulation which they're not going to be able to comply with so back in June I reached out to Openform Europe and we started a group we basically just as far as I know it's the first of its kind we brought together like 30 open hardware open silicon organizations and started talking through this and prepared a letter of petition and we kind of in a sense we've been piggybacking on the open source sort of advocacy because it is so similar we kind of just kind of slip in and still by the way this also affects open hardware I don't think we're going to get any text in specific to open hardware in the CRE itself but in that whole implementation process in you know developing the standards for what it means to be a secure product I do think there is room to help make space for open hardware within the overall structure of the legislation but it is definitely going to be something that affects all open hardware and open silicon organizations in the future and it's not I mean they could try to say our standards and designs and you know system verilog source code and like these are not intended to be used in Europe but that's actually really hard to limit once you have made things publicly available I mean block by IP addresses like what does it actually mean to restrict your distribution of a completely open digital element in this like highly connected global international system So we actually have a question from the audience we have Jimmy from Texas asking about how that relates to GDPR we are basically resulted in creating a lot of I would say an industry around compliance and implementation to work around it is there the same kind of potential ramification around the CRA or is it more is it going to be handled at the organization level but to answer more directly the question CRA and given the massive potential for individual and organizations do we expect like if it passes to a world industry to be created around working around it or is it much more strict and terminal in terms of who gets to be liable So what does the CRA say in terms of fines so if you are a manufacturer of a product with digital elements that's made available in Europe and you do not conform to the requirements of the act then it's 15 million euros or 2.5% of your annual revenue whichever is higher and so Clubs Foundation is one of the bigger open source foundations that's enough money to really give us pause I know it's got the attention of my board and so that's a real issue and the analogy of the GDPR is interesting because I think there's some truth to that and some issues with it so I think the truth part is there's a perspective among some GDPR was a success because it demonstrated European leadership towards privacy and if you take the cookie consent thing out of the GDPR actually being realistic about data retention and the kinds of things that the GDPR forced you to do in many ways was positive but there's some parts that in terms of as a consumer constantly clicking cookie consent forms is not my idea but I think there's some things that are quite different in that the implementation requirements of the CRA go far deeper into the product development aspects of the entire software industry than the GDPR did in terms of there's a couple of companies in the world that basically make money off of personal data but this is actually and they're some very large and well-known companies and they were the targets of the GDPR but they've seen to find ways to conform or find ways to pay the fines one way or the other but the implications of the CRA I think are far, far broader this isn't targeting this is not targeting any small group of companies with a very particular business model this is targeting the entire worldwide technology industry because pretty much when you talk about technology all technology embeds software and this touches every single one of those and so the implications are far far beyond the GDPR and passing comments one of the things in the preamble CRA if you read it is an economic impact statement that the potential benefits of the CRA are 290 billion euros a year in savings for European consumers and businesses and 29 billion euros a year in implementation costs I think the worldwide implementation costs of the CRA is probably measured in the trillions so they're off by several orders of magnitude in terms of the cost and that's not taking into open source I'm talking to repeat myself the intent of the CRA is to regulate the technology industry it's not to regulate open source we're just to a certain degree collateral damage in the larger goal of regulating the technology industry can I just add to that for the harm I don't think the fines are going to be the big things like the fines are quite shocking in the volume of the fines but at the same time I think there will be very few people who actually get brought to court and receive a fine compared to the number of people who have to make a decision can I publish this module I'm working for a hospital and I'm using WordPress can I give this module to WordPress or will that give my employer a bunch of responsibility and then not being able to get the approval from their boss and then WordPress having to think do we accept code from this person WordPress is just an example they're not going to be any worse or better than anyone else here so I think the fines are only in effect a very small sliver of people but the effects of the CRA will really be seen in how it changes the culture of people being able to join projects to collaborate or not and the other thing is that another relationship with the GDPR is some people say that with the CRA it will be difficult to get software into Europe and some people in the European institutions say don't worry Europe is a quarter of the world market I'm not sure if that's accurate but they say the economics incentives are there people will comply with the CRA even if they're outside the EU I'm doubtful about that but the thing is some people think that the European institutions see the GDPR influencing the rest of the world and maybe they're hoping the CRA can do the same but with the CRA not only not only is there a question about whether the GDPR is such a good thing in how it's influenced the rest of the world but also if there was an Indian CRA and a Japanese CRA and a Canadian CRA and a UK CRA and had to look at all the regulations before collaborating together then this model either Europe is big enough to encourage everyone to comply with the CRA in which case it will get copied in other regions and then we're left with these walls between regions or Europe is not big enough to influence the rest of the world in which case Europe will be just isolated because a lot of software I don't imagine somebody in New Zealand writing software and then say oh, better read the CRA to decide if I am allowed to distribute this in Europe a lot of people will just skip Europe in terms of distributing their software I was just mentioning the chilling effects I feel like are likely to be much more concerned because a lot of the innovation around open sources is based on the fact that you don't have to ask in order to innovate and build and it's going to create a lot of uncertainty and like we know developers will walk away or at least avoid any kind of uncertainty there and so the chilling effects are going to be in my opinion the most direct consequence of this we probably need to move on to talk about our other topics I guess my main question would be at this point is there anything we can still do about it and you mentioned the value stages in the process Karen earlier like are they trying to exempt open source or not because there are some details in the text that feels like they are trying to exempt open source maybe by explaining how those terms are not enough maybe we could make progress into a text that would not be as harmful as the current one or do you think it's actually very much willing to target open source and because open source is so massive now that you can't really ignore it I'm a bit more optimistic than Mike on this I still see room for improvement and I still see good faith on behalf of all three institutions and I do believe that they are trying to create an exemption some of the texts have gotten very complex and this is always a problem for us because once something is complex we are software projects in the free and open source software space often don't have legal counsel and don't have a company lawyer who can review the legal situation so once we have things that are complex then we have problems so there are there are wordings that are there and they mention free and open source software and so you can either think that they are trying to help us and they are not doing it in the right way or you can think that they are not really trying to help us at all I'm more in the first camp I still believe that they are trying to avoid bad effects from the legislation I think there is still room to influence this however it is getting more and more difficult and so in the trilog phase now this last phase between the end of September and the end of November it's mostly behind closed doors meetings there will still be some interactions but right now it's really going to be based on their relationships we've built and the trust that they have in us that we've built up over the last eight months or in the longest perspective some people have been talking to for many years it's difficult to get in at this stage and say who can I spam and try and have an effect that way but at the same time we've got the CRA after the CRA there is going to be 44 standards procedures there is also the product liability directive there is the AI liability directive there is this web environment integrity issues, child protection online, the standard essential patent regulations so there are so many other things to work on at the same time we can still work on CRA but if people are interested in helping out with any of these topics then there is plenty to do we actually have a good question from the audience on that topic Marcus what actions can one carry out to improve the CRA can any open source contributor do something at this stage can smaller open source associations take some action your opinion on that it's difficult at this stage it is quite late in the procedure so we have a group of people coordinating our work on this and that's a good group we've been working together for many months and everyone kind of understands the details and generally what's possible and what's not possible and so joining at this stage is quite difficult we still could use more publicity but at the same time we haven't had the spare capacity to be able to organize a public campaign that people could jump on board with actually maybe Mike has an idea for what could be done on this so we did write an open letter some months ago and a number of associations large and small signed on to that we helped draft it and build a group of organizations that helped co-sign it with us doing something like that again to try it and trying to time it so that it's published around the same time as the trial log so that it has the maximum impact so stay tuned for that feel free to reach out to me if you're interested in participating but as Kieran said the opportunities for major influence are very, very limited at this point this trial log happens behind closed doors we can try to answer questions and educate the participants about the ramifications of the decisions that they're making and hopefully that they listen but that's where we are at the moment it's unfortunate but it is where we're at and it's sort of just back to the previous topic about the kind of where we're going to end up and how we're going to end up there so and Kieran said that I guess I'm grumpy on this topic I actually think that I firmly believe that everybody involved in this process has good intentions and is trying to do the best that they can but I do think that there's some just a lack of understanding and I guess to a certain degree that's on us as open source community in terms of not doing an adequate job of explaining how things work in open source and so on it's sort of like we we've gotten to the point where open source represents, depending on which study you read, 80 to 95% of software is open source software that's continued a product so obviously we're important and obviously we need to be regulated because we're important, you know, if you want to regulate software industry and you're going to leave you can't actually say oh and we're going to leave 90% of the products out of the regulation that's not going to work so what I think the best possible outcome and I've been saying this for a long time is I think others, I'm not alone in this, others have said the same, it's like you need to regulate the products the things that are actually get into the hands of the consumer for money are the things that need to be regulated and I think if we can convince them that that's the right approach I think that actually sets up in the future a nice set of incentives where the companies that are now putting open source products that contain open source into the hands of the consumer and they have a responsibility are going to be incented to invest more upstream and help protect the cybersecurity and the sustainability of the projects that they're putting into their products and I think that that's actually that's the perfect outcome and I think it's almost to this point you could change just a couple of words in say the council draft and you're there there is some cause for optimism here in the sense that there are some drafts out there and there's some people that are involved in this process that are clearly listening and learning there's some that are listening and to my experience they don't seem to be learning and there's some that are listening and learning so I think there is some cause for optimism and I think for the ones that aren't learning then it's probably still on our fault it's still our fault because we haven't yet done a good enough job of explaining it but ultimately the goal I think is achievable protect European consumers and businesses from shoddy software while retaining the pace of largely retaining the pace of innovation that has led to so much success in the technology industry and the pace of innovation and economic prosperity in Europe and I think there's also for developers I think it may be helpful to realize that this is not the first time that open sources faced very strange legislative changes software patents that we had to respond to and change our approach and introduce new organizations new procedures new the law does change over time and this is just another law change and I still hope that as Mike said I still hope that we can get some changes in and improve it but one way or the other this regulation is a thing that international open source and open hardware are going to have to think about for decades into the future and I think by working together and a lot of open source projects already have best practices around cyber security and I think by working together and making sure that we share that wisdom and kind of craft those best practices I think we can actually take a lot of the pain out of not the most restrictive versions of the CRI but the intermediate even some of the less pleasant versions of the CRI I think actually we can help each other as communities of developers establish procedures that allow us to meet the requirements without like costing us millions and like completely destroying our collaboration practices but I think that's another angle to work on as a smaller project or just an individual developer OK we're almost out of time so I wanted to do a last round as a conclusion is there anything you want to add I know is there any other pieces of legislation we should be watching for or are there do you think it's business as usual defending open source or is there something really different in this one like anything you want to add to the video before we close and I'll start with Kieran Yes CRI is not business as usual and that was why it caught us kind of off guard like we've had issues with copyright and patents and platforms and so we're now a new piece of patent legislation is proposed the patent people they're looking at it and they're on it CRI is regulation it's liability within one definition of the word and it's just something like if you talk to software projects or even most companies they say well who's your software liability person we didn't have a set of experts so you kind of caught us off guard it is also bigger than we expected and so if we could shrink it down there are some things that we could automate and some things we could just improve our processes and this could be doable but then there's also things just like the obligation to provide five years of security fixes that's just something that people will not be able to get past their employer and this sort of thing we can't fix with improving our procedures and then the fines of 15 million there are still things that we have to really change in CRI we'll do our best in the coming three months but yet there is also a lot of other things happening in Paradell but we're running out of time so I'll move to Mike yeah so I agree the CRI is not business as usual and it's not business as usual because it is going to regulate the software industry the software industry through its entire history has been an unregulated industry and in some relatively short distant future we're talking in the range of somewhere in the two to five year range software is going to be a regulated industry and open source is part of the larger open source software industry and ecosystem and so we are going to feel that within our practices there's no absolutely no way that we're going to be able to avoid that but this is not just a European thing we're seeing CISA and various activities within the US government are making it very clear that some form of regulation is coming to the software industry inside in the US as well and that's absolutely crystal clear the only difference is we don't yet know we haven't yet written or sort of read the draft legislation but one thing I'd like to draw everyone's attention to is the White House published a request for information a week or so ago that open source organizations can reply to and one of the things that I really like about that is the simple fact that they specifically are coming to the open source community and asking for input into helping shape that future US regulation and that's very, very different from what happened in Europe whoever they were listening to in terms of how does the software industry work we're not taking open source into account because our open and transparent development processes are would be significantly impacted same as Allison was talking about in terms of open hardware the simple fact that we publish and produce things all the time not just on product release boundaries it's just that we're completely not taken into account in terms of how the CRA was constructed and I'll just say we have open source has focused on the US legislation for a very long time in terms of advocacy and we really need to get more international in the way we do it I'd say for Europe specifically open forum Europe has been doing great work but they haven't actually had as much attention so if you want to get involved in the policy analysis and advocacy side in Europe they're a great group to talk to and they can connect you with others all right so we're almost out of time we're even past time so if anyone needs to jump to another meeting feel free to draw about but I wanted to thank you all for joining us today and for this very intense and live discussion and thanks to our audience for asking some great questions during the show big thank you again to the Open Infra Foundation members for making this show possible and join us for our next Open Infra live on September 7 where a panel of Zool operators invites special guests to talk about their deployments and discuss their operations for this episode our guest will be Johannes Fouffas from Volvo also if you have an idea for a future episode we want to hear from you submit your ideas at ideas.openinfra.live and maybe we'll see you in a future show thanks again to our guests from today and see you all on September 7 for the next Open Infra live