 And thank you everyone for being here today. Thank you for our great panelists today, experts on CRA, and experience in open source, of course. Yeah, so we've gone through a couple of great presentations. So thank you for those, Kiaran and Javier. It's a great place for starting the discussion and having this. So I would like first that if you can introduce each of you, Mirko, you first. Hello, can you hear me? Hello, I'm Mirko Brum. I work for the Language Foundation Europe. I do community development. And I'm engaged in open source in Europe for two and a half decades, roughly. I participated in two key studies at the EU, one on the interaction of open source and standards development, and one on the economic impact of open source in Europe. So I'm really happy that we can discuss the outstanding issues for the CRA today. Thank you. Hi, everyone. This is Beatriz Benitez. I'm a lawyer. I'm specialized in new technologies, and in particular, in open source, and also in intellectual property. And it's an honor to be here with you of all this afternoon. Thank you. And so I work for the Eclipse Foundation. I work on public policy for the Eclipse Foundation, where I sort of look at the interaction between open source and policy. Cybersecurity is one of them. But we can think of competition. What's the role of open source in competition? We can think of the data of the software development, industrial policies, international relation, everything. Great. Thank you. I'm James from Red Hat. I'm director for public affairs for the EMEA region. I just want to thank, in particular, Oafi for this capital series previously called the Troika series. And what it was doing was every six months, the rotational EU presidency, we tend to spend our time in Brussels and the EU bubble. And it's absolutely critical to reach out to the capitals and connect the open source community, but also the national government. And very often, as open source, we don't have the kinds of resources you expect in proprietary. So we really cannot have people in all these various places, at least from a legal policy perspective. So these interconnects are really, really important. And again, also a special shout out for Javier and the Spanish presidency. I'm not just saying that because you're in the room. But also that you have been very collaborative, very accessible, and very keen to protect what we call open innovation. So thank you. Well, thank you for all of these introductions. So to start with something, one of probably the very first questions that I would like to go with is, OK, we had an original text a few months ago. Now we have this new text that was leaked. So first of all, can you elaborate a bit or, OK, what is this bringing to the conversation now? Because the original text was really kind of going to the basic foundations of open source. Like, OK, open source may not work anymore with this specific law if this goes as it is. So what have we learned now? What are the new advances that we see? And basically what you see that may make sense as, you know, start extra discussions here. So Mirko, you want to start? Sure. First of all, and I'm also not saying this just because Javier is here. I think we need to give the commission and the other EU parties involved a bit more credit. Because by having the courage to put the CRA out there with all the flaws that it initially had, it did open a floodgate of discussions. And it also created a lot of motivation in our community to participate and say, wait, this is not right. And my guess is that was partially intended. So what I'm trying to say in this context is in this year that we have been debating on the CRA, we've made a ton of progress. We've clarified a lot of questions. We see, for example, the initial way how open source software was almost circumscribed in the text, more or less normalizing on the well-accepted definitions of what very open source software is, which I find is a great improvement. We see a much deeper understanding in the text now of how the difference between commercial actors working, bringing products towards their consumers and the collaborative development processes that develop foundational blocks upstream, how they play together, and how they have different roles. And this is what we now see in the text reflected, possibly in the law, for the first time, which I also think is a great improvement. So maybe one thing that I take away from this is maybe you should have started talking and getting engaged a little bit earlier, we could have, so that many of these issues before they became part of the ready-made text. And maybe this is, for us, I can say, for legislation Europe. That's one of the key goals from the CRA processes to say, next time, we would like to provide our advice earlier. And that would be great. We just say this is a problem of open source communities in general, like what you said before, right James? Like, okay, we need to get together and do something and there is no much money involved as if compared in other industries. A bit too much hindsight from my perspective. There are a lot of ongoing legislative initiatives in the EU and you cannot regulate the ICT ecosystem today without touching open source software. As we've seen in the numbers, it's everywhere it's, every commercial product is built on this foundation and we know it's the most efficient way to develop software. And so, yes and no. So yes, we could have been engaged more, we can be established more strongly. But maybe all we need to learn, including the parties on the EC side and we are very happy to provide our advice. Well, thank you. Javier, if you want to jump in the conversation at any time, just take a microphone. I mean, anyone indeed in their position. So this is an open discussion now. Yeah, do we have a microphone now? I don't know. Can we have a microphone? There is even a chair. Yeah, perfect. Thank you. Maybe we can bring it here. Yeah. Yes, one small point, which I really should have mentioned before. The work is not done when the regulation is published. The work just starts because then you have the guides and you have the policies of the market service authorities. And upon these guides, and upon these can correct many deficiencies. So, and upon these guides and upon these experiences and upon these, a key of administrative criteria, the next law will be built upon. Therefore, don't stop loving. Please. Okay, let's enter more. Thank you, Javier. Let's enter more battery into technicalities perhaps. So, okay, what are the changes? Yeah, from the legal perspective. Yeah, I will say. Well, I read, we read the text and both amendments, the Commission 1 and the Department 1. Of course, there's an improvement. I think we can see the open source community there, but there's still a lot of work to do. That's the way it is. We have seen that has been introduced a new role that's here in Kiran said before, the Steward. Okay, but who will be the Steward? Because we know will be the foundations, but also the public administrations, universities may fall within this definition. And also, I mean, this will be a concern for them, and it's the way we feel, I mean, I feel it with my clients. The other aspect that I think is important is just to be aware that the open source community is really terogeneous, and we cannot talk about a Steward or no Steward projects, because I think it's not the reality. And then, just to go and step further, we have the concept of the collaborative development that is just no complex. Just to understand who will be within this definition, because there's a lot of open source projects that are seeded, for example, through corporate administrative academic contributors and there's not collaboration at the stage. So, yeah, we need to clarify and we need to think a little bit more about how we're going to interpret these concepts and how they're going to be applicable to these organizations so they can know and assume that they will need to afford and they will need to address some resources that maybe they haven't thought at the moment. So I think it is important, it's an improvement, of course, but I think, as I said, I think we will need to clarify and we will need to analyze a little bit more so there's certainty in the text and that's what I can say with this version. Quick question then, so my background is in academia, so what would be the impact for European Union is telling you, oh, you need to produce open source because this is open science, good. So then I'm prototyping things, da-da-da-da. So then I serve something as open source but I am a professor at university or PhD student or so, but then I decide, okay, this might be good for create a product and then I go commercial. So what do you think might be the importance of the difficulties of all of this with the CRA as it is now, perhaps the definition of collaborative development, the definition of STWAR too? Well, as an individual, if you are an academic, you will need to make a buyable to a market, the product. So that's like the commercial point of view. From the other point of view, that's excluded. That's what we talked about before. I think we'll be exempt of the obligations if we are not, I mean, because it cannot be every time considered as a collaborative development. If you are just one researcher, of course, makes sense for you to be exempt of these obligations and that's what we want to. I mean, if not, we'll be, I mean, hind the question. We'll hind the innovation. Do we have the microphone? Sure. Yeah. That would be our services as producers of software because we can do very specialized software. In many cases, companies cannot do it and that's why they have us. From that point of view, we are economic actors. The definitions as other is not clear at all. No. We are not covered by the law. Which means I need to do some kind of liability study within my university. I'm just putting money in my company. That doesn't make a lot of sense, I think. Oh yeah, of course. I would like to add something without totally hogging the discussion but that's something that's really, I still worry a lot in the current text of the series. We're talking a lot about the nature of the actors. Is that a commercial actor? Is that a university when the university does some things like paid research projects that are getting commercial? My problem with that is that in our world of software, the same actor does actions of very different nature. We think it is really laudable if a company hires a kernel maintainer and basically gives them free rein to contribute to Linux kernel. So you have a commercial entity, no question but the act that the person is doing is charitable in a way. So it's like it's given away for free and the company probably gains some reputation out of that or other benefits but the same company also brings products into the market. So for me it's not a question of who the actor is. We cannot classify the actor as such with all the actions that they're doing. The individual actions have a different nature and that's something that I find very difficult to describe in a text, it's not reflected. What I would really like to have the understanding that if somebody contributes code upstream into a collaboratively developed project it doesn't matter if that person is employed or not. It's like a non-profit charitable act. If the same company introduce a product to market, commercial, all the obligations apply. And that's something that I would really like to see. Maybe we can do this in revision too. So it's the act not the actor that count in terms of the obligations from my perspective. So sorry for that now, maybe the others can speak. Yeah, so let me go to James and so sorry about that. Because he mentioned, well we have developers so we are hiring developers to work on different open source projects. So what would be the specifically your point of view from Red Hat perspective as basically you are doing that, right? Yeah, so Beatrice I mentioned heterogeneity and also Tom asked about the global commons and the kinds of requirements that need to be adhered to. Because Tom I said that I look like a Spaniard. It's the nicest thing anyone said to me for a long time. I'm going to give him a shout out. Your question is really about where Red Hat is in the top left hand corner of this diagram. And we've had a product security team for over 20 years. So we have these hardened processes to ensure the highest grade of cybersecurity in the open source world. We do back porting, we were a long established steward maintainer in multiple projects. But also what I think is interesting is Merco from Linux. There was a couple of studies that came out and one which I just had to quickly Google to see what was happening. It says that of the survey, 75% of those surveyed who are contributing upstream are not from the IT world. So the point about heterogeneity and I think that comes back to your question about how Red Hat sees this is that we kind of federate that risk with our customers. So we're in 100% of the banks, telcos, airlines, all member states. We want to build hardened secure infrastructure and we do that together. So a rising tide raises all boats and those kinds of requirements are in this in the CRA. And I think one of the concerns we would have is the plausible duplicative nature of the CRA where we are doing the common criteria highest possible level and then we have to do a CE mark. But if I say in all the annex parts of the regulation and where it pertains to in scope open source, I think there's been huge improvements and going from the vulnerability disclosure bit to the no known vulnerabilities, risk management. I think there's some really good improvements and I'd say that I'm closing the importance of avoiding reinventing the wheel and ensuring that when companies are contributing upstream and all they do of deploying a commercial, you know, hardened enterprise solution that when they're doing, when they have to because their customers ask for it, a common criteria or what have you that there's mutual recognition. So they don't have to, and I understand, have you, that is understood in the text and that's where the EU wants this to head. They want to recognize the importance of open source. They want to protect open innovation and they don't want to lumber all those organizations which are increasingly contributing with extra duplicative and if I may say, quite costly requirements when they're already in the business of delivering secure open source. So, and so now I have a question for you which is, okay, so the role of open source foundations have been traditionally to protect developers somehow from, you know, IP attacks at the beginning. Now it's kind of an umbrella to perhaps have innovation and move forward, have a, you know, a new way of working, neutral place for corporations to play with software to produce things, right? So now what, where do you see the role of foundations and specifically the Eclipse Foundation where you work at? You mean in terms of the CRA or? Yes, I mean, this concept of Steward, so maybe you can elaborate there. Yeah, so it's complicated because the text is, it's a leak, right, so as you said, I can only comment on the leak since the information is confidential, but do you mind doing a really brief introduction to the leak document because we've been mentioning this, but maybe the rest of the audience, thank you. I mean, your first question on this was the very good one in a sense that the two versions of the text, the original version and the last version have something in common, they're both very complicated and if you thought that the presentation made by Karen and Javier was complex, it was one of the clearest, both of them very clear, explaining exactly what it is and the other presentation I've heard on this are far more complex than what I've heard today. The problem of the first one, the one of the commission, is that it was not looking at open source so much, they were trying to regulate something, open source was in the way, they solved the problem, that's it. What the other one, so the new one, the leak, the one that no one has seen apparently is doing is actually looking at what is existing in open source. In open source you have different roles, you have different people doing different things. You mentioned foundations, what you've described is pretty much what foundations are doing and what's good about this new text is that there is an understanding that open source foundations are not distributors, they're not manufacturers, we don't hire developers in order to develop open source software, we're here to help companies gathering or individual gathering together in order to develop something and that's extremely different from just distributing or manufacturing because there are things that you cannot do. If we have to develop patches as a foundation, we cannot do that, that's not our role, that's not our, the community has to do it, it would be weird for a foundation to just step in and say no, no, we have to modify the software that way, that's way better in order to regulate or in order to comply with regulations, that's not our role, we don't want to step into this so much, we want to help into improving security through processes and that's what the obligations of this new leak that no one has seen again is about building processes so Steward would have those obligations. Now I think the challenge to enter into maybe a bit further than what you asked of this new text is the obligation of the Steward, right? I see them as being two things, on one hand you have to develop a process, on the other hand you have to report. The problem is that for, and we need to be honest on this, you have different type of foundation, it's very heterodontical, sorry, it's very different, various, there is a diversity there and it would be very difficult to apply the same obligations and the same requirements to your foundations that only have volunteers with very small budget and then a market surveillance authority come on them and say no, your process is not good enough and then the volunteer has to work his all weekends, like the next 10 weekends so that it can build a process that a market surveillance authority would finally be happy with. So there is this problem as well, can we ask small foundations the same thing that very big foundations do and that's something hard, should we build standards, should we build process, is the role of a market surveillance authority only to sort of tell us you should do this, it's not good or help us into building those processes that they want us to have and the CRA want us to have and then there is the conversation on collaborative development that you've started and I think it's even more another question. I can only underline that so I was involved in the KITI project, does anybody remember that? It's one of the well, most original European free software projects. After some time, the initial 10 contributors came together and we founded a registered association. We applied at the rest of this in Germany, we applied for charitable status, it took a couple of years, we got it. The organization receives regular donations through a membership program, very small, can pay for one and a half staff basically, a bit more today. And I'm saying this and I'm describing it this way because that's what characterizes our open source ecosystem in Europe. We don't only have large foundations and big business, we have a whole network of small communities that are very much volunteer driven, very specialized, sometimes a bit obscure, you don't even realize that they're there but you're using their software all the time but there's another aspect to this and this is really interesting when it comes to European innovation. I meet my friends from this community today in every business I worked in, in every community that has further developed. There are engineering managers, there are architects for European products. So these communities are incubators of knowledge of our best software engineers. I'm convinced that that's true because they have the most experience to work in a diverse, difficult environment and produce great software as volunteers or students and then they grow into the industry and this is my biggest fear with the obligations that we push onto, let's say incorporated open source communities, is that if they're still volunteer driven, it's going to be a little barrier for these people to invest a lot of time and it's a very sensitive and fragile ecosystem and when you touch it, it goes whoop and then just disappears. So we need to foster this and we need to protect it. This is actually something, the policy decision we need to make in Europe is do we tolerate this? Because do we have people or do we like say, oh, it's a neutral, it's okay or is it really something that drives us and builds our European ecosystem? I'm leaning towards this is really an important contribution but then we need to not just let it live, we need to actually encourage it and that's what we're currently not yet doing. So that would be the thought that we need to develop. Really absent in it. Even more when there are countries as Spain where the percentage of small and medium enterprises is basically higher than if compared to the rest of Europe and then of course if compared to the US so it's how can we compete, right? And me being the owner of one of these small companies. James, you. Yeah, I'd like to just again talk a bit more about that diagram and since I'm an honorary Spaniard now, there was Goya, there's Vasquez, there's Dali, Picasso and now have you. So it was really helpful. I've been thinking about this is that a company like Red Hat is not in just one of those boxes, it's in multiple boxes and I think the reason why I'm making this comment because you've spurred this thought in my head is that if you are expected or you innovate and you continue to do certain things which perhaps typically a foundation wouldn't be doing, then what you are inadvertently doing is you are painting yourself further into the left-hand corner, right? And I think the point is you're doing a lot of great work in the automotive world where you have the automotive's coming together, they're collaborating, they're sharing code and they're agreeing with each other and Moko, you're much more knowledgeable than I am having been a former Mercedes-Benz guy but if I understand correctly, the differentiator when you buy a car is not necessarily whether it has best possible braking system, that is open source so that the concept or the wish is to kind of abstract that out and then you differentiate above it. So again, if for example, these rather risk-averse lawyers and these incredible companies fear that they might by collaborating in Eclipse or Linux or others suddenly find themselves up in the top left-hand corner, it's possible, correct me if I'm wrong, that they might, sorry, forgive the pun, put the brakes on, right? Yeah, I just wanna compliment this. I think what James just said is the center of this is in the new text, the new leak is the way collaborative development is defined. The way collaborative development is defined, the first two sentences that no one has seen is okay and then the last sentence says when there is one entity exercising control, then it's not collaborative development. The problem is that exercising control when it comes to open source is a bit of a strange element, right? What does it mean? Is a commuter the one exercising control? Is no one exercising control because of the transparency of underneutrality and meritocratic principle that we apply to all our projects in Eclipse? No one is doing it. If there is two commuters and then one disappeared then it becomes a single vendor project despite all the things that, what is exercising control of one single entity? Can we be under the governance of a steward and have one entity exercising control? I don't believe that's the case. I've heard people and colleagues saying the complete opposite. The text at the moment with this specific aspect is not clear and that would lead to what James just said. We go to Linux Foundation, to Eclipse Foundation, to Apache Foundation. We think we're doing collaborative development but because all of a sudden, exercising control is a weird one, then the market civilian authority of Sweden is telling me, no, now you're a single vendor and that's not okay because that is killing the sole idea of having stewards despite the fact that the text was trying to define stewards to help the open source community and that could be counterproductive. Mirko, and then we had the question. So two comments on this. So one, I see this as a homework for the open source community as well. So the commission, let's say that that concept of the open source steward goes in and creates two separate operators, commercial businesses and people, entities that care about open source projects. Then it's up to us to actually say, we adapt our governance the way we run the projects, the transparency we apply, so that it perfectly fits the steward definition. It's a give and take on this. So this is actually something I have told our communities a lot is, for now we can try to influence the text, but once the text is there, we need to start learning to live in the new environment and not all of that is just necessarily bad. A lot of it is also impetus for innovation. For example, the question of what does open governance mean is one of these blurry areas, of course, is a kind of a bit embarrassing that we in 2023 are not able to say in one sentence what open governance means and what the commission currently does it, it forces us to come to terms. It circumscribes it and says, no, you prove it. What's the one comment? The other comment is software development today is bidirectional. It is like take components integrate them further under the consumer user system. And at the same time, to make sure these components exist, employee developers can contribute there in that direction. And this change in direction until now in our perception is a firewall for liability, for responsibility, et cetera. Why? Because the communities that release the software, they don't have a relationship with their users. The users decide to use the software. It's their sole authority. They don't pay for it. And it sets a one-sided action. And that's why we say, if I make a mistake, and that's where the car maker example comes in, like I make a mistake and I introduce a bug and somebody else uses that software and now the brakes don't work. They cannot construe a liability to me because I didn't give them the software, didn't pay me for it. I released it into the comments and they made the call to use it. This is this firewall aspect of the upstream, the upstream comments. And I would really like this thought to be explicitly established. This is one-sided action. If I, as a manufacturer for product, decide to use an upstream project, I have to be aware that I bear the sole responsibility for that decision. I cannot make anybody else responsible for the cybersecurity vulnerabilities, the product defects that I introduce in my product. Unfortunately, I don't know, we kind of interpret this into the text, also in the product liability directive, but this is something that I wish, really wish, that the EU would explicitly put into the law. We had, let's go for the question. I wanted to ask to the panel, as someone that has found himself in all the different quadrants of the diagram that Javier showed for, it's hard warming to see that the current text is better than the initial text, but quite frankly, that doesn't seem to be enough just yet. And I'm thinking specifically about the right-hand side of the quadrant, so the anarchist, zero governance kind of projects. And the series seems to place a body incentive for these projects to stop their maturity process in a sense, because some of the problems that open source communities have had, are precisely lack of governance, lack of diversity, lack of resources, lack of direction, et cetera. So then my question would be for the panel, how can the interests of those projects be better represented during the negotiations and so on so that we can come up with solutions to these problems? Who would like to go? I love the question. No, anyone? Go for it. It's both a policy question and a democratic question, because the question is, can anarchists, because it was the symbol on the thing, actually get together into discussing with policymakers or don't they want to do it? And are they still anarchists? Right. But also, what is the solution of the policymakers in order to know how to interact with groups of people that are on purpose not organized or not yet organized, because that's just how it is? I think that's a very big challenge and I think that's what Mioko was going about, saying maybe we need to get together and discuss about what is open governance as well so that we can actually go back to policymakers and say all together, whatever you believe in, that is the way we see open governance all together. That's not going to be easy. Now, the thing of maturity of projects, with the last text, with the Seward thing inside, I cannot agree and disagree at the same time, because the obligations, if you have a project under the governance of a Steward that is for collaborative development, it doesn't mean that a manufacturer would have obligations. Only the Steward has the obligation to develop processes. If the text as the Steward goes as it is, it would be a problem with the smallest, for the smallest Stewards, as I mentioned before, because having a process is not easy and if the Spanish market surveillance authority comes at you and saying your process is not good enough, what are they going to do? But it would, I think my understanding as it is, is that it would be wrong to believe that the simple fact that you become bigger and you create a Steward or a foundation would make the manufacturer responsible. No, it would make the Steward responsible to build a process that the manufacturers might want or not want or be able or not be able to follow. But in the end, there is no real obligation for the manufacturer that has developed. But then, if it's really a big project, then the obligation falls because if it's a project that is controlled by one, that's another thing. So that's for the AOSP of that word, that the sort of not punishment, but that's how to take it, frankly, for an open source project, having to comply with such requirement on the design of an open source component, that's kind of a punishment considering that you give to the world for free. That's a long answer to your short question, sorry. I'll make it even longer. We have to kind of also keep in mind how open source projects evolve and what the role of this like anarchic, individually driven, highly decentralized part of our community is because we tend to focus on the big projects. The big projects, they have all established themselves about quite some time ago, developed proper governance structures, acquired corporate supporters that are funding them on a regular basis. I speak for the project of the Linux Foundation as well. But how did it start? How did Linux start? It was one student from Finland, right? So individual anarchist developer releasing the first version of the software. And that's the role of this, the right side of the diagram. Those are the actual innovators. The big projects, they introduce a technology, they develop it to maturity, but the next competitor to this project is not going to come from the big project. It's going to be one or two or 10 different anarchists throwing out projects and one or two of these projects may actually grow to be a small viable community. Then one turns out to be the next big thing. I mean, that we've seen lots of projects like this. So we need to be, I think, extra careful to not throw this part of the community out with the bathwater, but also allow them to take this transition because these projects today, they're only successful. We used a major transition from one anarchist, 10 anarchists registered association that is charitable, big business, right? And these are the sensibilities that we have in the text that you can really inhibit something from happening and this was hurt in Europe because we are the people that actually develop the software in Europe. Many of the projects develop here and we need to further and encourage that. Yeah, I'm not going to make the case for Anarchy, but 1936 Catalonia, things work quite well. Also, I'm also Belgian for 500 plus days. We didn't have a government. Everything was actually quite cushy. But that aside, I think the risk, I think Burko is going at is the introduction of swim lanes in how the ecosystem works. And it's not a bad thing to have folks right out there. And I mean, we have half our engineering upstream and they are doing development in perhaps projects which are related to downstream products, but also completely way off the reservation. And that's good. That's great. You know, that's how innovation should work. So I think if that happens, then the proverbial baby throwing out the bathwater is a risk. At the same time, we need to address this Wild West perception and this reputation even that we still have, I mean, there's still this FUD which was propagated 20 plus years ago and the ripples are still with us. So I think the CRA can help us frame that conversation and present the open source community or so the downstream products in a much more positive light. So I think there's an opportunity to protect the open innovation, but also enable and help the community understand better some of these concerns and perceptions and help them address them. So let's change the context here. So now let's go to daily operations. So we have a law firm, we have open source foundations, we have a profit company with big amount of customers, of course. So now it's kind of a quick survey here. So how many of your customers are anonymized? Of course, everything are really worried about the CRA. Are you having questions and so on? Maybe Beatriz, you can go with. Yeah, I mean, we have a lot of kind of clients, but as I said, we have, for example, universities, public administrations. And of course, there is a concern because they see these new obligations, the one that have been leaked as an administrative burden and they are worried about how I'm going to make this process work, or maybe I will have enough resources to deal with this. So, well, it's not clear, but of course, there's like a big red flag because, I mean, most of them, they are small projects. And of course, they won't afford these new processes as identification, the documentation, the reporting, then, I don't know, so many obligations that they're more reasonable, that's true, than the ones from the previous text. But of course, I mean, there's not certainty and I mean, we will have the lawyers, we will have a lot of work just to interpret this and try to, I don't know, I mean, assess the client, but of course, let's see what happens because, I mean, of course, the main thing and the main concern from our point of view, from my point of view, is that this may be a stopper just to the open source projects to, I mean, to develop, that's my opinion and that's why we are seeing in the law firm at the moment, at The Gross. Thank you from an open source foundation perspective, so. Yeah, look, we've heard it today. So, what I would say we'd concur and it's sort of a testimony and I think it would be an extremely sort of telly example. We've heard today the problem that you've mentioned just before, we've heard Javier saying as well before, we don't want to do this because we understand that there would be a burden on companies and on innovation. I will not be able to disclose the name of any company but we've already had a company coming to us saying, no, sorry, this project, we wanted to open it, not happening because we too scared of the CRA. We understand that and the cost of compliance doing it in-house would be reduced by, how many, I don't know, 100 times while if we do it to the open, the cost of compliance explodes to the roof. We don't feel like doing it at the moment. Let's see what's the discussion of the CRA happening and I think policymakers, and I'm pointing out Javier because he's the one who mentioned it today, understood this, but that's a critical reality. Imagine if we're talking about some of the biggest European companies. We are a European foundation, right? So we had voted in Europe, most of our members are European, I think 75% of our members or 70% of our members are European. We're talking about a very big European company that is like, we want to open something so that the whole European ecosystem can benefit from it and they say, no, we don't want to do it anymore. And that's not a small thing. And no one can blame them for this. Can they actually carry the cost that is multiplied by 100? And they don't think that they could do it and I understand them. Yeah, we actually did a panel that you saw some at Europe in Bilbao a month ago where we invited, we tried to really get like the pro-spectrum, the Linux kernel community, Python Software Foundation, GitHub, Red Hat and Ericsson. So we tried to get also like a European device maker business on board. We recorded that, we published it and we wrote a blog post about that that was published two days ago. So if you're asking what are the impressions of a wide range of stakeholders, I can only recommend you go and read that because it gives you kind of the in-the-field impression. Like now that we read this, now that we analyzed this, why are we scared? But there are two things, two takeaways from that panel that I would have to highlight. One is somebody highlighted that it was not necessarily a good idea to add barriers to sharing source code. This is how open source became successful. We had very low barriers. So collaboration was very simple and easy and straightforward. And now we're adding barriers to that sharing which is really the lowest level of the fabric of open source. So barriers to sharing code, we should really be careful with that and that's why it needs to be clear that the individual committer is not responsible, et cetera. The other one was to be aware that you can put up a legislation that has clear requirements for when you are compliant but being compliant does not equate to being secure. So what we have to keep in mind is that all the processes that the open source ecosystem have developed of really responsible disclosure of making sure fixes get propagated quickly, that kind of complements the law. And so when the standards are being developed once the text is done, we need to make sure that all the processes that we have are merged into what becomes the standard to accept the process and that we can even prove it on that. So yeah, so these are two impressions, no barriers to sharing code and make sure that the processes actually work and are not just following the law but actually focusing on compliance. Last and certainly least of all, I guess in sort of the lobbying fraternity of many of our customers and we have thousands of customers, I think the awareness of how important open source is to them from a legal policy perspective is pretty small. And it's only when they bump into, almost serendipitously, their engineer in the corridor, back at headquarters or what have you, there is this, what is going on? They then realize that not only are they using open source, they're also increasingly contributing to open source. I think we've seen a kind of shift, a shift, that's a pivot and a shift all together. Towards that awareness, I think the other thing is to your question, we also have millions of people around our products, this extraordinary ecosystem. So we're already sort of fielding questions from that community, individuals, and so what we will have to do as soon as it's done and dusted is look at it very carefully and produce some kind of FAQ as to what this actually means because I think we are sort of, yeah, we have a role to play as being still the world's leading open source solution providers. So that's something which is incumbent, but again, the resources are quite finite compared with perhaps others. I think maybe a final point for me, the resources point, I think there's never been a stronger case to collaborate. All those companies out there, the automotives, the banks and so on, I think there's a real opportunity, especially when it comes to the 44 standards that need to be developed, they will be involved in those, we need to educate them as to, hey, what are the open source implications? The review of the new legislative framework, likewise some of the notions of how it pertains to open source. And then also finally there's a whole piece around mutual recognition, what are the standards out there or what are the certifications out there which you are asking us, customer X, Y and Z to do, that then can be automatically CE marked so that we don't go through a huge extra cost round when actually the customer ultimately doesn't want that. If I may, Adele is in the audience and she's conducting a survey for Red Hat to kind of understand better where customers and partners and folks are thinking around Red Hat products but also open source more generally. So Adele if you'll put your, there we go, it's lovely lady. So I've done my job to identify. So over the drinks, it'd be great if you could have a chat with her. Thank you, back to you. Yeah, sure. Any more thoughts here? We have like 10 minutes left so I don't know if there are questions that are kind of boring you. No, I would like to come to your, Mikko to your comment on the difference between who you are and what you do. Because from my point of view, that's quite important. As you said, for instance, even large companies are sharing code just because they want to share or just because while they don't care. And that's not really commercial activity even if the company is commercial and very big. From my understanding of the current texts, the important thing is who is doing the fact. I mean, if it is a company, it gets liable and all of that. So but in open source software and in free software, it's very important to separate both things. But I don't see that in the law now and no intention of that. I mean, no movement, I'm not sure of anything about that. If that's not fixed, it's very difficult that all the actors behave in their own interest. I mean, I just share code because I don't care. I just share code because it's not a cost for me or whatever because they are all the time going to think about the liability. And in most companies that's a big issue. But that happens also for universities. So as I said before, my university is going to start thinking, can I be considered as a marketer of services, for instance? Even if I'm just sharing code because, well, I'm a professor and I don't care. But maybe the university is considered as a marketer, which means they can be liable and maybe I'm going to be said, please don't share code. Which goes against the policies of the commission, by the way, which is a bit strange, I would say. So maybe we've heard a lot about the concerns and everything that's complicated and that the world is coming apart. On this one, I think there's actually relatively simple fix. And that is to clarify that somebody who basically submits a pull request to a project is not responsible under the COA. It is the entity that makes a release of the software. Because that will already clarify that problem. Even a corporate software developer offers the integration of a piece of code. The upstream project accepts it. Unless the upstream project makes a release, that is not made available. And if it's made available and that's an open source steward, then it's clear what the responsibility for that community is. So that would be a very concrete suggestion is to say, clarify that it's not the individual developer, no matter if they're employed. It's the entity where this gets integrated that's responsible. Because the individual commit is not an entity in an ICT ecosystem. It's the release of the software. So that would be a very clear way, clarify that and then that problem is gone. There is another thing that was in a text that we have seen or not seen is something that would drastically improve the cybersecurity of open source, but not in a negative sense in a sense that it doesn't bring obligations on the least capable actor or the least financial means available actor. Is one element that says, if you're using an open source components and you improve its cybersecurity through a patch or whatever, that you have to report back that cybersecurity innovation back to the main center. I think I've not heard anyone in the open source community ever said that this was a bad element in the CRA. It is not, we have not seen it in the text of the steward thing or the collab development thing, but this is definitely a positive element for the open source community that would help drastically to improve cybersecurity and it doesn't feel like a regulation or a burden on the organization that have the less financial means available. This is also another instance of where we see huge progress in the understanding that there was a clause added that the patch needs to be made available in a way that it can actually be integrated upstream. License-wise, license need to fit. And yes, that's, maybe we should also highlight the good things in the CRA and that's definitely one of the potential real improvements. Would you say this is a, Caleb, let's play Evil Savocate here. Can we say CRA is an opportunity for open source? What if we play that role? So certainly one of the litmus tests of whether it's a success or not is whether it bolst upstream of contribution. Let's see. I mean, all the indicators, whether it's the sort of the GitHub innovator guide or the Linux researcher, et cetera. It's all doing this. As we'll find out in the next panel, there's some really exciting growth in terms of open source. So if there's a little dip, maybe that's acceptable. If there's something else that comes afterwards and then there's the next wave of open innovation. If not, then I think we'll see like we've done with NIST. NIST one, whether I had to come back, NIST two, we'll be looking at CRA two. If I may, Adele's not called Adele, it's Alona, isn't it? Sorry, my bad. And Javier, I think you wanted to come in, you put your hand up. Is that right? Yeah. Not to hug the conversation, but just to make a couple of points. The camera. Yeah. Thank you, thank you. Just to make a couple of points. First, you spoke very eloquently about small organizations and SMEs. Our heart is close to them and they will get surely a special mention, I think, in the final text, an exemption, which is already there, for example, in NIST. It only makes sense. Another point, a larger point, is for definitions. This is something that comes up once and again. If I had a euro for every time, I've got a complaint that in this law, the definition is not good. I'd have like 20 euros or so. It's already a lot of money. Good lunch. No, but really, that's the problem with laws. The map is not the territory. The map has much less detail than the territory. The reality is very granular and particularly in open source. Every specific organization has a specific little model where the founder gives them money and he only monitors it sometimes and we need a new quarter for a specific company. And yes, it's like that. Definitions are often fuzzy and they have to encompass. This has been the case too, for example, in the NIST directive with cloud service providers, which when this one came out, we had a very specific idea of what they would be and in the end, everyone under on is a cloud service provider and we had to get around, redefining the terms within the definition. And I'm sure this will be the case too, but that's what the guides are there for, for example, in the new legislative framework and that's what the administrative criteria of the market surveillance authorities are there for. And that's why market surveillance authorities sit together and say, let's have common criteria for these things. So, but there's a trade-off there. If we make the definition too alambicated, too Byzantine, too long, the compliance costs rise. So, we cannot make the definition too long either. So, there's no easy solution there. Thank you. Yep, nope, take it. So, the work question there. One more question to Beatriz in this case. This is a strictly legal question. There are many open source and free software licenses that end with the software is provided as is without warranty of any kind. How does that interact with the whole CRA and all the obligations and so on? Sure. Well, here we have seen there's other obligations that the steward will need to comply with. There's not the requirement of the CE certification of the risk analysis, whatever. Now we have other kind of obligations. Yeah, of course, this is a problem because who is going to be responsible? If there's any claim of if we have any problem with the use of the software. I mean, nowadays with this text, there's not a solution at all. I cannot say who are we going to do. I don't really know what is going to happen. As far as I know, we are going to deal with non-liability or the limitation of liability that the open source licenses have nowadays. But for example, there's another example that will impact with the copilife licenses with the no surrender freedoms. You can say that, for example, it says I'm doing it by memory, but it says that if you cannot comply with the terms of the obligation or any other obligations that this will be the obligations imposed by the CRA, you cannot convey the product under that license. So you cannot, I mean, transfer the license under the GPL, for example. If you are not complying with that obligations. So that's other concern that what are we going to do with this, I mean, that's really important. That's huge for the projects, from the licensing perspective, I think that's the most important, of course, as is the limitation of liability. That's huge also, yeah, but. So we'll have to change our licenses, basically. We'll have to change the whole thing. I hope not. No way, you know. That's why I think there's the need to work a little bit on this, because there's an impact, there's a legal impact. And of course, Mirko, you will know better, but I think it's necessary just to make a transactional cost and statutory cost of these obligations, just to ensure that these kind of organizations that we are talking about can deal with this. That's, I mean, I think it's important just to ensure that won't be that impact, that legal impact, in a short term, I mean. So the clauses that you describe are particularly to the GPL group three. But essentially that means that the body of software that is out there under this license may become undistributable. And that's certainly not the intended effect. I'm relatively sure that nobody wanted that. If that's the case, then we need to make sure that this doesn't happen. But there's kind of a medium term effect here and that is what should the community do that owns this code? Basically what we just said is they may not make this code available in Europe if they can't comply with the CRA and the license is you cannot comply with the CRA because you're taking freedoms from the user way. So what will happen is that either by license or by choice, they will say, well, but then we don't make it available in Europe because we're an open source community, we don't make money anyway. And that's, sometimes this has been described as like a doomsday scenario. But I'm looking at this from my head of I have run a community before as an elected representative. And if you have zero money, you have money to pay half a community manager. And all of a sudden you have such obligations and you cannot comply with the license that you will look for a straw that you can pull on and say, okay, we'll go this way. And this is not an unintended side effect. And I think we would be very ill advised as European citizens to let that happen. So that's definitely something we need to prevent from happening. And he would not even increase the level of cybersecurity because let's just say they don't make it available in Europe. And then a developer figured out a way to get access to it, I don't know, a random idea, like a VPN for instance, wow. And then they have access to it, they implement it. And then the only thing they have to do is now to make sure that this component complies with the CRA. Like Javier said before, if you buy a Chinese component with this weird C marking on it, which is not the actual C marking, the only thing you have to do is to make sure that the component is now compliant with their safety regulation. So in the end, no cybersecurity added and all the burden is in Europe and no else. No, nothing happened. Does this mean that basically we, no developers will exist, open source developers will exist in Europe anymore? Let's not end on that kind of note. Okay. Yeah, I think going overboard. Yeah. I think this is a regulation about horizontal resilience. It's not an IP regulation. So I don't see that as a secondary effect and that would be ridiculous as it stays. Okay, now probably last question for today because now it's been full hour almost. Now that I hear, you know, I own this small company called v3rdia. So we have the following situation. Let me know what I should do. So okay, we started in academia, Jesus there and Gregorio were my PhD advisors. So then we decided, okay, we produce this open source technology, tonalize open source projects, et cetera, et cetera, perfect. Then we started to have some companies, you know, pressing interest like, well, I would like to do this development or these things, so then this is helping me. So then I'm paying you money. It's not exactly research, but it's research, but it's kind of in between, right? So then after this, we say, okay, now we found the company, good, perfect. So then we take, everything was open source, GPL version three, we say, okay, we move into the testing the market. This is where we were basically at the beginning and then you have your mention, well, small companies will have a certain exemption here, chapter or section or so claiming this. So it took us several years to test the market. Now we have certain business running. Now in the last three, four years, our technology was forked by the Linux Foundation on the one hand and then they are providing a service. I don't know if there's still code on from ours. And then there is a Chinese company who awaited for the project and then they started the project called OSS Compass. So where are we in all of this basically? Because we have our project that we have certain collaborators. We are a part of chaos community, which is a Linux Foundation project. Then we have Linux Foundation that forked the same, their own project. And then we have this Chinese company doing this. How do we proceed here? I don't know, I don't even know how to start. Yeah, so I think it's a question for Patrick. Yes. I would say. Any thoughts? I think when one particular company a long time ago decided to fork at Enterprise Linux, we came out with unfakeable Linux, they came out with unbreakable Linux. We just doubled down on contributing upstream. That was the sort of the strategic move. But that's from a place of some momentum and resource. You are in a different environment. So yeah, I'm interested in what the answer is actually. Good question. Any thoughts? I was thinking how the CRA changes the picture in this case. I think this is maybe a good example for how complicated the structures in open source can be. Because you have contributors, often you have like a foundational piece of software that the business then builds upon, makes commercial versions of it, or provides services, operates it as a service. And we need to really understand what are the roles. You're running a business and it provides a commercial software. It's open source licensed, but you're as a business you're commercial, so. And that means you are fully responsible in the CRA. The Linux Foundation is probably a steward in this structure, we're not selling it. So maybe one conclusion here is the CRA will force us to make the roles of the individual actors who are developing, contributing, operating much more explicit. And we have the situation in open source, we have single vendor companies, many of them with the best intentions, many of them with murky intentions. But I'm developing my software, I sell commercial licenses to it, but I make an identical version available under an open source license so that the community can use it. Usually, of course, market penetration, it's reputation, but it's also just a good thing to do. Still, we're treating them as commercial actors and the CRA will make this explicit. So this idea of the single vendor model, we have to rethink it. How do you do that in the future? Do you separate those two? Make one into an openly collaboratively developed foundation and build the commercial model on top? Maybe that's a conclusion here. So the CRA is also an opportunity to mature as an ecosystem, which has also the downside that some approaches may not work that we were used to. So we always give this example of the single person maintainer that maintains a crucial piece of software that we're using everywhere. We are very endeared to this model, but it may be time to admit that for something that becomes critical infrastructure software, that might be a bit too brittle as a model. So maybe this will force us into a more mature government model for projects that are critical. And that's an opportunity without throwing the baby out with the bathwater and preventing small projects from emerging, which is a tight balance. Yeah, my first thought there was, okay, we are, okay, of course, Huawei is not gonna enter into the market, it's small, but it's like what you said, heavier, right? So the cybersecurity is here. So it's already here. The point is probably at the very beginning until we really understand how this works. We might be or other companies in a similar situation in kind of disadvantage, competitive disadvantage. So we need to learn how to deal with that. The help of open source foundations would be fundamental. The help of the European Union, of course, would be fundamental as well to make this happen. It's like a labyrinth, right? So far trying to make the puzzle and so on. So any more thoughts here? Or I think not, we are close to close. Okay, any more questions from the audience? That's, hope this was great for everyone. Good discussion. Thank you, our panelists. Thank you for your time and well, thank you all. Thank you.