 Thank you all for coming. We decided to slide the schedule a little bit just because of all the security measures downstairs. We hadn't expected to have a UN summit happening next door to our little event. So thank you all for coming. We hope that you're going to have a very interesting afternoon discussions now on this topic of the Cyber Resilience Act and also the digital policy in general that affects the free and open source software business ecosystem of Spain and of Europe and even the world. We have organised this jointly with the partners that you see before you. Myself, I'm from Open Forum Europe, we're a think tank based in Brussels and we try and work on the Brussels level EU legislation. So I will give a presentation on Cyber Resilience Act but we're organising this together with Red Hat to do group Learning Foundation Europe and Biturgia who all have their own angles of interest and you will get all these different points of view during the afternoon. I hope you're looking forward to as much as I am. Other than that I will mostly get straight into the content for the day and for that I will ask for my very basic slides to begin displaying on the screen. So the first half of the day is going to be about the Cyber Resilience Act or the first half of the afternoon. This has been a topic that has gotten a lot of attention over the last 12 months and it really got off to a little bit of a rocky start because we are used to having to deal with legislation but a lot of the time it's copyrights or it's patents and if we can go to different organisations we can say who's your copyright specialist but this is the first time I think that we've really had market regulation and so in that sense it was difficult to find all the right people but a very large coalition did form to work on this and so we work on this in particular from the angle of free and open source software. Now the Cyber Resilience Act is not about just free and open source software but we hope that there are other people in the software industry working on other parts and we focus mostly on the parts that are specific to our sector. So the general idea of the Cyber Resilience Act is that product safety should be that exists already for physical products should be expanded to include software and so this means that products have to be safe for the things they're going to be used for but also for things that you don't didn't expect people to use them for but you could imagine they're going to do. So for physical products this is a toy car for a child has to be safe for them to play with but they're going to put it in their mouth as well and even if you didn't intend them to put it in their mouth this is what it has to be safe for. So the way the Cyber Resilience Act is written it would work kind of fairly well for physical products and there's a lot of similarities between physical products and proprietary, non-free, closed source software. So normally you have a company and inside the company of all these different sub departments and units where they make different parts of the product and they pass the different parts around amongst themselves and then at some point they they put this product on the market and they get some income for doing this and so the Cyber Resilience Act comes in here to create obligations at the moment when the product is put on the market and so it's relatively simple for physical products and for proprietary software. Our software isn't developed within one company now we tend to have these entities that are out in the in the wild and the wild in legislative terms is called the EU market so everything that we do is happening on the market and we generally don't have a small number of contributors or we we aim to have a very large number of contributors and some of them are big and some of them are small. The issue for us then is what happens if we get new legislation which adds costs and obligations each time the software gets moved around among these different entities. So that's the the distribution aspect that's the complexity that we that makes our software different from proprietary software. There are other ways which I won't go into detail but on the supply side so that was the development side of the of the product on the supply side we we tend to have very frequent releases we don't wait until a certain number of features are ready and then do a big release we release early release often and this means that you're going to have more compliance procedures and we also have the same software being commercialized by a large number of companies and we encourage more and more companies to get involved commercializing software packages but of course this means that the more companies are doing commercial distribution the more compliance procedures are going to be carried out for the same piece of software. So one nice thing that is in the Cyber Resilience Act is that there is a paragraph at the start which explains that software is exempt is is not subject to the Cyber Resilience Act if it is free and open source software and if it is non-commercial. Now there are various different texts circulating and so different texts have different details I can't put all the different texts on one slide but that's the the initial plan was that free and open source software if it's non-commercial it's it's not out. The first issue we found then is how do you know if you're non-commercial and many people would assume that well if you're not selling the software but that's not what the word commercial means in EU legislation in EU legislation if you're making regular releases then you are like a commercial entity and then therefore you are commercial or if you're if your quality is very high then you are like a commercial entity and then you are commercial. So we have this flow chart for deciding if you are inside or outside the Cyber Resilience Act. This is maybe a third of the actual criteria that have to be looked at but this is the sort of thing that people would then have to go through when they're trying to decide whether this legislation applies to them or not. So until now the way we've always built our software was that we focused on having the lowest barriers to entry possible. We wanted everyone to be able to contribute their skills. If they're only good at being a user interface designer they can contribute that. If they're good at encryption they can contribute that. Nobody has to take responsibility for the whole thing and that's why our license as always says this comes with no warranty. It's to protect the developers to let them know they can contribute without creating an idea that they are a company that is responsible for this whole thing. People found it easier and cheaper than to contribute to the main project to contribute upstream because if they want to make changes to the software, if they don't contribute back to the original project then they have to maintain their modified versions, basically a fork. They have to maintain that separately and so our software grows in quality as we get more and more contributors because everyone finds it easier to contribute their software to the unified upstream project. So if we have then a cyber resilience act which creates obligations for people who distribute software or move software around then this is going to be the decision will be difficult for a company who's making a lot of money from a piece of software but a lot of our contributors are casual contributors. People who use the software in a company and they fix a bug, they add a feature and they send the software upstream and for them if they have to think about if they have to go to their boss and say can I get clearance to send this patch and then the boss says okay we'll check with the legal department, a lot of them will simply not be contributing anymore. We also have a lot of SMEs and at the start they're not profitable, that's the way SMEs start a lot of the time and they start off small, there wouldn't be a collaborative project, there would just be a few people. We have a lot of people in risk adverse sectors and in particular the public administrations. We've spent 20 years trying to get public administrations to join in in the development of free and open source software and in the last 10 years they've actually started and it would be a real shame if they then slowed down again simply because every time they're thinking about distributing software they have to think about do I have am I creating obligations for my government department and then there's also a lot of individuals and consultants who simply don't have legal staff to give them opinions and they would be nervous about contributing. So that's from the contributors side then the other issue is that from the project side whenever somebody does decide that they're going to contribute code upstream the projects will have to think well do I want to accept that code because once I accept that code I'm going to have to take responsibility for it and this is a problem if we want to grow our community by having more and more people contributing but this then creates more and more questions for the the maintainers of the project. So just to summarize some of the previous slides just for brainstorming for the discussion that will happen later we have to think about SMEs and anyone with a lean business model we have to think about how team building might become difficult we have to think about that people may stop distributing software and we may move more and more towards software as a service which means that in Europe we have even less control over our computing and we're often financing industries in other parts of the world instead of financing our own industries and finally if we make it difficult for development to happen in the EU it's possible that a lot of companies will continue their development in other parts of the world and they'll still send the the released versions to the EU and there would be cyber resilience act compliance but the we will lose expertise and we will no longer have as many developers in the EU which would be useful for doing security audits and addressing security issues. So right now the situation is that we've been looking at this for more or less 12 months we're in the trilog which is the the final stage now possibly the final two weeks the the text has been improved in quite a number of ways there's clarification now that people simply hosting code platforms and code hosts will be exempt there's a new idea that foundations would be referred to as stewards and they would no longer face the possibility of fines and I maybe I should mention that the minimum category of fines in the CRA is an up to five million euro category there is a an idea of a risk assessment which could allow some flexibility in deciding whether or not the the CRA's obligations apply but there's very little details on this so this is something we still have to work on in the coming days. The idea here is that the the CRA says that you cannot distribute software if it contains exploitable security vulnerabilities and of course there are many pieces of software that contain exploitable security vulnerabilities and we would like to continue to be able to distribute those pieces of software in the EU so the idea of a risk assessment could allow for that and the implementation which was originally planned to happen 24 months after the law was finalised it's now looking more likely to be 36 or or even 48. So there is quite a good bit of progress being made but there are still definitions and there are still parts of the text that rely on this concept of whether or not your software is commercial or whether you are commercial and these are often very unclear for software and for online services and then to be a foundation who would be a steward you have to make sure that your the money you're receiving is only covering costs and of course for a foundation they would generally aim to have a surplus at the end of the year and they would generally aim to be to be growing year by year to be able to take on more staff and including for dealing with things like cyber resilience act and so there are a lot of definitions like this that we're still working on even at the in these final days so that's what's happening right now in the in the legislative process we're trying to get these definitions done there's a very limited time because of the European elections in next June most piece of legislation are being finalised hopefully by the end of this year so that then people can focus on reelection campaigns and there's no clash between that the elections and legislation but once the cyber resilience act gets finalised we then have 44 obligations in the cyber resilience act and each one will be subject to a standards procedure so there's going to be a standard setting body which will give a definition or some clarity on what these obligations mean individually unfortunately free and open source software is not very well represented in these standards setting bodies and SMEs and innovators in general are also fairly weakly represented so we'll have to work on the standards and hope that we can improve our efficiency there businesses will have to adapt procedures and to comply with the CRA some businesses will find it easier to continue their business somewhere else so we will have to take into account that there will be some businesses who will no longer be contributing and then as a community we'll have to organise to try to develop ways to comply with the cyber resilience act in a collaborative way if we can centralise how this work is done and by doing that hopefully we can minimise the number of companies that do decide to leave the European Union for a less regulatory regime elsewhere. So we're glad to see there is a paragraph about free and open source software in the text on the other hand according to different studies and numbers 75% to 95% of software today is free and open source software so this is going to be the subject of a lot more market regulation in the coming years and we're going to have to think about the idea that regulation and procedures is a way that you can improve cybersecurity but our software with access to source code and the permission for anyone to audit it and to improve the security is also a way that we include increase the cybersecurity in the EU and so at the moment the CRA is focusing on regulation and procedures and we have to try and find a way to make regulation and procedures work hand in hand with making the use of the unique opportunities that our software provides and so we probably should expect regulation in the future that will focus hopefully on part two of those two criteria. I had a sentence at the end by moving up the topic just to make sure nobody is going to miss it at the very bottom. What we really need is as many commercial companies as possible taking an interest in free and open source software because this is how we improve our security the more contributors we have the more review and the higher the quality of the software so we have to think about how to preserve the number of contributors we have and encourage more companies to get involved. So to summarise what will be discussed on the panel the problems created are that one is developers will be nervous about putting software online projects may be nervous about accepting contributions projects may have less interest in starting a business and this would be really unfortunate because starting a business is one of the best ways to increase the quality of your software and then projects might also be unwilling to accept financing which would again be a pity if we had a way to finance the development of our software and we had to people felt the obligation to refuse because they don't want to lose the non-commercial categories that they're in. So we're we're still working on terminology and there is a text circulating which creates a lighter regime for the foundations which I mentioned as would then be called stewards it does this by defining these entities working on projects that are fully decentralized or collaborative and so we have to think about what these words mean because that's it's not defined too clearly in the text the text mentions the idea of having a single company exercising control and we also have to think well what does this mean and you know for us having a release manager is a sign of the quality of project but would this then cause a project to not be collaborative if there is a company employees the release manager so I hope all that looks solvable there are a few more issues that I didn't mention there are stricter categories for critical products which include things like web browsers and they may have to register with national authorities when you're developing these projects there are issues for component third-party components and due diligence there's discussion of an exemption for the public sector which could be good or could be bad or may may not work but I'll let somebody else delve into that support term the the cyber resilience act requires that you provide security updates for for five years and so this this number is up for discussion and that may change and then the last topic is responsible reporting of vulnerabilities this has gotten a lot of interest from national governments to the so much so that they want to work mostly on it themselves now but this is also something that we could improve by coming up with with proposals for how we plan to do responsible reporting of vulnerabilities in a coordinated way with that I hope I haven't started off on too negative a note the purpose of the presentation was to set the stage for other people who will hopefully have some solutions and some proposals and with that I will hand over and thank you all for your attention I welcome to the stage have you thank you