 Good afternoon. I think this panel is what is between you and lunch. So the theme of this panel is an important one. And actually, having been involved in this summit for several years now, it's a theme which is somewhat familiar. And in fact, I think as we will find out today, it's increasingly more acute. And similarly, tomorrow at FOSDEM, there are a couple of policy tracks looking at this development in terms of these unintended consequences for open source. Indeed, last night looking through the OFE community email, which was on fire. And similarly, during this event, so those who keep emailing focus, you're going to be here in the room. But there's quite a lot of concern around a number of areas of policy, in particular the Cyber Resilience Act, which we'll touch on briefly today, but also, again, in deep tomorrow. So I guess we're going to use the beef burger analogy in terms of how we're going to structure this. So the bun will be just a bit of a context setter. The burger will be going into a few examples. Again, we don't have time to touch on all of them. Previous panels did so. So we're going to riff off what they were talking about and not, hopefully, duplicate. And then finally, time permitting the secondary bun is to understand a bit better about what we could do together, both as a community, but also, importantly, with EU policymakers. If I may say, many of whom are equally frustrated that there are these unintended consequences as they adopt and contribute more and more into open source. So I'm James Lovegrove. I'm the policy wonk for Red Hat based here in Brussels, but looking at the region. And it's my honor to be the moderator and co-panelist today at this event. So Deb is going to be first up. She's a policy advisor to the Eclipse Foundation, also former Red Hatter, and brings together some really interesting experience from both the government side and academia. So I think you're going to kick things off, aren't you, Deb, just gives a little bit of a perspective of, in terms of scene setter, what you see as perhaps some of the drivers behind this situation we find ourselves in. So Deb. Thank you very much. So I appreciate being here as a non-EU citizen, but I have a perspective of about 25 years down the open source community. Today in the United States, it's been a software economy for some time. European Commissioned and the EU has an admirable and incredibly creative ICT roadmap, which is envisioning lifting all boats along with the digital sovereignty program. But the thing that's a common thread now that has been disruptive and a game changer is in the United States we've never really had public policy that addresses open source. It's been an operational concern government agencies have viewed it for years here in the European Union. Similarly, but again, a deliberate strategy for innovation going forward. The game changer has been the arrival of cybersecurity concerns. And so for the first time, open source community, the industry, the vendors are faced with potential regulatory concerns. And what we haven't really been prepared for is being part of the policy discussion, how that might actually impact the very industry and ecosystem that all of our plans rely on. And so we're a bit behind. We've not done a great job over the last several years of informing policymakers of what the open source ecosystem actually looks like. You know, what is the flow? Where are the economics? Who's making money? Where are there contributions? And so this I think is something that's a challenge both in the United States and in Europe where it's not well understood who the stakeholders are that might be better informed and involved in deliberating and forming public policy. And I think that's the fundamental landscape for us globally. We know there are other countries that are considering public policy making as well. Great, thank you, Deb. I'm gonna bring in Simon, who is the Director of Standards and Policy at OSI. As we all know in the room, but just for those who don't and those online, it is a global charity that is stewarding the very definition of open source. And indeed, the previous panel of seats in front of me brought up some of those key concerns about the importance of permissionless. So Simon, maybe give us your take on what's going on in Europe. Thank you. Thank you. So I've been watching over many years as open source has gradually moved from being a marginal curiosity to a central reality of the technology industry globally. And legislators have gone through several phases as they've reacted to this. They started out by having no idea that their legislation even impacted open source because they were unaware of it. They've gone through a phase of noting open source but not consulting any stakeholders. I believe we're now at a stage where legislators are responding to open source but they're consulting the wrong stakeholders as they're putting the legislation together. And I hope we're going to move into a Nirvana where that changes. I think the reason it's happening is because the way we've approached legislation is very much an industrial revolution approach to products. We have producers who make things. We have workers who belong to unions who do the labor of making things. And then we have consumers who use their money to buy things. And we're well set up to see legislation consult each of those modalities of engagement with the economy. So we have lobbyists who are representing the producers and we have unions who are representing the workers and we have civil society consumer organizations representing the consumers. But it turns out that open source is a fourth modality where the participants span the previous three modalities and our legislators are simply not equipped or set up to consult that fourth modality. And as a consequence, they consult with proxies that they believe represent that modality but they don't. So for example, in the recent CRA, we suspect that the framing about open source came from researchers who were involved in industrial open source who very much believed that open source was fit a particular mold and that that was the universal truth about open source. And so in the process, they accidentally misdefined it and may well ruin Europe's software economy as a result. So that's what I think is going on. I think we're still stuck with legislation in an industrial revolution approach and we need to help legislators progress into a modality where they understand that the new way of producing software spans the previous realities. Great, thank you. Talk about the fourth modality, it's a good, and you mentioned CRA, a good link to Martin who's the senior internet technologist at NL Labs, not-for-profit R&D Foundation. Previously, Martin was a security advisor, senior security advisor at the Dutch National Cybersecurity Center. And I've been working, and many of you here had the pleasure of working with him over the last few weeks, months on the CRA and he seems to feel that he's unwittingly found himself in the Brussels jungle. So it would be interesting to hear your take as a developer what your observations are. Thank you. Thank you, James, and hello. Yeah, I've been actually, I was not planning to be here. I work, I have some mic now, great. Yeah, thanks. I was not planning to be here in the sense that I work for a charity that has been making protocols and software for the internet for two decades. We make domain name system and routing software that you will likely have used today, even, when you use some of the internet. And we are quite used to work in communities to define these protocols and work on improving the standards and their resilience, the implementations and their resilience. And we are used to work on these in multi-stakeholder forums where the makers of these things are well represented. So when in November, or in October, I dove into the CRA and published a bit of an analysis in November, I was super surprised to really have hit a nerve within the wider community. The thing I wrote had 20,000 unique views within a couple of days worldwide. And it sparked quite a discussion. And I think that shouldn't have happened, because the analysis is of a train that has left the station. And I think it would have been far nicer if we could have had the discussion while the commission was deciding which way the train was going to drive. Because I think the goals they are achieving are very worthwhile, and more on that in the second segment. But I'm not sure if we are reaching the goals for this community in particular. And seeing that open source is becoming the foundation to most of everything, I think achieving those goals is very important. So I came to Brussels. I hope to have a tiny contribution in this space. And I'm happy to talk to you about this topic. Great. Thank you. I like this analogy of trains leaving stations. I think you're right. We needed to have been in the waiting room to have that consultation even before the text was released. Because I think we're not geared up to cope with that process. It's a very heavy process, both here in Brussels, but all the national capitals. So again, it's particularly important that these summits are taking place. We're galvanizing our interests together and then therefore being able to collaborate and mitigate some of these unintended consequences. I think that the theme of this panel was to avoid. I think that's unrealistic. There is no possibility of avoiding. But there is a possibility of getting more engaged earlier on to fend off some of those possible impacts to open innovation, which is absolutely critical to European recovery, but longer term competitiveness. So let's turn now to the meat, the burger, and go into a little bit of granularity as to what these unintended consequences can look like. The previous panel, as I said, has touched on a couple of areas. And this one, we're going to try and avoid the duplication. So I think, Martin, I think you mentioned the CRA. I think the audience would be interested to understand a bit more about what some of those concerns are. And again, noted there is going to be an event tomorrow of FOSDEM and multiple discussions within OFE and the network across Europe on what this means and how we can work together to improve it. Martin, that's you. Thank you, James. So yes, tomorrow at 11 o'clock on the main stage in FOSDEM, there will be a more detailed discussion about the CRA in particular, with the commission presenting and different stakeholders presenting their views, including Gijs on behalf of the European Commission Open Source Program Office. So what do we feel is particularly needs attention in the CRA? So the CRA basically tries to apply the CE marking to the space of software and hardware. And so it uses an existing piece of regulatory instrument to a new domain. And the commission was so good to put a exception for open source in a recital. However, the exception uses a very problematic qualifier, which, namely the word commercial. And it turns out that commercial is not actually a well-defined or a term that is very clear in the context of making software. And in particular, if you have a very broad interpretation of what it means to be commercial, then the exception has a very narrow basis for exclusion. And to make this more specific about NLNet Labs and the public benefit we do work on on internet infrastructure, one of the examples that qualifies for commercial activity is technical support services. And that is basically what we have relied on for two decades to exist. Because we make software and protocols. We give them away for free. We do our utmost best to make them resilient. And I think we, together with the whole DNS community, have made a system that has been super resilient for 30 years. But the 15 people doing this work need to pay their mortgage. So money has to come somewhere. And the way we've found is to actually find network operators willing to pay for support services. And what is problematic specifically about commercial to qualify is the essential truth that development and maintenance of open source and its cost is independent of the commercial benefit that arises from its deployment. And that is why it's very hard to define an exception that works. So I really do believe that the goal that the CRA is aiming for that is driving down the number of vulnerabilities in software is worth achieving. As a citizen, I really want to be able to rely on the solar panels in my home, the heating system to actually have some meaningful security in there. But I think the method that the CRA is currently including may not actually achieve that goal. And I think that is important with the rising importance of open source. So that's on the CRA. If you want to hear more, please come to FOSDEM or watch it back. Very good. Thank you. It's tempting to go into a bit more detail on CRA whilst people are here. But I would just add as a co-panelist the importance of squaring away components out of the scope of this proposal. I think what the lens that's been applied is very much a tangible product approach, something which you can drop on the floor and hear break and smash into millions of pieces. The fungibility of software is incredibly different. The supply chain is incredibly complex, let alone being open source. So I think this is the start of a long discussion. And again, initial contact with regulators has been actually very receptive. And it's quite humbling to see that, OK, we need to fix this. So I don't think it's a need to cry out that the sky is falling. But certainly we do need to act together to fix this and do this quickly and effectively before it goes into this rather protracted and heavy process, which we all know. And I was going to say in love. But maybe that's another statement. So Simon, talking about love, tell us a bit more about your love of IP and perhaps where there's a disconnect sometimes, because thanks. Well, there's been previous examples of things that have gone wrong. This isn't our first rodeo. So the first time that I spent a lot of time in Brussels was in 2005 around the Software Patent Directive, which was in the era of we didn't know that open source even existed for legislators. And then the next time around the loop was for the copyright directive, or the revision of the copyright directive, which was in the category of, well, we kind of know software exists, but we don't know who the stakeholders are. And it turned out that the stakeholders were significant enough to make people really worried in the European Parliament around the copyright directive. One of the hidden aspects of this is that within Europe we have a great deal of respect for Europe's industrial sector. And Europe's industrial sector is heavily anchored in what are described as open standards. I have to clarify for you that open standards, in the phrase open standards, the word open is used differently to the word open in open source. In open standards, the word open means that everyone is entitled to participate in the process, whereas in open source, the word open means that the final work product can be used freely by anyone for any purpose. And misunderstanding those two opens leads to people making ridiculous statements from stages like this about how open source and open standards are almost the same thing. But they're not. And there is a big sector of European industry which doesn't rely on a process, such as Red Hat users, to create wealth. We heard earlier from Andrew Katz, who was talking about how you have a permissionless environment and you create wealth via mechanisms that draw people together around standards. Well, there's a whole load of standards in Europe where the companies involved monetize the friction. And they're very worried that their ability to monetize that friction is going to go away as they see that everything in the world is turning from things that break when you drop them on the floor to things that live on a USB key. And those companies are stepping into the void I mentioned in the first section where there is no one to speak up for open source. And they're claiming that they are representatives of open source, that they have a big commitment to it in their company. There are some Scandinavian telecoms companies that do this, for example. And the result of that is we often discover that legislators have heard that open source is somehow about violating people's patent rights, that it is in some way anti-competitive, that it is wrong to have reciprocal rights. And so when we come to see the legislation, we discover this has already been whispered. The place we need to be is actually not in the train waiting room. We need to be in the first class carriage where these conversations are taking place between the special relationship consumer electronics companies of Europe who have got a special regard towards their monetization of patents and standards. And help people understand that more wealth is going to be created in Europe through open collaboration and the sharing of resources and through interoperability than is going to be created in the future through monetizing the friction of patents within standards. I think that's where we keep on finding in each act as it comes along. Someone has whispered sophistry into the ears of policy writers. And it's about time we stepped in and whispered some truth to them, I think. Thank you, son. Again, I don't want to flog this analogy of the train. But I think this open rail opportunity we see in front of us, the whole opportunity, which is once a lifetime digitally transforming our rolling stock across Europe, it will be telling if that doesn't have a strong open source component to it. If it doesn't, then I think we've missed the train. The other way I want to go to now, Deb, is yes, a carriage just for ospos. Let's talk about that. Buffet cart. The importance of using ospos in some way as a kind of window for policymakers into open source. But also, I think the proof is in the eating, I'm looking at the case there, the experience of civil servants who then start to contribute upstream, start to collaborate with communities, start to build product, start to abstract away the sort of vendor ecosystem is really powerful. I think it is a big step in understanding open source and that reflected in better policy making. So, Deb, maybe some thoughts from your side on this, but a positive swirl on this discussion. Thanks. Well, thank you. And I can always count on James to pop a surprise question. But I understand the way the question comes. So I spent eight years of my career running the open source program office for Red Hat. But I'd also worked at a university where we built a lab. And I'm also a government practitioner because I served as a deputy state CIO for a state in the US. And it was really struck a few years ago when the commission included the notion of creating funding and a construct for create open source program offices. I asked if they couldn't consider making that multi-industry, multi-stakeholder, not just government offices. Because there's really two things. One is I've described a concern I have about the lack of understanding of stakeholders. It's something that's really critical in the open source ecosystem. It's complex, but it's not enough to say you don't understand us. I think there's an important role for open source program offices in any sector to be able to serve as a convener and a surveyor and an identifier of who the stakeholders are in any regulation, regulatory body, or any policy that's created. So that's an important component. But I also think in support of upcoming adjacent areas that are going to be critical and may impact the open source ecosystem, AI data. These concepts are closely related. And open source program offices should also serve in a multi-industry construct to be able to find ways to find stakeholders that can help inform in that respect and also in a positive way to be able to create the kind of synergy and collaboration across industries that really becomes important in actually implementing and seeing a vision of collaboration actually come true. So I hope that continues to grow as a standard here and that you to have that kind of collaboration between open source program offices. These do not have to be a huge staffing concerns. This is really just saying we're resourcing an idea. We're resourcing a function and we're giving them a charter and an ear and we're going to rely on them to help us identify who the stakeholders are in any of these regulatory conversations. Thank you. I think this adage don't waste a good crisis is apt here. To the extent that there's significant amounts of funding in the recovery resilience packages across the union and that slide earlier on about the growth of OSPOS. I mean it's just the start of something quite special. So any governments listening out there you know where to put some of that money at least. So we're going to move to the third and final part of this panel, the under bun if you like. And also if we have some time for Q and A we'd love to hear from you guys as to some of the course correction that we could consider and how we can constructively and fruitfully engage on mitigating these frustrations that we've been talking about. So Deb, how can we better explain the life cycle the ecosystem of this global commons? I mean some of those insights you have from your past and also now at Eclipse in terms of using these tangible examples in the Eclipse Foundation in OSPOS across the public sector so better educate, better engage policymakers or is the audience too different? Are we not getting to the people in the first class carriage? No, I think we're quite behind in rising to this challenge. I think most of the conversations I've had in the last 48 hours since I've been in Brussels have been around what we can do to protectively respond. So Eclipse Foundation is a Belgium based foundation and our response was to immediately think about writing a case study to try to describe in more concrete terms rather than in the abstract. Concerns around where does liability fall? How do you define what a supplier is? If a software foundation is distributing software, is it really, should it really be accountable and liable down the chain and is the example for the CRI? So our instinct was to actually write a case study and explain in more concrete terms how the legislation would actually impact. I think we need more of that. We need to find 10 organizations that can describe in more concrete terms what proposed legislation might impact in the context of what their ecosystem looks like, who their stakeholders look like and then more generally we do need to move quickly to create better education. So we do need to write more. I have the privilege of being on an IEEE special edition guest panel for an edition on open source in the public sector and we were to reflect a comment and earlier panelists mentioned, we were quite surprised that we didn't have more contributions. I think governments have been shy to share their experience good or bad on implementation. So we need more, we need people to write more, we need more case studies and I also think we may need to consider doing something as simple as creating a video to describe the complex but important open source ecosystem. Who are the stakeholders? How does actually software development for open source happen? Who are the developers? Who are the suppliers? Who are the large corporations that are benefiting from it? Where does the money flow? How should we consider who's accountable and who's contributing and then of course that shouldn't form where investments might be made and I think we're going to have to do more concrete educational material and we're just at the beginning of that process. Again, we're at the caboose and we need to plow through the training, get to the front but I'm certainly looking forward for any ideas, Eclipse is very committed to help contributing to or help leading any of those kinds of efforts. Great, thank you Deborah. Now just a quick time check, I think we've got about 10 minutes left and then there's lunch. So I think we're going to have a slide or slides and I appreciate we're under time constraints so maybe Simon can touch on them. No, no, they're all here, I'm going to speak to them. We don't need to spill the book. Okay, fine. You had them panicking at the back there. Just seeing that you're awake, well done. Okay, so a few minutes on that and then Martin I've got a couple of questions for you to close us out, thanks. So in putting together OSI's response to the CRA, we focus very much on correcting one specific problem rather than trying to look at the whole bill and in the process of doing that, I realized that many of the issues we've had with previous legislation fall into a fairly reasonable taxonomy and so they appear to relate to four things to the identity of the stakeholders and misidentifying who the stakeholders of open source are. Secondly, in misunderstanding the motivations of the participants in open source projects. Thirdly, in understanding which mechanisms for compliance might be applicable and fourthly, to understanding what the path to sustainability for a project is and in each of those categories you can see that there are fairly straightforward lessons that we could take forward to policy advisors to help them to understand not how to favor particular business models, but how to frame legislation so that it has the intended consequences rather than unintended consequences. So I'm gradually working through all of that to produce a paper on those four areas in the taxonomy to give you a flavor for the things that fall under those categories. Under stakeholders, I think it's very important to understand that civil society voices are key even though you may perceive that it is an industrial matter and in particular, voices from that fourth mode are extremely important and it's very important to realize that the voices from the fourth mode have no representatives here in Brussels. The representatives of the other three modes they've got offices all over this area but the fourth mode has no office here and so legislators need to go out of their way to identify and consult with the voices of that fourth mode. Under who participants are in open source communities, people misunderstand the word volunteer, an open source project that is operating within say the Apache Software Foundation, everybody who participates is a volunteer in their relationship with the Apache Software Foundation but almost everyone who participates is actually the employee of a beneficiary company in their relationship with their employer and so when you use language which talks about volunteers or which talks about financial benefit, you'll almost certainly get it wrong. You need to use other language that talks about the putting of the software into deployment for trade, for example, rather than in terms of the commercial use of the software itself. It's very important to focus on the liberties to produce and collaborate. It's easy for people to be drawn into thinking about money the whole time and the result of us having used the word free about software for so long is people come onto the stage and they come here to talk about how it's cheaper, how the total cost of ownership is lower but the reason that governments want interoperability isn't to save money, it's to make the government succeed. It's to let the citizens be free, it's to allow them to put into place the sanctions that will end Russia's uncalled for attack on Ukraine. Those are the objectives, they're not about the aspects of the price of the software and so it's good for legislators to focus on the liberties that produce the outcomes rather than to focus on the price. It's very important also to note that the participants in software, their geographical location is not relevant. Every project I know has contributors from embargoed countries. Every project I know has contributors from at least three continents and so treating digital sovereignty as a matter of drawing a European border around software is a profound and fundamental mistake and should not be made. Then in terms of compliance, it's very important not to allow people to try and define open source afresh. Open source is a term of art that is globally understood and it results in the applicability of liberties to the way that you produce software. It's important also to note that open source software remains a social byproduct until it's deployed in commerce and consequently it's the deployment in commerce that needs law applied to it. And then it's very important that software that is going to implement standards, the standards have their embedded patents on a royalty waived basis. Not to say that people can't monetize patents in markets where that's appropriate but to say that if you want the collaboration you have to leave your guns at the door. So I'm working on a paper that looks at those things and some more things as well and maybe we'll bring that back to IFE or to some meetings at the commission at some point. That's music to our ears and we'd love to see more of that as you say. You have a draft, is it something which you want to sharing it more input from? It's just a little early for that. It's eight slides so you're very lucky to get in under half an hour just then. Yeah, well done. Covered a lot of territory. So in the final five minutes and Paolo if we do have time for some... Oh, okay. Then the developer in the room. Tell us more about how you see this in terms of being better understood and how you can manage your day job which is development as opposed to your night job which is lobbying. So I suppose it's quite difficult to make comments after Simon has just given this pretty elaborate analysis of the factors that I actually mostly agree with. So I think I want to talk about one aspect that is I think important within at least the CRA which is the aspect of putting a fence around Europe or balkanisation. I think it's a very... A topic that is on the minds of people in the space of internet. The question of whether it's a global network or not. And I think specifically with respect to the CRA what is important is that we don't end up in a situation where the makers of this network such as us are somehow... Our work product is made inaccessible outside of Europe or the other way around. But if you, for example, put an obligation to report incidents on us as a software maker relating to third-party use of our software, then we get into a position where we're conflicted between sharing information that we receive from the user of our software about what happened and our role to remediate any vulnerabilities that underlie the incident. And this relates to the balkanisation thing because surely Europe will not be the only government which requires us to do incident reporting. So, and someone else mentioned an example where if you place heavy... Heavy... ...compliance load on people writing software, then they will spend less time on the software. And I think that really resonated with us because I work at an organisation with 15 people, 15 of... 14 of which are either researcher or developer. So we don't have legal, we don't have compliance and we would be very incompetent in trying to prove that we do the right thing yet we have been doing it for two decades and somehow we still have working DNS sometimes. So I would really like to help in the coming months to kind of keep the policy goals of the commission and at the same time not suffer some of these unintended consequences. And if you have a means to help in this regard I would very much welcome them. And then I'll look at James to see if we... if I need to cover any other aspects of the question you just asked. Well, I think we're going to torture you tomorrow at Fastem with lots more questions. I'm going to go a lot more in detail about CRA but also other regulatory initiatives. We're doing rather well. I would love to open up. If there's anybody has a short question, then be my guest. You're obviously very hungry. Yes. So very good. Well then I'll close out by thanking this wonderful panel. In a very short time we've covered a lot of territory. You can clap in a second and throw gladioli. It would be great. So thank you. Thank you panel. Cheers. Thank you.