Okay.
Testing, testing.
Okay.
Yeah, there we go.
If I call your attention.
In the next session, we have a one hour and on the regulators are coming.
Your chair for this session is going to be Simon Phipps,
and he will tell you all about it.
Welcome.
Thanks for coming.
There we go.
Yay!
Hi.
So I'm Simon Phipps from OSI, and I'm part of a group of people from Open Source foundations
that have been engaging with the European legislators this year to fix the issues that you all told Benjamin about
after his talk at FOSDEM last year.
And the TLDR for when you leave early is that thankfully Benjamin and Omar down here listened very carefully
and have, I believe, addressed all of our concerns with the impact of the CRA on open source developers and open source charities.
There are some remaining issues that are a little more complex to deal with,
and they will be dealt with in some guidance that comes from the European Commission.
So to speak to you today, first of all I've got Benjamin Burgle, who is a head of unit now, head of sector at DG Connect,
and he was one of the authors of the Cyber Resilience Act and has been intimately involved in fixing it with us all year.
And he is going to tell us all about the CRA. After that we're going to hear from Gail Blondel from Eclipse Foundation,
who was also part of our group that was interacting with the Commission,
and he's going to tell you whether Benjamin is telling you the truth or not.
And then Omar is going to tell us the same things about the Public Liability Directive,
and then Doug Villum from Apache is going to tell you whether Omar told you the truth,
and then Enzo here is going to run an audience Q&A so you can ask these people all the questions that you want to.
We've only got 50 minutes, so if your question doesn't get answered, come to our dev room, which is all day tomorrow, in AW1120.
It's an open source in the European Legislative Landscape, and we're running four 2-hour workshops to give written feedback to the Commission
on their digital agenda legislative program.
So with all that said, Benjamin, thank you so much for coming back, and they've promised not to throw anything.
So go for it. Thank you.
Thank you so much, Simon. Thanks for having me again.
It's been an exciting year. I was here exactly one year ago.
Last year when I was here, I was presenting the Commission proposal, which is the first step of the legislative process.
We as the Commission, we make the proposal, and then the co-legislators, the European Parliament, as well as the Council,
which represents the Member States, they negotiate on the basis of our proposal,
and now I'm here to report back after one year of negotiations.
The text is almost done. It's quite stable. We still need the final vote by the European Parliament, so it's not entirely finished,
but we are quite confident that what I'm going to present to you today is a rather stable version of the Cyber Resilience Act,
the newest kid on the block when it comes to cybersecurity legislation.
Last year I presented the proposal. I will repeat some of that this year, but I will focus much more on the open source elements,
because there are much more open source elements in the final version compared to the original version.
For those that weren't there, what is the CRA about?
It essentially requires developers, hardware and software manufacturers to introduce security by design in their development processes.
The cheese on the left represents a product with digital elements, as we call them, filled with holes and security vulnerabilities.
On the right-hand side, once you've complied with the CRA, there will be way fewer holes,
although we do acknowledge, of course, that it will be impossible to get rid of all the holes.
That's just the nature of cybersecurity.
Here is a brief introduction into the main elements of the law.
As I said, it's about cybersecurity rules for the placing on the union market,
the entire European Union of hardware and software products.
We have three main actors in this legislation, the manufacturers.
They will bear the brunt of those rules.
They have to make sure that their products are secure, but then there are also obligations on other types of actors,
mostly the distributors, so these are essentially either brick-and-mortar stores or online shops.
They have to make sure that the products that they sell are secure, as well as importers that import from outside the union onto our market.
The rules come in the shape of essential requirements.
So essential requirements are high-level, objective-oriented, technologically neutral requirements for the placing on the market of the products.
They are things like ensure access control, ensure the confidentiality, integrity of stored and transmitted data, and so forth.
So you know all these are high-level.
This is the cybersecurity 101 that we're essentially putting in the law.
To make it more useful and more easy for manufacturers to comply with those requirements, the European Standardization Organizations,
they will develop harmonized standards, and then you can use those standards to comply with those requirements.
The European Standardization Organizations, essentially, they gather the manufacturers, so it will be the manufacturers themselves who will develop those standards.
Depending on the level of risk that is associated with a product, there will also be different types of conformity assessment.
I will explain that in a moment.
I also want to mention separately that there are going to be reporting obligations, so if you discover vulnerabilities in your products that are being actively exploited,
or you have an incident on your network that affects the security of your product, then you would need to report that.
And finally, another important element, of course, is the market surveillance and enforcement.
So all 27 member states, they will be required to set up their own national market surveillance authorities to check products
and ensure that the products that are on the market are actually secure or at least compliant with the CRA.
So these are the main elements.
We are tapping into an existing framework.
You've all seen it probably, the CE mark.
So on your smartphone charges, for instance, you have the CE mark.
The CE mark tells you that this product that you're holding in your hands is essentially compliant with all European product regulation.
And in the future, when you see the CE mark, it will not only mean that you're compliant with safety regulation at the union level,
but also with cybersecurity legislation, the Cybersecurity Act.
So which products are we talking about?
The scope is quite wide and deep.
So when I say wide, I mean that it applies to all sorts of hardware and software products, such as laptops or operating systems.
But it also applies not only to the final products, but to the components, because the nature of cybersecurity is, as you all well know,
that often vulnerabilities and components can have an impact on the security of the final product.
And in many cases, it is very difficult for the integrator who builds a final product to find all the vulnerabilities in those components,
often components of black boxes, in particular when they don't come in the shape of open source.
So they also need to be secured.
And so all components that are placed on the market as separate products, they are also in the scope of this regulation.
What is not in the scope?
I already explained that last time, but it was not sufficient for you.
I explained that non-commercial products would not be in the scope.
And I think this has been quite an issue that has been discussed very lengthy.
A lot of people have asked, what does it mean non-commercial in particular in the context of open source?
And this is one of the reasons why for the last year we've tried to flesh out in more detail what non-commercial means for open source.
And I can tell you that during the last year, barely a single day has passed by when I didn't wake up to a message from Simon,
Dirk Willem or Enzo trying to help along with this process.
So non-commercial products are not in the scope.
I will explain in a moment what that means for open source.
Stand-alone services, in particular software as a service, that don't come with a product that are stand-alone,
that you just access through a website, they are also not covered.
And we also have a few outright exclusions of products that are already regulated when it comes to cybersecurity,
so they don't need to be covered by the CRA.
And that includes, for instance, motor vehicles and medical devices.
Okay, so just to understand, I said the scope is wide and deep.
I want to talk a bit about what it means that it's deep, right?
So when you are a manufacturer of a final product, in this case a smartphone,
you will be integrating two types of components.
On the one hand, like in blue here, components that you've developed yourself,
as well as components here in yellow that you are buying on the market or sourcing from the market,
and you're also integrating them.
So you are responsible for the security of the entire product as a whole and for its compliance with the CRA.
But when it comes to the components that you source from third parties,
of course it's much more difficult to have assurance about the security.
And for those components, we've introduced a due diligence requirement.
That means that as a manufacturer you will have to do the utmost to make sure that the components that you integrate are secure.
That can mean that you simply check the change log.
Is this a component that is regularly maintained?
You check the vulnerability database that are out there on the internet to see if the latest version contains any vulnerabilities.
And if it's a commercial product and it is subject to the Cyber Resilience Act,
you can also check whether it carries the CE marking.
So this is how you can achieve that the product as a whole is CRA compliant.
So now to the conformity assessment, I mentioned it earlier,
and this is the first time I'm going to mention open source more explicitly.
This is where it's explicitly mentioned in the text.
For the vast majority of products, which we call the default category, manufacturers,
they will have to undergo a self-assessment.
That means that it's the manufacturer, Him or herself, that will check and ensure that the product is compliant.
But then there are some products that are explicitly listed in the annex of this regulation
that the co-legislator have considered as important or critical from a cybersecurity point of view,
and they will have to undergo a more stringent type of conformity assessment.
So first we have the category of important products, and manufacturers in this category,
they will have to apply at least a harmonized standard, the ones that I mentioned earlier,
or in some instances they will even have to submit their product to a third party to have it checked
if it's secure and compliant with the law.
So products in this category are for instance operating systems, antivirus software, or also firewalls.
Then there are also critical products.
They are also listed in the annex.
These are products such as smart cards and secure elements that we consider to be even more important.
By the way, only hardware products, no products that are softwares or nothing that is potentially open source.
And for these products we may in the future even go a step further and require a certification of the products.
Now when it comes to free and open source software, we have a special provision in the CRA that says
irrespective of whether your product is important or not, you will always be allowed to undergo a self-assessment.
So you will not have to submit any free and open source software that is in the scope of the CRA to a third party.
And the reason behind that is that when it comes to open source, it's a transparent product,
and anyone including the users or integrators, they can check for themselves whether this product is secure.
So you do not need to have a third party that vouches for the product.
Now we also try with the CRA to shift the responsibility from the developers of open source components to their integrators.
Because so far integrators have often been free riding on open source components and not giving enough back to the community
in terms of fixing vulnerabilities in these products.
So coming back to the smart phone product that I presented earlier, right?
So imagine a smart phone product that integrates an open source component.
Here is a silly open source component that prints fruit onto your... that prints fruit.
So far it was a one direction thing, right?
So the integrator would take the component and, I mean not always sometimes, of course integrators also contribute a lot back.
But in many cases they would just integrate the component into their own product and that would be it.
From now on the CRA will say, if you find a vulnerability in your component, you have to inform the developer of that component.
So that developer can also provide a fix to that vulnerability.
In addition to that, since as a manufacturer of a final product, you are responsible for the product as a whole
and in absence of a fix from the upstream manufacturer, you will also be required to provide a fix.
I mean either you fix the vulnerability in that component or you replace that component by a different component.
You just have to make sure that your product is secure.
But if you do provide a fix, then you will also have to provide that fix to the upstream manufacturer so that the upstream manufacturer can integrate it.
So this is how we want to share the burden on security between the developers of final products as well as the developers of free and open source software.
So is your open source software project covered by the CRA?
I think this is the question that you are all asking yourselves.
I said initially the commission proposal said, if you are not commercial, you are out of scope, right?
And now we fleshed this out in much more detail and we've even introduced a new type of actor.
The open source software steward which I will also present in a moment to you.
So if you are merely contributing to someone else's project, you are definitely not a manufacturer.
You're not subject to any obligations.
That was a worry that was expressed several times but here I can assure you, you can just keep contributing and you do not need to worry about CRA compliance.
Now if you are providing the project and not merely contributing to it, the question is, are you developing in the course of a commercial activity?
So if you're not, if it's really just a hobby project, again, you're not in the scope of the CRA.
Now if it is in the course of a commercial activity, the next question is, are you directly monetizing that product?
I mean, because we know that many open source projects, they do not directly monetize but they're still a wider commercial setting, right?
Many companies coming together to jointly develop a component that they will use for their own products that's a wider commercial setting.
But we only look here at the direct monetization of the project.
If you're directly monetizing it, then you are a manufacturer and then you are subject to the security by design requirements of the CRA.
If you're not directly monetizing the project but it's still taking place in this wider commercial context, this new type of actors introduce the open source software steward.
So these are essentially foundations, not-for-profit manufacturers and so forth.
Here we've invented a new very light touch regime.
So if you are a legal person that provides support to specific FOSS projects on a sustained basis and these projects they are intended for commercial activities,
then you will have to comply with the light touch regime of the CRA as regards the open source software steward.
But if you're just a collaborative project, no governance frameworks to speak of, no direct monetization, then again you're not in the scope of the CRA.
That means the vast majority of the open source projects will not be in the scope of the CRA.
So I don't know how do we still have time.
I can maybe quickly explain what the open source software steward will be.
I already gave some examples, right?
So foundations, not-for-profits, also companies that build open source for themselves for their own monetization or integration into their own projects,
but then make it available to the public, they will all be open source software stewards.
And I already said it's a light touch approach.
It's not going to be heavy, but the idea is to place some responsibilities on these types of actors,
but only responsibilities that they can also bear, giving the nature of their project and their organization.
So there are basically three types of obligations.
First, you have to put in place a cybersecurity policy.
The CRA is not very prescriptive what that cybersecurity policy should look like.
It provides some basic elements that need to be mentioned, such as supporting the community in providing information about security vulnerabilities,
describing how you will mitigate vulnerabilities and so forth.
Secondly, you will be required to cooperate with market surveillance authorities, just like any other actor in the Cyber Resilience Act.
And thirdly, you will also be required to report incidents and vulnerabilities,
but only to the extent that you are involved in the development.
So if you're not involved in the development and you know nothing about the project and the vulnerabilities,
then you will not be required to report vulnerabilities.
Okay, so this was a high level overview of the CRA.
Just maybe very briefly what are the next steps.
So we are hoping to conclude the CRA very quickly in the coming months.
The entry into force, I cannot be sure, but it will be roughly around middle of 2024, maybe a little bit later.
And then there's going to be a three years transition period.
During that three years transition period, the European standardization organizations are going to develop the standards.
We as commission are going to develop guidance.
For this, we will need you because of course the CRA is a high level legislation.
Many of the concepts, they need to be fleshed out through the guidance.
So I'm actually looking forward a lot to all your questions because these questions, they will help us determine what is relevant for the guidance.
Yes, and then in three years time from maybe June this year, so maybe in June 2027, the CRA will enter into force.
Thank you very much for your attention.
Thank you very much.
Still got to turn it on. There we go.
Thank you very much for all that.
Now Gail Blondel is one of the leaders of the Eclipse Foundation.
Eclipse has been speaking up frequently for the open source community in this legislative process.
They've had two staff working on it quite a lot of the time.
Deb Bryant and Enzo over here who you'll hear from later.
Gail, could you come and tell us how the Eclipse Foundation feels about the state of the CRA now?
Yes, thank you very much Simon and thank you Benjamin for the presentation.
Well, thank you for coming. You see that went well.
That was okay. So far.
So one first point is that I think that we have always said that we agree with the goal of the CRA.
That was on the first blog that was published by Mike on the topic.
We agree on the goal but initially that was very scary.
And I think that last year that was the conclusion of your presentation last year.
Hey, come on. What are you doing?
How can you put us on the spot like that?
Because putting C marking on all the open source project was just not an option.
One thing and that's very important is that we know that we have lots of open source developers that are volunteers.
And even when they are paid to do open source development, what they focus on is doing the features of their project.
And non-functional topics like security, etc.
I think that as a community, as an ecosystem, we know we have to take care of that because we had lots of issues in the past.
But having that coming through a regulation was something completely new to us.
And yeah, even if there is a legislative process that is kind of obscure for most of us,
I think that what's interesting is that to see that during the year,
we managed to establish some enough connections that the co-legislators listen to the open source community.
So I think that from your presentation today's obligation to push corrections, to push fixes, upstreams,
also the fact that contributing people are not responsible for, have no obligations, etc.
And also from my perspective, the introduction of a new kind of organization,
that's the first time there is a regulation talking about open source foundations or those kind of organizations as something specific.
That's very interesting aspects.
But to conclude, and maybe that's an opening for the conversation after,
is that that's just the beginning because we have mostly three years in front of us.
And in those three years, so you will write guidelines.
And hopefully we can collaborate well on writing guidelines.
But there will also be the standards.
And maybe from the point of view of the open source community,
it says that the standard organizations have not been the best friends of the open source community.
So that's how do we, I think that when you say open harmonized standards,
I guess that a few people in the room say, hmm, it's unlikely we will like such things like an harmonized standard.
So that's something we need to keep on our radar.
And the fact that the regulators are coming, that's the title of the panel,
I think that that's a good thing because that's also the fact that open source has won and is present everywhere.
So we used to be under the radar.
And now I see several faces from the European Commission in the attendance.
You are here to explain to us and we have established some connections.
So that's good things.
And yeah, the conversation continues tomorrow in the panel, in the EU policy day room.
And that's it.
Thank you.
So that's the CRA.
Now, the CRA sets the rules for the market surveillance authorities.
It says how countries are going to make sure their citizens are safe from the products that are being sold in those markets.
When it turns out those products aren't safe, Europe's Product Liability Directive gives citizens recourse to have justice brought into their lives.
And the Product Liability Directive has been in place for many years in Europe,
but it doesn't give any liability to software producers.
And so within boundaries that I will fix.
So the European Commission is going to do something about that.
Those big, bold, lettered disclaimers at the end of your software licenses do not apply in Europe anymore.
And that's because the Product Liability Directive is being updated to give software producers liability towards consumers.
And to tell us about that, we've got the legal and policy officer from DG Grow, Omar Anagi,
who was one of the primary authors of the PLD, and he's going to tell us what's in it.
So Omar, please.
Thank you Simon, and good afternoon everyone.
It's a pleasure to be here again this year.
Same as the CRA.
We are a year after, and we have now more than just a proposal.
We have a legislation that still needs to go through the adoption by the parliament.
But just as a small introduction, whatever has been said just before,
let's try to forget it for the next 12 minutes, because it is not applicable in our case here.
When we speak about the PLD, basically it applies to any type of products.
The only element that is necessary is whether they are made available on the market,
and made available on the market basically means any supply distribution of a use,
and whether it's return of payment or free of charge.
And the most important element is actually the commercial activity.
I know that everyone asks always, especially here last year, those questions,
what is a commercial activity?
Unfortunately, I cannot tell you exactly if your own product or your own software is in a commercial activity.
This is an assessment that is done by the judge itself.
There are elements, the number of supply of the product, the number of use of the product,
but this cannot be determined beforehand for the PLD, because of its own nature of safety net.
So the assessment will be done for each individual product,
even if it's let's take the more traditional product like a bottle,
and you will have to look at the specific bottle and not the series of bottles
to determine whether it is in a commercial activity or not.
And I say this is the scope, but then we arrive to the product itself.
Any product, the definition is really legalistic, so you don't need to really get that,
but basically it's everything, and we have clarified that also softwares, raw materials,
and digital manufacturing files are products on the PLD.
There is no definition of what is a software, as you probably know,
like the software 20 years ago is not the same than today.
So the idea was to leave it as open as possible to ensure future proof safety net nature of the PLD.
You asked me if SIS are covered, yes they are covered.
The PLD disregards how the product is supplied, how the product is bought,
how the product is used, how it is the model of the product, where it is stored.
All of this is totally disregarded. Any software is covered by the PLD,
algorithm, operating systems, AI systems, apps, whatever you want,
all of them are covered under the word actually software.
As Simon said, the PLD does not kick in.
I mean, you do your job, and in the PLD we're not telling you how to do your job.
The only thing that we are telling you is, nor the risk profile of your product,
because if something wrong happens, and maybe none of you will ever experience the PLD in your life,
if something wrong happens, someone has to get compensated for the damage.
The damages are pretty straightforward. It's basically death and personal injury,
including psychological health, the destruction of property,
and the last one is destruction or corruption of data.
Those are the three main categories of damages that need to be compensated.
If there is a single of one of these ones, you would then have to compensate
basically everything that is related to that.
As I said, you will not have a case if there is no damage,
and you will not have to face the PLD itself.
Except in certain situations, you might have liability even if the damage has not yet occurred.
Let's take a pacemaker. You know that the pacemaker has an issue.
You will not wait that the person dies because of it.
You will get preemptively the compensation, namely the damages of going back again for surgery and etc.
I use the pacemaker because they are part of the wider range of medical devices,
and medical devices also sometimes implies or include software.
This is a specific situation in itself.
When we talk about the liability, the question is for how long?
The main rule is ten years. This is the general rule.
Namely, if you place your product on the market, you may have it available on the market from the first day.
This is when the time starts running.
But as you know, a software might evolve, AI system for example as well.
Considering that a software that was placed 15 years ago and has been changed through a lot of updates for instances,
it will be kind of limiting to steer or only apply to ten years,
because it means that someone who bought the software ten years ago or eleven years ago
will not be able to cover the damages in case something wrong happens, although the software has been updated.
We have also included a new starting period, which is when the product is substantially modified.
I'm not going to go into detail. We're not explaining exactly what is a substantial modification.
In most of the legislation, you will find what a substantial modification is,
but roughly for software, I don't know if the CRA has a substantial modification definition,
but for instance you will have to go under the CRA to see what is a substantial modification in case of cyber vulnerabilities.
What we say is basically if you update your software and the update is as such that it changes the risk profile of your software,
it is a new product, it is a new software and the time limitation starts running from that moment again.
So each time you will change to that point or to that element of your software, you will restart the clock in that sense.
If it doesn't, then it doesn't, and then you're ten years, ten years.
The extension of the liability has also been put to 25 years in a specific situation, which are the health injuries.
That shouldn't concern you that much, but just for you to know, it's basically pharmaceutical.
That's the easiest one when you realize that you have some damages because of it, but it took more than ten years to appear.
So this is a specific situation, but software you just know.
We talk about time limitation and then we also need to talk about the exemptions.
Exemption means that even though your product caused the damage, one of the three, you might be able to be exempted from your liability.
There is a full list of exemptions, not going to go into details, but maybe two are important for you and I will explain the first one a bit later.
If you did not place your product on the market, but it was placed by someone else, or the development risk defense, what we call the state of the art,
which I think in your field is the most relevant one, and just to be clear, it's not the knowledge of the developer, it's the knowledge of the community, of the science around.
And it's not about the known unknown, it's about only the unknown unknowns.
Only in those cases, you will be able to be exempted from your liability.
So just to take an example for you and maybe to make it as clear as possible, the PRD does not apply for any product when they are supplied outside of a commercial activity.
This is the same for free and open source software.
If your free and open source software is developed or supplied outside of a commercial activity, but someone decides to integrate it into another product, and therefore the product is then sold to a person and causes harm,
the liability is pretty clear.
The person will only be able to go against the integrator of the software, but not against the developer of the free and open source software that has been supplied outside of a commercial activity.
That's a bit of clarity that is now in the text, which was not there before, but just for you to really understand how it will work.
And the very last point is about, I know that you have clauses in your license.
The PRD is pretty simple. No matter your clause, you cannot use it against a person, a natural person that is claiming compensation.
So there is no leeway for avoiding liability.
If it's a natural person, so me, you, anyone else comes against you, has a damage, asks for compensation, brings you to court,
you cannot say that you had a clause in your license that said that you will not be held liable.
That will not be accepted by a court.
That's a general principle that works for everyone, and for any type of product, is to avoid that the weakest party, namely the consumer, suffers from an imposed contract.
But what we have clarified in the legislation is basically, if you, a small company, very small company, decide that, okay, you sell your software to another company to integrate it,
but you do not want to take over the liability.
If this is your case, you can then have a clause in your license or in your contract.
And in that case, the manufacturer of the overall product, the integrator of the software, will not be able to come against you in case he has compensated the natural person.
What happens usually is the natural person goes against the name manufacturer of the product, and then it is that manufacturer of the overall product that will go against the other component manufacturer
for getting part of the compensation.
This would then not be possible if you have such a clause.
So that's a bit of the small panorama of the PRD.
So I leave you on that, and I hope you enjoy it. Thank you.
Thank you very much.
Perfect. I'll come get it from you now.
And to respond for the defence, we have Dirk Willem van Gulak from the Apache Software Foundation.
Thanks, Simon. So, yeah, so basically these were, so I think so like in many ways, what's happening here is that software is becoming, yeah, very grown up,
and just sort of like a, I don't know, a phone charger or an electric drill, where sort of like being put under the same rules.
Now, I think the positive news is here that in this process, the open source site, the development site, and also like the micro enterprises are largely sort of like out of scope.
However, what I want to stress, and also want to stress about the CRA, is that it is a massive change for our industry.
Even we as open source developers, we're not alone. We're actually part of that IT industry, and the PLD and the CRA will probably sort of like,
or will absolutely affect our industries way more than they do open source, because the industry has to come to the table.
The industry is basically squarely in the view of the CRA and squarely in the view of the PLD.
So I think one thing sort of like, we can sort of like, yeah, be positive about and celebrate about is that all the worries we had last year around the CRA
and especially about the PLD didn't really come to fruit. I mean, things are now sort of like, we've got a fair balance, I think.
But at the same time, as an IT community, we've got sort of like some massive challenges sort of like they're left.
And I think sort of like some of the questions of you may well be in that area. Thanks.
Thank you.
Okay.
And so we're going to move to an audience Q&A. If you've got a question that you would like to ask the panel, or particularly the guys from the commission,
then if you would like to raise a hand, there's a hand raised down here, and Omar is going to moderate for us.
I'm Enzo, not Omar.
Sorry, Enzo is going to moderate. My brain is gone.
Yeah, go ahead. Go ahead. Please, yeah.
Yeah. So we're glad that a lot of the concerns of the open source community were heard.
We can't hear you.
Yeah, okay. So we're glad that a lot of the concerns of the open source community were heard.
But for Linux distributions, like for example, Debian, we will be exempt because we don't do anything commercially.
But we are worried about our downstream users, which of course use Debian commercially.
So for example, a lot of very small and very small local IT providers sell computers with Debian, for example, or do other business using Debian
and integrating it into their products.
And we are worried about how they will be able to comply with the CRA obligations because they are so small that they can't do it themselves.
So it would be really hard for them.
And also the margins in the computer industry are not that big that they can just say, okay, I'm going to employ somebody who's doing that.
That's not possible for most of them.
So that's what we want to have guidance for.
And also it's really difficult for them to understand all these regulations and what this means in practice concrete for somebody who's, for example, just selling computers with Debian.
Thank you very much. I think it's a very good question.
I guess Benjamin, it's pretty obvious that this question is for you if you want to answer real quick.
Yeah, thanks. It's a great question, I think.
So indeed, if you are selling a laptop, for instance, with an operating system installed, if you're building that laptop, if you're the manufacturer of that laptop with the operating system, you will be in the scope of the CRA.
And the due diligence requirements as regards the integration of the operating system, they will also apply to you.
I mean, I explained before what due diligence means, right?
So there are a lot of ways in which you can do due diligence.
The CRA is on purpose not very prescriptive because we want to give a lot of flexibility to the integrators.
But one thing is for sure, it doesn't mean that you can only integrate CE mark products.
You can integrate any open source component that you like.
And there is a myriad of ways in which you can demonstrate that the components that you integrate are secure.
I think in a case like this one where the upstream provider, so the Debian project, is such a massive undertaking, I think it would be extremely helpful for your integrators if you provide them with useful documentation on how Debian as a software,
how Debian addresses the various security requirements of the CRA.
I mean, just because the CRA doesn't apply to you, doesn't mean that you shouldn't take security seriously and I'm sure you do, right?
So I'm sure many of the things that the CRA requires, such as the access control and so forth, I mean, obviously modern operating systems like Debian do that.
So if you document in a transparent manner how you are actually complying with security by design principles, I mean, you're essentially doing the work for your integrators and then they can just recycle that work for their own documentation.
So their documentation doesn't need to be heavy anymore.
Thank you very much, Benjamin.
Is there another question here over there? Thank you.
Yeah, this is a question for the Eclipse Apache foundations.
Aren't you afraid that you have kind of doomed the software foundations in shielding the developers?
Because when I look at this, the first thing that jumped out of me was, okay, I have to make sure that I'm not going to be a software steward.
So if somebody wants to pay me for work, then the best thing I can do is dump the project into one of the foundations and make myself just a contributor.
Thank you very much.
Dirk, maybe first or Gail?
Right, so I think the question is really like what do I do as a small developer, right?
And this forced me to dump my projects in one of the foundations.
And I think it's useful perhaps to turn this around.
I mean, what is happening here is that society is asking the software developers to start producing good secure software to basically use industry best practices.
Now in open source, we by and large do that. In fact, we pretty much set every industry best practice around security.
And it's our downstream people in the commercial markets who are often not updating.
I mean, we update log4j within 24 hours and then like now years later, it's still not being done universally.
So I think to a large extent the answer to that question is that as developers basically, we'll have to sort of like get more systematic and more explicit about documenting the good things we're doing.
And I fully expect sort of like that a year from now, two years from now, we basically all more or less have documented that in the same way.
Because I mean, at Apache we've documented some of the things at Eclipse, at Python, we basically all doing the same thing.
So yes, of course, we're going to steal each other's documents, right? It's open source. I mean, that's just the easiest way of doing it.
And then indeed, basically, you sort of like get that foundation like style, all those things which are part of an open source steward like being sustained in the market, being responsible about these things.
Yeah, simply then becomes much wider available.
Thank you, Dirk.
Yeah, just maybe to add something like I hear your point that, OK, if there is some constraint due to the fact that there is an open source steward, I absolutely want to avoid being in this situation or I want to make.
I don't think that people or organizations bring their projects to a foundation just to avoid the theory or to do something like that.
And that's the main point is more likely to set up collaborations or to have a vendor neutral governance or stuff like that.
I think that's our main point in my opinion is that we help create consortia, but the open source steward is a good way to implement the requirements of the CRA in the context where.