So hello everyone and welcome to our next session and the title of the session is Going open and a bracket source. So going open source in test and measurement the future of TNA TNM Automation with open tap. So, um, yeah, I'm very honored to have Brandon de Renzo and Jeff driller here at the session And I would like to introduce our speakers. So hello guys And where are you at the moment? 11 p.m. Saturday night here in California, so it's it's 11 p.m. Somewhere somewhere for beer and I guess that's where I am nice I'm in Colorado. So it's Sunday morning for me now 12 12 30 a.m. Okay, excellent. So I would like to introduce you before and we can hear about Your insights. So Brandon de Renzo is a software application engineer at Keysight technology and Brennan you started your career as an intern at Agilent technologies, which is now Keysight technologies and that was back in 2012 so you're serving in various roles in the test and measurement space over your career and Brennan is currently the automation product manager focusing on both Keysight's commercial automation tools Which is called the path wave test automation as well as the open source test sequencer open tap and the associated community and ecosystem The open tap project is the first known open source projects stewarded by Keysight Agilent ULT Packard in in the 10 lineage TNM lineage and Brennan graduated from University of Colorado with a bachelor in science and electrical computer and energy engineering With a minor in computer science and yeah, still living in Colorado And that's where you are today. And you enjoy hiking camping and fishing with his wife and doc very nice Thank you very much for joining us and then we have jeff driller and jeff is a business development and planning responsible software is responsible for software programs and at Keysight technologies as well And jeff has been with Keysight and former Agilent for over 15 years focusing in a number of different roles on test and measurement And yeah, he is a director of Keysight software acceleration team focused on enabling customers and internal business units with valuable software infrastructure in the spaces of automation and here open tap and of course also in cloud and analytics And so these topics are all connected in addition jeff Sorry in addition jeff Overseas the commercial automation program planning and business activities And he was part of the team that took open tap to open source in 2019 the first known open source project as we heard already here by Keysight And jeff is passionate about both open source as well as inner source software And has been an advocate of both internal and external to Keysight jeff graduated with an mse e and then b s e focusing on computer architecture and robotics From the university of southern california where he also played for their a c h D2 ice hockey team. He's currently based in santa clara california Jeff i'm sorry. I don't always know the abbreviations Because i'm not a natus speaker But and like I was thinking but then there was no time to actually check with you and what does it mean ms E is it like master of science and electrical engineering? I was thinking but I wasn't sure and and what is a c h a d2 I saw pt. What does it do? What is these abbreviations stand for? So i'm a subway as you as you got it is a master's of science and electrical engineering inside it both my degrees at usc And I I happen to be a lifelong ice hockey player and got to play through university I actually then coached the team and i'm still general managing it in my spare time. So lifelong hockey pan a c h a is the american collegiate club hockey association So it's uh, it's not the nc AA level. It's it's it's one below that Okay, thank you very much for cleaning that up and now we can get into the topic and I will hand over to you And thank you very much for joining us Excellent. Well, uh, thanks. Thank you Thank you mario and and and thanks everyone for for attending today I'm we were really looking forward to the potential of doing the face to face And so we have a large contingent of our team in singapore And in uh in the future we'll be looking forward to the next ones where we actually are there But today we're just going to talk a little bit about the the transformation that we've gone through And and as the title says going going open source in Testive measurement automation with our open tap project and as you've heard now twice in the in the intro bios It's uh, it it's the first known open source project that we're aware of in the entire test of measurement lineage of Hb through Agilent all the way into uh into key site and and i'll explain what that means if you're not really familiar with the Testive measurement industry. Um, obviously it being our first project Probably not as much awareness in this space. Although the for the ps lab crew. I think you're you're going to find some really interesting stuff in here For those who have heard ps lab There's there's a session that we have following that you should definitely stick around for showing the two working together So as uh, as as mentioned brennan and I are really passionate about the project on the community evangelism side awareness building That's that's really what we're trying to push here and get more visibility to the project itself And again, we we have a vibrant and growing Tech community around this in testing measurement and look forward to more people joining It's one of you to the next slide there brennan So a little bit of history. So if you're not familiar, many of you have probably heard the name to Packard or HP obviously but sometimes people haven't Realized or understood that the original HP Hewlett Packard back in 1939 founded in the garage on Addison Avenue in Palo Alto It was really a tested measurement company And and that is effectively known as the birthplace of silicon valley If you visit us today in in the region, you can still drive over to Palo Alto There's a nice plaque outside over on Addison Avenue in front of the garage, which still stands to this day So it's a very cool Historical aspect of technology in general around the world Spark of inspiration from from Bill and a and so for for many many years definitely Very much in a leadership position in the test measurement space. It evolved and in 1999 The the TNM arm actually was spun off from from HP or Hewlett Packard Into what it was then known as Agilent technologies and over the years Agilent and that's at the time when I joined and brennan as well um at Over the years we would acquire other companies Including life sciences and then it was determined in 2014 to spin off once again And and we formed as Keysight. So we keep getting punted out I don't know why that keeps happening, but it's okay. We're we're we're doing very well right now And it's it's again a pleasure to be kind of in the leadership position and fully focused on the test and measurement market No distractions Outside of TNM like life sciences or chemical analysis. Those are good businesses as well But but we're really focused directly on the test measurement market And in in 2019 we continue to celebrate that that's 80 years now of leadership in the test measurement space So we've been around for a while as a company our dna is is long and deep and Why is that important? Well, um as we go to the next slide here brennan In 80 years as you've heard before We've never launched an open source project And so i'm going to walk you through a little bit of the journey of open tap And how that came about Um and and brennan's going to take it on and show you where it's going And again, we're we're just trying to really reach out to the the vibrant open source communities around us We've been at fos them now a couple times First time at fos asia And and we're seeing some really good opportunities for connection and collaboration And so back in 2011 We had lots of internal needs and this will come up again as to why we're doing this. What problem are we trying to solve? We had lots of internal needs for for test automation This is a core part of our Various businesses and the business I happen to be in was the wireless business And and we have a very cutting edge software research team located in northern dead market in a city called all board And asked them to do a little bit of a project See if they could optimize and simplify And and and really make it very scalable to do automation in in the wireless market segment specifically And that that's market segment is testing handset So going back to bunny's presentation just a few minutes ago Testing those kind of devices as they roll off the production line during the rf calibration and our verification And so As we progressed forward we continued to use it with more and more chipset vendors We created a whole program around it called our silica better program And and we were really engaged in kind of a very narrow slice as we transformed in the key site in 2014 That really took off We we had a summit that actually sitting before And at our site there and and we decided you know This was going to be the automation core for the rest of keyset for the rest of the company Again as keyset spun out of Agilent really focused in on testing measurement It was really decided we needed to transform from being a hardware-centric Company toward a a software-centric solutions company And and tap at the time was very much a piece of helping create many unique and cool and valuable solutions to our customers And so we continued to push that forward and and ultimately through kind of a Big meeting in a board room battle royale of different options We ultimately came about to decide on tapping the platform going forward. So 2016 we launched it as a commercial product um started getting a lot of traction With customers because we had already been using it for many years and kind of in bespoke commercial deals and then Like into the the 2016 Later era we got a unique question. Um, we got a unique question from nokia. Um, many of you know them as the handset vendor That's really no longer. Um, I think maybe they license it out and so exist But but the true essence the original nokia the handset team is no more But the base station team is a market leader In in network infrastructure And that team had a lot of pedigree and dna and history from both automation Factory production, but really also open source. Um, nokia is definitely known As being very pro open source and and driving certain communities forward And so, uh, they pushed us and they pushed us to take tap at the time open source And our first question was uh, as you would expect a big company. It's four billion In in in revenue and and like 20 000 people Everybody's going to say wait, you're crazy. You're you're giving away your valuable ip and software for free And that's what we thought honestly. So, uh, it was a scary moment for us when our Customer at the time asked us hey, give us all your stuff. Uh open and we really didn't know what that We didn't know what that meant. Um, so we went we went back and we started asking questions reaching out Connected in with the linux forum. Um, try to learn as much as we could about open source and and the ways and the models that a commercial company could be engaged in it successfully and continue to invest um and and attended the uh linux foundation open source leadership summit Met a lot of great contacts and and really started thinking wow, there there is an opportunity here You know the core the core sequencer that we're talking about so much here and you'll see in the architecture It's it's it's valuable But it is commodity in a way And we checked internally and and we had uh 15 years before our own manufacturing team One manufacturing team in one company had uh tens multiples of tens of various sequencers in in one production center and and how does that come about? Well, it comes about because everybody creates their own There's not invented here There's the fact that sequencers are quite simple when you start and so somebody can create one over the course of a weekend Uh, a really good programmer can uh, or maybe even not a good programmer And so as as these proliferate, uh and teams don't talk Then then then this causes such a problem and it wasn't just our problem But we saw this in every one of our customers and and and and uh community members and engage parties around the world So, uh, we we realized that there was a problem here And even one inside our own company and so continued forward Worked with nokia to understand really what what value we could provide them And ultimately decided that yes, we would take this forward On that journey there in 2017 they brought us into the intersource commons event Actually, they hosted a naperville, uh, illinois at one of the nokia original bell lab sites And and really continued on that journey of driving things forward Even understanding the term intersource, which we just thought meant sharing code internally Be inside open source and and that was just a thing everybody did Turns out nobody was doing that in our company. Everything was siloed People were hiding their code and and not sharing it and innovation was stifled And when we started doing that the traction just picked up by orders of magnitude inside Keysight at the time and we realized wow, there's there's real power and potential here We can provide our own unique value in other ways But let's let's take this forward and let's open this up. So in 2019 we took it open source That was a scary and exciting moment all at the same time It takes a lot of convincing again in a commercial company of our size that that hasn't done this before But we started gaining momentum People started seeing the value and even some of our executives started coming in from outside companies that had experience in open source And that paves a lot of the way for you that really does help And so we were at foster in 2020 later in 2020 we launched a forum Which was one of the mistakes. I'll I'll say that that we we didn't do it sooner You're always going to learn things and we're still learning things today That was the way to engage the community And if you're interested, please join and engage us. That's where you see the activity now But but that was something that we just launched back in december and it's really starting to move forward And then obviously We're we're here today at posseja and there's much more to come Brennan. We'll talk about that shortly But just really quickly to cue him up kind of what What were the things driving us to get here? What were the trends that we were seeing in the industry and and I'll I'll highlight on three And if you're familiar with tm, you'll probably agree with these There's probably more but these are the big ones that are driving us these days So one is as I said before we're seeing lots of internal tools perforate and just drag teams down Slow them down to a crawl in their ability to innovate. They really want to create Value to their companies whether they're a A big commercial company whether they are a small startup where they're a hobbyist People don't want to create the commodity and uh, it's uh What we found is that when you do that Then then it just drags you down like a boat anchor because you've got to support it If you're in a big company, you've got to maintain it You got to add basic features and capability that everybody else already has So there's no value in that so in the automation space We really see open tap as being the the core that everybody can use and leverage going forward Whether it's a key site or even when a key sets competitors, whether it's a hobbyist Whether it's a small startup company There's really no need in the tm space to create your own automation anymore If it was commercial that would be a problem And that was a driving factor behind us deciding to open source That core up and and just put in it out there and we want the community to use it and leverage it The other trend we're seeing or the second one we're seeing is being open and extensible From the core tap was very Scalable so open tap by default is going to be scalable Just what you need not taking the whole kitchen sink basically and shoving it down everybody's throat But really allowing people to take the modules that they need and orchestrate them in a way Being our team is from Denmark. We always like to think of the the lego metaphor And we will continue to use that To to date on the openness side again As we mentioned And so Jeff Just unmuted there Let me know if you can hear me again Mario Yes, sorry. There was a background noise. So we had to mute everyone and yeah, please go ahead. Thank you very much. No worries. So again Scalable and and extensible but also again open and and that's not just the open source in the core But the fact that the apis are documented and open and and everybody can use and access them So they can build unique value around they could choose where licensed under an mpl v2 license So people can choose if they want to Open their plugins or or peripheral code or not We're not going to infect people with the gpl Just because in in an industry like the testing measurement industry You're going to find a lot of players would be really nervous with that a lot of ip lawyers Would would kind of shut that down pretty quickly including our own if we were ever taking it So we want both commercial and non commercial entities to utilize the same capability. So that was the reason behind that Finally on the hardware differentiation front and obviously we will continue to differentiate our own commercial hardware For its value and and its uniqueness again with our dna and lineage From from the hp days And that will continue but hardware will always get squeezed for margin from a commercial perspective And and we're seeing software continue to differentiate right now. We're talking about automation We're also seeing different areas on the cloud fronts, etc Where anybody can really create a lot of new value and and and that's that's again something We're really starting to transform and shift our company toward that software centricity So this was really well aligned with that and with the markets going in that direction So that's kind of the back story. That's how we got to this point again That sounded really really easy, right? We just decided we wanted to go open source and and everybody supported us. We just did it Obviously not the case and if anybody's trying to go open source. I mean, we're fresh kind of across that threshold People like everybody at fos asia like at fos dam like at the open source Leadership summit they helped support us and give us the inspiration and the confidence to move forward And we're happy to continue to pass that on to the open source and inner source communities So if you're at that stage and you feel like your situations similar to ours Please let us know we'd be happy to share our experience and best practices and continue to have Engagement and I think I was looking at bunny's profile while he was Doing his q&a there because I have not met him or interfaced with him But it seems like our paths could have an interesting intersection I think it says don't contact me on linkedin come have a beer. So With that I'll say come have a beer with us sometime We are open to happen and I'll hand over to brennan to show you what's in store for the future here Yeah, so so jeff kind of took us through, you know our history and and how we got here and and now I'll talk a little bit about what what we're kind of doing today and and where we're looking to go moving forward And and with that one of the the big things that we're looking at is You know, ultimately what are what are the challenges that we're that we're trying to solve here jeff kind of talked about some of the The trends that we're seeing but but fundamentally when we're when we're talking to customers and our end users You know, whether it's in the the pure kind of open source purest community Or if it's in more of our sort of commercial traditional space of things What is it that they're trying to achieve? That they're ultimately open tap is trying to help them with and really I think it comes down to three main pieces One of them is is time to market, right? That's that's always something that that people are worried about There's there's always a push to release faster to release sooner There's always going to be issues that occur and things that they run into and so That anything that they that we can do to help them With that is ultimately going to be beneficial and so As we look at the the different areas when they're coming to us time to market is is probably the the major major focus that they ultimately push on us and in kind of within that You know, especially looking at a sequencer In general from an open type sense that the question that we always get is around performance and test feed, right? And that's that's something that we we really Put a lot of focus in we even though this is an open source Component it it can't sacrifice on performance ultimately We it has to be just as good as a commercial tool or or other Internally developed tools that's how we're we're going to replace those ultimately we can't be You know just having something that's free and open source and thinking that's good enough It ultimately has to have the performance around it as well for people to to truly use it because Ultimately they have a job that they they need to accomplish And it's they can't just you know mess with something Early that's not really ready. It needs it needs to be ready for full production. This is used in you know Large manufacturing lines in all different industries of the world and and it needs to have that that overall test performance to be there And then another major issue that we that always comes up is you know We're we're talking about companies that have existed for many years within key set as Jeff mentioned you know, we have a 80 year history of Of writing tests and and developing products and and many of our customers have that history as well, right? and so They they don't have the ability to throw everything out and start over they they need to be able to integrate with existing stuff Integrating with new technologies coming in the future And not be kind of forced into a strict model of everything. They can't Um, you know throw everything away and start over and build on our platform They need to be able to leverage what they have and integrate with our platform to be able to Ultimately provide them the benefits that they need And so how did we accomplish that ultimately and what is it that we're kind of delivering? Um, this is just a high level overview of things in about an hour after this. There's a deeper dive technical tutorial that we have Um, that will really get you Um, a deeper understanding of developing on the platform and how it what it looks like and how to build everything out But this is just kind of high level overview of things And basically, um, what we have is as at the bottom here is the open tap sequencer engine And this is the kind of open source piece that we ultimately have created And then we have this plug-in architecture around everything and this is kind of a combination of Things that get created by Keysight things that get created by our customers our partners I'm going to get built out to create an overall solution. And so there's a couple main components within that One is what we call depth plugins, which is basically the the device that you're testing So you'll create a plug-in to be able to interface to that device, whether it's no common interface ssh Um, gcp, whatever happens to be as long as there's an api for it. Ultimately, we can connect to it And then you have what we call instrument plugins and basically this is sort of You know Keysight specialty, right? This is the the test equipment that you're going to be controlling the measurement equipment That you're going to be controlling the measurement equipment, whether it's Power supplies or signal analyzers and signal generators network analyzers, whatever happens to be again anything with An api we can ultimately have a plug-in for and this is kind of where Keysight has a lot of their focuses creating these plugins that um bridge the gap between the sequencer and then the the physical equipment that we sell ultimately And then kind of one of the other fundamental pieces is what we call a result listener This is basically what is in charge of handling the data. So as you're running tests, this will parse the data filter it Format it write it to a database send it to a csv file Anything ultimately any data format any type of data storage you can create a result listener for to handle the data Then kind of building up from there you create what we call test steps So basically these are your kind of test functions the specific measurements that you're doing You know putting the device in particular state calling a measurement on instrument kind of bundles that larger communication With settings that an end user would potentially pass in to do specific functions And then kind of the next step up from there. So we call a test plan This is basically a sequence of your of your test steps So you can have kind of just a flat sequence of multiple steps you can do sweeping you can do conditional branching you can do You know if statements different types of things to kind of sequence through all of your steps in the full kind of automated Way basically that's ultimately what we're trying to do here, right is is actually automate all of our test sequences Versus kind of the manual state of things And then kind of the the top level ultimately is a user interface We have what we call the the editor which there is a free Community edition for and then also a commercial version that the keysight sells But an end user could also build a custom user interface on top of this because again open tap is completely open source The platform can easily be extended for these lower level plugins But also the the higher level interfaces as well So this is kind of the the solution ultimately that we see people building and and Why if we've kind of had a lot of success with this model Is that because of the the plug-in architecture? It allows for one to have a common platform That's really one of the bigger issues that we've seen right is that As Jeff mentioned even within keysight we had 10 20 Different sequencers that were created none of them work together none of the teams Worked together none of them talked to each other So there is a lot of replication and duplication that was that was getting created And and that's even exponential outside of our company right that no one's talking to each other Everyone's doing the same thing over and over again And so this really provides that standardized platform and then we can Add the value on top of it by you know being able to leverage You know instrument plugins different result listeners different types of steps Ultimately the devices that are being tested are going to be kind of custom and proprietary to Do whoever's running those tests, but they can they can grab an existing instrument plug-in that knows nothing about their device And still be able to interface all of them So the architecture is really the the big piece of everything that'll that allows this to tile together And so if you're interested and hopefully you are in about an hour We'll have a couple other people from our team and actually some university students that will have a tutorial of building a a solution out and it's actually Using the the ps lab board if you're familiar with that and our open source python plugin Which is another interface that we have into the open tab sequencer So it'll be kind of a a full open source solution from the the software to hardware and so kind of now that we've Kind of achieved the the main just open sourcing Component of things we we don't feel like we're done right. There's there's more to it than than just Getting your lawyers to sign off saying it's okay to open source this you need to be able to do Multiple different things to ultimately truly be successful And so we're kind of focusing on growing in a couple main areas one of them is building the community. So we're doing that by sponsoring events like fascia and meeting new people and engaging with people We're creating a couple different things to help reach out to two people that may be interested Which is our newsletter our forum. We have different sets of youtube videos We have a new blog and news page. So there's a lot kind of going on that We'll be able to actively reach out to people versus just Giving them the code and hoping they can they can figure everything out And so that's kind of a big step that we're taking I posted the links in the chat For most of those things if you guys want to sign up, it would be great We we're not going to bombard you with stuff on the newsletter side of things. It's it's more or less a quarterly newsletter. So Hopefully it's at a good cadence where it's useful, but but not over overbearing and filling up your email box of things That the other kind of set of things that we're really working on is big building out our portfolio plugins So like we said that having the kind of standard platform is a big step But then ultimately what we need is kind of the common portfolio plugins that everyone can use and consume, right? So that a lot of those right now are coming from key site But our hope is to help build out that community where they're creating these plugins contributing them back We have um A few existing customers that have started contributing things back We're hoping to kind of streamline that process Make it even easier to do and then Ultimately that is really where we're going to see a lot of value We think where these kind of standard plugins can be used by everyone So you're not building everything from scratch every time And then the longer we go along this path the less and less you're actually building from scratch You're really focusing on adding your true innovation. You know everything that's specific to what you're trying to do not something that um Someone has already done, you know once or a hundred times before And kind of related to that the the other aspects that we're trying to build out is is our contributors as as I said Right now a lot of the actual contributors are from key site We have a few different companies That have signed our contributor license agreement um ps lab is Part of that as as of now and there's a few other ones. Nokia as Jeff was mentioning was kind of the major um Initial kind of big company. We have various other ones. They're all listed on our website And we're hoping to build that out as we as we move forward to really show the overall kind of benefit From not just key site, but to the the entire test measurement community And so with that, um, we these are kind of the the big things that we're hoping, you know We'll we'll help you guys and and us ultimately so we have our forum as we mentioned Um, this is where kind of all the engagement goes on for technical questions And anything else is is all posted on this forum. We have our newsletter that we just launched Um, so if you can sign up for that, um, you'll be able to kind of keep up to date with everything You won't have to go to you know reach out for what can we can tell you when uh When things are coming and provide updates and give you kind of an overall summary of what's happened over the last quarter essentially And then kind of the main landing page is at open tap.io. This is Where you can link to The forum the news the blog our our git lab page where all the code is hosted as long as well as the plugins themselves and so Um anything that you can do you can basically get to from the from the open tap page Then kind of the the last thing with all of this is I mentioned a few times but we have A tutorial coming up in about an hour that will do kind of a deeper technical dive on all of this So we gave you the high level overview of of why why we did this and kind of the journey But to kind of get your hands dirty and really see some of the stuff in action We have a live tutorial as well That's taking the open tap sequencer engine our python plugin and then the the ps lab board connecting all together Building out those instrument plugins the test steps the test plans that I was talking about in the architecture picture So hopefully you guys found this talk interesting enough that uh, you'll you'll join us again in an hour for for the next one Um, but yeah, I think that's ultimately All that we had so I think I'll open up for questions from there Okay, thank you very much and uh, yeah, I think people are also preparing already for your tutorial workshop and but there's one question here and from Um roland roland would you like to ask the question yourself? Yes, sure. So I've Just noticed you in the last two minutes. Actually, you know, you're cla But I wanted to understand you're thinking about including or carrying Drivers for competitors equipment in your code tree so for example Not so much that a competitor would do it. Although they might but if I is a the owner of a rigal Spectral analyzer or to develop a driver and send you a pull request Would you be inclined to accept it? Yeah, so I'll answer first and maybe I'll let just give some more detail because we've actually had some of this happen before But so part of it is ultimately things like that would be They wouldn't be in the core of open tap, right? They would be in a plug-in. So actually we wouldn't even be managing that so We don't really even have control of saying no actually. So if someone wanted to do it They they could they can contribute that plug-in and and even if we wanted to say no, we would not be able to But Sure, you control your own tree Well You by definition decide whether you accept it or you don't Yeah, so but but for something like controlling a specific device that actually doesn't end up in the open tap core That ends up in a plug-in, which is which is a separate component basically um So that so they're they actually all have their own individual repos ultimately and they're managed independently There's not there's not like a conglomerate of every possible thing. There's there's a core Repo for for open tap the sequencer engine and there's individual repositories for different plugins So whether that's for particular devices or particular instruments or or a collection of those that those are all separate actually We we we have a git lab page where we kind of collect everything Um and and kind of try to organize things and make it easy to find But they're actually in separate repos But I think more specifically to your question independent of the architecture That that's very much something that we would support and it's something that we we recognize is You know to really be ultimately our goal is to be a de facto standard in the industry and for that to happen we we need to support competitive products and you know Particularly within our industry. There's um from our companies that we work with they're generally Not only using keysight hardware to begin with so we have to be able to to support those That's a lot of the reason that companies will ultimately go You know and create their own Internal tools anyways because they feel like something coming from a commercial customer is going to lock them into To their their hardware, right and and we very intentionally have um an open structure that they wouldn't um Allow what it doesn't lock them in the the whole point is to take in They'd be able to connect to any device that they want it ultimately Yeah, I think I think brand you you kind of got to the crux of it is The core itself doesn't interface with the the hardware Etc. So that would be in a plugin. Those plugins can be created by anybody and has brand indicated That interface is documented and open and there's no way for us to prevent it But even if if there was we're fully supportive of people created plugins Actually, some of our customers have have actually created Competitive plugins as Brennan said they're they're not using a hundred percent key site And then they've open sourced those on to the the core Project repo. So there's different project spaces that people can go and create those Probably more valuable in the test and measurement industry I don't think as many people are going to be going hard into the source code itself But they would want to see on the plugins exist the binary form of that and And if you go to the open tap that I owe package repo, we'll be allowing anybody to load up As long as they acknowledge that they are the The authority and have copyright or permission to host those then then we can have them hosted and Put up onto the web page. So that's whether it's competitor obvious commercial company customer, whatever Anybody's free and welcome to to do so And I think those legal questions are never easy and yeah possibly A lot of questions and yeah, so the the question is always like Which contribution to accept and which not and what are the What's the process and how does it work? And I think there's also some time later on in after the tutorial And you will be around and also be able to Go to more detail than with the questions that people have. Yeah Yeah, and if if people still have continued questions, please feel free to take them to the forum on on open tap and Definitely happy to engage everybody continued on when it's not two in the morning in In colorado or three in the morning because it's daylight savings time this weekend actually I'm about to lose an hour But thank thank you guys for the the attention and the questions and again Really hope that you stick around for an hour for the ps lab integration demo that that's coming Okay, so Claps to you. Thank you very much for this presentation and I have to say it's a dream coming true. Yeah, because like how many years are we talking about this? all layers have to be free and open and Yeah, I mean we understand they're always like details And and questions about policies and about merging and about development and so on But I think the approach that you are taking is really exciting for a lot of people and yeah I'm really happy that we start to have a cooperation more closely also with the false asia community and with the pocket science lab project So thank you very much for joining us and we see more from open tap and You both of you in a little bit Thank you. Cheers. Thanks everybody


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.  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.  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.  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.  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.