Hi, so my name is Toby Langelle.
I run a small consulting firm based in Geneva, Switzerland.
And I have kind of straddled throughout my career open source and standards.
So people thought it was a good idea to bring me in to talk about this.
So this lightning talk is called 40 New Ways to CRI Can Accidentally Harm Open Source.
And that of course references the 40 plus standards that are, the harmonized standards
that are going to be written in the next couple of years to essentially make it possible to
implement the CRI.
So the first thing I want to say is the CRI has landed.
It could have been really, really bad.
A lot of us were really, really concerned.
And it turns out that it isn't.
Firstly, first thing is the open source community rose to the occasion.
And I think that's really amazing and it was beautiful to see.
And like a lot of people put a lot of work in.
And I think we should all be very thankful for the work they have put into helping us.
And then also policy makers actually paid attention, listened, and considered the input
from the community.
And also for this, I think we ought to be really thankful.
So thank you for both sides for making this happen.
In the process, we avoided harming open source pretty seriously.
And we also avoided harming that EU's ability to leverage open source, which was another
one of the potential risks of the original versions of the CRI.
So we do now have a lot more clarity.
There's an asterisk there because lots of people still have lots of questions, myself
included.
My key takeaways from the last version of the CRI is that the responsibility falls
in the right place.
IE was the people monetizing open source.
The company is monetizing open source.
So for me, this is really important and it's great that this has spelt out really clearly
in the last version.
And then the other thing that I thought was really interesting is the open source stewards,
this new notion of open source stewards, which really institutionalizes the foundations
that have been playing an important role in our space.
And it's also, I believe, a really smart instrument for the EU's ambition around Southern Tech.
That said, it's going to have industry and ecosystem-wide impact.
I think companies will be a lot more cautious.
I will certainly advise my clients to be more cautious.
And a lot of projects will move to foundations and I think they will do so earlier.
And then the conformance requirements, they're going to climb up the dependency tree.
And so essentially, I'm suspecting pretty quickly most of the ecosystem will actually
be subject to some parts of the CRA, probably the lighter version that is for open source
stewards.
And I do have a question that was this.
This is going to create a lot of financial and work overhead.
And I'm still kind of wondering who's going to be paying for this.
So I think this is a question that will need to be dug into a little more in the future.
So to meet the CRA, there are essentially going to be two options.
Either you demonstrate conformity by yourself, so the burden of proof is on you, or you will
essentially follow a set of standards, the harmonized standards, and this is going to
provide presumption of conformity.
So the fact, though, the standards are going to be how the CRA impacts open source because
that's what everyone's going to do.
Essentially follow the standards so that they can be presumed to be conformant.
And so 40 plus standards, that's 40 plus way things can go wrong.
If you believe that the standardization process is less opaque, easier, more open source community
friendly than policymaking, I have bad news for you.
And so essentially the same kind of misunderstanding, the same kind of risk that CASC carry through
the CRA is probably going to carry through 40 different standards.
Actually sitting in 40 different rooms to make sure that 40 different standards don't
harm open source in a weird and unexpected way is a lot of work.
So I mentioned the opaque standardization processes.
Also open source has special requirements.
Things have to happen in the open.
They cannot be patterns around the standards.
And not every organization functions in an open source friendly way to put it mightily
when it comes to how they deliver the standards and how non-uncumbered by patterns these standards
are.
So that's also something that will be incredibly important to make sure that the open source
community can actually have access to those standards and be able to implement them.
The two last points is there's a huge diversity of open source stakeholders, a lot of which
were very poorly represented in the CRA even though the open source community was there.
So there were these two words obviously and they were very much involved.
Hobbyists, it's very hard to actually represent hobbyists, right?
Small commercial open source startups that are going to be incredibly impacted, including
in the EU because they will be considered manufacturers, rightfully so.
Probably don't have the resources or the know-how to be involved in the process.
And the last point is interop was other jurisdictions.
One of the huge strengths of open source is the fact that licensing is essentially standardized
worldwide and like the MIT means the same thing here and there roughly sufficiently
that it's like okay.
And if we start having security standards that are different across different jurisdictions
it's going to be a huge burden on open source maintainers and open source developers and
we want to make sure that if you comply to whatever the EU comes up with in terms of
standards it's fairly similar to what NIST is coming up in the US, etc. etc.
And that's it.
Thank you very much.