All right, cool. Hi, again, for those of you that are earlier. So my name is Toby
Langeon. I run a small consulting firm where I focus on open source standards. And so
while today, I'm going to talk to you about open source compatible standards or open
source compatible standardization. This is a very much sort of like mashed up longer
talk. The slides are the longer slides are available online if you want the whole thing.
So I'm going to give you a tiny bit of context. Talk about the interplay between standards
and legislation. Talk about open stand, which is a related successful earlier attempt
at creating something that is open source compatible close enough. And define a bit more
precisely what I mean by open source compatible standards and sort of offer a way to move
forward. So context, there is a rush towards standardization of open source security best
practices. Thanks to cyber resilience act. And there is a bit of a friction because
the organizations who are responsible for the standardization of this legislation and the
related legislation are essentially publishers. Like their business model is selling
standards. And this is a gross approximation, but it's good enough to have this conversation.
And if the standards need to be sold, then it's usually hard to make them freely available.
And so of course that is hardly compatible with the way that open source is developed
and maintained. And so we have a problem not only for creating those standards in the first
place, but also for then consuming them. And this is not a new problem, but now
like there's a forcing function to try and address this. So there's been a really long
history of interplay between standardization and legislation. Originally it was driven
in the industrial age by safety concerns. When you had dangerous machines that were built
like trains and things like this. So that was kind of like a forcing function for this
interplay, interoperability issues, trade, competition. And that really drove governments
to push for standardization from the industrial revolution onwards. And that was really,
really, really accelerated with the first World War. And you know, the other aspect of this
is the liability risk. Has driven practitioners to essentially adopt standards or best practices
because it is really nice to be able to say when you get sued for something that goes off
way wrong, that you've actually done your job properly. You can point to a document that shows
that. So you really have these two sort of like original aspects. And this has been since
formalized in Europe through the new legislative framework where essentially it was recognized
that from the perspective of legislators, it was best to leave the formalization of best practices,
to the actual people doing it and have some form of interplay and structure to make sure that
that was done in a proper way. And so that enabled moving faster and being able to adapt to
technological innovation faster than it would if it was only legislation. And yeah, and it's been
you know, formalized in Europe like through the new legislative framework and by adopting the concept
of harmonized standards, which are approved by the European Commission and create a presumption of
conformity. So if you implement them, that helps you essentially say that you are meeting the legal
requirements, legal compliance requirements. So of course the impact of formalizing the role of
standards was legislation essentially creates distinction that if standards become part of legislation
and aren't really accessible, then legislation itself isn't. And this was successfully argued
in court recently. And the solutions that were designed for this, of course have to kind of
preserve the business model of the existing standard organizations. And so while it's, you know,
to some degree a step forward, it also doesn't really solve the underlying problem of standardization
of software and opens with in particular. All of this is in very broad strokes to set the context
just to be clear, because of the time constraints. And there are nuances in all of these different
points. So before, so yeah, so, like this tension between the business models of traditional
standard organizations and the needs of the IT industry have existed for a long time. And in 2012,
IEEE, the Internet Architecture Board, ITF, ISEC, and W3C created this concept called OpenStand,
which was essentially a way to formalize and market the way that they were doing standards,
which was built in a much more open way and also made in general freely available.
And in technology and in the IT sector, in general, when people talk about standards, that's what they
think of. But this is very different from the standards from the European standard organizations.
It's not the processes and the outputs are very different, and their legal significance is also very different.
So, what is an open source compatible standard? Well, essentially, it's what is an open stand,
which is a well- understood world system that's been very successful for lots of organizations
in the past. And it's open stand plus these essentially these three things, right?
The output of the process itself has to have some form of permissive, open-source-seed-like
license, regardless of what it is, right? Notably so it can be forked. This might be unpleasant for
some organizations, but actually making sure that standards can be worked on elsewhere if they're
stalled somewhere has proven to be very, very useful in the past on a number of occasions.
That's not an necessity, but it's something that's very useful. The second, of course, is that the
standard has to be available for free in an open format. And then, oh, there are four points,
so you just don't see it for here, because it's green on green. Sorry. The third point is that it must
be royalty free. It must not be incumbent by patents, right? You cannot force upon the open source
community standards that would require like paying patents of fees to just implement them.
And then, lastly, the participation model, like how you build the standards themselves has to
essentially be compatible with the way. Was an open ecosystem that's international and across
lots of different trades. So, one of the things is we actually have a pretty good definition
of this that's been around. Oh, really? Oh, sorry. So, I'm going to wrap it up in a second.
I thought my timer was right. Okay. So, yes. So, the open source initiative has a nearly
perfect definition since 2006, which is called the open standards requirement for software. I
encourage you to go have a look at it. We really, apparently, are not very good at marketing this,
right? Because I hadn't heard of it. And so, you know, to close the point, I think we have a
really big opportunity right now. Was OSI's definition, we have a pretty good definition of what
we need. With open standards, we have a playbook of actually how to push something forward like this.
The CRA related standardization effort that I'm like very much in the weeds that are right now
gives us like in the trenches way to experience this and and feel the pain and figure out solutions.
And there was an upcoming revision of regulation 1025, which gives us this window of opportunity to try
and make the European Synodization process more compatible with open source and software in general.
Thank you.