Minutes 12 Feb 2026 - elisa-tech/wg-osep GitHub Wiki

Host: Paul Albertella

Participants: Pete Brink, Victor Lu, Igor Stoppa, Naga (Timesys/Lynx), Dana Vede

Agenda

  • In the last meeting we discussed drafting a presentation for the wider ELISA community, to explain some of the conclusions / consensus we have reached. For example, why ELISA should *not* try to :
    • argue that Linux is safe, on the basis that it is 'proven in use'
    • persuade the Linux community to 'make Linux safe' by following the safety standards
    • argue that the processes used to develop the kernel are *equivalent* to those expected by the safety standards

Notes

Victor talked about discussion of roles in the SDPX community, and how this might correlate to roles in open source projects, and e.g. what role they have in a security process.

e.g. Committer and Project Lead roles in Eclipse Foundation, Maintainer in Linux

Pete: Roles are typically associated with competency. But the group assigning and approving individuals in roles might not even have the required competency to determine what competency is required.

Paul: This raises the question of whether we can expect open source communities and Linux in particular to meet the expectations of safety standards (or similar).

Igor: Greg’s response to Gab seems to confirm that the Linux kernel community has no interest in doing this.

Pete: This is a common phenomenon: there’s an interest in developing the technology, without the kind of process rigour that the safety standards expect.

Paul: In my experience, people are unwilling to follow formal processes because they don’t understand the value or motivation behind them. And open source projects are unwilling to seek to comply with standards because the standards are expensive and achieving compliance can be even more expensive.

Igor: Isn’t the process space well-established and extensively documented? The challenge is how you can persuade people (and FOSS) to use it…

Dana: The engineers are not interested in where the requirements come from, they just want to have something that tells them what they should or should not do. And they want to know “What’s in it for me?” - how does it make things better?

What is really needed is just an engineering process that other people can make the claim in relation to the applicable standards.

Igor: The best way to encourage engineers to do things is to show them.

Daniel: But everyone I speak to says that ISO 26262 is impossible to apply to

Pete: It is almost impossible to apply retrospectively…

Paul: But you can apply these things to the engineering that you are doing, which might include using software that already exists, which was not developed with this in mind.

Dana: The engineers should be concerned with the engineering practices.