Okay, so welcome back to this session on the CRA and PLD block.
We are having a panel with some of the people that directly wrote the pieces of legislation
we're discussing in this block.
To my left we have Benjamin Bergle, who is working for the European Commission as Head
of Sector for Standardization and Product Security.
I almost did it right.
Next to him is Chuck Dinghou, who is Director for the Python Software Foundation and we
really wanted to get a community perspective on this panel, which is what Chuck will provide
and also what Chuck will challenge you to help us provide, because that's kind of what
we are trying to do here.
And finally we have Omar Enaji, who is Policy Officer for DGGROW, who has worked on the
Product Liability Directive for multiple years now.
My name is Martin and I will try to ask some questions.
You will be asking the really clever ones.
I will be asking the other ones.
So let's get started.
I would like to ask our panelists to do a real quick introduction specifically to answer
the question, what does implementation of these laws mean to you?
Because we've been over the proposals, we've had the negotiations, they're about to be
confirmed by Parliament.
So what this panel is about really is about looking forward.
We're not doing the negotiations over.
We're now looking at when will these actually hit Europe and what's needed to get there.
Thanks a lot, Martin.
So for the Cyber Resilience Act, I mean the text isn't final yet, right?
So we don't know exactly when it will enter into force.
As I said yesterday, sometime around the middle of 2024, maybe a little bit later.
And then we have a three years transition period.
So manufacturers, hardware and software manufacturers, they will have to start applying the rules
roughly around June 2027.
So that gives us three years during which we can prepare for the implementation.
We just had this fascinating presentation on the 40 standards, right?
So that's going to be a huge part of our work, helping the European standardization organizations
with the standards.
We will also have to produce guidance, of course.
And thank you actually very much for inviting us here because I think these are the venues
where you get all the tricky questions that need to be answered in the guidance, right?
Because of course the CRA is a high level piece of legislation.
It will not provide an immediate answer to every edge case that you may have.
So I think this is where the guidance really comes in.
And we want to be inclusive in this process.
We want the community there, open source, single vendors, everyone.
And we're really looking forward actually to this process.
Thank you Martin as well.
So for the PLD, a bit different from the CRA because it's a directive and not a regulation.
So it requires transposition at a new level in each member states.
Actually the law will be applicable in each member state.
So this year will be 2026 in theory around June, July.
It will depend exactly when the parliament will give the vote.
And by then the liability rules will be kicking in.
So yeah, that's roughly it.
Would you mind spending a couple of cents more on the difference between a regulation
and a directive because we appreciate that a lot of you may know a lot about software
and we also think some of you may not know a lot about you lawmaking.
So can you?
Yeah, so I mean just a quick legalistic view says at you level you have three types of
acts.
You have three types of acts.
A regulation, a directive and a decision.
A regulation and a decision basically only requires to be directly applicable at national
level.
But the law remains the same.
For a directive it requires transposition and the transposition is basically incorporation
into the national law.
You will have 27 different laws that would say the same basically.
But because of the particularity of the directive it would also require changes in some other
parts of the national legislation.
A directive also requires implementation along with the incorporation.
The regulation only requires the implementation of it.
And it's directly applicable as a regulation into the national laws while the directive
needs to be incorporated to be applicable.
So you will have the central piece of legislation but for the rest you will have national laws
that will tell you or give you the answer.
And the role of the commission during the transposition, the two years transposition,
that's why there is a deadline for that.
It's to check each legislation to ensure that there is no mistakes that doesn't go against
what the main legislation says.
So that's the big picture.
So my next question is about your personal experience trying to express false into law
or maybe to interact in the EU policy space whereas you may have previously focused on
the developer space.
So a different question for each of you.
So for you, what was it like to work on a policy topic as someone who is very knowledgeable
about software development?
For each of you, what was it like to work on a topic with the nuances that open source
has in your policy?
So first of all, again, my background is very similar to a lot of developers.
I'm closer to a software developer than a policymaker.
So for us, I think we have a lot of concern about whether I will be reliable.
I mean, maybe I've created some fun stuff.
I publish it as open source because I want to share it but then you have no control of
who is taking it and doing what about it.
For example, the car example maybe at the beginning when I created this project, I'm
not expecting someone to use it in a car and then the car will hit someone.
So that is something that I think a lot of developers have that in their mind.
There's a bit worry that now if this happens, will we be not publishing anything anymore
so that will affect the open source ecosystem a little bit more?
And also, for example, if you're working for companies or maybe then your company would
tell you to not do it because the company don't want to get involved in your hobby
project that may get into trouble.
So there is a lot of concern, I think, as someone who, you know, and also, because
software is very different from hardware, right?
You can't make something at your backyard and then come and in fact you can take it in
production.
But software, you know, the power of software is like, you know, some individual developers,
they can still develop a piece of software that is, you know, very applicable in a lot
of application but is maintained with very limited resources.
I think that that make hardware and software a huge difference in terms of scales.
You know, you don't have enough, you know, resources, you can't massively produce something
in hardware but if you have limited resources, you can still massively produce some things
in software that like a lot of people use, right?
So that's the concern from a developer perspective.
Yeah.
So.
Thanks.
Yeah, I mean, for us, I think it was a huge challenge to adopt the existing European framework
for product legislation, the new legislative framework, as you call it, or the CE marking
that you're familiar with, to software and to cybersecurity, right?
Because, I mean, software is not a tangible good.
It's different and cybersecurity is also very special.
It's not the same as safety.
Usually we've always regulated safety.
Now, for the first time, we are regulating security and I found that to be a huge challenge.
I think we managed to get it right but it was a challenge.
What I really liked about engaging with the open source community is that you meet a lot
of passionate people who really care, right?
So when we regulate other areas, you get to meet lobbyists who are simply paid to defend
interests.
Of course, you're also defending your interests.
But on top of that, I mean, you meet people that actually really care about the things
that they work on and you see it's more than just a job, it's a mission for them.
And I really appreciate that.
Well, I mean, for me, it's a bit different because let's say that the product I really
like to direct is about any type of product.
So what I had, it's basic.
I think it's the CO2.
Do you see maybe it's a defective product.
But the idea is basically how to deal with perfume industry, with car industry, with
tables, with chairs, with vaccines, with pacemakers, with hats, with whatever you want, all of
those industries.
With the PRD, we didn't have a specific sector.
We had all of them at the same time.
And what we actually needed is basically to have people that could represent each of those
sector to hear the concerns and what could work and what could not work.
And I have to say that with the open source software community, it was maybe a bit harder
to achieve that because of the fact that you are all individuals, there is not really
someone that represents you.
You need to speak a little bit harder because this is not a mic.
It's only for the recording.
So what was really complicated for the open source software community for me is basically
I could not have a single voice that could tell me what were the full concerns, had different
voices.
But to be totally honest, the one that we're more talking about, your issues, let's say
the bigger one, which I pretty sure do not represent you.
And so that was the main difficulties for us from the PRD perspective, was to get what
are the real concerns and how do we reply to them.
But at the same time, we also had to be totally honest.
The PRD is a piece of legislation made for victims, which is basically all of you, all
of us.
So we needed to find the right balance, not to put too much pressure on the one that creates
the product, but also not too much pressure on the person that actually suffered the damage.
And that was what we needed to achieve.
And where we need to find the good balances when we have your inputs, this is where we
can actually find the perfect balance in a way.
So I will be asking, giving the crowd a opportunity to ask questions.
So if you have one, raise it before I'll get to you.
I'll ask two questions to Benjamin so I can have a look around.
So my first question, Benjamin, and it's about stewards, is how can a steward know they're
a steward?
And my second question is, suppose they find out they're a steward, but they're not in
the EU, who is the supervisory authority they are supposed to be talking to?
Okay, so I mean, you find out if you're a steward by looking into the law, the law defines
the concept of steward, right?
It says you have your, if you're someone that's, I mean, if you're a legal person that supports
a project on a sustained basis, and this project is ultimately intended for commercial
purposes, you are a steward.
The regulation also gives a few examples, such as foundations, I mean, not every foundation
will be a steward, but if it meets those criteria, it's a steward.
And so you can look it up in the law.
As I said before, there will be cases where it's maybe not as clear cut, right?
We hope that with the guidance, we can also address those cases.
So I'm quite confident that the end of the implementation process, people will usually
know if they're stewards or not.
Now, if you're outside the EU, so the CRA is indeed a regulation, yeah?
It means it applies across the entire single market in a uniform manner, and all the market
surveillance authorities are responsible for you, essentially, yeah?
If your product is, or if your software is published and accessible across the entire
internal market, then all the market surveillance authorities will also be responsible for supervising
you.
So I will be walking into the crowd to get a question.
I will be off camera, which is fine.
So please state your name and affiliation and a question if you have it.
I'll hold the mic.
Okay.
My question is about a Debian, which there is a Debian foundation in France, and there
is software in the public interest, but these foundations only handle financial issues.
They have nothing to do with code in any way or form.
Are they going to be considered stewards?
Yeah.
So unfortunately, I cannot give legal advice on individual projects, right?
Because if I get it wrong now, then it's a huge problem.
So you will have to check for yourselves.
I mean, what I can tell you is, I mean, we put some indications into the law when you
could be considered a steward.
So for instance, when you are hosting the collaboration platform, if you are to some
extent governing the project, if you take decisions on the project, or if you do steer
the development process, then you would be considered a steward.
Taking another audience question.
So please state your name and affiliation and then the question.
I'll hold the mic.
Thierry Carreze, Open Infra Foundation and the open source initiative.
You mentioned the chilling effects on development and engagement from the open source community.
And I think it's the main fear we have is that whatever legislation is created, it would
prevent or discourage people from participating in the open source commons.
And I think it's linked to any uncertainty will be interpreted in a worse way.
So how are we going to, with 40 standards on the CRS side and transposition in every
country, 27 countries on the PLD side, how are we going to have enough certainty for
those people to, for them not to have this chilling effect on their participation?
Thank you.
I'm going to Omar first.
Well, I think you can send an email to one of us.
That's basically the first.
I mean, we are open to have any discussion with anyone that has an issue on the ground
because we are not on the ground.
So this is how it works for every unit in the commission is basically everyone has legislation
or has a policy and we receive feedbacks from people.
Someone, for example, for transposition would say, well, I'm in Spain and this is how the
law applies in Spain.
And I'm pretty sure that that was not the main idea because when I looked into the main
piece of legislation, it says something opposite.
Well then it's the work of the commission to realize, well, that something goes wrong
there and then we enter into contact with the national authorities.
That's for the transposition part.
But if there is like, there are issues during the years of applications of the directive,
then we have what we call a review clause in each piece of legislation.
Every three years or five years, you will have someone from the commission, usually
one of us that will do the review with the study, having interviews, taking all the evidences
and proof and you will collect all of them and then realize, OK, there is an issue that
was not foreseen at the beginning.
How do we solve it?
There was a gap.
How do we, how do we feel it?
That was actually the main, the same thing that happened with the PRD, the PRD that dates
back from 85.
It took 40 years to review it.
Before that, we started the collection of the reviews of the proof and we collected all
the opinions and this is where I say that maybe your community was the one that was not
really involved into that because of how the process is, but everyone has a voice in the
seat there.
Sorry, I want to ask a follow-up question.
So I know that like sometimes the White House will have some open call for like suggestions
and comments.
Will you plan to do something like that?
Well, first of all, we need to apply it, but that is for sure that for the next review,
which will happen.
So it's two years, four years, it will be in six years.
In six years, we will take us, do a state of play of how it's applied and then obviously
we'll have to collect a bit of information and we will have to check with people of the
industry, the communities to see what is their experience and if there are things that
work or don't work.
So that's how we will have to do it.
But I cannot tell you right now, but it will be one, but I'm sure that it will be one because
it's how it works for these kind of things.
Yes, so I would like to fork Omar's answer.
I would like to add that, I mean, I don't think there will be a chilling effect on open
source coming from the CRA, to be honest.
I mean, let's be frank, open source is essentially outside the scope.
I mean, of course, there will be cases where manufacturers will, of course, try to place
requirements upstream, right, and talk to upstream developers, but I mean, you are for
the most part not covered by the Sub-Brazilian Act.
If you want to make sure that the transition goes smoothly indeed, I mean, please do reach
out to us.
I think we've proven over the last year that we are a very approachable bunch here.
We are taking your concern seriously.
We are going to do our utmost to find solutions, but we are even legally obliged in the CRA.
There is a specific provision that requires the commission to consult the community.
I mean, we would do so anyway, but you even have that reassurance that we have to do it.
And yes, I mean, just please do reach out.
Just one thing for the chilling effect, because for the PRD we have experience with that.
Forty years ago, I could show you the newspapers that was going all around Europe from manufacturers
saying that if this piece of legislation would enter, there would be no products anymore
in Europe.
I'm pretty sure that this is not the case anymore.
What the PRD did is basically give trust into people.
When they buy something, they know that if something goes wrong, at least they will have
the back cover.
That is the idea of the entire piece of legislation.
One practical comment I would like to make with respect to the question that was just
asked is that after the panel, we'll have a workshop.
And one of the mechanics is that we want to ask you about your fears, but also hopes and
perhaps your solutions.
So if you're listening to this and think, hey, but I have these corner cases that I'm
really worried about, make sure to remember for like 20 minutes more and then put them
to paper because we're actually trying to collect these.
I saw multiple hands.
I'm first going to ask a question myself and then I'll return to the audience questions.
So it's related to the PLD.
In December, a political deal was reached on the PLD and one of the things that was
publicized by the MEPs looking out for open source specifically was that open source would
not be in scope if it was not a commercial activity.
And it was a delegation to the technical level to implement this idea along the principles
of the CRA.
Now when the text of the PLD became public in end of January, what we saw was that there
was a single or maybe one and a half PLD recital and the CRA has seven, eight maybe.
So I'm asking is the PLD team that much better at writing recitals?
Can we somehow use the nuance that was expressed in CRA in the PLD or are you going to offer
guidance?
Because I was a bit surprised.
I was expecting more nuance but maybe I'm wrong and you're the expert.
So maybe a bit of a tough question for you Omar and I'd like to hear from you.
So I mean I will ask you a very short question.
How many products do exist in the world?
Because what you as a community got is basically one full recital over 47 while the PLD applied
to millions of products.
So I think in proportions you got quite a lot actually.
The difficulties for the PLD is basically to say that yes there is a CRA that gives an
explanation about open source software but you will also have the AI act for that.
You will also have all the type of legislation that will get the open source point and we
have to cover all of them at the same time.
We cannot copy paste from one single legislation because we apply to all of them at the same
time.
So the difficulties was really to find the right wording.
I think as you said the MEP that quoted said that the main idea is that is the commercial
activity.
While this is applicable for any product, any product that's actually been developed
or supplied outside, mostly supplied outside of a commercial activity, it's out of the
liability regime.
And that's what we written in the recital.
It's basically restating the fact that if it's outside of a commercial activity then
you're out.
But if you're in, that's where the PLD applies.
We cannot create a specific regime of open source in the PLD itself also because of the
nature of the legislation that has to be neutral and you cannot have just very specific provisions
about one single product because each provision has to apply in the same way to any other
type of product.
That's a bit of the, and the CRI would apply for cyber vulnerabilities but then you will
have the AI act that would apply also for open source.
And for us we need to cover all of them so that's why it's in this way.
So I have a question that relates to work that will be a little bit out of your hands.
So for you Omar, it's about the 27 member states that somehow need to get the work
you did and then make their own and somehow understand the nuance of what open source
is about.
For you it will be about Toby Stark on 40 standards.
What will you be doing for Chuck and me and all the other people writing software to apply
what you learned in the past 12 months or maybe you already were to help the people
doing that work not make, like understand the nuance of what is essentially a niche of
a niche but also rules the world of products with digital elements.
So what will the commission do to help the community in these stages of the process?
Okay.
Yeah, I mean, so the commission is not writing the standards, right?
I mean, that is how it works.
I think you also would not want us to write the standards.
So that's probably a good thing that we are not writing them.
It's the European standardization organizations.
They are made up of national delegations from the national standards bodies.
These standards bodies, they often send representatives from manufacturers and from others.
We have like, the commission has basically three ways of being involved in that process.
First, we are the ones drafting the standardization request, which is the basis on which the ESOs,
the European standardization organizations are going to work on those standards.
So in the standardization request, we can already express our expectations,
what the standards should look like.
Then, although while we are not going to be writing the standards,
we are going to be there all the way, right?
So we will be in all the meetings.
We will listen to the conversations.
We will give our views.
We will answer questions on how things are to be interpreted in the CRA and so forth.
And in the end of the day, we also have to rubber stand the standards.
They have to be cited in the official journal of the European Union that gives them this power to give presumption of conformity.
So what I can reassure you is that we are going to be there all the way.
We are going to look at the process very closely.
We are also more than happy to engage with those parts of the open source community that do have expertise in standards, right?
To find solutions to the issues that you may have.
So again, I mean, I already said it a couple of times, please do reach out and let's discuss that in more detail.
Thank you.
Well, I mean, my work is not done yet.
As I said, the transposition will kick in as soon as the co-legislator have officially voted,
which should happen either in June, July or September in any event.
And then after that, we launch the transposition period,
which means basically that we will be receiving the 27 piece of legislation piece by piece,
or sometimes just the entirety of it.
And we will have to work closely with each single member state to ensure that the legislation reflects exactly the directive.
What we have as a tool in the commission is what we call the infringement procedure.
So when the commission realizes that a member state does not conform itself with a new legislation,
we can bring the case to the court to ensure that the member state applies it or does it properly.
I'm not, I mean, as a small background, the first PRD took for some member state more than 20 years to properly transpose the directive.
So I hope we're not going to be there, but this is how it works from our side.
And then once it's transposed in any event, we will have to check constantly if there is a good application,
because one of the things is it's not only the transposition by the member state,
but also how the jurisdictions will be applying the law.
A national court is also a representation of the member state at your level.
So if there is a misapplication at that level, we would also have to intervene to ensure that it is done in conformity.
Thank you very much. I will take two audience questions, one here and one there.
And then we will continue with the panel if there's time.
I will be holding the mic. Please state your name and affiliation.
Alistair Woodman representing 2501C3's outdoing open source projects.
As far as the PLD is concerned, do you anticipate that the market will support insurance policies for this to deal with the sort of quenching thing?
Or is it a non-goal or a goal to encourage insurance in this particular regard for non-mulse-feasant behavior?
I think that was for you Omar.
So the PLD does not have any requirement about insurances.
So everyone is free to do whatever they want.
Basically, it's just you need to calculate your own risk.
And once you know your risk exposure, you will know whether you need one or not.
But it's not from outside that we do it.
And to be also totally frank with you, as I said also yesterday,
most of you here will never have a claim on PLD.
I mean, this does not happen every single day for each type of product.
We have a few cases that can happen.
You can have access to all of them.
It's true that for software it's a bit more rare that this happens
because you have something that the traditional products don't.
You can correct the piece of software before something wrong would happen.
You know that there is a vulnerability.
You know that there is maybe something defective inside.
And then you will correct it with an update and then you avoid having any issue.
That's a bit more of a facility for you.
And we will not impose from our end-in-end insurance for that.
That's a bit of the approach.
Audience question. Please state your name and affiliation.
Hi. Olli Johansson.
I'm an open source developer also active in OpenSSF and OVASP.
The problem with those 40 organizations that create standards for us open source developers
is that ECMA, Sennilec, all of them require quite huge fees.
Who will pay them so we can take part in the standardization effort?
I think this will be for Benjamin.
Yes, I don't think I have necessarily a satisfactory answer for you, right?
Yeah.
So I will take note of your financial needs.
But indeed, I mean the CRA is just one of many pieces of legislation.
So we do not shape the standardization policy.
We just use the standardization process for the CRA.
But indeed, I mean this is an important question and we are more than happy to look into that.
Thank you.
So we're slowly nearing the end of this panel.
I'm going to ask a number of questions in succession and then we'll see if there's more time for audience questions.
So to Omar, I'll ask, do you know about any other related legislation that is coming for this community
that we should be waking up about?
So take a moment to think about it.
I'll get to you for the answer.
So for Benjamin, I would like to talk to you about the guidelines.
Can you be very specific about how people can contribute to the process of writing them?
And there is this delegated act possibility about voluntary security at the station programs.
Can you talk about what your intentions are, maybe how people can help?
So my goal is with these three questions to the two of you, is to give people in the room a clear view of what they can do.
Should they have the time, the money, etc. to be involved in EU policymaking?
So now I'll hand over to Omar.
Well, I have no idea.
I have to be totally honest with you.
We are many, many directorates.
But it's as simple and it doesn't really require any money.
It's just two times time to check what the commission is doing.
The various directorate channels, I mean, mostly did connect, but it can also be did you grow?
Could be just wherever the directorate is.
And then if you have a question, you are wondering something, you are...
I mean, don't say that to my other colleagues, but you can send an email to the units.
And this doesn't cost any money.
They will happily reply to you and give you any answer that you're seeking.
There are stuff that you don't understand from legislation.
There are information that you would want to bring to the attention to the commission itself.
Our emails are open for that.
And this is also our role to have a look into what happens on the ground.
I mean, as I already said, we are legally obliged to consult.
But we would do it anyway, of course.
As the commission, I mean, we are very likely going to organize conferences where people can attend and bring their ideas to the table.
We are likely going to have some form of expert group or a similar body where people that want to, like, be more involved than just ad hoc,
but in a more structured manner where they can engage with us.
And, of course, you will be seeing us at conferences.
You can invite us to your events.
We're happy to attend, maybe not always physically, but online.
So there will be plenty of opportunities to engage.
As regards the voluntary security attestation programs,
so, yeah, I mean, the idea is basically to give those projects that are not directly in the scope of the CRA a chance to provide some form of assurance that the projects are secure, right?
We know that many of these projects, they don't have financial resources.
So the provision is quite open in that regard.
It does not require the ones that develop a project to also pay for that program, but other people can step in.
So, for instance, integrators that take an active interest in a certain component because they need it for their own due diligence, they need the assurance that it's secure.
They could also team up and pay for that assurance.
Now, these attestation programs, there is only a so-called empowerment in the law.
That means that the commission is empowered.
We are allowed to flesh them out.
So they are not there yet.
We don't have these assurance programs at this point in time.
But the commission will be able to work on this.
And for this, we will also need your input so that we can shape these programs in a way that they are useful for the integrators or users to have the assurance that they need.
But they also take into account all these specificities of open source projects because they are often so different, right?
The way they are structured and the promises or commitments that they can make compared to more traditional, manufacturer-based projects.
So I think we'll take one more audience question and then I'll ask Chuck if she wants to do any reflection on what this means for Python maybe.
Let's see. I think there was a hand pretty early on.
So name and affiliation, please.
Hi, Vittorio Bertola from Open Exchange, which is a 300-people German open source software maker.
So the question is, well, first, this is creating cost, of course, not for security because we have a flow of security record.
We already spend all the money that's necessary on security.
But for the bureaucracy that now you are introducing for compliance.
So this is making us less competitive and all our competitors are from outside Europe, including Google.
So how is this going to be compensated?
And maybe ours, we are a pretty big company.
We can cope for it.
But the French Foundation for Debian that has to hire a lawyer, there are going to be costs.
Are you going to put some money onto this, maybe to fund developers to cope with security issues or to fund the bureaucracy?
And also, how are you going to avoid the international players from gaming the system?
I mean, it's way too easy. I see this happen for like the Googles and Apple.
They create some initiative, which is a non-profit.
They put the code into that.
It gets outside of the CRA scope or maybe gets the like system, whatever.
And then they don't have to support the cost of compliance.
Well, we still compete with the same piece of software and we have to pay the full cost of compliance.
So do you have any thoughts on this?
Do you want to check to go first or answer the question first?
Yeah.
Yeah, I mean, it's true, of course, that there will be some bureaucracy.
I mean, no law has ever been created that doesn't create some bureaucracy.
Okay, maybe the PLD doesn't because it only hits you once something happens and not before.
But usually, of course, there is a certain compliance cost that's quite unavoidable.
I think the competition concerns there may be a bit overstated because the CRA does not only apply to European companies or manufacturers or open source projects,
but it applies to anyone who is bringing, publishing or putting on the market those products in Europe, right?
And we all know that Europe is a big continent.
It's quite relevant.
There are probably very few manufacturers in the world that do not place products on the European market.
So they will all be subject to the rules.
We do have some field facilitations actually for small manufacturers when we talk about actual manufacturers.
So there is a provision that again, it's an empowerment for the commission.
It allows us to create a form for a simplified technical documentation for small companies.
So that means that small companies, they will only have to fill out one form essentially and the length of the form is somehow going to inform the expectations towards how much information you're going to provide.
So I think that can help a lot like one single form makes your life much easier.
And then we also have some funding calls.
Actually there are funding calls ongoing right now until the end of March that also aim at helping small companies deal with the implementation of the CRA.
Thank you Benjamin.
So I think we are at time.
I would like to thank our panelists for the courage to come here to talk to us, to have this conversation.
They're not leaving yet, but I will ask you for a round of applause before we continue.