First of all, thank you. Thank you for coming here to this session. I think it's fantastic
to have an audience who is potentially interested with regulation and compliance. This is something
that impact us all of us as a community, as our users, consumers, and also from a work
perspective. So I think it's really important to be able to understand what are the impacts
of regulations, compliance, certifications, when we are developing software, when we
are sharing our work from, I would say, a community perspective, but also when that
work goes into production on systems, critical systems. So thank you for being here for that.
Today we have the unique opportunity to have some of the folks who wrote, or at least review
wrote, some of the legislation directives, like the Cyber Resilience Act. And we will
go through a couple of lightning talks, because I think it's really important to set the scene.
So we could start discussing about having a panel, but if we don't understand the overall
construct of those regulations, that's going to be hard. So I would like to have a warm
welcome from Benjamin here, if you can give him a bit of love. Thank you. Thank you. So
we are really honored to have the European Commission here to help us with this. So thank
you. Benjamin, up to you. Thank you very much. Thank you so much for having me and also for
showing interest in our work that will maybe affect some of you, but most of you probably
won't be affected by it. I mean, as a Commission, we're always trying very hard to reach out
to all the people that could potentially be affected by our regulation, but it's sometimes
a bit difficult. I mean, it's often mostly large companies that have the resources to
actually engage with us. So I'm really happy to be here and I'm so glad that so many of
you decided also to stay for this panel. So the Cyber Resilience Act is a new proposal
of the European Commission. It intends to improve the cybersecurity of hardware and
software products. It's intended to complete a puzzle. So there's already other legislation
at union level on cybersecurity. Most notably, there is the NIS directive, which has recently
been reformed. The NIS directive focuses more on the users of hardware and software. So
it ensures that large companies, critical infrastructure providers and so forth, take
security seriously, do their patches regularly and all that. But the Cyber Resilience Act
now focuses on the other side, on the manufacturers of these products. And I mean, I know that
many of you are probably not dealing with policy every day, and it's particular not
with European Union policy. So I've just like added one slide at the very beginning to quickly
explain to you like what the Commission is and where we are in this process and who the
other players are. So yeah, this is highly simplified. It's much more complicated than
that, unfortunately. So I work for the European Commission for the Director General Connect.
It's like the Director Generals. They are like departments within the Commission. So
we mostly deal with telecommunications, internet, emerging technologies and so forth. And it
is the European Commission that makes legislative proposals in the European Union. So we write
the draft and then we propose this draft to the so-called co-legislators. That's the European
Parliament and where you have the members of the European Parliament, so parliamentarians,
and the Council that represents the 27 member states. And these two institutions, they analyze
the Commission's proposal. They come up with their own positions and once they've done that,
they negotiate with one another. And at the very end, once they agree on a common line,
a common position, they adopt the text and it enters into force. It becomes a law. So
this is basically how it works. It's very simplified. So our proposal came out on 15
September 2022, so in autumn. And it's now with Parliament and Council. Parliament has
not yet started discussing it. They're still sorting out which committees will be in charge
of it. But the Council is already at full speed. There are regular meetings every second
Wednesday. The Council is meeting to discuss the text proposed by the Commission. So that's
just for your background. And now we'll talk about the substance of the proposal. So what
are we trying to achieve? So we want to reduce the number of vulnerabilities in hardware and
software products. Of course, we know that it's an unrealistic goal to aim for zero
vulnerabilities in products. And this is what the slide represents. So the cheese represents
a hardware software product filled with holes. I mean, I know not all are filled with holes,
but many are. And I mean, we attempt to reduce the number of such security holes in hardware
and software products through legislation. And, yeah, I will just get right into the
main elements of the proposal to give you an overview and then I will, you know, provide
some more details. So it's all about providing cybersecurity rules for hardware and software
products when they're placed on the market. So placing on the market entails that we're
talking about commercial activities here. So companies that make money with hardware
and software products, they will have to follow these rules. We're using a well-established
framework. It's called the new legislative framework. It's been used in the past by the
European Union to regulate other products such as toys or machinery or electrical equipment.
And you may not know it, but you're all actually very familiar with it. So whenever you see
a product that has the CE marking on it, CE, I will show it later, like you have it, for
example, on laptops or iPhone chargers and such things. So this is all a new legislative
framework regulation then. What we do in the proposal is we establish obligations for three
types of economic operators for the manufacturers. I mean, that's the core element, of course,
of the proposal. But then there are also the distributors. These are brick and mortar stores,
online shops, and also importers that place products on the European market that have
been developed in third countries. And the importers and the distributors, they don't
have to, I mean, they don't do secure coding, of course. They are just selling products,
but they have to ensure that the products that they are selling are in line, I mean,
that they comply with the Cyber Resilience Act. One of the core novelties of our proposal
is that it does not just cover rules for the placing on the market, so what the product
should look like, but it also covers the period after that, the entire life cycle. So I mean,
you all know that for cybersecurity, it's extremely important that you keep tracking
your products, that you ensure that when you discover new vulnerabilities, that you fix
them, you mitigate them, you provide patches and so forth. And this is part of our proposal
that for a period of five years after the placing on the market of a product, you do
that, you provide security updates. One essential element of any new legislative framework regulation
is harmonized standards. So the rules that we propose in the Cyber Resilience Act, they
are very high level, technology neutral, objective oriented. I mean, if you go through
the proposal, you will see they're really high level. It's more like on the level of
provide a secure by default configuration, take care of access management, make sure
data is handled confidentially and so forth. So it's really high level. But then we have
the standards that will be developed by the European standardization organizations. You
may have heard of them. They're called SanSanElec and Etsy. And they will, I mean, they are
voluntary. You don't need to use these standards, but they will help you write secure products.
And then there is also the conformity assessment. So manufacturers, they will have to demonstrate
that their products are actually compliant, but I will explain that in more detail later.
Yeah. And finally, there's the market surveillance. So in all the member states, you will have
authorities that can check out the products and approach manufacturers, ask them to remediate
vulnerabilities, eliminate risks, and if they don't comply, even hand out fines. So the
scope of the proposal, it's hardware and software products, products, not services. So when
I say hardware products and software products, I mean, final products such as laptops or
operating systems, but also components such as CPUs, hard drives, software libraries and
so forth, we have, we don't regulate services. So software as a services outside the scope
of this proposal, that's already regulated by the NIS directive, which I mentioned earlier,
but we do regulate something that we call remote data processing solutions. So often
today, products, they actually come with some cloud or other elements such as many mobile
applications. They usually, they access data in the cloud and these are essential functionalities
of the program. And then you would also have to ensure the security of these remote data
processing solutions. As I already explained, we only regulate commercial products. So anything
that is non-commercial is outside the scope, including open source when it's non-commercial.
But on the other hand, so open source that is commercial, I mean, there are a lot of
large commercial projects, I'm sure you're aware of them, they would be covered. And
then we exclude certain products that already regulated by other regulations such as cars
or medical devices. Yeah, I mean, why did we choose to exclude non-commercial open source
software from the scope? There are a few reasons. And first of all, this is standard practice
for any new legislative framework, product regulation at union level. We only focus on
commercial activities. But also in the case of open source, there are some more special
considerations that we took. So first of all, like, is it even, would it be fair to regulate
someone that does not make a profit with a product, right? I mean, and we think it would
not. And wouldn't we be setting the wrong incentives to regulate someone who doesn't
make money with it, right? I mean, would you keep developing something if you're asked
to like follow regulation and you're not even earning money with it? So we would be setting
the wrong incentives. That's why we decided to exclude them. And then of course, we also
know that open source, I mean, it's critical often from a cybersecurity perspective, but
it's just as critical from an innovation and growth perspective. I mean, there are so many
small companies, medium sized companies that use your components, your products free of
charge to develop on top other products and services. And for them, it's crucial that
they that they have access to this resource. And that's, I mean, we're fully aware of that.
And my colleague Rice, he will, he will, I mean, he will later on the panel also explain
to you how, in how many other ways we, we, we support open source as the European Commission.
So here in a nutshell, the obligations that manufacturers of commercial products would
be, would have to comply with. I mean, first you do a risk assessment of your product during
the design phase, then you comply with the essential requirements that are in the regulation.
I explained earlier what they look like, these high level objective oriented requirements.
Then you establish vulnerability handling processes, such as a coordinated vulnerability
disclosure policy. And yeah, and of course, I mean, with any legislation, you will have
to document in which way you comply. This would be called a technical file. And once
you've done all that, once you've done the conformity assessment, you can fix the CE
marking to your product. And then for a period of five years, you will be required to handle
the vulnerabilities that arise in your products.
On top of that, there's also an obligation to report critical vulnerabilities to our
cybersecurity agency. We are talking about vulnerabilities that are already exploited
in the wild by criminal actors, but that have not been necessarily fixed. And this is for
the purpose of helping national authorities mitigate risks in critical infrastructure
and so forth. Here's one example of how we are also trying
to help the community. So in the article 11, which is about the reporting requirements
for manufacturers, we require them whenever they integrate a component and they discover
a vulnerability in it. And this could be an open source component that they notify the
entity or the person that maintains this component. I mean, so people like you often, for example.
So for example, when you go, when you're from GitHub, when you source a component and then
you discover a vulnerability, at least you should reach out to the maintainer and inform
them of the vulnerability. Ideally do more, maybe even provide code to fix it.
So here is how it works as regards components. This is an example of a smartphone manufacturer
that builds a smartphone. So there will be some components here. You see them on the
left-hand side in blue. These are components that the manufacturer develops themselves.
So they would not be placed on the market separately, but as part of the final product.
And then for these components, you would not need to do a separate conformity assessment,
but it would be part of the final product. But then there are other components. You see
them on the right-hand side, such as the ones that are developed by upstream manufacturers.
So here you see the RAM or the CPU in that example would be manufactured by someone else.
So and so these are placed on the market separately, and it would be the upstream manufacturer
who would need to ensure the security of these components and to fix the CE marking.
And of course, the manufacturer of the smartphone is responsible for the entire product, right?
Just because you integrate a component of someone else doesn't mean you don't take any
responsibility for it, but you would be, you would need to do due diligence when you integrate
those components. Yeah, so these are the categories for the conformity assessment that you propose.
For the vast majority of products, the default category, you would do the conformity assessment
yourself as a manufacturer. You do not need to interact with any third party. But then
there is a smaller list of critical products, which you can find in the annex of our proposal.
It's roughly 10% of the scope, and there we require more stringent conformity assessment
and sometimes even independent third party assessment. Examples of these more critical
products are firewalls, CPUs, or operating systems. And then there is also a possibility
for highly critical products. We are not making use of that now, but we are proposing that
in the future we can add highly critical products to a list for which it would be necessary
to undergo a mandatory certification. We do not have any products in mind. This is really
just to future proof the legislation, because we all know that digital products permeate
society more and more, and we become more and more dependent on them. And there may be
a point at which we will rely on such crucial products that we need even a higher level
of assurance. I don't know, human brain interfaces or something like that. I mean, yeah. Okay,
this is the CE marking that you're all very familiar with. We are also trying to facilitate
compliance for the manufacturers as much as possible. So we would be providing after the
entry into force of the proposal guidance on compliance in general, as well as examples
of how to do things in practice, for example, on how to delineate what is a commercial product,
what is a non-commercial product. We will also, I mean, as I said, develop these harmonized
standards. We are looking into providing funding through the Digital Europe program, that's
a European funding initiative, for national market surveillance authorities, but also
for manufacturers to help them comply. But then, frankly, we are also counting on you,
on the community, on software developers, on the market also, to come up with tools
that can help facilitate compliance. I mean, many of these tools already exist, of course,
such as static and dynamic code analysis tools, S-bomb generators, but, I mean, you name
it, there can be any number of tools that could help facilitate compliance, maybe to
generate some of the documentation automatically, and, I mean, also be extremely open to ideas
on how to facilitate this. So, feel free to approach me after the panel, and we can discuss
it. Here, this is the timeline just for you to better understand, and this is also my
last slide. So, as I said, we made the proposal on 15 September. We are now undergoing this
legislative process. We are hoping to conclude it before the European elections in May 2024.
And then, once it's done and enters into force, we will launch a request for standardization
with the European standardization bodies. And then, 24 months later, it would enter
into application, so that's when manufacturers would need to comply with the rules, and also
when the harmonized standards would become available. Yeah, so there's still plenty of
time for you to help in the process, to reach out to members of parliament if you have concern
or to the member state authorities and get involved. We are, of course, also extremely
interested in your views, so you can also reach out to us. I mean, I also brought some business
parts, so later, if you're interested, you can have some. And, yeah, I mean, I'm extremely
looking forward to the discussion now. Thanks. Sorry for being so fast, but I only have 15 minutes.
Thank you, Benjamin. So, I don't know if you saw me
moving around during the talk, but we were discussing both cyber resilience and also
potential software defect. I just escorted a bug outside how convenient it was, so saving a bug.
So, now we're transitioning to Martin from NLNet Labs, and he's going to give us this point of
view of the CRA based on, from an NGO, so a non-government agency or office, organization, sorry.
So, this is a different approach, and, yeah, they are dealing with DNS, so that might be
important infrastructure element to consider in this topic. One welcome from Martin, please.
Good morning, everyone. So, I'm really grateful that Benjamin just did the hard work of explaining
the legislation, and for me, the, I suppose, easier part of reacting to it. So, my name is Martin Arte.
I work for NLNet Labs, which is a non-profit R&D organization. We make open source software
for the internet. I stole this terminology from a great report from a quite a while ago.
And, what we do is we develop internet standards, or we contribute to the development of internet
standards, and we make implementations. And, the specific area of focus that we have.
The mic, closer to you.
Ah, I'm, I will. So, the specific work that we do is we develop, we contribute to the
development of internet standards, and we make implementations in software that are open source.
And, we've been doing this for two decades. We make software in the area of DNS, and we make
software in the area of routing, specifically, routing safety. And, what we also do is we try to
bring that knowledge to policymakers, and that's what I'm doing, hopefully, today.
So, Benjamin just talked about the scoping, and he mentioned that most of us would be out of scope.
And, when I read the proposal in September, October, I wasn't so sure, and I think that's
something we should discuss. So, there is a recital in the text that basically reads,
free in open source software should not be covered by this regulation, which is, I think,
I think we should be very happy that the commission is aware of open source, and has taken concern
to actually address this in new legislation that I come up with. So, I think that is a,
something we should celebrate, much like the fact that open source has been here for 25 years.
So, maybe a little warm round of applause just to acknowledge that we've been here.
And, what I want to talk about today is the fact that there's a clause here, and it says,
outside the course of a commercial activity. And, what is a commercial activity? There are some
examples. It's not a defined term. And, one of the examples that is relevant to my organization,
to Enelnet Labs, is specifically that what is called out is that if you charge a price for
technical support services, then you are considered commercial. So, the organization I work for is
a registered charity. We make software, we develop standards, we give it away for free,
we give away updates for free. And yet, we employ people with mortgages. So, the question is, how
are we supposed to make money? And, we've found a way, namely, the network operators that use our
software want it to be available long term. And, they want there to be different implementations
available. So, they've chosen to pay us to provide support. And, so this makes our work a commercial
activity, at least in the way we read this text. I would be glad to be wrong about most of the
slides I'm showing you today. And, please tell me if I am. But, that's why we got interested in
this legislation. And, there are some risks if you look at this exception. Because, if you have an
expansive interpretation of the word commercial, then the exception is narrow. It's this balance,
right? Depending on how you interpret commercial. And, if it's a narrow scope of exemption,
then what you create is a disincentive for open source developers who start working on something
in their free time to professionalize. Because, at some point, when you hit this commercial
qualifier, then you come into scope of regulation. And, there's nothing bad about regulation per se,
but we have to acknowledge that the step from not being regulated to be regulated is a change,
right? And, what we don't want to happen is for charities like Anelot Labs and others who make
this kind of software to realize that the way they've been able to sustain their development
is now disappearing. So, this, what we don't want is for there to be an incentive to move to
closed-source software. And, finally, especially in the area of DNS, what we want is product
diversity. So, it's not a good outcome if we have, if we go to a place where there's less
organizations working on these projects. Because, what we want is different implementations that
do not share code for stability. So, it's not just me. The OSI reacted to the response. And,
they said, and I like this quote a lot, the problem is not the lack of taxonomy of commercial,
so the solution is not explaining what commercial is supposed to be. It is the very act of making
commercial the qualification rather than deployment for trade. And, what is relevant about this quote
is that there's a very different, the act of maintaining and creating software and the cost
of that is very distinct from the act of profiting from its deployment. And, if you confuse these
two steps, then you, and commercial may help you confuse those steps, then we get into this place.
So, that's about general scoping issues. I'd like now to move to specific concerns we have
from analog labs. And, why do we have concerns? It's because we have products. We make unbound,
the resolver, we make some other products. At least, we believe it's not an unreasonable
interpretation to consider the stuff we release, including binaries, to be products. And, maybe
we're wrong. Love to hear that. So, if we are products and if what we do is considered commercial,
then there are some unintended consequences by being covered by this legislation. Because,
currently, we are in outfit with 15 people, 14 of whom are either software engineers or developers.
Every effort we put into proving that we're doing the right thing, the compliance bit,
which is a logical part of any legislation, every effort that we spend on compliance
will not be spent on securing our software. And, the only reason why a charity like ours
exists is baking secure software, resilient software for internet infrastructure. And, if you look at
the NX3 list of critical products, it doesn't take too much imagination to frame most of what we do
as critical products in terms of this legislation. And, I think Benjamin explained about the way
to avoid having to call in third-party auditors. But, it depends on the availability of European
standards that are applicable to our work. And, in general, I think most of us are not engaged in
the European policy process. And, even less of us are involved at the European standard
institutions. Because, basically, we have no need to be there at this point in time. And, we have
not had a need in the past. So, at Inelid Labs, we quite work quite a lot on standardization,
but it's at multi-stakeholder forms, accessible to any party, without payment, etc. And, that's
not how these European standardization institutions work, unfortunately. So, the escape hatch,
if you are a critical product, to not have to call in third-party auditors may not actually
be available in practice. And, that means we will have a costly burden checking our processes,
which does not actually contribute to the quality of code. And, that's why I think this is a concern
for us, or at least an unintended consequence. There's also text in there which requires you
to fix all known vulnerabilities. And, this does not have a regard for severity. And, what this
does is, if you have to fix all known vulnerabilities, then discus your engineering effort from
practices that protect you against unknown vulnerabilities. So, this is, I think this is
not what it was actually intended. I'm just flagging it, because we, I think we want to,
there to be good laws, and we want to help in a democracy to achieve those good laws. I mean,
why, if you live in a democracy and you like that, why not contribute, I suppose? Otherwise,
there's not a lot of points. So, there's also more detailed concerns. So, for example, we currently
have the opportunity to provide security updates to providers we know are extremely critical to
the functioning of the internet. So, if we are about to release a patch and give full information
about what it fixes, we can choose to provide a update just ahead of time to a, for example,
root server operator or some other entity which is not equal in terms of importance to all of
society. And, the current text takes away our ability to do so, because it requires us to do
everything at the same time, which may not actually benefit security, which is the goal.
There's also obligations to report incidents that actually relate to third party use of our
software. So, we don't do any operations, we just develop software, but if we are obliged to report
incidents that relate to the use of our software, this gets into a conflict of our role of remediating
vulnerabilities. And, this is the case, because these third parties may have some reason not to
go public with an incident at first. And, if you create a conflict of interest in talking to us,
then we may need longer to fix the vulnerability if there is such a thing. What we don't know,
and this is more of an uncertainty, we don't know what constitutes substantial modification.
So, the whole idea of that you trigger reassessment of your product for the CE marking, it hinges on
the fact that, when substantial modification is made, you need to do it again. And, we currently
don't know if that's a major release, minor release, patch release. We do quite a lot of releases.
And, depending on how this pans out, we may spend a lot of work doing compliance and less
work of doing release engineering. Finally, there is some clause about time limited availability
of software testing purposes. And, I think that's fundamentally incompatible with how open source
is done. Much of the points I've made today, we worked on together with ISC, the authors of Bind,
among others. And, on their website, you can download about 30 years of binaries, of all versions of
Bind ever made, which is really helpful if you're trying to find issues, vulnerabilities, whatever
you try to. So, what we don't want is for them to have to get this stuff offline, because I don't
think it actually helps us reduce vulnerabilities. So, if you are interested in this stuff, I recommend
you to read further, because this was just my perspective. And, Elnert Labs, as an organization,
a charity employing people that are getting paid full time to develop open source software,
is not very common. And, I realize that. But, you don't have to take it from me. You can also
read about other responses. So, there's the work of OSI. There's work by Open Forum Europe,
Brussels-based Think Tank, which collects voices from other organizations relating to open source,
including commercial ones. And Simon, who's in the front here, maybe he can raise his hand,
actually compiled a list of responses by other. So, you can take a look yourself and give it
some thought. I wanted also to quickly give a shout out to a blog written by Thomas DePierre.
I'm hoping I'm not butchering your name. And, it relates to supply chain thinking, how that's
currently quite dominant in thinking about security for open source. And, his point is basically,
you supply chain thinking doesn't work if someone in this supply chain is not actually
considering themselves to be a supplier. So, that's it with respect to what I had to say.
In summary, we believe that these goals that the commission is trying to achieve are worthy goals.
And, as a consumer, I would like them to succeed. However, there's also some unintended consequences
in their current proposal. And, I think we should aim as a society to fix those. I'm very interested
to hear your perspective. And, for now, I'd like to thank you for your attention. And, I'm looking
forward to the panel. Thank you, Martin. We hit 30 minutes with two different opinions and views.
Is there some questions in the audience? Not yet? Oh, one, two. Two questions. I'm from the UK.
So, how does that affect other European countries that may be?
Okay. How does it affect the UK and the UK working with Europe? We're still part of Europe after
Brexit. And, secondly, how does it affect what's happening in the U.S. in terms of all the stuff
that NIST is doing, particularly on, you know, from the executive order that happened in 2021?
I couldn't hear the second question. The second question was, how does this affect the U.S.?
So, yeah, thanks a lot for that question. So, for the Subresilience Act, we are applying the same
principle as for any other union legislation that is about services or products. So, whenever you
provide a service or a product in the European Union, you have to comply with the rules of the
European Union. So, that means for the Subresilience Act, if you provide a hardware or software
manufactured outside the European Union to consumers or other users within the union,
you would have to comply with the Subresilience Act. So, there's absolutely no difference. It
doesn't matter where you're located. If you want to sell your products here, then you have to comply.
So, there's also no risk that there would be an advantage for maybe manufacturers from America
or so forth that they would not have to comply and therefore have lower costs. No, it's an
level playing field. Everyone who wants to sell their products here would have to comply with
the same rules. I hope that answers your question. Hi. Why is policy the right place to put these
measures into effect rather than a standardizations body like ISO, which already does a lot of the
same things and provides people who want the guaranteed, the guarantees associated with this
reliability testing to select products that comply with the ISO requirements?
Okay. If I understood the question, the question is why we think that a mandatory approach is
necessary, right? Right. Why is the mandatory approach necessary instead of a voluntary approach
that could be selected by consumers who want it? Yeah. I mean, the voluntary approach is the
approach that we took basically for the last 20 years, right? And it hasn't worked. I mean,
we are not eager to regulate new sectors. I mean, especially when it comes to such
innovation and growth fostering sectors such as hardware and software. So, I mean,
that's one of the reasons why the Commission of the European Union for a long time decided not
to regulate. But, I mean, we see that, you know, despite of new standards coming out,
development of lots of secure development lifecycle, guidance, new programming languages
that are memory safe. I mean, all this is coming. We see that. But nonetheless, I mean,
the vulnerabilities, they are not going down. And we see actually more cybersecurity incidents
than ever before. And this is why we chose to regulate. I mean, in our view, there is simply
not sufficient incentive for the market to take cybersecurity as seriously as it should.
I mean, I mean, you all know this. I mean, you have so many specific features in this market,
such as, yeah, time to market. I mean, first mover advantage, who is the first one to build
a platform wins basically the whole market, yeah? So, under all these constraints, manufacturers
do not have an incentive to prioritize cybersecurity. And we feel that this can only be fixed through
regulation. Thank you. So, there's more questions to come. But we have a panel after. So, you will
be keep your question, ask your question after so that we can proceed with the last presentation.
I was also thinking about the same thing as you, sir, about the ISO part. Working with
customers and partners at Red Hat, I can tell you that they need a directive or a compliance
based on the law. Otherwise, they will never apply the things. So, the next speakers, Omar,
is going to introduce us to the other part, which is more like the defective product and
what it means in terms of liability. So, please welcome Omar with a round of applause. Thank you.
You're okay with that? Yeah, we can take the mic. Did Martin show you how to use that?
Yeah, I think it's, yeah. Thank you. So, thank you for the invitation. Thank you to be here. And
I'm going to try to not use too much legal terms because I think now we're going to enter a zone
that if you're not a lawyer, you will not really understand what we're talking about. So, I will
kind of try to use more simple situations. I think the name of the proposal speaks by itself,
product liability directive. The PLD, as we call it, is about the liability.
So, I'm going to tell you, give you some examples. Boeing 737 Marks, two of them
crashed some years ago. An autonomous vehicle that crashed and killed a person. In South Korea,
lawn mower that went into a person. Your mobile phone that overheats.
All of these situations are what we call the liability. And all of them includes softwares.
So, what Benjamin explained to you are the obligation that when you want to place your
product in the union on the market, but when something goes wrong, someone has to pay the bill.
This is how every system works in all countries. And what the product liability does tells you
who is the liable person and what the victim has to show to claim the compensation.
So, the regime of the PLD exists since 85. But as you know, the product of 85 was not the one
that we have today, including software, AI systems, IoT, etc. So, what we have done is to
redraft and re-clarify the regime that existed by including all softwares in it. Because as you
know, and with the example that I gave to you, software can in some situations cause harm
and cause a damage. So, what the PLD does and it says that the manufacturer is liable for
damage caused by a defect in their product and the injured person, so in a tribunal or in a court,
has to prove the damage, the existence of the damage, the defect in the product, and the link
what we in legal terms call the causal relationship between the defect and the damage itself. If this
is proved, the manufacturer has to compensate the victim or the family of the victim in case
of death. So, the manufacturer is defined, this is a definition that appears in all legislation,
product legislation in the union. The damage, what damages are we talking about? Death,
personal injury, damage to property, think about an IoT boiler system in your house,
overheats, the house explodes, someone has to pay for that. That's a simple situation,
but at least you see exactly what we're talking about. Data loss, data corruption,
this is a new addition. So, obviously the liability that you had until now covered any physical
things, but as you know, your own stuff, even in the material world, when you talk about NFTs,
when you talk about NFTs, why would you be covered if your painting burns because of your
house exploded, let's say, or whatever, but you cannot get compensation if actually you lose
your NFT. So, all of this has been re-adapted and included in the regime. So, these are the
damages for which the manufacturer has to pay compensation in case there was a defect that
caused the damage to one of them. And so, the entire notion of defect, and I'm going to try to
explain a bit also what was the part of the revision, the entire idea of defect is that the
product did not, let's say, had a lack of safety that a general person is expected to have. So,
your fire alarm does not detect the smoke, you are expecting that it would actually do it.
If you have a computer and actually the software has so many vulnerabilities that you lose any of
your data, you might expect that actually you should not do it. So, all of these are normally
explained in quotes, and if you establish that there was a defect and that there was a damage,
then you get compensation. Defect does not mean that we're talking about a zero absence of bugs
in a software, for instance. This is not what it means. Zero, it's impossible. You cannot have it,
but you can have vulnerabilities that, as a developer, you should have expected, or you
should have foreseen. So, all of these are elements that are taken into account to establish the
liability of the manufacturer or manufacturer developer depends on which type of product we
are talking about. So, as I said, the liability has been revised. There are different adaptations
of the regime for liability, the digital age, circular economy, this is about the
substantial modification that we've talked about. The global value chains, this is a concept that
we talk of mostly in trade, where a product comes from outside of the union, the manufacturer is
established outside of the union, and brings the product in the union, and so you need to know who
is the liable one, and then a better protection for victims. So, basically, what the new proposal
or the new product liability directive propose is to say that any software is a product,
no matter how it's supplied or provided. So, in this, obviously, also includes any AI systems.
No matter if it's a software as a service, or anything that will be concerned as a service,
all of them are software, and all of them are products, and all of them will be covered by
the liability. But at the same time, you also know that software do not work independently.
You have what we call the digital service, the flow of data that feeds the AI system
for the training, all of them will be covered, and all of the providers of those data, for instance,
will be also covered by the liability in case something goes wrong. As we talk about already,
there is the exception of open source software outside of a commercial activity. To be clear,
outside of a commercial activity is the exception for any product. If a product is outside of a
commercial activity, it's out. But what is a commercial activity? Well, if your software
is sold, this is a commercial activity. If you provide services to the company that takes
your open source software, this is a commercial activity. Those are examples of commercial
activity. This is how it has been interpreted by the court. This is part of the court judgments
and case law. Obviously, you will have different situations, but these are some examples that I
gave to you. The damage is to data loss and corruption. The software updates and upgrades.
Obviously, your software or any type of product that are digital evolved during their lifetime,
and this has also to be taken into account. If you do not provide the software update or upgrade
that was necessary to avoid the damage, you can be held liable. These are the different
elements, but obviously, I will not go into absolute details. Addressing the cyber vulnerabilities
might also open a claim for damages. The evolution of an AI system through machine learning could
also open a claim if the machine creates any damage. That's a bit of the adaptation.
The circular economy is the general concept of substantial modification. Obviously,
if someone substantially modifies a product, in this case, a software, it should be the one who
should be held liable if something happens, has a manufacturer or the developer of this
software after he has done the substantial modification. The value chain is more related to
the traders that impose the product in the union. As a victim, you should not be blocked just because
you do not know who is the manufacturer of the product. Anyone who is part of the value chain
that brought the product in the union can be held liable. Through an importer,
if you buy through an online marketplace, those entities could be held liable instead of the
manufacturer. Obviously, if they have contract with the manufacturer itself, they can have recourse
against them. The better protection, it's more for technical points, but it's how it's going
to work in courts. You have situations that are so complicated. Let's take an AI system,
explaining where the defect is in an AI system might be complex as a victim to show. We created
what we call in legal terms legal presumptions. If the victim can prove one of those elements,
you have what we call the presumption. We presume that the product is defective and it
has caused the damage. If it's the case, then it is to the manufacturer to explain that actually
it is not the case. That is a legal tool that exists in every system, but we have adapted it
to ensure that if something goes wrong, someone at least has a possibility to have a claim.
It does not mean that you are liable. It just means that you can bring a claim to a court
and make your case and explain why the product was defective and why you have a damage and
why the manufacturer should be held liable. This is not an automatic situation. It's not because
we have included software, for instance, in the scope of the legislation that it means that you
will be held liable. You need to have a damage. You need to have a plane that crashes because of
the software that obliged the pilot to go down instead, to go up, the autonomous vehicle that
goes into a wall while there was nothing on the road. Those kind of situations are the one that
at least allow a victim to make the claim and go in court and try to get the compensation.
If the product was not defective, well, then there is no problem. Again, when we talk about
software, this is not a zero bug that we are talking about. We are talking about expectation
that you have about the software, the fact that your software should not overheat your boiler,
the fact that the pilot, the software pilot in your plane should not push down while you're
trying to go up. Those kind of things, these are the situations that we're talking about.
These are a bit of technical situation, but we have what we call a disclosure of information.
Only the manufacturer of the product itself knows the product. As a victim, you need to have access
to some sort of information, like the data used, any kind of evidence that could be of an help
to create the claim. Obviously, those information are protected by trade secrets.
This is not a way of giving away your secrets. They are protected through courts.
There are systems. We have years and years of practice in national system, in tribunals,
to know exactly what can be showed, how can it be showed, and what to protect. But there should be
an access to the necessary information for that. Finally, this is a bit of the small details
that have been changed. There was a ceiling before for claims, before you could not get
more than 70 million. I mean, we're not talking about every claim will be 70 million. Let's put it
like this. But there was a ceiling cap. This has been removed. Nothing explained that you should
limit it in number of money. There was a threshold. If your damage was less than 500 euros, you could
not have any claim for liability. And then the liability as a time period, you're not liable
for 300 years. You're liable for 10 years after putting on the market your product.
After that, you cannot be held liable under these rules. But there is a time limitation.
This allows to predict and to ensure the risk of your business, if it's a business, or of your
product. And there has been a small adaptation for personal injuries. This is typical for some
specific product like pharmaceutical products where the damage appears after. I mean, I didn't go
into all the details, but the product liability does not apply only to software. It's one of the
product. We're talking about chairs, cars, pharmaceutical product, all of them. So any damage
that any of those products will cause, you would have a claim for compensation. So that's it from
me. Thank you very much. I hope there was not too technical. Thank you, Omar. We're going to go
now to the panel, and I will introduce James Lovegrove from Red Hat, our policy director.
Who will be the moderator? So I'm giving the mic to James.
Very good. Welcome, everyone. I appreciate that we're halfway through the session. So if you
want to stand up and then sit down and stretch your arms, that's fine. So in terms of the first
and weekend, I mean, yesterday we had the policy summit brought together a couple of hundred people
in person and hundreds more online, I understand. But what's interesting is only five, six years ago
when we started it in earnest, as the OFE is in the crowd, there was literally, I see, it was there,
there were sort of 14, 15 people in the room. So I mean, that massive scaling is interesting in the
sense of a response to the growth of EU policy impacting digital ecosystems, open source included,
but also the intent and realization that as a community of open source practitioners, further
collaboration and coordination is absolutely essential. I think today is a good example
where the Commission see that as well. We're joined today by three members of the European
Commission from Digit, from Grow, from Connect, and frankly, I think they're worth a shout out
and a round of applause. It's a big deal having them here. Thank you.
So, I mean, music to our ears, Benjamin Meade really clear up there. He mentioned rational
to exclude non-commercial open source. So, you know, the door is open, the ears are open,
but this is a complex process. Yesterday, we were talking about the analogy of trains,
leaving stations and so forth, and yeah, it's now en route. It's going through quite a complex
co-regulatory process, and as a community, we don't have the resources in many cases to
actually keep up with that. So this kind of collaboration is absolutely critical if we're
going to reflect that rationale of best practices when it comes to open source, but also best practices
in terms of the tools that we're talking about into the law, into the practice. Otherwise,
there will be unintended consequences, and I think nobody wants to hear that. I think the final
point I want to make just before I hand over to our first panelist is that even if we get the
open source exclusion and some of the clarity into the text and the articles around open source,
it's still kind of half of the journey, and I think that's important just to underscore. There
are still elements which need further discussion on how they practically impact this extraordinary
ecosystem, and I think without further joining, I'm going to hand over to Zoe, who is a senior
policy manager from Digital Europe. I'll let her introduce what the organization does and who it
represents, but it's a big deal when it comes to engaging with EU policymakers both here in
Brussels but across the Union, and it's great to have her here to let us know what Digital Europe
thinks about this. Thanks. Thank you, James. Thanks a lot, everyone, and indeed many thanks to
the organizers of the panel, but also to the commission. We also do really appreciate that
you always take the time, and I know how much effort you're putting on this legislation. So
Digital Europe is an industry trade association. For those that you don't know, we represent
the tech industry that is active in Europe, but we also obviously represent both, well,
global actors from across all regions that they are doing business in the tech industry in Europe,
and we have two chambers of members. We have the corporate ones, and we also have the national
trade associations, that this gives us an outlook on both the global scale of things, but also on
the national level. So through our trade, national trade associations, we also represent all sizes,
including SMEs, for example. So why are we here is that's because we think that the Cyber Resilience
Act is one of the most pivotal legislations that we are going to have, well, now with this mandate,
but in general, it's a trendsetter. It's a very, very important legislation. At Digital Europe,
we do a sort of internal search to see what is important for our members to make sure that our
resources are allocated accordingly, and AI, data, and the Cyber Resilience Act have been ranked as
the three highest priorities for the digital industry. So I just want to emphasize again how
important this legislation is, and thank again the organizers for really taking the time to
highlight this. Now, I think it's probably one of the first times that the industry and NGOs really
agree. So Martin's presentation was very interesting, and I noted down many of the points that we also
highlight in our position. I also want to take a moment to say that you probably wonder, especially
the open source community, you wonder why the industry, the big tech or multinationals, why do
they care about the open source community. So actually, I just wanted to clarify that for us,
it's very, very important to make sure that the open source community is not overburdened by this
legislation. For many of our members, even up to 100% of their commercial products have
rely on open source components. And just like James said, there are many priorities, many
things that we can improve at this area, but not overburdening the open source community is one of
our top priorities as well. So it is also important to note that it's a bit of a stereotype to think
that the big tech companies, for example, they only rely on closed source and they don't care
about the open source community. But I want to highlight that for us, it is a very, very high
important to make this a key priority for the CRA to have clarity on what this means for the
open source community. So I'm not going to repeat too much myself because you already said it,
Recital 10 excludes open source. And we very much welcome this. And in general, we welcome the
legislation. It's a very good draft. It's something we can really work with. And we need it. Let's
start from that. We all agree, also the private sector, that we absolutely need these type of
requirements. So we are very willing to find a way together that makes it work. But we really need
to get it right, including too much, too soon can also be very damaging. So for open source,
there is a conundrum of it's excluded, but not really. So the tech says that it's not in, but
then when you look at the commercial element of it, and if you look at the definition of what
commercial is under the blue guide of the new legislative framework, it says that commercial
is understood as providing goods in a business-related context. So what does this mean for the
open source community? What does the business context mean? Most, like I said before, many
of the commercial products rely on open source components. So we need clarity. Right now,
if you look at the document, there are 85 pages. Commercial is mentioned only twice and there
is no definition. But this brings me to the bigger element, the issue of the proposal that
we really see. One, we really welcome the fact that the NLF is the approach that is chosen.
Benjamin did a great job explaining the NLF and the same marketing and everything
related tangible products. The big quest right now is how to move a regime that has been so
working very well. We think for tangible products, but now the biggest challenge is the CRA wants
to transform this regime into something that is workable for software, which is again very welcome
because NLF has proven to be the right way to do things. But we really need to work more on the
definitions. So commercial is just one way, one example. Then there are other examples,
like components. In article 11, when it comes to reporting, it says that manufacturers have to
also report on vulnerabilities including soft open source components in paragraph 7. So the
question there is, what does a component mean in the context of a software as well? So this is a
general comment on how we really need to work together to transform NLF into something that
makes sense for software. This is why at Digital Europe we have been really advocating for a
clear provision asking the commission to develop guidelines that they adapt to the
specificities of software and specifically standalone software. With the inclusion of
the industry, because what we see here is that the people that are going to actually have to
abide by the new compliance rules, the industry players, are not really included in the draft in
the sense that we really want to be part of an expert group, that we are going to help the
commission, that we know has the appetite to do this right. But we bring the experience and we
bring the questions also. What does this mean? What does placement of the market for software,
for example, mean? What does substantial modification mean? So all these things,
we, I think the important thing is that we all see that we have the appetite, but it still needs
to be clarified in the text. And maybe just as a final point, all these things need time.
And I really welcome the question before on standardization. We appreciate that 90% of the
products that rely on self-assessment and when existing harmonized standards are there.
But we also need to look at what does this 10% mean for critical products? Have we actually made
an assessment of how much of the burden is for third-party conformity, for example, are notified
but is ready? So these all means that we need time to get it right. The current proposal says
24 months for implementation, for the development of harmonized standards, sorry, and for the
development process is just too little. And I think this is probably something we are more or
less aligned on that we need more time. And for us, the proposal is 48 months, but I know this
is something we will discuss further with the commission and with the colleagues later. Okay,
so I don't want to go into more, there is way more there. Maybe just as a final comment,
even if, as James said, even if we get the open source exclusion right, there are several things
that need to work in the whole context of software, including reporting obligations.
The right timelines right now, it says 24 hours for initial notification to be, but we want it
to be aligned fully with the needs directive because we think it's just introducing too many
processes is just too much. And yeah, I mean, I don't want to go too much into more details
because James is giving me a smile that says that I've talked too much. Thank you very much.
Thank you, Zoe. Well done. So I'm going to now turn to Rom, a colleague of mine, as you know,
Red Hat is an upstream first pure play open source software company. And therefore,
Rom spends a lot of his time, maybe a lot of most of his time upstream as a volunteer, as a
developer, as a contributor. So I'd be interested in hearing your perspective. As Martin was
mentioning, you know, he has a particular perspective on it from DNS and now the sort of
wider larger ecosystems are involved in the kinds of products and projects that Red Hat's involved
in. And to Omar's point earlier about just getting real on zero bugs being impossible
in the concepts of PLD, I think that's an important point to underscore and something which, you
know, the no known vulnerabilities, implications for open source or even for proprietary, not
that I care much about proprietary, but nonetheless, it is important to have that recognized that
the commission understands that, but it needs reflecting, as I say, in the text to make sure
that clarity is clear. So, Rom, I'm going to come over to you and give you the microphone.
Thank you. Yeah, so we are in a unique position at Red Hat of being a large contributor for the
open source. And if you look at the portfolio of product that we have, I think we're depending
and contributing to about more than a million different open source projects. That's the level
of contribution. One particular example that James was mentioning is the look at critical
systems, but also critical products like credentials and the zero bug. We all know that zero bug
policy is impossible to achieve. And I'm really glad that Omar underlined this. But the reality is
that if we don't have clear definition about this, it's going to slow down so much contribution,
so much innovation that we have. And we already see that through the lens of our internal folks
and myself for some project that I'm working on from communities, maybe you know communities,
with the special interest group for authentication and key management system,
there's a lot of people scared there. And sometimes we're looking into putting into,
I would say into the product, new features that we deem interesting. And we truly believe that
it will be a game changer for the community and putting a product in production. But in the
meantime, we are really scared because we are not able to make a full interrupt compatibility
assessment with all the different projects. As I said, one million projects. Can you imagine if
you start having the need to go through the full cycle of integration and testing for this?
We try to do it at Red Hat. And that's sometimes the reason why when you look at the difference
between what you find in the community with Fedora, or I'm doing a bit of marketing now,
about Fedora, or CentOS, or I would say OKD, you will see that there's a major gap between
what we have there, which is like top edge cutting edge solution versus what we have in
the product. Because we're scared about it. Not scared in a sense that we don't want to
give innovation, but we are scared about what would be the end goal, the end results,
if we are becoming responsible also for some breaches. With credentials, and the work I'm
doing on contributing, actually, because we are about 112 person working on this, we look
into this perspective, this lens of compliance and regulation. And no later than yesterday,
I was in one of our company events where we had 1200 people, techie people, we're interested
in technology, and we were discussing a group of 60 there about this. And that's the moment
some people were like, oh, I'm not going to touch this, I don't want to be responsible of this.
So we need more clarity, we need more understanding. So when we see the law, and that's what I would
really love to have, it's to have more like a framework where we can share this with the community
and make sure that we can put straight upstream those perspective, those regulation compliance
perspective, so that you guys are not afraid of contributing to any top notch cutting edge solutions.
Credential is one of them. If you know a bit communities, you know that it's nothing related
to password managers, but as soon as you're using secrets with communities, then it becomes a
password managers. And it's a critical class one product then. And so it's those kind of things
that nobody think about, but we need to get that into perspective so we understand what needs to
happen then in the product. So there's specific elements to take care. And there's a cycle of
work that is really, I was going to say burden, but we all know that when we do software, we need
to go through a secure supply chain. This is the buzzword of 2022 and 2023. But it's a reality.
And I like the comment about the ISO part. There's so many different ways to standardize this.
There's so many ways. There's the best practices from an industry standpoint. There's guide. I
think the EU has the blue guide also where you can have some guidelines. So there's different ways
to approach this. But it's an ethical responsibility to apply it. And sometimes, well, we are so
carry on with our innovation that we forget about it. We're like, oh, we should do it like this.
And so that's the other side. I'm really worried about the regulation. But in the meantime,
I'm really happy that there's something there to enforce us straight from the beginning
to have this secure supply chain in perspective. That's for me, actually.
Great. Thanks, Ron. Yeah. So I think one of the things I took from that is,
and I think this penny is dropping, not just in this room, but elsewhere, is that software is
fungible. And I think some of the terms in the draft regulation around intended purpose around
sorry, it's calling from my son. Probably not a good time by Sam. Yeah. So in terms of intended
purpose, reasonably foreseeable, any known or foreseeable circumstances, I think that's something
which gives open source a pause for concern. And I think one of the reasons is coming from an
open source licensing perspective is that bringing that community together is not just a question
of passion to solve problems and build our open innovation in Europe, but also to be shielded.
So developers do not incur liability nor offer warranties. And I think that's something which
is clearly important. And actually, it's a good segue to Chris, because in his capacity at Digit,
in the open source program office, the EUPL is one of such license, which again,
is important to open source contributors, collaborators. So I'd be interested to hear
more from your perspective by Sam, and understand from your thoughts on this particular topic.
Thanks. Thank you. And it's very good to be back at FOSTA, people. I think we all agree.
This legislation, of course, also impacts the commission open source projects.
So we're looking forward to figuring out how to work on this. To give you a bit of perspective,
so I talk on behalf of the European Commission's open source program office, and going to quote
the words from Deborah Bryant yesterday, we're basically, for you, an easy to find, easy to access
way to find out who to talk to amongst our colleagues. We will do the legwork, we'll find out who we
should put you in touch with, we'll find out who to talk to. And we will liaise when necessary
between the commission policymakers and the open source community. So that's one thing I can
promise you, we'll try and make this happen. A little bit about the OSPO, James, is that okay,
as context, so we started in 2020, thanks to a communication from the commission to itself,
about an open source strategy that recognized that if the commission wants to reach its political
goals, it needs to basically take into account that in everything there is software and in
all the major political goals, open source is a critical component. To be an industry, to be a
European market, to be active in innovation, to be active in competition, open source is there
and it can't be taken out. One of the first things we did as OSPO is make it super easy
for the commission to disseminate its open source process. So far, previously it was a
paperwork process that would take six months, now it is basically up to the project to the
site, we want to go open and we have a code repository, code.europa.tu, which now has some
200 projects and 700 users and this is from the commission, from ISMA, from DigiConnect,
from JRC, from the European Central Bank, from the EDPS, so you should check that out and maybe
start working on some of these solutions and this also shows that we will be impacted because
we're pulling in an enormous amount of open source to build these components.
Another thing that I think is good for you to realize is that we're, as a commission,
OSPO in touch with OSPs in the member states. Some of them are here, I have my colleagues
from Germany on the right for you on the left and the colleagues from the Czech Republic on the
left for me, so on the right for you and we're in touch with these specifically for this kind
of reasons. We need to network as OSPOs, we need to avoid making mistakes that others have made
before us and work as a group. I think I'll stop here, it's a good introduction. Very good, thanks
Case. So I am conscious we have, if I'm right, another half an hour, 25 minutes, is that right?
So I would like to give Benjamin the floor just to capture some of the thoughts I see you scribbling
down, I hope I put you on the spot, but I'm sure some of them are familiar and it would be really
good to hear from you on this, thanks. Great, thank you so much, Jamin, actually all the points
are familiar to me. We are of course engaging a lot with stakeholders and as the Commission,
we are now in a tricky position because we made the proposal and it's of course the Commission's
view that our own proposal is perfect the way it is. That being said, it's the beginning of the
journey and it goes without saying that the Parliament and Council will closely look at the
text and they're of course also consulting us a lot and many of the things that have been
mentioned here, they are being discussed by the co-legislators. So for example, this question of
providing products with no known vulnerability, I mean, I can say that this is being discussed
already by the co-legislators and also, I mean, we've heard quite often already this, I mean,
this concern that maybe the transition period is too short. I mean, we believe that 24 months
is sufficient but we hear this a lot from other stakeholders. So I mean, you can be sure that
this is being all taken very seriously from us. Wonderful. Now folks, it's really important that
this community here in this room take this opportunity. It's not a speak now or forever
hold your peace but it is a good opportunity. So if there are any who want to chime in a question,
comment, that would be great. And then we're going to move back to the panel. Who's first?
I think you're first. I already stole your mic, sorry. Okay, go for it.
Sorry. So, well, I'll try to be brief but there's a lot to say. So first I have to apologize
because I feel about this. So I will be carried away. Sorry. Nothing I'm going to say is meant
to be offensive to the commission. Actually, I think that many of the recent acts are very good
for the internet industry, for the internet, like the digital market sector. So the criticism
will not be meant as a rejection of regulation. So my perspective, I'm the software developer
and I'm the head of policy for open exchange which is a German open source software maker
of around 270 people. So I'd say that we are small if compared to the big tech industries
from globally. But we are still one of the biggest. So we are also one of the companies that,
I mean, we make stuff that is in every Linux distribution like Davcott and so we care about
security. We are ISO certified, ISO 27.1. So we are among those that could afford to follow
everything that's in the Sierra and would do that. But we are part of an ecosystem.
And so we feel the need to, I mean, also bring the perspective of others,
including some smaller projects that we use in our own projects. And the problem with this
regulation is, well, there are multiple problems. Let's start from the non-commercial exemption.
So there isn't really no way that you can tell commercial projects from non-commercial projects
because each and every project except maybe like my hobby project which I only, I mean,
do for myself and publish somewhere, has some economic result, creates a value. And there
will be people using it to create further value. And so it is basically very hard to write a
non-ambiguous way to tell commercial from non-commercial. And all projects, including like,
I mean, search centers, like NLNet universities need some money to, we need to get at least
donations. And so there is no way you can prevent, you can tell this. And on the other hand,
I would also be against in saying that all open source software is exempt from this regulation
because I'm sure that the proprietary software makers would come and say, you know, as they have
been saying for 20 years, you know, open source is just a toy, it's just a hobbyist project,
so you should use proprietary software which is secure. So don't do that. The problem is really
that this law doesn't seem to understand how software works. I mean, software, pure software,
material products have a nature which is significantly different than any physical
product with software on it. So this regulation seems to be designed with cars in demand,
with toys, with IoT devices, but not for pure software. Pure software is more similar to
literature in a way. It's something that is the result of collective development. And if you have
a look at open source projects, I mean, yes, we are the manufacturers of Dovcott, but if you look
at the code, it's written by people everywhere on the planet. So yes, but the real authors are
maybe like a thousand people which are in Europe, outside of Europe, everywhere. And so your law seems
to put the burden of like putting a CE mark on every line of code which is imported into Europe.
I don't even know what that means. I mean, we have repositories, maybe they are in Europe,
but they are mirrored in the US. There's people from Australia, I'm from China, I'm putting code
into it. And this code is traveling all over the world throughout the borders of the European Union
several times per second. So should I, every time I check some code, I mean, someone should
stop the code at the border and put the CE mark. This doesn't really make any sense. It's simply
impossible. And it is to say, I mean, all the people here, I mean, your law is designed for the
traditional 20th century way of making things in which there's a manufacturer and there's a
distributor and someone that sells them in a shop and then there's the user, the consumer. I mean,
like if we were still buying, sorry, I'm trying to be short, but I know you want to stop me,
but I have to say this. Yeah. And so this seems designed for the time when we went to the shop
to media market and bought Windows 95 in a box on a CD. And this is not how it works. Everyone
here is at the same time, a manufacturer, a distributor, an importer, and a user of code.
And there's no way you can distinguish these roles. So you have to find something,
you have to find somewhere. So no, I can cut it short. So I don't understand the problem you're
trying to solve. Show me one case in which a European piece of open source software had
a problem that created issues with the entire world, and how this could be solved by this
regulation. Because if you just maybe funded some security audits for projects that cannot afford
them, this would make a much bigger effect. So let's start again discussing from software for
something specific for software, because this really is not working. Thank you. Thank you.
So I submitted the Openform Europe document that Martin referenced. I probably have a
dozen questions, but I picked one. So to publish software in the EU or to import software into
the EU, the publisher must perform CRA certification and accept CRA obligations.
So this means that software from outside the EU will no longer be available in the EU
if those developers do not perform CRA certification or accept CRA obligations.
How is that not a massive problem?
Yeah, I think my understanding is one of the goals of the CRA is to avoid
log 4j or open source type of incidents, but they are non-commercial open source software.
And when we exclude them from CRA, we are technically not addressing these cases. So what
do you think about this? And as a solution, what do you think about expanding the proposal to set
up necessary operational financial assistance dedicated to the critical open source initiatives?
Maybe especially the EU ones, maybe European Ospo. Is that feasible?
Thank you, Alex. Thanks. Thanks for the insights and thanks for the panel. I mean,
I have two questions. We have a lot of problems, but I'm interested in solutions.
So first, what's your proposal to fix this commercial term? So do we have one? Could you let
us know? And the second one to the commission. So do you see the issue like NL net? So would
you consider charities to be affected by this definition or not? So what's the commission
take on the NL net position? Thank you. Thank you very much. And finally, we've known for a long
time since David Wheeler wrote his paper stating that all open source software is commercial,
that the word commercial is a bad word to use if you want to exclude open source.
And so I recognize that it arises from the courts in Europe and from the blue book,
but have you considered using different terminology to solve the conflict that exists here because
of the nature of the community you're addressing rather than because of the context of the existing
legislation? And secondly, which community organizations did you consult in working on
working on both the PLD and the CLA? You see the panel is comprised purely of commercial
organizations or commission members. And all of the questions you've received are from community
charity representatives who are in the audience and on the panel. I wonder what you're going to do
to fix this problem so that you don't get it with every subsequent bill. Thank you.
Yeah, thanks a lot for all these questions. I mean, maybe first this one on who we consulted.
So as a run up to any commission proposal, there is a public consultation which runs for three
months. It's a period of three months where we ask a set of questions to the public and everyone
can respond to these questions, including you. I mean, maybe you didn't know it's possible. I
understand that. Of course, we know, of course, very well that these public consultations, I mean,
that big players, commercial players, they are more paying attention to this because they have
the resources to do, though. And that's clear to us. But that's also, of course, one of the reasons
why I'm here, right? Because I know that this community, maybe the voice is not heard as much
as the voice of other communities. And as I said, we can, of course, keep engaging. You can come
later. I can give you a card and we can discuss. We can even do maybe another small event and
discuss further, right? I mean, it's all possible. On this concept of commercial, so first, I mean,
I think it would be very difficult for us to replace it by another concept because it's well
grounded in this new legislative framework. And all the industry players that we've been speaking
to so far, they all say they want us to use the new legislative framework because they are familiar
with it from other product types, right? So, and we want to ensure that all stakeholders
can use the same framework. If we now invent a different framework, it will lead to a lot of
fragmentation. It will make compliance more difficult for companies. So that would be difficult.
Of course, I mean, there's this crucial question of where to draw the line of commercial. I think
we are open to all your points. We understand them. I think what would, from our perspective,
be very difficult. I mean, this is how I understood your intervention would be to say we just exclude
all open source because it's all somewhat commercial and it all needs to be excluded. I think this
would not work simply for the fact because it would create an incentive for proprietary manufacturers
to swiftly switch over to open source, right? Okay. Not everyone can do that. Ah, you want that? Okay.
Okay, I see. No, but it would create an incentive to get out of the scope and to not have to comply,
right? I don't think this is what you want. Then there was also a point from you on all the many
small players and how it would be maybe difficult for them to comply. Now, so the Cyber Resilience
Act is, I mean, the requirements in there are their risk-based. That means that, I mean, when
you're a very small player, there is also a chance that maybe your project faces smaller risks and is
maybe less critical. And you can take that into account when you comply with the requirements
of the regulation. On top of that, for the vast majority of products, we only require self attestation
by the manufacturers, which means you will not have to reach out to any third parties or interact
with any authorities. You can do it all by yourself. And this should be absolutely feasible.
What other questions did we have? Yeah, there was this question of how the CRA would improve the
ecosystem for components that are vulnerable, such as Log4J, where you said, I mean, this is a non-
commercial component. So, I mean, we have this due diligence obligation in our proposal. That means
that in the future, when a commercial manufacturer integrates a product, for instance, a logging
utility that is free of charge available, they will have to make bigger effort than today
looking at these components. I mean, that, again, of course, depends on the risk. I mean,
if your project is low risk, you will only maybe check the change log if there are regular security
updates or not, and you're done with this assessment. But of course, if you integrate this component
into something much more critical, you will have to take a much closer look at these components.
So what we're trying to do is we're trying to make manufacturers of commercial products,
proprietary or open source or whatever, assume more responsibility for the open source components
that they're integrating. And we believe that this will help raise the level of security on
these components as well. Yeah, there was this question on whether charities would be considered
as a commercial activity. So I cannot just give you a straight answer on that. I think it always
depends on the individual case, right? I mean, what we've learned is that there are so many
different types of open source projects, so many different types of funding models. So you really
need to look at each and every case to see if it's a commercial activity or not. What I already
said, I mean, we are, as the Commission, we are absolutely willing to provide more clarity.
This could be done, for instance, already in the legislative process that we single out important
examples and we provide clarity directly in the legal text. But for all these other niche cases
that will come up, this will not be possible in the text because we cannot, you know,
a legal text needs to be short and concise and we cannot take into account every single example.
But we're absolutely prepared to provide examples once it has come into force so that you have
the certainty that you need to know whether you are in the scope or not with your project.
I think I took them all. Yeah, I think that's because, so for, I mean, I'm going to speak for
the PLD, but for my proposal, we had expert groups consultation in 2018-2021, consultation also
through the contractor where they were questioned through different kind of stakeholders.
We had the consultation for when the proposal was adopted by the Commission in September 2022
with the Have Your Say portal. This is where you find all the proposals and where you can give
your comments on it. So, and it was for more than three months for hours. So, we always tried,
obviously, to reach as much as possible. The thing is, obviously, there are sometimes channels.
It's not that we avoid having talks with the people that can criticize the legislation. We need
critics to also make the legislation better. This is how it works. So, obviously, as you said that,
yeah, there might be some players that are more voiceable. This is the reality. I think it's
also part of how the field or the ecosystem organized between itself. You need to have one
speaker, someone that can represent also the community, because obviously, if we have someone
that comes for the open source community that says that he is speaking for the community,
then he would bind everyone. So, you know, those companies that have those trade associations,
et cetera, this also gives a framework for us to really say, okay, this is a voice of this sector,
this sector, this sector. When you do not have this, it's a bit complicated for us to take it as
just being the voice of the entire community, because you can have an opinion and someone
else can have another one, but then which one do I have to consider as being the one of this
community? That's a bit of the complexity also for us, just to be honest. On the charity one,
there are definitions. Commercial activity is whatever against money or for free. It does not
matter the economic value in that sense. It's a concept that goes much more broader than this. So,
I understand that there is this need of clarification. This is where the definitions
are there, but they are also the basics of any legislation that we have in the union.
It's not that simple to change just one definition that it's common to all of them
in one single piece of legislation. This is also the reality of how the proposal works.
You need coherence. You can have some exclusions, but we talk about why, I mean,
it's not just the need of excluding open source software. It's also the need of ensuring that
does not have an impact on innovation, but you also need to take it into account the reality
of it. So, that's a bit of the... Thanks, Omar. Benjamin. Yeah, sorry. I just want to be thorough.
I forgot to answer one of the questions I just realized. So, there was a question on whether
there could be a risk that products developed in third countries would simply not be made
available anymore on the European Union market. So, no, we don't see this risk, to be honest.
I mean, the European Union, depending on the figures that you look at,
is probably the biggest economy in the world. I think everyone has a very strong interest in
bringing their products on our market. It has also not been the case with other regulation.
If you think of the GDPR, I mean, the list of companies that choose not to provide services
in the European Union because of GDPR is very short. So, we don't see this risk.
Thanks, Benjamin. Anna Martin, you're dying to say something. So, how do I go to you?
Thank you, James. So, I will answer the question of Alexander of how to fix this,
but first, I would like to respond to some of the comments made. So, I think you hit the
nail on the head by saying that the consultation, it's complex within the existing way of how
Brussels operates, at least that's my perspective now as a newcomer here. And I think if we are
not addressing that bit, like how to talk to communities like this, then we will be in this
situation again and again and again and again. And I want to point out specifically that the
discussion about commercial just now, I've read both your proposals, and you are not
using the same examples of what constitutes a commercial activity. So, if you're saying that
they originated from the legal jurisprudence, then one of you seems to have a different
view on the jurisprudence and the other one. So, and I asked, I was wondering, have you
considered talking to the open source program office when considering the definition, and I'm
sorry if this is a bit confrontational, but I was just actually curious. So, before you answer,
I am going to try to answer Alexander's question. I think he was asking how to fix this.
I'm not jealous of your jobs because I think this is extremely complicated, and I don't have the
full answers. I have one sub-answer, and it relates to critical products. I believe that there should
be an escape hatch for class one and class two critical products, that if they are completely
open source, then there should be the ability to do self-assessment, regardless of any other factors.
Because I think the value of having critical products that are open source
is tremendous in terms of security, too. So, we should be considering that aspect in addition to
whether or not there is an EU standard that it can conform to, for example. I hope I touched
somewhat on the ask again in maybe a couple of weeks, because I think they are in a hurry,
so we should be, too. And then maybe back to the question I just asked about talking to Gijs.
The power of the moderator. What's it worth? Cold beer? Maybe just to add one question to make
your job a bit harder. Well, first, I think that we also need to recognize that you guys are also
here on a Saturday and everything, so I think the appetite to interact with many groups is also
there, so I think that's important to acknowledge as well. But I'm mostly wondering about the part
on technical support, because we are focusing a lot on the definition of commercial, but
the text itself says also, especially when technical support is provided, then the open
source software is not excluded anymore. And I guess this is more of a general question, because
I'm not myself an open source developer, but I'm just wondering to what extent this is demotivating
then for developers, because I understand a big part also of the maintenance after, for example,
is a motivating factor for people to develop, because then they are also involved later on
on the maintenance. And I'm wondering also to what extent this is counterproductive for the
objectives that the CRA sets, having the people that are involved in the development, but also
they're involved in the later stages of making sure that the product remains secure. Then actually
this, I think I would assume that it helps the security of the product. So it's more of a question
on whether you have discussed this part. I'm sure you have if you put it there, but just if you
could elaborate a bit further and an open question also to the audience, just because I think it's
important for the audience to sort of educate us as well. Thank you. Yes, okay, we've got five
minutes left. So Rom and Oma, and then we close. Yeah, okay. So I'm just going to continue what
you just said. I think one of the tremendous beauty of the open source community is giving
support to each other. And I think technical support as defined is very dangerous. And I'm
going to give an example. If you are having a, if you maintain a project and you use one of these
services like GitHub and you start helping someone to make the solution work, so it's
technical support, right? So you open an issue, you start helping the person and so on. If the
person, the person who will receive the help decide to sponsor somehow the developers,
giving money, giving contributions in terms of money, then it, from the definition, it becomes a
commercial activity. This is not the incentive. It's a donation. So I think it's really important
to get that into perspective. So we are not reducing the level of contribution, both in terms of
software development, documentation, but also money to run some testing infrastructure that is
required to do security. So that's my point. Just it. Wonderful. There's an applause. There we are.
Good. So Oma, I'm going to hand it over to you. I know you wanted to answer a point from, from
Mathen. So for the internal cuisine of how the commission works, proposal don't come out from
one own service. So we are three different director general. So connect for the telecommunication,
DigiGro is for the industry and Digit. Each proposal before going out is assessed by all the
dedicated services of the commission. So everyone is consulted and everyone makes the legislation
readapted where it needed because obviously the expertise of each one of the directory channels
helps to make the proposal. So you need, it's an internal mandatory step. So that's a, and on the
small definition, it's not that we have different concepts. It's the, how it has been interpreted
until now and we're talking about almost 40 years of case law. It's elements of what the commercial
activity can be and cannot be. It's never a proper situation. It does never draw a specific line.
I know it does not reply to your question, but we have elements of what is or what is not a
commercial activity and all of them take into account at the end to create the commercial
activity, but they are not, it's not just if you are in room A, it's commercial activity and in
room B, it's a commercial activity. It's different elements that can constitute the commercial
activity or not. That's a bit of a situation. If you are developing your open source
software from your couch on a Sunday, this is not covered. If you're, if a big company takes it
out from, from a website, whatever, you are not making the commercial activity, but the company
is doing the commercial activity. So you are not, you know, these are a bit of the differences.
These are the elements, but if you make it, if you make yourself money out of it, this is a
commercial activity in a way or another. If yourself make it, you are the commercial activity.
If a big company takes the, the, the software and puts it, and puts it in his product,
he's doing the commercial activity, but not you. So he will be the one to cover it, not yourself.
It's a bit of, this is how the commercial activity works. Yeah, I know it's, it's complex, but yeah.
Yeah. We have two minutes left. So 60 seconds.
Yeah. I mean, on this technical support, I mean, it's of course a tricky one, right?
The idea behind the commission proposal of the side resilience is act is to say that
when you're making money with a product, it's a commercial activity. And then you should comply
with the rules because there are so many different ways in which you can monetize a project. It's
not always just charging a price. Yeah. Could also be placing ads in your mobile app or,
I mean, charging a lot of money for technical support. I mean, technical support does not
necessarily mean that it's a non-commercial activity. So of course it's different if you
just recover your costs. Yeah. That's maybe something else. But if you're truly making money
with a project, project, we, we are convinced that it's only fair that you are covered by the
sub-resilience act. So that end device compatibility check, compliance check, I think is, is important.
And I think we've run out of time. We could have gone into the whole notion of components,
which you mentioned on 11.7 and, and where, where we see that, that posing some workability issues.
Unfortunately, we've run out of time. But I would like to ask you all to show your