Open source and standardisation: Necessary but at times challenging collaboration towards compliance

This talk discusses the intersection of open source and standardization within the context of the Cyber Resilience Act (CRA). The speaker, affiliated with Nokia's Open Source Program Office, shares insights on the importance of collaboration between the open source community and regulatory bodies. Emphasizing Nokia's long history with open source, the talk highlights challenges faced by the community in engaging with standardization processes, particularly in the EU. The speaker outlines efforts made to establish an Open Regulatory Compliance working group to address these challenges and improve communication with standardization organizations. By exploring the regulatory landscape, the talk advocates for a proactive role for open source in shaping standards and ensuring that they serve the community's needs.

Yes, like Juan said, um this is the topic. So, about the open source and standardization. And especially now in the context of the CRA, so that's the kind of frame. Of course, there are other environment environments where where the collaboration is necessary and crucial, but I use I use the CRA because it's it's the one that has been for the past couple of years closest to to

me. And um the time budget, of course, here, as we all know, is 45 minutes. Um don't really know if I would fancy to talk all that. Maybe I would be much more pleased if I would be able to get some discussion about the topic. Um so, I would maybe go through the presentation as I have prepared it, and then then we could entertain whatever aspects you

may have in your mind to to elaborate on, because this is something that is an ongoing effort, a dilemma, and not solved by any means yet. So, a little bit of me. Juan already told some some details. Um this goes in in a way of like why do you even need Why would I be kind of qualified to to stand here and talk about this topic of

these two two things and and how they should go together. So, I am in Nokia open source program office. Um mainly in in in in addition to regulatory aspects, I I deal with the automation orchestration in in open source. So, all kinds of projects that land there. But regulation or the CRA related things have recently been maybe more time-consuming. I also do have some lengthy background history

on on on industry collaboration. So, a couple of decades in the actual standardization in different organization and now recently a little bit more than a decade in the in the open source front. And yeah. When told, we have this open regulatory compliance working group in in the Eclipse now for second year uh up and running. Uh I'm I've been co-chairing it from the beginning with with uh

Dirk Willem uh from Apache Foundation. Native Finn, that's a warning because we've been told that we are sometimes blunt and I'm not going to shy away from that because I just don't know how to. And I did some computer science uh in in in the early early years, so I believe I know something of the technology as well even if I've been with this uh industry collaboration

for quite some time. always need to have pictures. So, couple of pictures. none of them really tied to the topic. Maybe to me, but but definitely not the topic. So, next I'm going to talk about a little bit about Nokia and open source. And the reason for that is that while while I'm standing here and said couple of times this open regulatory compliance, this is necessarily a

manufacturer view as well. I just it it is impossible to distinguish or me to distinguish that angle from from from any of this talk. And then of course and of course some of individual views as well. So, let's So, this is not not a company spill. Not intended to be. But there are two messages I probably would like people to take away from this today there's no

mobile phones. So, Nokia and mobile phones are not together anymore. So, we are a company that delivers critical infrastructure in in in form of of networks, network equipment. Be it mobile, fixed, optical, be it to the operators as we know, or to web scalers, data centers. That's that's the kind of the technology and the business environment we are revolving around. Something that comes with that is a

regime. So, telecommunications has been from the very beginning highly regulated environment. So, from the company point of view, CRA as a regulation is is not kind of a new thing. A regulation is not a new thing. We have learned to live with it and and make best out of it. So, from that point of view, kind of a little bit easier for me to enter the trenches

than for example somebody who is like die hard open source person and has not had this encounter with the regulatory environment. And the other thing probably worthwhile to notice is the Where is it? That one. patents are big thing for us and and in our industry and that doesn't always go well with the open source constituency but so now now now you know that as well. So

it's not a secret and it does have some implication on the way that we deal with with these questions. But that's that's all for for the company. About the open source, why do we care? So we do have a fairly long history. You barely can see it but it starts from the 1990s. And then there are multiple milestones. You probably don't see them. Not necessarily to read

them but in the material you can then study but it tells you that we've been there from fairly early on. And then we have upped our game by kind of being founders of certain open source environment. So open source is really important for We say that some of our products are built with open source or contain open source and then there are others that are kind of

pretty much open source that we then put some some additional stuff there. So it's like a continuum of how much there is but there is a lot. So this is something that has to work for us like the community wise and and and all those collaborations that we are going to discuss soon about with the standardization and open it says about our kind of uh high level

strategy on how we deal with open source. It's about low differentiation areas reaching compatibility with the through the ecosystem. So, that's the kind of technical open source. The CRA is a little bit different animal as as we know, but still these are the guiding principles. now that we are as I said, open source and standards are something that are that are really readily in our um I

would say DNA. So, these are part of what we call openness, Nokia openness model. So, they they contribute to that thought and and and driver of of openness because in an environment like a global mobile where you come to Brussels regardless of if you travel from Shanghai or New York Antarctica your mobile functions. And that's because there's interop interoperability, there are standards and there are solutions that

are built with the openness and interoperability in mind. If that wouldn't exist, then the whole system ecosystem would be totally different. So, that's that's why this openness as a bigger concept is is relevant for us. But that's Now I stop talking about diving into into the interplay of of standardization and open source. I trust everybody knows what we talk about when we talk about the global uh

when we talk about c- Cyber Resilience Act, CRA. Anybody who doesn't know what those three letters stand for. Good, because I didn't inject a slide explaining that. What I did instead was that it's not only about the law text. Well, that we all know already by now. Most of us know. There might be some who still don't. harmonized standards, which is a concept in the uh European

legislation There are European standards organizations that are listed there, CEN, CENELEC, and ETSI, who have the mandate to write those harmonized standards when the Commission so asks and and they uh agree. So, that's going to be part of what what goes with the with the CRA. Then we have other stuff, which is no less relevant, which is the Commission's implementing act, delegated acts, all kinds of guidelines,

guidances. They have different bearing than somebody else's white papers. So, they they are relevant. And then there are all kinds of industry best practices, like something that the ORC has been working on and delivering. So, there's plenty of things that are with slight somewhat different uh relevance or legal bearing, but but still still something that needs to be observed and engaged with. Especially thinking from the open

source community point of view, we need to get it get it get all these right. Then there is an triangle that many of us have seen so many times are and have fallen in love gives you an idea of a structure of the harmonized standards which was the commission standardization requests request with 40 something topics on it and that's how it then kind of fell fell out

so there is a something that is called horizontals work by CENELEC and verticals currently but the esteemed colleague over here can correct me if I'm wrong but it's around 18 groups currently working in Etsy on on these different things so individual standards coming for specific vertical industry area at some point maybe this gives an kind of landscape uh how how it how it works out so I

think if we stare this slide for a moment and start to think that CIRA touches open source quite significantly and pretty much first time ever in in in law context now we have this number of different areas where standards are being worked to explain and put some requirements on products with digital elements and these all of these have potential to have something on open source so who

wants to start going through them and check which ones has and does it really matter it's it's a daunting task. And pretty much that was what the open source community was was up against uh when when all this show started and and took took form. So, the challenge is obviously there was clarity on CRA text. That's why open OSC actually started was that there was no clarity.

There was a lot of fear, a lot of misconception, uh a lot of I want to walk away because this makes my life miserable if it comes into force as it is written and all that. Where does that leave me as an maintainer, as a contributor, as somebody who loves open source and wants to wants to make make world better with it. input the standard. So, if

if you look at if you still remember the previous slide, how do you then influence that? What are the ways? It's some three or four or five letter acronym somewhere. How do you How do you get involved with them? And to be honest, you don't. Well, at least you didn't in the beginning because there was no way. For one, it was through some national standardization body. Who

has heard about those? What are those? How do I get access to those? Only through them you could get access to some of it. And then there was some obscure Southern French establishment. How do you get involved So, challenge is interfacing with regulators. So, direct contact with the commission people because they are writing the stuff, the guidances, and those things. How do we get handle? We just

over the lunch discussed this that you send an email to somebody in commission and then you die of old age before you see any response. So, that doesn't work. And then the awareness thing like for the community, try to make people at ease that it's not so bad that it might be better and we can't actually do something. Something that that helps. So, that that that was

the challenge environment that we were up against. So, what did we do? We organized ourselves. We created an open regulatory compliance working group in in Eclipse and then little later an OpenSSF Global Cyber Policy Working Group the focus on let's get our act together in context of the CRA and start learning how to overcome those challenges on the previous slide. So, that's that's where it all started

and of course I have to say that both of these groups planning to expand their focus or yeah, how you expand focus. But anyway, so kind of not only focus on CRA, but take some other regulatory activities in into their into their scope when they emerge and that was already it's by design. It's was something that was agreed early on. CRA of course was the burning thing

but there are others on the way. So, they this these two groups started to and have done a mighty job so far. So, here's a little bit of what the ORC has done. So, there's a lot of documentation, there's white papers in in planning, input contributions to the commission standardization so forth. And and and other form of of materials like specifications. So, and then the global cyber

policy way just highlighting some of the things. So, what happened was that those challenges that that we saw and those kind of no access to standardization, no easy access to standardization. So, what we did was that that these organizations stepped up and kind of improved their game and made it possible for them to attend the standardization. So, they got got a place in the room and they

got uh they were allowed to speak. So, they were they were able to make make a difference. So, that that was a decisive moment when things started to turn to right direction. So, now we had a channel. Now, we had a way to collaborate with the standardization and and then of course with the commission. But, that's what it required. And it took a while. I mean, it

took few months for both of these to to be kind of off the ground people getting to know them and getting involved and starting to to collaborate and contribute. So, what we then then learned when we started to be able to attend this standardization organization, first of all, they are independent from each other. So, they do have different working practices. So, it doesn't really cut that you

know how Sense and Select works at the Etsy side or vice versa. So, you need to learn both ways. So, a lot of learning. They do have their own working practices that work for them well and have worked for them well. think about mobile network standards, thousands of documents and tens of thousands of pages. And it works. They get it done for every bloody release that they

they work on. And now it's the sixth generation coming up. it works. You You can't argue against You can argue against it if it works well in in this theory context, but by and large, works. And the big question in the standardization setting is reaching consensus. And then, of course, comes how do you define consensus? But anyway, so that's the target. That's the main target. So, they

want to want to reach that so that they can close the books and now that's what has been agreed. And they do have means to get there. So, then when we entered Now, I'm using we as as open source communities to this place, we had to first learn their their ways of working. And we probably didn't like them so much. We are not so used to in

in in those practices and felt that maybe those are are archaic. And there are much better ways, flexible ways. We just throw PRs and people push put push put plus ones and we get things rolling. Didn't happen in in that side with their work documents and and weekly calls. a challenge. And of course then even if we had these groups, these two groups there, our way of

organizing ourselves was not still not exactly cut for these these challenge because it was still a kind of loose collaborate collection of of people and when you need to get a specific opinion representing this community it's a challenging task with a loose way of working that that we have in the So, we were kind of stuck sometimes with with not being able to articulate what actually we

are looking for and what we are asking for. And then we of course noticed that it's a profession, the standardization. So, those people have been doing for a long Open source folks are not professional standardization people. So, there's a friction there obviously and we don't want to be. So, it's like we have something more interesting and important in our days to to to work on than sit

in in a meeting. So, again, not exactly the right Well, not exactly an approach that would easily allow us to be as efficient as we would like to be in in that standardization environment. And then of course uh the not only the the the foundations the Eclipse and and Open SSIP were putting effort on, but also then quite soon we noticed that we do have actually colleague

colleagues in in open source communities who do have access to the those standardization organization who do have some experience there and who are willing to talk on behalf of the open source community like well, I was one of those because uh because of the company affiliation had all of those places where the standards were discussed. So of course then we had other people who who were sharing

the same possibilities or having the same possibilities. So we started to collaborate so we kind of donated the same way as we donate to the open source our contributions we donated our time and and and effort to coordinate some somewhat the open source uh input to the standards if you like. And by well, then fairly soon we started to hear from the open source from the standardization

folks that they actually mm appreciated the engagement. it started to bear some fruit. So we were listened to, we were asked and and things started to work. So it wasn't all uphill struggle from beginning until now. something nice also happened along the way. But still I think the biggest problem I saw was that we were not really efficient and able to provide coherent and uh and to

the point contribution from open with the given time constraints because then of course you need to understand that the document that they are writing has a timeline and a practice how they want to develop You need to contribute at the right And that that was not always uh very easy. Again, referring to this little bit kind of free floating way of organizing the open source discussion on

this getting close to the end. Now, we're describing the the way it was started, how we got engaged, and how we overcame some of the first hurdles. So, with contributing or collaboration collaborating with the standardization. lies ahead or how can we then move forward with this this activity because we assume that uh continue with the collaboration still still some time to come. Some good indications have been

there that the ESO's, so the standardization organizations, have been willing to adapt slightly their ways of working. Like Etsy, for example, they have something kind of a Git-like tool available. It's not extensively utilized to the best of its abilities, but it it is there. So, it's not only word documents that you need to edit, but you can do some something that is more familiar for for the

open source community. And also, they have started to share their draft materials earlier on than what had been practice before. So, earlier it was like only those members who were part of part of the happy family had the access to drafts, but nowadays they do they do share it more more more widely. So, little nudges to the direction to help help other people who are not intimately

into the standardization. CENELEC is a more challenging thing, but let's see if that that works better. We had a a lettered what we call letter to the ESOs sent out so both to the CENELEC and to the ETSI kind of highlighting this that we need to be part of it. We are part of this. But we need to be able to engage. So, what what are the

challenges and what would be the proposed ways forward to solve those challenges. So, we highlighted this what I said already limited access to working documents. And then these meeting frequencies and uh face-to-face video call meetings uh not asynchronous way of working. And not even having access to meeting calendars always. So, of course that's kind of defeats the the purpose. Can't access if you don't know that the

meeting happens. So, then some some proposals were shared dialogue just needs to continue. And uh and and we need to kind of emphasize that these are not solved things. This is something that still needs some improvement and then of course be thankful for the little nudges that that take place. Not going to read through all those bullets, but uh especially this uh kind of optimizing the value

of the synchronous meetings, meaning the face-to-face meetings or the video conferences. So, have a good agenda. have as much as possible pointed out kind of a the times when certain things are being discussed because well, people who don't have the luxury of spending two full days on a week in a meeting, they would need to understand where the topic that they feel strongly about happens. So, that

kind of making those those changes doesn't seem to be an easy thing to to happen. So, easy thing to happen, but uh but still this is something that hoping for taking place. Hoping for it to take place um little by little. And I think it has improved. I think we currently have the agendas that are little bit better. And and I'm now referring to the Cincinnati part

because that was for me that was like the newer environment and I was blown off with the agenda which says that the meeting starts at 9:30. We have coffee at 11:00, lunch at 12:30, coffee at 5:00 and go and and close the meeting at 5:30. Nothing in between. So, it's like all That's an agenda. But I just don't know what's going to be on the meeting. Now

they have more specific things, so things have improved. Okay. These are the things that I would like to kind of leave leave you with my thoughts on on kind of way forward. Assuming first of all that CRA is not one-off because if it is if we think that it is then we don't need to think about these things too much. We just survive with the current thing

and forget it. It was a nightmare and move on. But if we think that with the regulation and the harmonized standardization it exists and it has an impact to open source then probably we want to do some things better than than what we've done so far together. So, I said already continue the dialogue and propose the improvements. I mean that's we need to be active. They won't

changes won't don't happen if if we don't push for them. We need to show that we are active, we care and there are still things to be improved. And especially in the context of this harmonized European norms because technical standards I think that's a little bit different story. But this especially I think this is relevant because it's about law. So, we need those things obstacles need to

be removed as much as possible when it applies to to law that has some bearing helping ourselves to understand things is that learn how that standardization works and why does it work the way it does. There are reasons for that. Some of them are historical but then there are other things like good reasons why This consensus seeking then making sure that you end up with a consensus

decision. So, there's merit in there. us here what is the open source community with? That's kind of an interesting question I would be hesitant to say that the view that the ORC working group provides to the outside would be the open source view. Or that the view that the global cyber policy working group from OpenSSF comes up with the position. I wouldn't say that even that isn't

the open source view. So that that is I think it's a true kind of challenge on how we how we kind of come to that. I don't have a an answer to that. But maybe it's a worthwhile to kind of discuss and debate within our community that that when are we happy with an open source view formed. And then I think the last point which can kind

of maybe I got some war scars when trying to inject some of the open source software steward definitions into the CNCF failed miserably and walk away with tail between my legs. Let's try and also improve here on that area. So how do we get these things coherent, timely, and such that we all agree on it as much as possible. And it's an impactful contribution. So that also

the the the other side or the audience understands what what do we say and why do we say what we say. Mhm, done. Thank you. Thank you, Timo. We have time for at least one question. Any questions from the audience? Please. Hi. One question. Is open source fit for standardization? Because because in my view, I mean, I know don't know too much about standardization, but in my

view, standardization a little bit fixes the boundaries, which I cannot be changed. >> Mhm. So, open source is something, in my opinion, which is more flexible. so, this is why I put the question. Yeah. And I think that's that is a very good question. Thank you. Um perfect answer to this or anything else for that matter, but it's like I would address this in the in the

context of the the CRA or or the harmonized stan- standardization, which is like the fringes of the of the regula- of the regulation. So, um I think it it is difficult because it is the standardization is not in the DNA o- of an open source. We we create code. But when it comes to regulation, creating code doesn't cut it because you have an impact on on actually

something that is written, which is closer to standards. So, I think here there is a lot of lot of kind of um upskilling, so getting skills into the game in the open source where we can provide then meaningful contributions. So, but it's yeah, I think challenging probably is the is the word, and it's a new territory. So, that's the other thing that it's like we are not

used to that kind of work way of working and that kind of deliverables. yeah, that that it goes I I kind of strongly that it goes to this this slide where I said just highlighted a couple of things that what what we should as an open source community should be improving in this game. So, that answer to that question finds its home in that slide. We don't

have the answer, at least in my view. But, we need to One more. Sure. Alister. Yeah, so just a comment to your question to your observation. Um rebuttals, slight rebuttals. So, I I work on multiple open source projects the first observation is one of them many of them follow ITF standards and a whole bunch of other things and have been implementing open source standards for the longest

period of time. I can think of all the web browsers. Mozilla does W3C stuff. I mean, following standards is not difficult for assuming that they want to. For for ones that don't want to because they want to be creative, they don't. But, for the ones that want to interoperate with other people's equipment, they do a very good job. The routing stacks that I work with, we support

BGP, ISIS, OSPF, and everything else that the ITF does. And this is all open source. The guys who do DNS resolvers, all that's open source, and they stand up in the ITF meetings and do all these standards. So, I would make a very hard rebuttal to the fact that projects can't do this. Some of them decide to because of the field that they're in. Some Many do

not. So, I agree with that, but some are very, very good at doing the standards and are better than commercial products many times. So, I wouldn't want that observation to to sit in the room. The other one is a lot of this stuff is related to process. following process is something that open source projects can decide to do or not do. And a lot of the standardization

work that has been done here is process related. then deciding to opt in to follow a standard process including the ability to file your vulnerabilities and doing other types of things is just a process thing. It doesn't make a statement about whether the code is doing something one way or another way. And this just makes it clear for other people that you're doing things in that particular

regard. So, I'm not trying to pick a fight. I'm just making the observation that the initial thing was not quite accurate about the fact that it's a choice for open source projects. And many of them do would quite happily follow process standards and we're already following technical standards where it's appropriate. Thank you, Alister. Thank you, Timo.