[00:00.000 --> 00:09.680]  First of all, thank you. Thank you for coming here to this session. I think it's fantastic
[00:09.680 --> 00:17.600]  to have an audience who is potentially interested with regulation and compliance. This is something
[00:17.600 --> 00:26.280]  that impact us all of us as a community, as our users, consumers, and also from a work
[00:26.280 --> 00:33.280]  perspective. So I think it's really important to be able to understand what are the impacts
[00:33.280 --> 00:39.440]  of regulations, compliance, certifications, when we are developing software, when we
[00:39.440 --> 00:46.280]  are sharing our work from, I would say, a community perspective, but also when that
[00:46.280 --> 00:54.760]  work goes into production on systems, critical systems. So thank you for being here for that.
[00:54.760 --> 01:04.160]  Today we have the unique opportunity to have some of the folks who wrote, or at least review
[01:04.160 --> 01:13.640]  wrote, some of the legislation directives, like the Cyber Resilience Act. And we will
[01:13.640 --> 01:19.840]  go through a couple of lightning talks, because I think it's really important to set the scene.
[01:19.840 --> 01:26.160]  So we could start discussing about having a panel, but if we don't understand the overall
[01:26.160 --> 01:34.040]  construct of those regulations, that's going to be hard. So I would like to have a warm
[01:34.040 --> 01:45.480]  welcome from Benjamin here, if you can give him a bit of love. Thank you. Thank you. So
[01:45.480 --> 01:50.640]  we are really honored to have the European Commission here to help us with this. So thank
[01:50.640 --> 01:57.280]  you. Benjamin, up to you. Thank you very much. Thank you so much for having me and also for
[01:57.280 --> 02:03.600]  showing interest in our work that will maybe affect some of you, but most of you probably
[02:03.600 --> 02:10.680]  won't be affected by it. I mean, as a Commission, we're always trying very hard to reach out
[02:10.680 --> 02:15.240]  to all the people that could potentially be affected by our regulation, but it's sometimes
[02:15.240 --> 02:19.960]  a bit difficult. I mean, it's often mostly large companies that have the resources to
[02:19.960 --> 02:25.840]  actually engage with us. So I'm really happy to be here and I'm so glad that so many of
[02:25.840 --> 02:33.000]  you decided also to stay for this panel. So the Cyber Resilience Act is a new proposal
[02:33.000 --> 02:39.640]  of the European Commission. It intends to improve the cybersecurity of hardware and
[02:39.640 --> 02:47.320]  software products. It's intended to complete a puzzle. So there's already other legislation
[02:47.320 --> 02:54.400]  at union level on cybersecurity. Most notably, there is the NIS directive, which has recently
[02:54.400 --> 03:01.000]  been reformed. The NIS directive focuses more on the users of hardware and software. So
[03:01.000 --> 03:06.680]  it ensures that large companies, critical infrastructure providers and so forth, take
[03:06.680 --> 03:11.840]  security seriously, do their patches regularly and all that. But the Cyber Resilience Act
[03:11.840 --> 03:18.120]  now focuses on the other side, on the manufacturers of these products. And I mean, I know that
[03:18.120 --> 03:22.840]  many of you are probably not dealing with policy every day, and it's particular not
[03:22.840 --> 03:28.680]  with European Union policy. So I've just like added one slide at the very beginning to quickly
[03:28.680 --> 03:32.880]  explain to you like what the Commission is and where we are in this process and who the
[03:32.880 --> 03:39.320]  other players are. So yeah, this is highly simplified. It's much more complicated than
[03:39.320 --> 03:47.360]  that, unfortunately. So I work for the European Commission for the Director General Connect.
[03:47.360 --> 03:52.680]  It's like the Director Generals. They are like departments within the Commission. So
[03:52.680 --> 03:59.120]  we mostly deal with telecommunications, internet, emerging technologies and so forth. And it
[03:59.120 --> 04:06.200]  is the European Commission that makes legislative proposals in the European Union. So we write
[04:06.200 --> 04:11.720]  the draft and then we propose this draft to the so-called co-legislators. That's the European
[04:11.720 --> 04:17.520]  Parliament and where you have the members of the European Parliament, so parliamentarians,
[04:17.520 --> 04:24.240]  and the Council that represents the 27 member states. And these two institutions, they analyze
[04:24.240 --> 04:29.120]  the Commission's proposal. They come up with their own positions and once they've done that,
[04:29.120 --> 04:35.200]  they negotiate with one another. And at the very end, once they agree on a common line,
[04:35.200 --> 04:41.600]  a common position, they adopt the text and it enters into force. It becomes a law. So
[04:41.600 --> 04:47.360]  this is basically how it works. It's very simplified. So our proposal came out on 15
[04:47.360 --> 04:54.720]  September 2022, so in autumn. And it's now with Parliament and Council. Parliament has
[04:54.720 --> 04:59.360]  not yet started discussing it. They're still sorting out which committees will be in charge
[04:59.360 --> 05:04.840]  of it. But the Council is already at full speed. There are regular meetings every second
[05:04.840 --> 05:10.000]  Wednesday. The Council is meeting to discuss the text proposed by the Commission. So that's
[05:10.000 --> 05:16.640]  just for your background. And now we'll talk about the substance of the proposal. So what
[05:16.640 --> 05:23.440]  are we trying to achieve? So we want to reduce the number of vulnerabilities in hardware and
[05:23.440 --> 05:31.440]  software products. Of course, we know that it's an unrealistic goal to aim for zero
[05:31.440 --> 05:36.560]  vulnerabilities in products. And this is what the slide represents. So the cheese represents
[05:36.560 --> 05:41.760]  a hardware software product filled with holes. I mean, I know not all are filled with holes,
[05:41.760 --> 05:48.000]  but many are. And I mean, we attempt to reduce the number of such security holes in hardware
[05:48.000 --> 05:54.240]  and software products through legislation. And, yeah, I will just get right into the
[05:54.240 --> 05:59.440]  main elements of the proposal to give you an overview and then I will, you know, provide
[05:59.440 --> 06:05.640]  some more details. So it's all about providing cybersecurity rules for hardware and software
[06:05.640 --> 06:09.680]  products when they're placed on the market. So placing on the market entails that we're
[06:09.680 --> 06:14.640]  talking about commercial activities here. So companies that make money with hardware
[06:14.640 --> 06:19.280]  and software products, they will have to follow these rules. We're using a well-established
[06:19.280 --> 06:24.560]  framework. It's called the new legislative framework. It's been used in the past by the
[06:24.560 --> 06:31.040]  European Union to regulate other products such as toys or machinery or electrical equipment.
[06:31.040 --> 06:35.160]  And you may not know it, but you're all actually very familiar with it. So whenever you see
[06:35.160 --> 06:40.440]  a product that has the CE marking on it, CE, I will show it later, like you have it, for
[06:40.440 --> 06:46.160]  example, on laptops or iPhone chargers and such things. So this is all a new legislative
[06:46.160 --> 06:52.120]  framework regulation then. What we do in the proposal is we establish obligations for three
[06:52.120 --> 06:57.680]  types of economic operators for the manufacturers. I mean, that's the core element, of course,
[06:57.680 --> 07:02.800]  of the proposal. But then there are also the distributors. These are brick and mortar stores,
[07:02.800 --> 07:08.320]  online shops, and also importers that place products on the European market that have
[07:08.320 --> 07:12.800]  been developed in third countries. And the importers and the distributors, they don't
[07:12.800 --> 07:17.200]  have to, I mean, they don't do secure coding, of course. They are just selling products,
[07:17.200 --> 07:22.520]  but they have to ensure that the products that they are selling are in line, I mean,
[07:22.520 --> 07:30.200]  that they comply with the Cyber Resilience Act. One of the core novelties of our proposal
[07:30.200 --> 07:36.720]  is that it does not just cover rules for the placing on the market, so what the product
[07:36.720 --> 07:42.240]  should look like, but it also covers the period after that, the entire life cycle. So I mean,
[07:42.240 --> 07:46.560]  you all know that for cybersecurity, it's extremely important that you keep tracking
[07:46.560 --> 07:51.320]  your products, that you ensure that when you discover new vulnerabilities, that you fix
[07:51.320 --> 07:56.120]  them, you mitigate them, you provide patches and so forth. And this is part of our proposal
[07:56.120 --> 08:00.440]  that for a period of five years after the placing on the market of a product, you do
[08:00.440 --> 08:07.960]  that, you provide security updates. One essential element of any new legislative framework regulation
[08:07.960 --> 08:15.080]  is harmonized standards. So the rules that we propose in the Cyber Resilience Act, they
[08:15.080 --> 08:20.280]  are very high level, technology neutral, objective oriented. I mean, if you go through
[08:20.280 --> 08:23.920]  the proposal, you will see they're really high level. It's more like on the level of
[08:23.920 --> 08:34.240]  provide a secure by default configuration, take care of access management, make sure
[08:34.240 --> 08:38.720]  data is handled confidentially and so forth. So it's really high level. But then we have
[08:38.720 --> 08:45.960]  the standards that will be developed by the European standardization organizations. You
[08:45.960 --> 08:51.360]  may have heard of them. They're called SanSanElec and Etsy. And they will, I mean, they are
[08:51.360 --> 08:57.520]  voluntary. You don't need to use these standards, but they will help you write secure products.
[08:57.520 --> 09:04.280]  And then there is also the conformity assessment. So manufacturers, they will have to demonstrate
[09:04.280 --> 09:08.080]  that their products are actually compliant, but I will explain that in more detail later.
[09:08.080 --> 09:11.800]  Yeah. And finally, there's the market surveillance. So in all the member states, you will have
[09:11.800 --> 09:18.880]  authorities that can check out the products and approach manufacturers, ask them to remediate
[09:18.880 --> 09:26.840]  vulnerabilities, eliminate risks, and if they don't comply, even hand out fines. So the
[09:26.840 --> 09:33.960]  scope of the proposal, it's hardware and software products, products, not services. So when
[09:33.960 --> 09:39.480]  I say hardware products and software products, I mean, final products such as laptops or
[09:39.480 --> 09:47.920]  operating systems, but also components such as CPUs, hard drives, software libraries and
[09:47.920 --> 09:54.320]  so forth, we have, we don't regulate services. So software as a services outside the scope
[09:54.320 --> 09:59.640]  of this proposal, that's already regulated by the NIS directive, which I mentioned earlier,
[09:59.640 --> 10:05.520]  but we do regulate something that we call remote data processing solutions. So often
[10:05.520 --> 10:11.280]  today, products, they actually come with some cloud or other elements such as many mobile
[10:11.280 --> 10:16.200]  applications. They usually, they access data in the cloud and these are essential functionalities
[10:16.200 --> 10:20.840]  of the program. And then you would also have to ensure the security of these remote data
[10:20.840 --> 10:27.600]  processing solutions. As I already explained, we only regulate commercial products. So anything
[10:27.600 --> 10:33.400]  that is non-commercial is outside the scope, including open source when it's non-commercial.
[10:33.400 --> 10:36.920]  But on the other hand, so open source that is commercial, I mean, there are a lot of
[10:36.920 --> 10:42.360]  large commercial projects, I'm sure you're aware of them, they would be covered. And
[10:42.360 --> 10:46.920]  then we exclude certain products that already regulated by other regulations such as cars
[10:46.920 --> 10:54.120]  or medical devices. Yeah, I mean, why did we choose to exclude non-commercial open source
[10:54.120 --> 10:58.960]  software from the scope? There are a few reasons. And first of all, this is standard practice
[10:58.960 --> 11:04.800]  for any new legislative framework, product regulation at union level. We only focus on
[11:04.800 --> 11:09.960]  commercial activities. But also in the case of open source, there are some more special
[11:09.960 --> 11:14.880]  considerations that we took. So first of all, like, is it even, would it be fair to regulate
[11:14.880 --> 11:18.960]  someone that does not make a profit with a product, right? I mean, and we think it would
[11:18.960 --> 11:23.360]  not. And wouldn't we be setting the wrong incentives to regulate someone who doesn't
[11:23.360 --> 11:29.080]  make money with it, right? I mean, would you keep developing something if you're asked
[11:29.080 --> 11:33.800]  to like follow regulation and you're not even earning money with it? So we would be setting
[11:33.800 --> 11:37.760]  the wrong incentives. That's why we decided to exclude them. And then of course, we also
[11:37.760 --> 11:42.640]  know that open source, I mean, it's critical often from a cybersecurity perspective, but
[11:42.640 --> 11:47.880]  it's just as critical from an innovation and growth perspective. I mean, there are so many
[11:47.880 --> 11:53.400]  small companies, medium sized companies that use your components, your products free of
[11:53.400 --> 11:58.400]  charge to develop on top other products and services. And for them, it's crucial that
[11:58.400 --> 12:04.440]  they that they have access to this resource. And that's, I mean, we're fully aware of that.
[12:04.440 --> 12:08.760]  And my colleague Rice, he will, he will, I mean, he will later on the panel also explain
[12:08.760 --> 12:17.200]  to you how, in how many other ways we, we, we support open source as the European Commission.
[12:17.200 --> 12:21.400]  So here in a nutshell, the obligations that manufacturers of commercial products would
[12:21.400 --> 12:26.920]  be, would have to comply with. I mean, first you do a risk assessment of your product during
[12:26.920 --> 12:33.560]  the design phase, then you comply with the essential requirements that are in the regulation.
[12:33.560 --> 12:39.040]  I explained earlier what they look like, these high level objective oriented requirements.
[12:39.040 --> 12:44.360]  Then you establish vulnerability handling processes, such as a coordinated vulnerability
[12:44.360 --> 12:50.200]  disclosure policy. And yeah, and of course, I mean, with any legislation, you will have
[12:50.200 --> 12:57.160]  to document in which way you comply. This would be called a technical file. And once
[12:57.160 --> 13:00.720]  you've done all that, once you've done the conformity assessment, you can fix the CE
[13:00.720 --> 13:06.840]  marking to your product. And then for a period of five years, you will be required to handle
[13:06.840 --> 13:10.840]  the vulnerabilities that arise in your products.
[13:10.840 --> 13:15.960]  On top of that, there's also an obligation to report critical vulnerabilities to our
[13:15.960 --> 13:20.720]  cybersecurity agency. We are talking about vulnerabilities that are already exploited
[13:20.720 --> 13:27.760]  in the wild by criminal actors, but that have not been necessarily fixed. And this is for
[13:27.760 --> 13:33.360]  the purpose of helping national authorities mitigate risks in critical infrastructure
[13:33.360 --> 13:38.240]  and so forth. Here's one example of how we are also trying
[13:38.240 --> 13:43.400]  to help the community. So in the article 11, which is about the reporting requirements
[13:43.400 --> 13:48.440]  for manufacturers, we require them whenever they integrate a component and they discover
[13:48.440 --> 13:53.880]  a vulnerability in it. And this could be an open source component that they notify the
[13:53.880 --> 13:59.120]  entity or the person that maintains this component. I mean, so people like you often, for example.
[13:59.120 --> 14:03.240]  So for example, when you go, when you're from GitHub, when you source a component and then
[14:03.240 --> 14:08.240]  you discover a vulnerability, at least you should reach out to the maintainer and inform
[14:08.240 --> 14:15.040]  them of the vulnerability. Ideally do more, maybe even provide code to fix it.
[14:15.040 --> 14:22.800]  So here is how it works as regards components. This is an example of a smartphone manufacturer
[14:22.800 --> 14:26.360]  that builds a smartphone. So there will be some components here. You see them on the
[14:26.360 --> 14:32.720]  left-hand side in blue. These are components that the manufacturer develops themselves.
[14:32.720 --> 14:38.160]  So they would not be placed on the market separately, but as part of the final product.
[14:38.160 --> 14:42.360]  And then for these components, you would not need to do a separate conformity assessment,
[14:42.360 --> 14:46.200]  but it would be part of the final product. But then there are other components. You see
[14:46.200 --> 14:52.040]  them on the right-hand side, such as the ones that are developed by upstream manufacturers.
[14:52.040 --> 14:57.320]  So here you see the RAM or the CPU in that example would be manufactured by someone else.
[14:57.320 --> 15:01.960]  So and so these are placed on the market separately, and it would be the upstream manufacturer
[15:01.960 --> 15:07.200]  who would need to ensure the security of these components and to fix the CE marking.
[15:07.200 --> 15:11.640]  And of course, the manufacturer of the smartphone is responsible for the entire product, right?
[15:11.640 --> 15:15.320]  Just because you integrate a component of someone else doesn't mean you don't take any
[15:15.320 --> 15:20.600]  responsibility for it, but you would be, you would need to do due diligence when you integrate
[15:20.600 --> 15:28.600]  those components. Yeah, so these are the categories for the conformity assessment that you propose.
[15:28.600 --> 15:35.520]  For the vast majority of products, the default category, you would do the conformity assessment
[15:35.520 --> 15:40.440]  yourself as a manufacturer. You do not need to interact with any third party. But then
[15:40.440 --> 15:45.400]  there is a smaller list of critical products, which you can find in the annex of our proposal.
[15:45.400 --> 15:51.240]  It's roughly 10% of the scope, and there we require more stringent conformity assessment
[15:51.240 --> 15:56.120]  and sometimes even independent third party assessment. Examples of these more critical
[15:56.120 --> 16:01.880]  products are firewalls, CPUs, or operating systems. And then there is also a possibility
[16:01.880 --> 16:09.280]  for highly critical products. We are not making use of that now, but we are proposing that
[16:09.280 --> 16:15.560]  in the future we can add highly critical products to a list for which it would be necessary
[16:15.560 --> 16:20.320]  to undergo a mandatory certification. We do not have any products in mind. This is really
[16:20.320 --> 16:26.000]  just to future proof the legislation, because we all know that digital products permeate
[16:26.000 --> 16:29.880]  society more and more, and we become more and more dependent on them. And there may be
[16:29.880 --> 16:35.040]  a point at which we will rely on such crucial products that we need even a higher level
[16:35.040 --> 16:42.280]  of assurance. I don't know, human brain interfaces or something like that. I mean, yeah. Okay,
[16:42.280 --> 16:48.160]  this is the CE marking that you're all very familiar with. We are also trying to facilitate
[16:48.160 --> 16:53.520]  compliance for the manufacturers as much as possible. So we would be providing after the
[16:53.520 --> 17:04.080]  entry into force of the proposal guidance on compliance in general, as well as examples
[17:04.080 --> 17:09.000]  of how to do things in practice, for example, on how to delineate what is a commercial product,
[17:09.000 --> 17:15.000]  what is a non-commercial product. We will also, I mean, as I said, develop these harmonized
[17:15.000 --> 17:20.320]  standards. We are looking into providing funding through the Digital Europe program, that's
[17:20.320 --> 17:24.960]  a European funding initiative, for national market surveillance authorities, but also
[17:24.960 --> 17:30.920]  for manufacturers to help them comply. But then, frankly, we are also counting on you,
[17:30.920 --> 17:36.400]  on the community, on software developers, on the market also, to come up with tools
[17:36.400 --> 17:41.000]  that can help facilitate compliance. I mean, many of these tools already exist, of course,
[17:41.000 --> 17:48.200]  such as static and dynamic code analysis tools, S-bomb generators, but, I mean, you name
[17:48.200 --> 17:52.520]  it, there can be any number of tools that could help facilitate compliance, maybe to
[17:52.520 --> 17:58.200]  generate some of the documentation automatically, and, I mean, also be extremely open to ideas
[17:58.200 --> 18:03.560]  on how to facilitate this. So, feel free to approach me after the panel, and we can discuss
[18:03.560 --> 18:09.720]  it. Here, this is the timeline just for you to better understand, and this is also my
[18:09.720 --> 18:16.040]  last slide. So, as I said, we made the proposal on 15 September. We are now undergoing this
[18:16.040 --> 18:23.720]  legislative process. We are hoping to conclude it before the European elections in May 2024.
[18:23.720 --> 18:28.600]  And then, once it's done and enters into force, we will launch a request for standardization
[18:28.600 --> 18:33.880]  with the European standardization bodies. And then, 24 months later, it would enter
[18:33.880 --> 18:39.560]  into application, so that's when manufacturers would need to comply with the rules, and also
[18:39.560 --> 18:44.280]  when the harmonized standards would become available. Yeah, so there's still plenty of
[18:44.280 --> 18:51.240]  time for you to help in the process, to reach out to members of parliament if you have concern
[18:51.240 --> 18:55.720]  or to the member state authorities and get involved. We are, of course, also extremely
[18:55.720 --> 19:00.680]  interested in your views, so you can also reach out to us. I mean, I also brought some business
[19:00.680 --> 19:05.800]  parts, so later, if you're interested, you can have some. And, yeah, I mean, I'm extremely
[19:05.800 --> 19:10.600]  looking forward to the discussion now. Thanks. Sorry for being so fast, but I only have 15 minutes.
[19:10.600 --> 19:18.280]  Thank you, Benjamin. So, I don't know if you saw me
[19:18.280 --> 19:24.120]  moving around during the talk, but we were discussing both cyber resilience and also
[19:25.000 --> 19:31.640]  potential software defect. I just escorted a bug outside how convenient it was, so saving a bug.
[19:32.920 --> 19:43.320]  So, now we're transitioning to Martin from NLNet Labs, and he's going to give us this point of
[19:43.320 --> 19:54.040]  view of the CRA based on, from an NGO, so a non-government agency or office, organization, sorry.
[19:54.040 --> 20:05.240]  So, this is a different approach, and, yeah, they are dealing with DNS, so that might be
[20:05.240 --> 20:14.760]  important infrastructure element to consider in this topic. One welcome from Martin, please.
[20:19.560 --> 20:26.200]  Good morning, everyone. So, I'm really grateful that Benjamin just did the hard work of explaining
[20:26.200 --> 20:35.800]  the legislation, and for me, the, I suppose, easier part of reacting to it. So, my name is Martin Arte.
[20:35.800 --> 20:44.200]  I work for NLNet Labs, which is a non-profit R&D organization. We make open source software
[20:44.200 --> 20:49.160]  for the internet. I stole this terminology from a great report from a quite a while ago.
[20:49.160 --> 20:55.800]  And, what we do is we develop internet standards, or we contribute to the development of internet
[20:55.800 --> 21:05.960]  standards, and we make implementations. And, the specific area of focus that we have.
[21:05.960 --> 21:07.960]  The mic, closer to you.
[21:07.960 --> 21:16.680]  Ah, I'm, I will. So, the specific work that we do is we develop, we contribute to the
[21:16.680 --> 21:23.160]  development of internet standards, and we make implementations in software that are open source.
[21:23.160 --> 21:28.600]  And, we've been doing this for two decades. We make software in the area of DNS, and we make
[21:28.600 --> 21:35.560]  software in the area of routing, specifically, routing safety. And, what we also do is we try to
[21:35.560 --> 21:40.600]  bring that knowledge to policymakers, and that's what I'm doing, hopefully, today.
[21:40.600 --> 21:51.800]  So, Benjamin just talked about the scoping, and he mentioned that most of us would be out of scope.
[21:51.800 --> 21:57.960]  And, when I read the proposal in September, October, I wasn't so sure, and I think that's
[21:57.960 --> 22:05.240]  something we should discuss. So, there is a recital in the text that basically reads,
[22:05.240 --> 22:10.600]  free in open source software should not be covered by this regulation, which is, I think,
[22:12.200 --> 22:19.400]  I think we should be very happy that the commission is aware of open source, and has taken concern
[22:19.400 --> 22:26.680]  to actually address this in new legislation that I come up with. So, I think that is a,
[22:27.800 --> 22:32.920]  something we should celebrate, much like the fact that open source has been here for 25 years.
[22:32.920 --> 22:37.960]  So, maybe a little warm round of applause just to acknowledge that we've been here.
[22:41.160 --> 22:46.280]  And, what I want to talk about today is the fact that there's a clause here, and it says,
[22:46.280 --> 22:52.840]  outside the course of a commercial activity. And, what is a commercial activity? There are some
[22:52.840 --> 22:58.760]  examples. It's not a defined term. And, one of the examples that is relevant to my organization,
[22:58.760 --> 23:03.800]  to Enelnet Labs, is specifically that what is called out is that if you charge a price for
[23:03.800 --> 23:10.520]  technical support services, then you are considered commercial. So, the organization I work for is
[23:10.520 --> 23:15.640]  a registered charity. We make software, we develop standards, we give it away for free,
[23:16.360 --> 23:22.840]  we give away updates for free. And yet, we employ people with mortgages. So, the question is, how
[23:22.840 --> 23:29.400]  are we supposed to make money? And, we've found a way, namely, the network operators that use our
[23:29.400 --> 23:35.640]  software want it to be available long term. And, they want there to be different implementations
[23:35.640 --> 23:45.800]  available. So, they've chosen to pay us to provide support. And, so this makes our work a commercial
[23:45.800 --> 23:50.680]  activity, at least in the way we read this text. I would be glad to be wrong about most of the
[23:50.680 --> 23:58.040]  slides I'm showing you today. And, please tell me if I am. But, that's why we got interested in
[23:58.040 --> 24:07.320]  this legislation. And, there are some risks if you look at this exception. Because, if you have an
[24:07.320 --> 24:14.040]  expansive interpretation of the word commercial, then the exception is narrow. It's this balance,
[24:14.040 --> 24:19.960]  right? Depending on how you interpret commercial. And, if it's a narrow scope of exemption,
[24:19.960 --> 24:26.440]  then what you create is a disincentive for open source developers who start working on something
[24:26.440 --> 24:31.880]  in their free time to professionalize. Because, at some point, when you hit this commercial
[24:31.880 --> 24:38.360]  qualifier, then you come into scope of regulation. And, there's nothing bad about regulation per se,
[24:38.360 --> 24:45.240]  but we have to acknowledge that the step from not being regulated to be regulated is a change,
[24:45.240 --> 24:51.720]  right? And, what we don't want to happen is for charities like Anelot Labs and others who make
[24:51.720 --> 24:57.960]  this kind of software to realize that the way they've been able to sustain their development
[24:57.960 --> 25:04.760]  is now disappearing. So, this, what we don't want is for there to be an incentive to move to
[25:04.760 --> 25:11.240]  closed-source software. And, finally, especially in the area of DNS, what we want is product
[25:11.240 --> 25:18.520]  diversity. So, it's not a good outcome if we have, if we go to a place where there's less
[25:19.720 --> 25:25.640]  organizations working on these projects. Because, what we want is different implementations that
[25:25.640 --> 25:33.640]  do not share code for stability. So, it's not just me. The OSI reacted to the response. And,
[25:33.640 --> 25:39.560]  they said, and I like this quote a lot, the problem is not the lack of taxonomy of commercial,
[25:39.560 --> 25:45.320]  so the solution is not explaining what commercial is supposed to be. It is the very act of making
[25:45.320 --> 25:52.120]  commercial the qualification rather than deployment for trade. And, what is relevant about this quote
[25:52.120 --> 25:57.800]  is that there's a very different, the act of maintaining and creating software and the cost
[25:57.800 --> 26:05.080]  of that is very distinct from the act of profiting from its deployment. And, if you confuse these
[26:05.080 --> 26:12.680]  two steps, then you, and commercial may help you confuse those steps, then we get into this place.
[26:14.600 --> 26:20.520]  So, that's about general scoping issues. I'd like now to move to specific concerns we have
[26:20.520 --> 26:27.960]  from analog labs. And, why do we have concerns? It's because we have products. We make unbound,
[26:27.960 --> 26:34.120]  the resolver, we make some other products. At least, we believe it's not an unreasonable
[26:34.120 --> 26:39.400]  interpretation to consider the stuff we release, including binaries, to be products. And, maybe
[26:39.400 --> 26:46.120]  we're wrong. Love to hear that. So, if we are products and if what we do is considered commercial,
[26:46.120 --> 26:52.840]  then there are some unintended consequences by being covered by this legislation. Because,
[26:52.840 --> 27:00.440]  currently, we are in outfit with 15 people, 14 of whom are either software engineers or developers.
[27:00.440 --> 27:10.280]  Every effort we put into proving that we're doing the right thing, the compliance bit,
[27:10.280 --> 27:17.320]  which is a logical part of any legislation, every effort that we spend on compliance
[27:17.320 --> 27:23.080]  will not be spent on securing our software. And, the only reason why a charity like ours
[27:23.080 --> 27:30.760]  exists is baking secure software, resilient software for internet infrastructure. And, if you look at
[27:30.760 --> 27:40.760]  the NX3 list of critical products, it doesn't take too much imagination to frame most of what we do
[27:40.760 --> 27:48.200]  as critical products in terms of this legislation. And, I think Benjamin explained about the way
[27:48.200 --> 27:55.000]  to avoid having to call in third-party auditors. But, it depends on the availability of European
[27:55.000 --> 28:01.800]  standards that are applicable to our work. And, in general, I think most of us are not engaged in
[28:01.800 --> 28:07.720]  the European policy process. And, even less of us are involved at the European standard
[28:07.720 --> 28:13.000]  institutions. Because, basically, we have no need to be there at this point in time. And, we have
[28:13.000 --> 28:18.680]  not had a need in the past. So, at Inelid Labs, we quite work quite a lot on standardization,
[28:18.680 --> 28:25.080]  but it's at multi-stakeholder forms, accessible to any party, without payment, etc. And, that's
[28:25.080 --> 28:31.800]  not how these European standardization institutions work, unfortunately. So, the escape hatch,
[28:31.800 --> 28:36.920]  if you are a critical product, to not have to call in third-party auditors may not actually
[28:36.920 --> 28:44.680]  be available in practice. And, that means we will have a costly burden checking our processes,
[28:45.320 --> 28:50.360]  which does not actually contribute to the quality of code. And, that's why I think this is a concern
[28:50.360 --> 28:57.080]  for us, or at least an unintended consequence. There's also text in there which requires you
[28:57.080 --> 29:04.200]  to fix all known vulnerabilities. And, this does not have a regard for severity. And, what this
[29:04.200 --> 29:11.080]  does is, if you have to fix all known vulnerabilities, then discus your engineering effort from
[29:11.080 --> 29:17.560]  practices that protect you against unknown vulnerabilities. So, this is, I think this is
[29:17.560 --> 29:22.680]  not what it was actually intended. I'm just flagging it, because we, I think we want to,
[29:22.680 --> 29:28.200]  there to be good laws, and we want to help in a democracy to achieve those good laws. I mean,
[29:28.200 --> 29:34.280]  why, if you live in a democracy and you like that, why not contribute, I suppose? Otherwise,
[29:34.280 --> 29:43.480]  there's not a lot of points. So, there's also more detailed concerns. So, for example, we currently
[29:43.480 --> 29:50.520]  have the opportunity to provide security updates to providers we know are extremely critical to
[29:50.520 --> 29:56.280]  the functioning of the internet. So, if we are about to release a patch and give full information
[29:56.280 --> 30:04.520]  about what it fixes, we can choose to provide a update just ahead of time to a, for example,
[30:04.520 --> 30:11.160]  root server operator or some other entity which is not equal in terms of importance to all of
[30:11.160 --> 30:16.920]  society. And, the current text takes away our ability to do so, because it requires us to do
[30:16.920 --> 30:22.760]  everything at the same time, which may not actually benefit security, which is the goal.
[30:22.760 --> 30:31.400]  There's also obligations to report incidents that actually relate to third party use of our
[30:31.400 --> 30:39.080]  software. So, we don't do any operations, we just develop software, but if we are obliged to report
[30:39.080 --> 30:44.760]  incidents that relate to the use of our software, this gets into a conflict of our role of remediating
[30:44.760 --> 30:52.040]  vulnerabilities. And, this is the case, because these third parties may have some reason not to
[30:52.040 --> 30:59.720]  go public with an incident at first. And, if you create a conflict of interest in talking to us,
[30:59.720 --> 31:07.080]  then we may need longer to fix the vulnerability if there is such a thing. What we don't know,
[31:07.080 --> 31:16.200]  and this is more of an uncertainty, we don't know what constitutes substantial modification.
[31:16.200 --> 31:23.480]  So, the whole idea of that you trigger reassessment of your product for the CE marking, it hinges on
[31:23.480 --> 31:29.640]  the fact that, when substantial modification is made, you need to do it again. And, we currently
[31:29.640 --> 31:35.240]  don't know if that's a major release, minor release, patch release. We do quite a lot of releases.
[31:36.920 --> 31:43.480]  And, depending on how this pans out, we may spend a lot of work doing compliance and less
[31:43.480 --> 31:53.000]  work of doing release engineering. Finally, there is some clause about time limited availability
[31:53.000 --> 31:57.720]  of software testing purposes. And, I think that's fundamentally incompatible with how open source
[31:57.720 --> 32:04.600]  is done. Much of the points I've made today, we worked on together with ISC, the authors of Bind,
[32:04.600 --> 32:12.680]  among others. And, on their website, you can download about 30 years of binaries, of all versions of
[32:12.680 --> 32:18.920]  Bind ever made, which is really helpful if you're trying to find issues, vulnerabilities, whatever
[32:18.920 --> 32:29.000]  you try to. So, what we don't want is for them to have to get this stuff offline, because I don't
[32:29.000 --> 32:36.840]  think it actually helps us reduce vulnerabilities. So, if you are interested in this stuff, I recommend
[32:36.840 --> 32:43.080]  you to read further, because this was just my perspective. And, Elnert Labs, as an organization,
[32:43.080 --> 32:48.520]  a charity employing people that are getting paid full time to develop open source software,
[32:48.520 --> 32:53.960]  is not very common. And, I realize that. But, you don't have to take it from me. You can also
[32:53.960 --> 33:01.640]  read about other responses. So, there's the work of OSI. There's work by Open Forum Europe,
[33:01.640 --> 33:09.560]  Brussels-based Think Tank, which collects voices from other organizations relating to open source,
[33:09.560 --> 33:15.000]  including commercial ones. And Simon, who's in the front here, maybe he can raise his hand,
[33:15.880 --> 33:25.880]  actually compiled a list of responses by other. So, you can take a look yourself and give it
[33:25.880 --> 33:32.440]  some thought. I wanted also to quickly give a shout out to a blog written by Thomas DePierre.
[33:32.440 --> 33:38.600]  I'm hoping I'm not butchering your name. And, it relates to supply chain thinking, how that's
[33:38.600 --> 33:43.560]  currently quite dominant in thinking about security for open source. And, his point is basically,
[33:44.120 --> 33:50.200]  you supply chain thinking doesn't work if someone in this supply chain is not actually
[33:50.200 --> 33:56.680]  considering themselves to be a supplier. So, that's it with respect to what I had to say.
[33:57.560 --> 34:03.480]  In summary, we believe that these goals that the commission is trying to achieve are worthy goals.
[34:03.480 --> 34:10.040]  And, as a consumer, I would like them to succeed. However, there's also some unintended consequences
[34:10.040 --> 34:19.640]  in their current proposal. And, I think we should aim as a society to fix those. I'm very interested
[34:19.640 --> 34:24.360]  to hear your perspective. And, for now, I'd like to thank you for your attention. And, I'm looking
[34:24.360 --> 34:38.040]  forward to the panel. Thank you, Martin. We hit 30 minutes with two different opinions and views.
[34:38.040 --> 34:55.800]  Is there some questions in the audience? Not yet? Oh, one, two. Two questions. I'm from the UK.
[34:56.440 --> 35:00.680]  So, how does that affect other European countries that may be?
[35:00.680 --> 35:10.680]  Okay. How does it affect the UK and the UK working with Europe? We're still part of Europe after
[35:10.680 --> 35:17.560]  Brexit. And, secondly, how does it affect what's happening in the U.S. in terms of all the stuff
[35:17.560 --> 35:23.560]  that NIST is doing, particularly on, you know, from the executive order that happened in 2021?
[35:23.560 --> 35:29.320]  I couldn't hear the second question. The second question was, how does this affect the U.S.?
[35:31.880 --> 35:37.640]  So, yeah, thanks a lot for that question. So, for the Subresilience Act, we are applying the same
[35:37.640 --> 35:44.840]  principle as for any other union legislation that is about services or products. So, whenever you
[35:44.840 --> 35:49.320]  provide a service or a product in the European Union, you have to comply with the rules of the
[35:49.320 --> 35:55.320]  European Union. So, that means for the Subresilience Act, if you provide a hardware or software
[35:55.880 --> 36:01.560]  manufactured outside the European Union to consumers or other users within the union,
[36:01.560 --> 36:05.800]  you would have to comply with the Subresilience Act. So, there's absolutely no difference. It
[36:05.800 --> 36:11.080]  doesn't matter where you're located. If you want to sell your products here, then you have to comply.
[36:11.080 --> 36:18.520]  So, there's also no risk that there would be an advantage for maybe manufacturers from America
[36:18.520 --> 36:23.240]  or so forth that they would not have to comply and therefore have lower costs. No, it's an
[36:23.240 --> 36:27.960]  level playing field. Everyone who wants to sell their products here would have to comply with
[36:27.960 --> 36:45.400]  the same rules. I hope that answers your question. Hi. Why is policy the right place to put these
[36:45.400 --> 36:55.080]  measures into effect rather than a standardizations body like ISO, which already does a lot of the
[36:55.080 --> 37:06.280]  same things and provides people who want the guaranteed, the guarantees associated with this
[37:06.280 --> 37:15.800]  reliability testing to select products that comply with the ISO requirements?
[37:18.440 --> 37:23.480]  Okay. If I understood the question, the question is why we think that a mandatory approach is
[37:23.480 --> 37:34.040]  necessary, right? Right. Why is the mandatory approach necessary instead of a voluntary approach
[37:34.040 --> 37:41.400]  that could be selected by consumers who want it? Yeah. I mean, the voluntary approach is the
[37:41.400 --> 37:46.760]  approach that we took basically for the last 20 years, right? And it hasn't worked. I mean,
[37:48.120 --> 37:52.840]  we are not eager to regulate new sectors. I mean, especially when it comes to such
[37:53.880 --> 37:58.280]  innovation and growth fostering sectors such as hardware and software. So, I mean,
[37:58.280 --> 38:03.160]  that's one of the reasons why the Commission of the European Union for a long time decided not
[38:03.160 --> 38:10.280]  to regulate. But, I mean, we see that, you know, despite of new standards coming out,
[38:10.280 --> 38:20.680]  development of lots of secure development lifecycle, guidance, new programming languages
[38:20.680 --> 38:24.760]  that are memory safe. I mean, all this is coming. We see that. But nonetheless, I mean,
[38:25.480 --> 38:30.600]  the vulnerabilities, they are not going down. And we see actually more cybersecurity incidents
[38:30.600 --> 38:36.520]  than ever before. And this is why we chose to regulate. I mean, in our view, there is simply
[38:36.520 --> 38:43.000]  not sufficient incentive for the market to take cybersecurity as seriously as it should.
[38:43.000 --> 38:49.400]  I mean, I mean, you all know this. I mean, you have so many specific features in this market,
[38:49.400 --> 38:53.800]  such as, yeah, time to market. I mean, first mover advantage, who is the first one to build
[38:53.800 --> 38:59.000]  a platform wins basically the whole market, yeah? So, under all these constraints, manufacturers
[38:59.000 --> 39:04.040]  do not have an incentive to prioritize cybersecurity. And we feel that this can only be fixed through
[39:04.040 --> 39:12.040]  regulation. Thank you. So, there's more questions to come. But we have a panel after. So, you will
[39:12.040 --> 39:17.080]  be keep your question, ask your question after so that we can proceed with the last presentation.
[39:18.440 --> 39:24.360]  I was also thinking about the same thing as you, sir, about the ISO part. Working with
[39:24.360 --> 39:31.800]  customers and partners at Red Hat, I can tell you that they need a directive or a compliance
[39:31.800 --> 39:37.960]  based on the law. Otherwise, they will never apply the things. So, the next speakers, Omar,
[39:37.960 --> 39:44.920]  is going to introduce us to the other part, which is more like the defective product and
[39:44.920 --> 39:55.400]  what it means in terms of liability. So, please welcome Omar with a round of applause. Thank you.
[39:57.160 --> 40:01.560]  You're okay with that? Yeah, we can take the mic. Did Martin show you how to use that?
[40:02.200 --> 40:11.480]  Yeah, I think it's, yeah. Thank you. So, thank you for the invitation. Thank you to be here. And
[40:11.480 --> 40:18.120]  I'm going to try to not use too much legal terms because I think now we're going to enter a zone
[40:18.120 --> 40:23.400]  that if you're not a lawyer, you will not really understand what we're talking about. So, I will
[40:23.400 --> 40:29.640]  kind of try to use more simple situations. I think the name of the proposal speaks by itself,
[40:29.640 --> 40:36.120]  product liability directive. The PLD, as we call it, is about the liability.
[40:36.120 --> 40:44.440]  So, I'm going to tell you, give you some examples. Boeing 737 Marks, two of them
[40:44.440 --> 40:53.720]  crashed some years ago. An autonomous vehicle that crashed and killed a person. In South Korea,
[40:55.800 --> 41:02.200]  lawn mower that went into a person. Your mobile phone that overheats.
[41:02.200 --> 41:10.760]  All of these situations are what we call the liability. And all of them includes softwares.
[41:11.640 --> 41:16.600]  So, what Benjamin explained to you are the obligation that when you want to place your
[41:16.600 --> 41:22.520]  product in the union on the market, but when something goes wrong, someone has to pay the bill.
[41:23.080 --> 41:31.080]  This is how every system works in all countries. And what the product liability does tells you
[41:31.080 --> 41:38.680]  who is the liable person and what the victim has to show to claim the compensation.
[41:39.800 --> 41:49.160]  So, the regime of the PLD exists since 85. But as you know, the product of 85 was not the one
[41:49.160 --> 41:57.480]  that we have today, including software, AI systems, IoT, etc. So, what we have done is to
[41:57.480 --> 42:06.680]  redraft and re-clarify the regime that existed by including all softwares in it. Because as you
[42:06.680 --> 42:13.800]  know, and with the example that I gave to you, software can in some situations cause harm
[42:13.800 --> 42:20.920]  and cause a damage. So, what the PLD does and it says that the manufacturer is liable for
[42:20.920 --> 42:29.240]  damage caused by a defect in their product and the injured person, so in a tribunal or in a court,
[42:29.240 --> 42:37.640]  has to prove the damage, the existence of the damage, the defect in the product, and the link
[42:37.640 --> 42:46.280]  what we in legal terms call the causal relationship between the defect and the damage itself. If this
[42:46.280 --> 42:52.520]  is proved, the manufacturer has to compensate the victim or the family of the victim in case
[42:52.520 --> 42:59.720]  of death. So, the manufacturer is defined, this is a definition that appears in all legislation,
[42:59.720 --> 43:06.280]  product legislation in the union. The damage, what damages are we talking about? Death,
[43:06.280 --> 43:13.480]  personal injury, damage to property, think about an IoT boiler system in your house,
[43:13.480 --> 43:19.160]  overheats, the house explodes, someone has to pay for that. That's a simple situation,
[43:19.160 --> 43:24.360]  but at least you see exactly what we're talking about. Data loss, data corruption,
[43:24.360 --> 43:31.480]  this is a new addition. So, obviously the liability that you had until now covered any physical
[43:31.480 --> 43:38.600]  things, but as you know, your own stuff, even in the material world, when you talk about NFTs,
[43:38.600 --> 43:44.040]  when you talk about NFTs, why would you be covered if your painting burns because of your
[43:45.000 --> 43:51.800]  house exploded, let's say, or whatever, but you cannot get compensation if actually you lose
[43:51.800 --> 43:58.040]  your NFT. So, all of this has been re-adapted and included in the regime. So, these are the
[43:58.040 --> 44:03.800]  damages for which the manufacturer has to pay compensation in case there was a defect that
[44:03.800 --> 44:11.080]  caused the damage to one of them. And so, the entire notion of defect, and I'm going to try to
[44:11.080 --> 44:18.120]  explain a bit also what was the part of the revision, the entire idea of defect is that the
[44:18.120 --> 44:27.560]  product did not, let's say, had a lack of safety that a general person is expected to have. So,
[44:27.560 --> 44:34.200]  your fire alarm does not detect the smoke, you are expecting that it would actually do it.
[44:35.400 --> 44:43.720]  If you have a computer and actually the software has so many vulnerabilities that you lose any of
[44:43.720 --> 44:49.160]  your data, you might expect that actually you should not do it. So, all of these are normally
[44:49.160 --> 44:55.320]  explained in quotes, and if you establish that there was a defect and that there was a damage,
[44:55.320 --> 45:02.280]  then you get compensation. Defect does not mean that we're talking about a zero absence of bugs
[45:02.280 --> 45:08.680]  in a software, for instance. This is not what it means. Zero, it's impossible. You cannot have it,
[45:08.680 --> 45:15.000]  but you can have vulnerabilities that, as a developer, you should have expected, or you
[45:15.000 --> 45:20.280]  should have foreseen. So, all of these are elements that are taken into account to establish the
[45:20.280 --> 45:25.640]  liability of the manufacturer or manufacturer developer depends on which type of product we
[45:25.640 --> 45:33.320]  are talking about. So, as I said, the liability has been revised. There are different adaptations
[45:33.320 --> 45:39.400]  of the regime for liability, the digital age, circular economy, this is about the
[45:39.400 --> 45:45.400]  substantial modification that we've talked about. The global value chains, this is a concept that
[45:45.400 --> 45:51.240]  we talk of mostly in trade, where a product comes from outside of the union, the manufacturer is
[45:51.240 --> 45:57.480]  established outside of the union, and brings the product in the union, and so you need to know who
[45:57.480 --> 46:07.560]  is the liable one, and then a better protection for victims. So, basically, what the new proposal
[46:07.560 --> 46:13.800]  or the new product liability directive propose is to say that any software is a product,
[46:13.800 --> 46:20.680]  no matter how it's supplied or provided. So, in this, obviously, also includes any AI systems.
[46:21.720 --> 46:27.000]  No matter if it's a software as a service, or anything that will be concerned as a service,
[46:27.000 --> 46:32.120]  all of them are software, and all of them are products, and all of them will be covered by
[46:32.120 --> 46:37.720]  the liability. But at the same time, you also know that software do not work independently.
[46:37.720 --> 46:45.880]  You have what we call the digital service, the flow of data that feeds the AI system
[46:45.880 --> 46:52.360]  for the training, all of them will be covered, and all of the providers of those data, for instance,
[46:52.360 --> 46:58.840]  will be also covered by the liability in case something goes wrong. As we talk about already,
[46:58.840 --> 47:04.360]  there is the exception of open source software outside of a commercial activity. To be clear,
[47:04.360 --> 47:11.240]  outside of a commercial activity is the exception for any product. If a product is outside of a
[47:11.240 --> 47:20.120]  commercial activity, it's out. But what is a commercial activity? Well, if your software
[47:20.120 --> 47:26.600]  is sold, this is a commercial activity. If you provide services to the company that takes
[47:26.600 --> 47:31.720]  your open source software, this is a commercial activity. Those are examples of commercial
[47:31.720 --> 47:40.200]  activity. This is how it has been interpreted by the court. This is part of the court judgments
[47:40.200 --> 47:46.440]  and case law. Obviously, you will have different situations, but these are some examples that I
[47:46.440 --> 47:53.560]  gave to you. The damage is to data loss and corruption. The software updates and upgrades.
[47:54.360 --> 48:01.000]  Obviously, your software or any type of product that are digital evolved during their lifetime,
[48:01.000 --> 48:07.320]  and this has also to be taken into account. If you do not provide the software update or upgrade
[48:07.320 --> 48:13.960]  that was necessary to avoid the damage, you can be held liable. These are the different
[48:13.960 --> 48:20.200]  elements, but obviously, I will not go into absolute details. Addressing the cyber vulnerabilities
[48:20.200 --> 48:27.080]  might also open a claim for damages. The evolution of an AI system through machine learning could
[48:27.080 --> 48:35.080]  also open a claim if the machine creates any damage. That's a bit of the adaptation.
[48:36.520 --> 48:42.680]  The circular economy is the general concept of substantial modification. Obviously,
[48:42.680 --> 48:48.120]  if someone substantially modifies a product, in this case, a software, it should be the one who
[48:48.120 --> 48:53.160]  should be held liable if something happens, has a manufacturer or the developer of this
[48:53.160 --> 49:01.000]  software after he has done the substantial modification. The value chain is more related to
[49:01.000 --> 49:09.720]  the traders that impose the product in the union. As a victim, you should not be blocked just because
[49:09.720 --> 49:17.400]  you do not know who is the manufacturer of the product. Anyone who is part of the value chain
[49:17.400 --> 49:22.520]  that brought the product in the union can be held liable. Through an importer,
[49:22.520 --> 49:29.800]  if you buy through an online marketplace, those entities could be held liable instead of the
[49:29.800 --> 49:36.360]  manufacturer. Obviously, if they have contract with the manufacturer itself, they can have recourse
[49:36.360 --> 49:48.040]  against them. The better protection, it's more for technical points, but it's how it's going
[49:48.040 --> 49:54.760]  to work in courts. You have situations that are so complicated. Let's take an AI system,
[49:54.760 --> 50:01.960]  explaining where the defect is in an AI system might be complex as a victim to show. We created
[50:01.960 --> 50:10.120]  what we call in legal terms legal presumptions. If the victim can prove one of those elements,
[50:10.760 --> 50:17.080]  you have what we call the presumption. We presume that the product is defective and it
[50:17.080 --> 50:23.560]  has caused the damage. If it's the case, then it is to the manufacturer to explain that actually
[50:23.560 --> 50:31.800]  it is not the case. That is a legal tool that exists in every system, but we have adapted it
[50:31.800 --> 50:38.440]  to ensure that if something goes wrong, someone at least has a possibility to have a claim.
[50:38.440 --> 50:44.360]  It does not mean that you are liable. It just means that you can bring a claim to a court
[50:44.360 --> 50:52.280]  and make your case and explain why the product was defective and why you have a damage and
[50:52.280 --> 50:57.880]  why the manufacturer should be held liable. This is not an automatic situation. It's not because
[50:57.880 --> 51:03.880]  we have included software, for instance, in the scope of the legislation that it means that you
[51:03.880 --> 51:08.600]  will be held liable. You need to have a damage. You need to have a plane that crashes because of
[51:08.600 --> 51:15.720]  the software that obliged the pilot to go down instead, to go up, the autonomous vehicle that
[51:15.720 --> 51:21.800]  goes into a wall while there was nothing on the road. Those kind of situations are the one that
[51:21.800 --> 51:29.080]  at least allow a victim to make the claim and go in court and try to get the compensation.
[51:29.080 --> 51:36.600]  If the product was not defective, well, then there is no problem. Again, when we talk about
[51:36.600 --> 51:43.720]  software, this is not a zero bug that we are talking about. We are talking about expectation
[51:43.720 --> 51:49.560]  that you have about the software, the fact that your software should not overheat your boiler,
[51:50.600 --> 51:57.560]  the fact that the pilot, the software pilot in your plane should not push down while you're
[51:57.560 --> 52:03.400]  trying to go up. Those kind of things, these are the situations that we're talking about.
[52:03.400 --> 52:10.040]  These are a bit of technical situation, but we have what we call a disclosure of information.
[52:13.160 --> 52:21.240]  Only the manufacturer of the product itself knows the product. As a victim, you need to have access
[52:21.240 --> 52:31.640]  to some sort of information, like the data used, any kind of evidence that could be of an help
[52:31.640 --> 52:38.200]  to create the claim. Obviously, those information are protected by trade secrets.
[52:39.000 --> 52:46.120]  This is not a way of giving away your secrets. They are protected through courts.
[52:46.760 --> 52:54.760]  There are systems. We have years and years of practice in national system, in tribunals,
[52:54.760 --> 53:02.280]  to know exactly what can be showed, how can it be showed, and what to protect. But there should be
[53:02.280 --> 53:13.080]  an access to the necessary information for that. Finally, this is a bit of the small details
[53:13.960 --> 53:21.400]  that have been changed. There was a ceiling before for claims, before you could not get
[53:21.400 --> 53:27.400]  more than 70 million. I mean, we're not talking about every claim will be 70 million. Let's put it
[53:27.400 --> 53:33.160]  like this. But there was a ceiling cap. This has been removed. Nothing explained that you should
[53:33.160 --> 53:41.160]  limit it in number of money. There was a threshold. If your damage was less than 500 euros, you could
[53:41.160 --> 53:50.040]  not have any claim for liability. And then the liability as a time period, you're not liable
[53:50.040 --> 53:56.200]  for 300 years. You're liable for 10 years after putting on the market your product.
[53:56.840 --> 54:04.760]  After that, you cannot be held liable under these rules. But there is a time limitation.
[54:04.760 --> 54:13.640]  This allows to predict and to ensure the risk of your business, if it's a business, or of your
[54:13.640 --> 54:21.560]  product. And there has been a small adaptation for personal injuries. This is typical for some
[54:21.560 --> 54:29.720]  specific product like pharmaceutical products where the damage appears after. I mean, I didn't go
[54:29.720 --> 54:34.840]  into all the details, but the product liability does not apply only to software. It's one of the
[54:34.840 --> 54:42.760]  product. We're talking about chairs, cars, pharmaceutical product, all of them. So any damage
[54:42.760 --> 54:49.720]  that any of those products will cause, you would have a claim for compensation. So that's it from
[54:49.720 --> 55:03.080]  me. Thank you very much. I hope there was not too technical. Thank you, Omar. We're going to go
[55:03.080 --> 55:10.040]  now to the panel, and I will introduce James Lovegrove from Red Hat, our policy director.
[55:10.040 --> 55:15.800]  Who will be the moderator? So I'm giving the mic to James.
[55:19.480 --> 55:26.280]  Very good. Welcome, everyone. I appreciate that we're halfway through the session. So if you
[55:26.280 --> 55:33.320]  want to stand up and then sit down and stretch your arms, that's fine. So in terms of the first
[55:33.320 --> 55:39.960]  and weekend, I mean, yesterday we had the policy summit brought together a couple of hundred people
[55:39.960 --> 55:44.680]  in person and hundreds more online, I understand. But what's interesting is only five, six years ago
[55:44.680 --> 55:51.240]  when we started it in earnest, as the OFE is in the crowd, there was literally, I see, it was there,
[55:51.240 --> 55:56.280]  there were sort of 14, 15 people in the room. So I mean, that massive scaling is interesting in the
[55:56.280 --> 56:03.720]  sense of a response to the growth of EU policy impacting digital ecosystems, open source included,
[56:04.360 --> 56:10.120]  but also the intent and realization that as a community of open source practitioners, further
[56:10.760 --> 56:15.320]  collaboration and coordination is absolutely essential. I think today is a good example
[56:15.320 --> 56:21.240]  where the Commission see that as well. We're joined today by three members of the European
[56:21.240 --> 56:27.640]  Commission from Digit, from Grow, from Connect, and frankly, I think they're worth a shout out
[56:27.640 --> 56:30.440]  and a round of applause. It's a big deal having them here. Thank you.
[56:36.280 --> 56:41.080]  So, I mean, music to our ears, Benjamin Meade really clear up there. He mentioned rational
[56:41.080 --> 56:47.720]  to exclude non-commercial open source. So, you know, the door is open, the ears are open,
[56:47.720 --> 56:54.600]  but this is a complex process. Yesterday, we were talking about the analogy of trains,
[56:54.600 --> 56:59.720]  leaving stations and so forth, and yeah, it's now en route. It's going through quite a complex
[57:00.520 --> 57:06.040]  co-regulatory process, and as a community, we don't have the resources in many cases to
[57:06.040 --> 57:11.240]  actually keep up with that. So this kind of collaboration is absolutely critical if we're
[57:11.240 --> 57:16.760]  going to reflect that rationale of best practices when it comes to open source, but also best practices
[57:16.760 --> 57:21.240]  in terms of the tools that we're talking about into the law, into the practice. Otherwise,
[57:21.240 --> 57:27.880]  there will be unintended consequences, and I think nobody wants to hear that. I think the final
[57:27.880 --> 57:36.120]  point I want to make just before I hand over to our first panelist is that even if we get the
[57:36.120 --> 57:43.160]  open source exclusion and some of the clarity into the text and the articles around open source,
[57:43.160 --> 57:49.080]  it's still kind of half of the journey, and I think that's important just to underscore. There
[57:49.080 --> 57:56.120]  are still elements which need further discussion on how they practically impact this extraordinary
[57:56.120 --> 58:04.360]  ecosystem, and I think without further joining, I'm going to hand over to Zoe, who is a senior
[58:04.360 --> 58:09.640]  policy manager from Digital Europe. I'll let her introduce what the organization does and who it
[58:09.640 --> 58:15.480]  represents, but it's a big deal when it comes to engaging with EU policymakers both here in
[58:15.480 --> 58:20.840]  Brussels but across the Union, and it's great to have her here to let us know what Digital Europe
[58:20.840 --> 58:32.040]  thinks about this. Thanks. Thank you, James. Thanks a lot, everyone, and indeed many thanks to
[58:32.040 --> 58:37.000]  the organizers of the panel, but also to the commission. We also do really appreciate that
[58:37.000 --> 58:42.440]  you always take the time, and I know how much effort you're putting on this legislation. So
[58:43.160 --> 58:50.040]  Digital Europe is an industry trade association. For those that you don't know, we represent
[58:50.840 --> 58:56.760]  the tech industry that is active in Europe, but we also obviously represent both, well,
[58:56.760 --> 59:02.920]  global actors from across all regions that they are doing business in the tech industry in Europe,
[59:02.920 --> 59:07.400]  and we have two chambers of members. We have the corporate ones, and we also have the national
[59:07.400 --> 59:13.960]  trade associations, that this gives us an outlook on both the global scale of things, but also on
[59:13.960 --> 59:19.560]  the national level. So through our trade, national trade associations, we also represent all sizes,
[59:19.560 --> 59:31.320]  including SMEs, for example. So why are we here is that's because we think that the Cyber Resilience
[59:31.320 --> 59:37.800]  Act is one of the most pivotal legislations that we are going to have, well, now with this mandate,
[59:37.800 --> 59:43.080]  but in general, it's a trendsetter. It's a very, very important legislation. At Digital Europe,
[59:43.080 --> 59:49.800]  we do a sort of internal search to see what is important for our members to make sure that our
[59:49.800 --> 59:57.640]  resources are allocated accordingly, and AI, data, and the Cyber Resilience Act have been ranked as
[59:57.640 --> 01:00:04.520]  the three highest priorities for the digital industry. So I just want to emphasize again how
[01:00:04.520 --> 01:00:09.800]  important this legislation is, and thank again the organizers for really taking the time to
[01:00:09.800 --> 01:00:17.080]  highlight this. Now, I think it's probably one of the first times that the industry and NGOs really
[01:00:17.080 --> 01:00:24.280]  agree. So Martin's presentation was very interesting, and I noted down many of the points that we also
[01:00:24.280 --> 01:00:31.480]  highlight in our position. I also want to take a moment to say that you probably wonder, especially
[01:00:31.480 --> 01:00:38.920]  the open source community, you wonder why the industry, the big tech or multinationals, why do
[01:00:38.920 --> 01:00:45.560]  they care about the open source community. So actually, I just wanted to clarify that for us,
[01:00:45.560 --> 01:00:50.840]  it's very, very important to make sure that the open source community is not overburdened by this
[01:00:50.840 --> 01:00:58.520]  legislation. For many of our members, even up to 100% of their commercial products have
[01:00:58.520 --> 01:01:05.880]  rely on open source components. And just like James said, there are many priorities, many
[01:01:05.880 --> 01:01:10.760]  things that we can improve at this area, but not overburdening the open source community is one of
[01:01:10.760 --> 01:01:18.360]  our top priorities as well. So it is also important to note that it's a bit of a stereotype to think
[01:01:18.360 --> 01:01:26.120]  that the big tech companies, for example, they only rely on closed source and they don't care
[01:01:26.120 --> 01:01:31.240]  about the open source community. But I want to highlight that for us, it is a very, very high
[01:01:31.240 --> 01:01:37.080]  important to make this a key priority for the CRA to have clarity on what this means for the
[01:01:37.080 --> 01:01:43.080]  open source community. So I'm not going to repeat too much myself because you already said it,
[01:01:43.080 --> 01:01:50.680]  Recital 10 excludes open source. And we very much welcome this. And in general, we welcome the
[01:01:50.680 --> 01:01:55.560]  legislation. It's a very good draft. It's something we can really work with. And we need it. Let's
[01:01:55.560 --> 01:02:01.160]  start from that. We all agree, also the private sector, that we absolutely need these type of
[01:02:01.160 --> 01:02:06.520]  requirements. So we are very willing to find a way together that makes it work. But we really need
[01:02:06.520 --> 01:02:14.920]  to get it right, including too much, too soon can also be very damaging. So for open source,
[01:02:14.920 --> 01:02:23.000]  there is a conundrum of it's excluded, but not really. So the tech says that it's not in, but
[01:02:23.000 --> 01:02:28.360]  then when you look at the commercial element of it, and if you look at the definition of what
[01:02:28.360 --> 01:02:34.200]  commercial is under the blue guide of the new legislative framework, it says that commercial
[01:02:34.200 --> 01:02:40.040]  is understood as providing goods in a business-related context. So what does this mean for the
[01:02:40.040 --> 01:02:45.240]  open source community? What does the business context mean? Most, like I said before, many
[01:02:45.240 --> 01:02:52.440]  of the commercial products rely on open source components. So we need clarity. Right now,
[01:02:52.440 --> 01:02:57.880]  if you look at the document, there are 85 pages. Commercial is mentioned only twice and there
[01:02:57.880 --> 01:03:04.360]  is no definition. But this brings me to the bigger element, the issue of the proposal that
[01:03:04.360 --> 01:03:09.800]  we really see. One, we really welcome the fact that the NLF is the approach that is chosen.
[01:03:12.280 --> 01:03:16.280]  Benjamin did a great job explaining the NLF and the same marketing and everything
[01:03:16.280 --> 01:03:24.440]  related tangible products. The big quest right now is how to move a regime that has been so
[01:03:24.440 --> 01:03:31.400]  working very well. We think for tangible products, but now the biggest challenge is the CRA wants
[01:03:31.400 --> 01:03:38.280]  to transform this regime into something that is workable for software, which is again very welcome
[01:03:38.280 --> 01:03:47.240]  because NLF has proven to be the right way to do things. But we really need to work more on the
[01:03:47.240 --> 01:03:53.080]  definitions. So commercial is just one way, one example. Then there are other examples,
[01:03:53.080 --> 01:04:00.280]  like components. In article 11, when it comes to reporting, it says that manufacturers have to
[01:04:00.280 --> 01:04:09.800]  also report on vulnerabilities including soft open source components in paragraph 7. So the
[01:04:09.800 --> 01:04:15.400]  question there is, what does a component mean in the context of a software as well? So this is a
[01:04:15.400 --> 01:04:21.080]  general comment on how we really need to work together to transform NLF into something that
[01:04:21.080 --> 01:04:26.520]  makes sense for software. This is why at Digital Europe we have been really advocating for a
[01:04:26.520 --> 01:04:33.880]  clear provision asking the commission to develop guidelines that they adapt to the
[01:04:33.880 --> 01:04:42.280]  specificities of software and specifically standalone software. With the inclusion of
[01:04:42.280 --> 01:04:46.440]  the industry, because what we see here is that the people that are going to actually have to
[01:04:46.440 --> 01:04:52.360]  abide by the new compliance rules, the industry players, are not really included in the draft in
[01:04:52.360 --> 01:04:56.600]  the sense that we really want to be part of an expert group, that we are going to help the
[01:04:56.600 --> 01:05:01.560]  commission, that we know has the appetite to do this right. But we bring the experience and we
[01:05:01.560 --> 01:05:06.360]  bring the questions also. What does this mean? What does placement of the market for software,
[01:05:06.360 --> 01:05:11.480]  for example, mean? What does substantial modification mean? So all these things,
[01:05:11.480 --> 01:05:17.240]  we, I think the important thing is that we all see that we have the appetite, but it still needs
[01:05:17.240 --> 01:05:23.720]  to be clarified in the text. And maybe just as a final point, all these things need time.
[01:05:23.720 --> 01:05:31.080]  And I really welcome the question before on standardization. We appreciate that 90% of the
[01:05:31.080 --> 01:05:37.320]  products that rely on self-assessment and when existing harmonized standards are there.
[01:05:37.320 --> 01:05:43.080]  But we also need to look at what does this 10% mean for critical products? Have we actually made
[01:05:43.080 --> 01:05:48.120]  an assessment of how much of the burden is for third-party conformity, for example, are notified
[01:05:48.120 --> 01:05:57.720]  but is ready? So these all means that we need time to get it right. The current proposal says
[01:05:57.720 --> 01:06:05.320]  24 months for implementation, for the development of harmonized standards, sorry, and for the
[01:06:05.320 --> 01:06:11.560]  development process is just too little. And I think this is probably something we are more or
[01:06:11.560 --> 01:06:17.880]  less aligned on that we need more time. And for us, the proposal is 48 months, but I know this
[01:06:17.880 --> 01:06:22.840]  is something we will discuss further with the commission and with the colleagues later. Okay,
[01:06:22.840 --> 01:06:27.240]  so I don't want to go into more, there is way more there. Maybe just as a final comment,
[01:06:28.520 --> 01:06:34.680]  even if, as James said, even if we get the open source exclusion right, there are several things
[01:06:34.680 --> 01:06:40.440]  that need to work in the whole context of software, including reporting obligations.
[01:06:42.520 --> 01:06:49.320]  The right timelines right now, it says 24 hours for initial notification to be, but we want it
[01:06:49.320 --> 01:06:54.440]  to be aligned fully with the needs directive because we think it's just introducing too many
[01:06:54.440 --> 01:07:01.640]  processes is just too much. And yeah, I mean, I don't want to go too much into more details
[01:07:01.640 --> 01:07:06.840]  because James is giving me a smile that says that I've talked too much. Thank you very much.
[01:07:07.800 --> 01:07:17.240]  Thank you, Zoe. Well done. So I'm going to now turn to Rom, a colleague of mine, as you know,
[01:07:17.240 --> 01:07:23.720]  Red Hat is an upstream first pure play open source software company. And therefore,
[01:07:24.520 --> 01:07:31.080]  Rom spends a lot of his time, maybe a lot of most of his time upstream as a volunteer, as a
[01:07:31.080 --> 01:07:37.000]  developer, as a contributor. So I'd be interested in hearing your perspective. As Martin was
[01:07:37.000 --> 01:07:43.400]  mentioning, you know, he has a particular perspective on it from DNS and now the sort of
[01:07:43.400 --> 01:07:49.080]  wider larger ecosystems are involved in the kinds of products and projects that Red Hat's involved
[01:07:49.080 --> 01:07:56.440]  in. And to Omar's point earlier about just getting real on zero bugs being impossible
[01:07:56.440 --> 01:08:01.400]  in the concepts of PLD, I think that's an important point to underscore and something which, you
[01:08:01.400 --> 01:08:06.440]  know, the no known vulnerabilities, implications for open source or even for proprietary, not
[01:08:06.440 --> 01:08:11.480]  that I care much about proprietary, but nonetheless, it is important to have that recognized that
[01:08:11.480 --> 01:08:16.200]  the commission understands that, but it needs reflecting, as I say, in the text to make sure
[01:08:16.200 --> 01:08:22.760]  that clarity is clear. So, Rom, I'm going to come over to you and give you the microphone.
[01:08:22.760 --> 01:08:30.680]  Thank you. Yeah, so we are in a unique position at Red Hat of being a large contributor for the
[01:08:30.680 --> 01:08:36.120]  open source. And if you look at the portfolio of product that we have, I think we're depending
[01:08:36.120 --> 01:08:41.960]  and contributing to about more than a million different open source projects. That's the level
[01:08:41.960 --> 01:08:51.640]  of contribution. One particular example that James was mentioning is the look at critical
[01:08:51.640 --> 01:09:00.360]  systems, but also critical products like credentials and the zero bug. We all know that zero bug
[01:09:00.360 --> 01:09:07.320]  policy is impossible to achieve. And I'm really glad that Omar underlined this. But the reality is
[01:09:07.320 --> 01:09:15.000]  that if we don't have clear definition about this, it's going to slow down so much contribution,
[01:09:15.000 --> 01:09:21.160]  so much innovation that we have. And we already see that through the lens of our internal folks
[01:09:21.160 --> 01:09:27.160]  and myself for some project that I'm working on from communities, maybe you know communities,
[01:09:27.960 --> 01:09:33.480]  with the special interest group for authentication and key management system,
[01:09:34.440 --> 01:09:41.560]  there's a lot of people scared there. And sometimes we're looking into putting into,
[01:09:41.560 --> 01:09:51.640]  I would say into the product, new features that we deem interesting. And we truly believe that
[01:09:51.640 --> 01:09:58.760]  it will be a game changer for the community and putting a product in production. But in the
[01:09:58.760 --> 01:10:06.920]  meantime, we are really scared because we are not able to make a full interrupt compatibility
[01:10:06.920 --> 01:10:13.880]  assessment with all the different projects. As I said, one million projects. Can you imagine if
[01:10:13.880 --> 01:10:21.000]  you start having the need to go through the full cycle of integration and testing for this?
[01:10:21.720 --> 01:10:28.520]  We try to do it at Red Hat. And that's sometimes the reason why when you look at the difference
[01:10:28.520 --> 01:10:33.640]  between what you find in the community with Fedora, or I'm doing a bit of marketing now,
[01:10:33.640 --> 01:10:42.760]  about Fedora, or CentOS, or I would say OKD, you will see that there's a major gap between
[01:10:43.400 --> 01:10:48.760]  what we have there, which is like top edge cutting edge solution versus what we have in
[01:10:48.760 --> 01:10:56.760]  the product. Because we're scared about it. Not scared in a sense that we don't want to
[01:10:56.760 --> 01:11:01.080]  give innovation, but we are scared about what would be the end goal, the end results,
[01:11:01.080 --> 01:11:09.320]  if we are becoming responsible also for some breaches. With credentials, and the work I'm
[01:11:09.320 --> 01:11:20.520]  doing on contributing, actually, because we are about 112 person working on this, we look
[01:11:20.520 --> 01:11:26.280]  into this perspective, this lens of compliance and regulation. And no later than yesterday,
[01:11:26.280 --> 01:11:35.000]  I was in one of our company events where we had 1200 people, techie people, we're interested
[01:11:35.000 --> 01:11:41.640]  in technology, and we were discussing a group of 60 there about this. And that's the moment
[01:11:41.640 --> 01:11:45.000]  some people were like, oh, I'm not going to touch this, I don't want to be responsible of this.
[01:11:46.040 --> 01:11:52.680]  So we need more clarity, we need more understanding. So when we see the law, and that's what I would
[01:11:52.680 --> 01:12:00.440]  really love to have, it's to have more like a framework where we can share this with the community
[01:12:00.440 --> 01:12:09.480]  and make sure that we can put straight upstream those perspective, those regulation compliance
[01:12:09.480 --> 01:12:17.800]  perspective, so that you guys are not afraid of contributing to any top notch cutting edge solutions.
[01:12:17.800 --> 01:12:24.040]  Credential is one of them. If you know a bit communities, you know that it's nothing related
[01:12:24.040 --> 01:12:30.040]  to password managers, but as soon as you're using secrets with communities, then it becomes a
[01:12:30.040 --> 01:12:37.400]  password managers. And it's a critical class one product then. And so it's those kind of things
[01:12:37.400 --> 01:12:44.200]  that nobody think about, but we need to get that into perspective so we understand what needs to
[01:12:44.200 --> 01:12:49.800]  happen then in the product. So there's specific elements to take care. And there's a cycle of
[01:12:49.800 --> 01:12:56.760]  work that is really, I was going to say burden, but we all know that when we do software, we need
[01:12:56.760 --> 01:13:04.680]  to go through a secure supply chain. This is the buzzword of 2022 and 2023. But it's a reality.
[01:13:04.680 --> 01:13:10.920]  And I like the comment about the ISO part. There's so many different ways to standardize this.
[01:13:10.920 --> 01:13:18.440]  There's so many ways. There's the best practices from an industry standpoint. There's guide. I
[01:13:18.440 --> 01:13:26.600]  think the EU has the blue guide also where you can have some guidelines. So there's different ways
[01:13:26.600 --> 01:13:35.240]  to approach this. But it's an ethical responsibility to apply it. And sometimes, well, we are so
[01:13:35.240 --> 01:13:40.840]  carry on with our innovation that we forget about it. We're like, oh, we should do it like this.
[01:13:41.480 --> 01:13:46.280]  And so that's the other side. I'm really worried about the regulation. But in the meantime,
[01:13:46.280 --> 01:13:51.080]  I'm really happy that there's something there to enforce us straight from the beginning
[01:13:51.080 --> 01:13:56.440]  to have this secure supply chain in perspective. That's for me, actually.
[01:13:56.440 --> 01:14:03.720]  Great. Thanks, Ron. Yeah. So I think one of the things I took from that is,
[01:14:04.440 --> 01:14:10.680]  and I think this penny is dropping, not just in this room, but elsewhere, is that software is
[01:14:10.680 --> 01:14:21.160]  fungible. And I think some of the terms in the draft regulation around intended purpose around
[01:14:21.160 --> 01:14:30.360]  sorry, it's calling from my son. Probably not a good time by Sam. Yeah. So in terms of intended
[01:14:30.360 --> 01:14:37.960]  purpose, reasonably foreseeable, any known or foreseeable circumstances, I think that's something
[01:14:37.960 --> 01:14:44.920]  which gives open source a pause for concern. And I think one of the reasons is coming from an
[01:14:44.920 --> 01:14:50.840]  open source licensing perspective is that bringing that community together is not just a question
[01:14:50.840 --> 01:14:57.400]  of passion to solve problems and build our open innovation in Europe, but also to be shielded.
[01:14:58.520 --> 01:15:04.200]  So developers do not incur liability nor offer warranties. And I think that's something which
[01:15:04.760 --> 01:15:11.400]  is clearly important. And actually, it's a good segue to Chris, because in his capacity at Digit,
[01:15:12.040 --> 01:15:19.320]  in the open source program office, the EUPL is one of such license, which again,
[01:15:19.320 --> 01:15:25.560]  is important to open source contributors, collaborators. So I'd be interested to hear
[01:15:25.560 --> 01:15:34.280]  more from your perspective by Sam, and understand from your thoughts on this particular topic.
[01:15:34.280 --> 01:15:39.960]  Thanks. Thank you. And it's very good to be back at FOSTA, people. I think we all agree.
[01:15:42.360 --> 01:15:46.280]  This legislation, of course, also impacts the commission open source projects.
[01:15:46.280 --> 01:15:55.400]  So we're looking forward to figuring out how to work on this. To give you a bit of perspective,
[01:15:55.400 --> 01:16:01.720]  so I talk on behalf of the European Commission's open source program office, and going to quote
[01:16:01.720 --> 01:16:08.200]  the words from Deborah Bryant yesterday, we're basically, for you, an easy to find, easy to access
[01:16:08.200 --> 01:16:14.760]  way to find out who to talk to amongst our colleagues. We will do the legwork, we'll find out who we
[01:16:14.760 --> 01:16:21.240]  should put you in touch with, we'll find out who to talk to. And we will liaise when necessary
[01:16:21.240 --> 01:16:26.440]  between the commission policymakers and the open source community. So that's one thing I can
[01:16:26.440 --> 01:16:33.000]  promise you, we'll try and make this happen. A little bit about the OSPO, James, is that okay,
[01:16:33.000 --> 01:16:40.840]  as context, so we started in 2020, thanks to a communication from the commission to itself,
[01:16:40.840 --> 01:16:48.200]  about an open source strategy that recognized that if the commission wants to reach its political
[01:16:48.200 --> 01:16:53.640]  goals, it needs to basically take into account that in everything there is software and in
[01:16:53.640 --> 01:17:01.080]  all the major political goals, open source is a critical component. To be an industry, to be a
[01:17:01.080 --> 01:17:07.640]  European market, to be active in innovation, to be active in competition, open source is there
[01:17:07.640 --> 01:17:15.960]  and it can't be taken out. One of the first things we did as OSPO is make it super easy
[01:17:15.960 --> 01:17:22.360]  for the commission to disseminate its open source process. So far, previously it was a
[01:17:22.360 --> 01:17:27.000]  paperwork process that would take six months, now it is basically up to the project to the
[01:17:27.000 --> 01:17:33.160]  site, we want to go open and we have a code repository, code.europa.tu, which now has some
[01:17:33.160 --> 01:17:41.000]  200 projects and 700 users and this is from the commission, from ISMA, from DigiConnect,
[01:17:41.000 --> 01:17:45.880]  from JRC, from the European Central Bank, from the EDPS, so you should check that out and maybe
[01:17:45.880 --> 01:17:50.280]  start working on some of these solutions and this also shows that we will be impacted because
[01:17:50.280 --> 01:17:53.480]  we're pulling in an enormous amount of open source to build these components.
[01:17:53.480 --> 01:18:03.640]  Another thing that I think is good for you to realize is that we're, as a commission,
[01:18:03.640 --> 01:18:09.560]  OSPO in touch with OSPs in the member states. Some of them are here, I have my colleagues
[01:18:09.560 --> 01:18:14.120]  from Germany on the right for you on the left and the colleagues from the Czech Republic on the
[01:18:15.080 --> 01:18:20.280]  left for me, so on the right for you and we're in touch with these specifically for this kind
[01:18:20.280 --> 01:18:25.960]  of reasons. We need to network as OSPOs, we need to avoid making mistakes that others have made
[01:18:25.960 --> 01:18:34.920]  before us and work as a group. I think I'll stop here, it's a good introduction. Very good, thanks
[01:18:34.920 --> 01:18:46.520]  Case. So I am conscious we have, if I'm right, another half an hour, 25 minutes, is that right?
[01:18:46.520 --> 01:18:55.800]  So I would like to give Benjamin the floor just to capture some of the thoughts I see you scribbling
[01:18:55.800 --> 01:19:00.120]  down, I hope I put you on the spot, but I'm sure some of them are familiar and it would be really
[01:19:00.120 --> 01:19:08.520]  good to hear from you on this, thanks. Great, thank you so much, Jamin, actually all the points
[01:19:08.520 --> 01:19:16.920]  are familiar to me. We are of course engaging a lot with stakeholders and as the Commission,
[01:19:16.920 --> 01:19:23.240]  we are now in a tricky position because we made the proposal and it's of course the Commission's
[01:19:23.240 --> 01:19:29.160]  view that our own proposal is perfect the way it is. That being said, it's the beginning of the
[01:19:29.160 --> 01:19:36.040]  journey and it goes without saying that the Parliament and Council will closely look at the
[01:19:36.040 --> 01:19:41.400]  text and they're of course also consulting us a lot and many of the things that have been
[01:19:41.400 --> 01:19:45.480]  mentioned here, they are being discussed by the co-legislators. So for example, this question of
[01:19:47.880 --> 01:19:52.920]  providing products with no known vulnerability, I mean, I can say that this is being discussed
[01:19:52.920 --> 01:19:59.560]  already by the co-legislators and also, I mean, we've heard quite often already this, I mean,
[01:19:59.560 --> 01:20:04.280]  this concern that maybe the transition period is too short. I mean, we believe that 24 months
[01:20:04.280 --> 01:20:10.600]  is sufficient but we hear this a lot from other stakeholders. So I mean, you can be sure that
[01:20:10.600 --> 01:20:21.800]  this is being all taken very seriously from us. Wonderful. Now folks, it's really important that
[01:20:21.800 --> 01:20:28.520]  this community here in this room take this opportunity. It's not a speak now or forever
[01:20:28.520 --> 01:20:35.000]  hold your peace but it is a good opportunity. So if there are any who want to chime in a question,
[01:20:36.040 --> 01:20:43.880]  comment, that would be great. And then we're going to move back to the panel. Who's first?
[01:20:43.880 --> 01:20:53.080]  I think you're first. I already stole your mic, sorry. Okay, go for it.
[01:20:53.080 --> 01:20:58.200]  Sorry. So, well, I'll try to be brief but there's a lot to say. So first I have to apologize
[01:20:58.200 --> 01:21:03.480]  because I feel about this. So I will be carried away. Sorry. Nothing I'm going to say is meant
[01:21:03.480 --> 01:21:07.880]  to be offensive to the commission. Actually, I think that many of the recent acts are very good
[01:21:07.880 --> 01:21:12.200]  for the internet industry, for the internet, like the digital market sector. So the criticism
[01:21:12.200 --> 01:21:19.720]  will not be meant as a rejection of regulation. So my perspective, I'm the software developer
[01:21:19.720 --> 01:21:24.920]  and I'm the head of policy for open exchange which is a German open source software maker
[01:21:24.920 --> 01:21:30.440]  of around 270 people. So I'd say that we are small if compared to the big tech industries
[01:21:30.440 --> 01:21:34.520]  from globally. But we are still one of the biggest. So we are also one of the companies that,
[01:21:34.520 --> 01:21:39.800]  I mean, we make stuff that is in every Linux distribution like Davcott and so we care about
[01:21:39.800 --> 01:21:46.120]  security. We are ISO certified, ISO 27.1. So we are among those that could afford to follow
[01:21:46.120 --> 01:21:50.680]  everything that's in the Sierra and would do that. But we are part of an ecosystem.
[01:21:50.680 --> 01:21:54.360]  And so we feel the need to, I mean, also bring the perspective of others,
[01:21:54.360 --> 01:21:59.240]  including some smaller projects that we use in our own projects. And the problem with this
[01:21:59.240 --> 01:22:03.800]  regulation is, well, there are multiple problems. Let's start from the non-commercial exemption.
[01:22:03.800 --> 01:22:09.880]  So there isn't really no way that you can tell commercial projects from non-commercial projects
[01:22:09.880 --> 01:22:15.240]  because each and every project except maybe like my hobby project which I only, I mean,
[01:22:15.240 --> 01:22:20.120]  do for myself and publish somewhere, has some economic result, creates a value. And there
[01:22:20.120 --> 01:22:25.720]  will be people using it to create further value. And so it is basically very hard to write a
[01:22:25.720 --> 01:22:31.400]  non-ambiguous way to tell commercial from non-commercial. And all projects, including like,
[01:22:31.400 --> 01:22:36.600]  I mean, search centers, like NLNet universities need some money to, we need to get at least
[01:22:36.600 --> 01:22:41.240]  donations. And so there is no way you can prevent, you can tell this. And on the other hand,
[01:22:41.240 --> 01:22:45.080]  I would also be against in saying that all open source software is exempt from this regulation
[01:22:45.080 --> 01:22:49.480]  because I'm sure that the proprietary software makers would come and say, you know, as they have
[01:22:49.480 --> 01:22:53.000]  been saying for 20 years, you know, open source is just a toy, it's just a hobbyist project,
[01:22:53.000 --> 01:22:57.400]  so you should use proprietary software which is secure. So don't do that. The problem is really
[01:22:57.400 --> 01:23:03.000]  that this law doesn't seem to understand how software works. I mean, software, pure software,
[01:23:03.000 --> 01:23:07.560]  material products have a nature which is significantly different than any physical
[01:23:07.560 --> 01:23:11.640]  product with software on it. So this regulation seems to be designed with cars in demand,
[01:23:11.640 --> 01:23:16.920]  with toys, with IoT devices, but not for pure software. Pure software is more similar to
[01:23:16.920 --> 01:23:22.600]  literature in a way. It's something that is the result of collective development. And if you have
[01:23:22.600 --> 01:23:27.160]  a look at open source projects, I mean, yes, we are the manufacturers of Dovcott, but if you look
[01:23:27.160 --> 01:23:33.000]  at the code, it's written by people everywhere on the planet. So yes, but the real authors are
[01:23:33.000 --> 01:23:38.120]  maybe like a thousand people which are in Europe, outside of Europe, everywhere. And so your law seems
[01:23:38.120 --> 01:23:43.000]  to put the burden of like putting a CE mark on every line of code which is imported into Europe.
[01:23:43.000 --> 01:23:47.000]  I don't even know what that means. I mean, we have repositories, maybe they are in Europe,
[01:23:47.000 --> 01:23:51.080]  but they are mirrored in the US. There's people from Australia, I'm from China, I'm putting code
[01:23:51.080 --> 01:23:55.640]  into it. And this code is traveling all over the world throughout the borders of the European Union
[01:23:55.640 --> 01:24:01.160]  several times per second. So should I, every time I check some code, I mean, someone should
[01:24:01.160 --> 01:24:05.800]  stop the code at the border and put the CE mark. This doesn't really make any sense. It's simply
[01:24:05.800 --> 01:24:12.440]  impossible. And it is to say, I mean, all the people here, I mean, your law is designed for the
[01:24:12.440 --> 01:24:16.680]  traditional 20th century way of making things in which there's a manufacturer and there's a
[01:24:16.680 --> 01:24:22.040]  distributor and someone that sells them in a shop and then there's the user, the consumer. I mean,
[01:24:22.040 --> 01:24:25.880]  like if we were still buying, sorry, I'm trying to be short, but I know you want to stop me,
[01:24:25.880 --> 01:24:32.360]  but I have to say this. Yeah. And so this seems designed for the time when we went to the shop
[01:24:32.360 --> 01:24:38.520]  to media market and bought Windows 95 in a box on a CD. And this is not how it works. Everyone
[01:24:38.520 --> 01:24:43.800]  here is at the same time, a manufacturer, a distributor, an importer, and a user of code.
[01:24:43.800 --> 01:24:47.640]  And there's no way you can distinguish these roles. So you have to find something,
[01:24:48.840 --> 01:24:54.520]  you have to find somewhere. So no, I can cut it short. So I don't understand the problem you're
[01:24:54.520 --> 01:24:59.320]  trying to solve. Show me one case in which a European piece of open source software had
[01:24:59.320 --> 01:25:04.520]  a problem that created issues with the entire world, and how this could be solved by this
[01:25:04.520 --> 01:25:08.840]  regulation. Because if you just maybe funded some security audits for projects that cannot afford
[01:25:08.840 --> 01:25:13.720]  them, this would make a much bigger effect. So let's start again discussing from software for
[01:25:13.720 --> 01:25:17.960]  something specific for software, because this really is not working. Thank you. Thank you.
[01:25:17.960 --> 01:25:40.360]  So I submitted the Openform Europe document that Martin referenced. I probably have a
[01:25:40.360 --> 01:25:45.160]  dozen questions, but I picked one. So to publish software in the EU or to import software into
[01:25:45.160 --> 01:25:50.040]  the EU, the publisher must perform CRA certification and accept CRA obligations.
[01:25:50.040 --> 01:25:53.560]  So this means that software from outside the EU will no longer be available in the EU
[01:25:53.560 --> 01:25:57.960]  if those developers do not perform CRA certification or accept CRA obligations.
[01:25:57.960 --> 01:25:59.720]  How is that not a massive problem?
[01:25:59.720 --> 01:26:24.440]  Yeah, I think my understanding is one of the goals of the CRA is to avoid
[01:26:24.440 --> 01:26:29.720]  log 4j or open source type of incidents, but they are non-commercial open source software.
[01:26:30.280 --> 01:26:37.320]  And when we exclude them from CRA, we are technically not addressing these cases. So what
[01:26:37.320 --> 01:26:45.000]  do you think about this? And as a solution, what do you think about expanding the proposal to set
[01:26:45.000 --> 01:26:52.360]  up necessary operational financial assistance dedicated to the critical open source initiatives?
[01:26:52.360 --> 01:26:59.080]  Maybe especially the EU ones, maybe European Ospo. Is that feasible?
[01:27:04.280 --> 01:27:10.200]  Thank you, Alex. Thanks. Thanks for the insights and thanks for the panel. I mean,
[01:27:10.200 --> 01:27:15.480]  I have two questions. We have a lot of problems, but I'm interested in solutions.
[01:27:15.480 --> 01:27:22.760]  So first, what's your proposal to fix this commercial term? So do we have one? Could you let
[01:27:22.760 --> 01:27:29.240]  us know? And the second one to the commission. So do you see the issue like NL net? So would
[01:27:29.240 --> 01:27:35.080]  you consider charities to be affected by this definition or not? So what's the commission
[01:27:35.080 --> 01:27:47.560]  take on the NL net position? Thank you. Thank you very much. And finally, we've known for a long
[01:27:47.560 --> 01:27:53.560]  time since David Wheeler wrote his paper stating that all open source software is commercial,
[01:27:54.200 --> 01:27:58.600]  that the word commercial is a bad word to use if you want to exclude open source.
[01:27:58.600 --> 01:28:04.600]  And so I recognize that it arises from the courts in Europe and from the blue book,
[01:28:04.600 --> 01:28:12.200]  but have you considered using different terminology to solve the conflict that exists here because
[01:28:12.200 --> 01:28:18.200]  of the nature of the community you're addressing rather than because of the context of the existing
[01:28:18.200 --> 01:28:26.040]  legislation? And secondly, which community organizations did you consult in working on
[01:28:26.040 --> 01:28:33.160]  working on both the PLD and the CLA? You see the panel is comprised purely of commercial
[01:28:33.160 --> 01:28:39.480]  organizations or commission members. And all of the questions you've received are from community
[01:28:39.480 --> 01:28:44.680]  charity representatives who are in the audience and on the panel. I wonder what you're going to do
[01:28:44.680 --> 01:28:57.080]  to fix this problem so that you don't get it with every subsequent bill. Thank you.
[01:29:02.120 --> 01:29:06.200]  Yeah, thanks a lot for all these questions. I mean, maybe first this one on who we consulted.
[01:29:06.200 --> 01:29:15.640]  So as a run up to any commission proposal, there is a public consultation which runs for three
[01:29:15.640 --> 01:29:21.240]  months. It's a period of three months where we ask a set of questions to the public and everyone
[01:29:21.240 --> 01:29:25.800]  can respond to these questions, including you. I mean, maybe you didn't know it's possible. I
[01:29:25.800 --> 01:29:31.720]  understand that. Of course, we know, of course, very well that these public consultations, I mean,
[01:29:31.720 --> 01:29:35.400]  that big players, commercial players, they are more paying attention to this because they have
[01:29:35.400 --> 01:29:41.000]  the resources to do, though. And that's clear to us. But that's also, of course, one of the reasons
[01:29:41.000 --> 01:29:46.680]  why I'm here, right? Because I know that this community, maybe the voice is not heard as much
[01:29:46.680 --> 01:29:54.680]  as the voice of other communities. And as I said, we can, of course, keep engaging. You can come
[01:29:54.680 --> 01:30:00.840]  later. I can give you a card and we can discuss. We can even do maybe another small event and
[01:30:00.840 --> 01:30:07.880]  discuss further, right? I mean, it's all possible. On this concept of commercial, so first, I mean,
[01:30:07.880 --> 01:30:12.840]  I think it would be very difficult for us to replace it by another concept because it's well
[01:30:12.840 --> 01:30:18.440]  grounded in this new legislative framework. And all the industry players that we've been speaking
[01:30:19.080 --> 01:30:25.080]  to so far, they all say they want us to use the new legislative framework because they are familiar
[01:30:25.080 --> 01:30:31.480]  with it from other product types, right? So, and we want to ensure that all stakeholders
[01:30:31.480 --> 01:30:35.800]  can use the same framework. If we now invent a different framework, it will lead to a lot of
[01:30:35.800 --> 01:30:40.920]  fragmentation. It will make compliance more difficult for companies. So that would be difficult.
[01:30:40.920 --> 01:30:46.440]  Of course, I mean, there's this crucial question of where to draw the line of commercial. I think
[01:30:46.440 --> 01:30:52.280]  we are open to all your points. We understand them. I think what would, from our perspective,
[01:30:52.280 --> 01:30:57.880]  be very difficult. I mean, this is how I understood your intervention would be to say we just exclude
[01:30:57.880 --> 01:31:02.920]  all open source because it's all somewhat commercial and it all needs to be excluded. I think this
[01:31:02.920 --> 01:31:08.600]  would not work simply for the fact because it would create an incentive for proprietary manufacturers
[01:31:08.600 --> 01:31:14.680]  to swiftly switch over to open source, right? Okay. Not everyone can do that. Ah, you want that? Okay.
[01:31:15.720 --> 01:31:21.640]  Okay, I see. No, but it would create an incentive to get out of the scope and to not have to comply,
[01:31:21.640 --> 01:31:27.720]  right? I don't think this is what you want. Then there was also a point from you on all the many
[01:31:27.720 --> 01:31:33.320]  small players and how it would be maybe difficult for them to comply. Now, so the Cyber Resilience
[01:31:33.320 --> 01:31:37.640]  Act is, I mean, the requirements in there are their risk-based. That means that, I mean, when
[01:31:37.640 --> 01:31:43.320]  you're a very small player, there is also a chance that maybe your project faces smaller risks and is
[01:31:43.320 --> 01:31:49.160]  maybe less critical. And you can take that into account when you comply with the requirements
[01:31:49.160 --> 01:31:56.360]  of the regulation. On top of that, for the vast majority of products, we only require self attestation
[01:31:56.360 --> 01:32:02.040]  by the manufacturers, which means you will not have to reach out to any third parties or interact
[01:32:02.040 --> 01:32:07.480]  with any authorities. You can do it all by yourself. And this should be absolutely feasible.
[01:32:08.280 --> 01:32:14.360]  What other questions did we have? Yeah, there was this question of how the CRA would improve the
[01:32:14.360 --> 01:32:20.440]  ecosystem for components that are vulnerable, such as Log4J, where you said, I mean, this is a non-
[01:32:20.440 --> 01:32:26.760]  commercial component. So, I mean, we have this due diligence obligation in our proposal. That means
[01:32:26.760 --> 01:32:32.600]  that in the future, when a commercial manufacturer integrates a product, for instance, a logging
[01:32:32.600 --> 01:32:38.040]  utility that is free of charge available, they will have to make bigger effort than today
[01:32:38.760 --> 01:32:42.520]  looking at these components. I mean, that, again, of course, depends on the risk. I mean,
[01:32:42.520 --> 01:32:48.520]  if your project is low risk, you will only maybe check the change log if there are regular security
[01:32:48.520 --> 01:32:53.160]  updates or not, and you're done with this assessment. But of course, if you integrate this component
[01:32:53.160 --> 01:32:59.560]  into something much more critical, you will have to take a much closer look at these components.
[01:32:59.560 --> 01:33:04.280]  So what we're trying to do is we're trying to make manufacturers of commercial products,
[01:33:04.280 --> 01:33:10.360]  proprietary or open source or whatever, assume more responsibility for the open source components
[01:33:10.360 --> 01:33:14.920]  that they're integrating. And we believe that this will help raise the level of security on
[01:33:14.920 --> 01:33:22.200]  these components as well. Yeah, there was this question on whether charities would be considered
[01:33:22.200 --> 01:33:27.320]  as a commercial activity. So I cannot just give you a straight answer on that. I think it always
[01:33:27.320 --> 01:33:32.440]  depends on the individual case, right? I mean, what we've learned is that there are so many
[01:33:32.440 --> 01:33:39.000]  different types of open source projects, so many different types of funding models. So you really
[01:33:39.000 --> 01:33:43.560]  need to look at each and every case to see if it's a commercial activity or not. What I already
[01:33:43.560 --> 01:33:48.280]  said, I mean, we are, as the Commission, we are absolutely willing to provide more clarity.
[01:33:48.920 --> 01:33:53.960]  This could be done, for instance, already in the legislative process that we single out important
[01:33:53.960 --> 01:33:58.760]  examples and we provide clarity directly in the legal text. But for all these other niche cases
[01:33:58.760 --> 01:34:02.360]  that will come up, this will not be possible in the text because we cannot, you know,
[01:34:02.360 --> 01:34:07.000]  a legal text needs to be short and concise and we cannot take into account every single example.
[01:34:07.000 --> 01:34:15.240]  But we're absolutely prepared to provide examples once it has come into force so that you have
[01:34:15.240 --> 01:34:19.560]  the certainty that you need to know whether you are in the scope or not with your project.
[01:34:19.560 --> 01:34:28.680]  I think I took them all. Yeah, I think that's because, so for, I mean, I'm going to speak for
[01:34:28.680 --> 01:34:42.440]  the PLD, but for my proposal, we had expert groups consultation in 2018-2021, consultation also
[01:34:42.440 --> 01:34:47.000]  through the contractor where they were questioned through different kind of stakeholders.
[01:34:48.040 --> 01:34:54.440]  We had the consultation for when the proposal was adopted by the Commission in September 2022
[01:34:54.440 --> 01:35:00.840]  with the Have Your Say portal. This is where you find all the proposals and where you can give
[01:35:01.400 --> 01:35:08.760]  your comments on it. So, and it was for more than three months for hours. So, we always tried,
[01:35:08.760 --> 01:35:15.640]  obviously, to reach as much as possible. The thing is, obviously, there are sometimes channels.
[01:35:15.640 --> 01:35:21.160]  It's not that we avoid having talks with the people that can criticize the legislation. We need
[01:35:21.160 --> 01:35:28.280]  critics to also make the legislation better. This is how it works. So, obviously, as you said that,
[01:35:28.280 --> 01:35:35.800]  yeah, there might be some players that are more voiceable. This is the reality. I think it's
[01:35:35.800 --> 01:35:42.360]  also part of how the field or the ecosystem organized between itself. You need to have one
[01:35:42.360 --> 01:35:49.240]  speaker, someone that can represent also the community, because obviously, if we have someone
[01:35:49.240 --> 01:35:54.760]  that comes for the open source community that says that he is speaking for the community,
[01:35:54.760 --> 01:36:00.200]  then he would bind everyone. So, you know, those companies that have those trade associations,
[01:36:00.200 --> 01:36:06.840]  et cetera, this also gives a framework for us to really say, okay, this is a voice of this sector,
[01:36:06.840 --> 01:36:12.120]  this sector, this sector. When you do not have this, it's a bit complicated for us to take it as
[01:36:12.120 --> 01:36:18.040]  just being the voice of the entire community, because you can have an opinion and someone
[01:36:18.040 --> 01:36:22.520]  else can have another one, but then which one do I have to consider as being the one of this
[01:36:22.520 --> 01:36:28.840]  community? That's a bit of the complexity also for us, just to be honest. On the charity one,
[01:36:30.600 --> 01:36:37.640]  there are definitions. Commercial activity is whatever against money or for free. It does not
[01:36:37.640 --> 01:36:46.280]  matter the economic value in that sense. It's a concept that goes much more broader than this. So,
[01:36:46.280 --> 01:36:53.160]  I understand that there is this need of clarification. This is where the definitions
[01:36:53.880 --> 01:37:00.680]  are there, but they are also the basics of any legislation that we have in the union.
[01:37:01.560 --> 01:37:09.080]  It's not that simple to change just one definition that it's common to all of them
[01:37:09.080 --> 01:37:15.720]  in one single piece of legislation. This is also the reality of how the proposal works.
[01:37:15.720 --> 01:37:23.720]  You need coherence. You can have some exclusions, but we talk about why, I mean,
[01:37:23.720 --> 01:37:29.000]  it's not just the need of excluding open source software. It's also the need of ensuring that
[01:37:29.000 --> 01:37:34.280]  does not have an impact on innovation, but you also need to take it into account the reality
[01:37:34.280 --> 01:37:41.320]  of it. So, that's a bit of the... Thanks, Omar. Benjamin. Yeah, sorry. I just want to be thorough.
[01:37:41.320 --> 01:37:45.320]  I forgot to answer one of the questions I just realized. So, there was a question on whether
[01:37:45.320 --> 01:37:52.600]  there could be a risk that products developed in third countries would simply not be made
[01:37:52.600 --> 01:37:57.960]  available anymore on the European Union market. So, no, we don't see this risk, to be honest.
[01:37:57.960 --> 01:38:00.680]  I mean, the European Union, depending on the figures that you look at,
[01:38:01.480 --> 01:38:06.920]  is probably the biggest economy in the world. I think everyone has a very strong interest in
[01:38:06.920 --> 01:38:11.320]  bringing their products on our market. It has also not been the case with other regulation.
[01:38:11.320 --> 01:38:17.240]  If you think of the GDPR, I mean, the list of companies that choose not to provide services
[01:38:17.240 --> 01:38:21.560]  in the European Union because of GDPR is very short. So, we don't see this risk.
[01:38:25.640 --> 01:38:30.760]  Thanks, Benjamin. Anna Martin, you're dying to say something. So, how do I go to you?
[01:38:31.880 --> 01:38:37.480]  Thank you, James. So, I will answer the question of Alexander of how to fix this,
[01:38:37.480 --> 01:38:43.720]  but first, I would like to respond to some of the comments made. So, I think you hit the
[01:38:44.360 --> 01:38:52.360]  nail on the head by saying that the consultation, it's complex within the existing way of how
[01:38:52.360 --> 01:38:58.760]  Brussels operates, at least that's my perspective now as a newcomer here. And I think if we are
[01:38:58.760 --> 01:39:04.520]  not addressing that bit, like how to talk to communities like this, then we will be in this
[01:39:04.520 --> 01:39:09.960]  situation again and again and again and again. And I want to point out specifically that the
[01:39:10.760 --> 01:39:16.760]  discussion about commercial just now, I've read both your proposals, and you are not
[01:39:16.760 --> 01:39:21.640]  using the same examples of what constitutes a commercial activity. So, if you're saying that
[01:39:23.560 --> 01:39:32.520]  they originated from the legal jurisprudence, then one of you seems to have a different
[01:39:32.520 --> 01:39:40.360]  view on the jurisprudence and the other one. So, and I asked, I was wondering, have you
[01:39:40.360 --> 01:39:48.600]  considered talking to the open source program office when considering the definition, and I'm
[01:39:48.600 --> 01:39:53.880]  sorry if this is a bit confrontational, but I was just actually curious. So, before you answer,
[01:39:53.880 --> 01:39:59.720]  I am going to try to answer Alexander's question. I think he was asking how to fix this.
[01:39:59.720 --> 01:40:07.000]  I'm not jealous of your jobs because I think this is extremely complicated, and I don't have the
[01:40:07.000 --> 01:40:12.680]  full answers. I have one sub-answer, and it relates to critical products. I believe that there should
[01:40:12.680 --> 01:40:19.640]  be an escape hatch for class one and class two critical products, that if they are completely
[01:40:19.640 --> 01:40:30.280]  open source, then there should be the ability to do self-assessment, regardless of any other factors.
[01:40:31.720 --> 01:40:35.720]  Because I think the value of having critical products that are open source
[01:40:35.720 --> 01:40:43.400]  is tremendous in terms of security, too. So, we should be considering that aspect in addition to
[01:40:43.400 --> 01:40:52.120]  whether or not there is an EU standard that it can conform to, for example. I hope I touched
[01:40:52.120 --> 01:40:58.760]  somewhat on the ask again in maybe a couple of weeks, because I think they are in a hurry,
[01:40:58.760 --> 01:41:04.840]  so we should be, too. And then maybe back to the question I just asked about talking to Gijs.
[01:41:04.840 --> 01:41:14.440]  The power of the moderator. What's it worth? Cold beer? Maybe just to add one question to make
[01:41:14.440 --> 01:41:21.720]  your job a bit harder. Well, first, I think that we also need to recognize that you guys are also
[01:41:21.720 --> 01:41:28.600]  here on a Saturday and everything, so I think the appetite to interact with many groups is also
[01:41:28.600 --> 01:41:34.280]  there, so I think that's important to acknowledge as well. But I'm mostly wondering about the part
[01:41:34.280 --> 01:41:38.920]  on technical support, because we are focusing a lot on the definition of commercial, but
[01:41:39.800 --> 01:41:47.640]  the text itself says also, especially when technical support is provided, then the open
[01:41:47.640 --> 01:41:53.800]  source software is not excluded anymore. And I guess this is more of a general question, because
[01:41:53.800 --> 01:41:59.720]  I'm not myself an open source developer, but I'm just wondering to what extent this is demotivating
[01:41:59.720 --> 01:42:05.560]  then for developers, because I understand a big part also of the maintenance after, for example,
[01:42:05.560 --> 01:42:10.840]  is a motivating factor for people to develop, because then they are also involved later on
[01:42:10.840 --> 01:42:16.040]  on the maintenance. And I'm wondering also to what extent this is counterproductive for the
[01:42:16.040 --> 01:42:20.920]  objectives that the CRA sets, having the people that are involved in the development, but also
[01:42:20.920 --> 01:42:27.320]  they're involved in the later stages of making sure that the product remains secure. Then actually
[01:42:27.320 --> 01:42:32.600]  this, I think I would assume that it helps the security of the product. So it's more of a question
[01:42:32.600 --> 01:42:39.320]  on whether you have discussed this part. I'm sure you have if you put it there, but just if you
[01:42:39.320 --> 01:42:43.640]  could elaborate a bit further and an open question also to the audience, just because I think it's
[01:42:43.640 --> 01:42:52.680]  important for the audience to sort of educate us as well. Thank you. Yes, okay, we've got five
[01:42:52.680 --> 01:42:59.800]  minutes left. So Rom and Oma, and then we close. Yeah, okay. So I'm just going to continue what
[01:42:59.800 --> 01:43:05.480]  you just said. I think one of the tremendous beauty of the open source community is giving
[01:43:05.480 --> 01:43:12.120]  support to each other. And I think technical support as defined is very dangerous. And I'm
[01:43:12.120 --> 01:43:19.640]  going to give an example. If you are having a, if you maintain a project and you use one of these
[01:43:19.640 --> 01:43:27.320]  services like GitHub and you start helping someone to make the solution work, so it's
[01:43:27.320 --> 01:43:32.280]  technical support, right? So you open an issue, you start helping the person and so on. If the
[01:43:32.280 --> 01:43:39.480]  person, the person who will receive the help decide to sponsor somehow the developers,
[01:43:40.280 --> 01:43:45.960]  giving money, giving contributions in terms of money, then it, from the definition, it becomes a
[01:43:45.960 --> 01:43:52.200]  commercial activity. This is not the incentive. It's a donation. So I think it's really important
[01:43:52.200 --> 01:43:59.320]  to get that into perspective. So we are not reducing the level of contribution, both in terms of
[01:43:59.320 --> 01:44:06.920]  software development, documentation, but also money to run some testing infrastructure that is
[01:44:06.920 --> 01:44:13.480]  required to do security. So that's my point. Just it. Wonderful. There's an applause. There we are.
[01:44:13.480 --> 01:44:21.400]  Good. So Oma, I'm going to hand it over to you. I know you wanted to answer a point from, from
[01:44:21.400 --> 01:44:32.040]  Mathen. So for the internal cuisine of how the commission works, proposal don't come out from
[01:44:32.040 --> 01:44:40.200]  one own service. So we are three different director general. So connect for the telecommunication,
[01:44:40.200 --> 01:44:50.200]  DigiGro is for the industry and Digit. Each proposal before going out is assessed by all the
[01:44:50.200 --> 01:44:56.280]  dedicated services of the commission. So everyone is consulted and everyone makes the legislation
[01:44:56.280 --> 01:45:02.760]  readapted where it needed because obviously the expertise of each one of the directory channels
[01:45:02.760 --> 01:45:11.160]  helps to make the proposal. So you need, it's an internal mandatory step. So that's a, and on the
[01:45:11.160 --> 01:45:19.320]  small definition, it's not that we have different concepts. It's the, how it has been interpreted
[01:45:19.320 --> 01:45:26.360]  until now and we're talking about almost 40 years of case law. It's elements of what the commercial
[01:45:26.360 --> 01:45:32.440]  activity can be and cannot be. It's never a proper situation. It does never draw a specific line.
[01:45:32.440 --> 01:45:37.800]  I know it does not reply to your question, but we have elements of what is or what is not a
[01:45:37.800 --> 01:45:43.160]  commercial activity and all of them take into account at the end to create the commercial
[01:45:43.160 --> 01:45:49.240]  activity, but they are not, it's not just if you are in room A, it's commercial activity and in
[01:45:49.240 --> 01:45:53.640]  room B, it's a commercial activity. It's different elements that can constitute the commercial
[01:45:53.640 --> 01:45:57.720]  activity or not. That's a bit of a situation. If you are developing your open source
[01:45:57.720 --> 01:46:05.400]  software from your couch on a Sunday, this is not covered. If you're, if a big company takes it
[01:46:05.400 --> 01:46:11.720]  out from, from a website, whatever, you are not making the commercial activity, but the company
[01:46:11.720 --> 01:46:16.760]  is doing the commercial activity. So you are not, you know, these are a bit of the differences.
[01:46:17.720 --> 01:46:23.640]  These are the elements, but if you make it, if you make yourself money out of it, this is a
[01:46:23.640 --> 01:46:29.480]  commercial activity in a way or another. If yourself make it, you are the commercial activity.
[01:46:29.480 --> 01:46:35.320]  If a big company takes the, the, the software and puts it, and puts it in his product,
[01:46:35.320 --> 01:46:41.000]  he's doing the commercial activity, but not you. So he will be the one to cover it, not yourself.
[01:46:41.000 --> 01:46:47.640]  It's a bit of, this is how the commercial activity works. Yeah, I know it's, it's complex, but yeah.
[01:46:47.640 --> 01:46:53.880]  Yeah. We have two minutes left. So 60 seconds.
[01:46:56.040 --> 01:46:59.720]  Yeah. I mean, on this technical support, I mean, it's of course a tricky one, right?
[01:47:01.400 --> 01:47:06.200]  The idea behind the commission proposal of the side resilience is act is to say that
[01:47:06.200 --> 01:47:11.080]  when you're making money with a product, it's a commercial activity. And then you should comply
[01:47:11.080 --> 01:47:15.240]  with the rules because there are so many different ways in which you can monetize a project. It's
[01:47:15.240 --> 01:47:21.400]  not always just charging a price. Yeah. Could also be placing ads in your mobile app or,
[01:47:21.400 --> 01:47:25.560]  I mean, charging a lot of money for technical support. I mean, technical support does not
[01:47:25.560 --> 01:47:31.000]  necessarily mean that it's a non-commercial activity. So of course it's different if you
[01:47:31.000 --> 01:47:35.720]  just recover your costs. Yeah. That's maybe something else. But if you're truly making money
[01:47:35.720 --> 01:47:41.160]  with a project, project, we, we are convinced that it's only fair that you are covered by the
[01:47:41.160 --> 01:47:50.600]  sub-resilience act. So that end device compatibility check, compliance check, I think is, is important.
[01:47:50.600 --> 01:47:56.680]  And I think we've run out of time. We could have gone into the whole notion of components,
[01:47:56.680 --> 01:48:04.200]  which you mentioned on 11.7 and, and where, where we see that, that posing some workability issues.
[01:48:04.200 --> 01:48:10.040]  Unfortunately, we've run out of time. But I would like to ask you all to show your