Minutes 29 Jan 2026 - elisa-tech/wg-osep GitHub Wiki

Host: Paul Albertella

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

Agenda

  • ‘Quality’: what does this mean in the context of safety?
  • What do we mean by “Open Source Engineering Process”?
  • Can we show the value of applying these processes to the kernel, as a way to encourage the Linux community to adopt them?
  • Can we show the value of applying these processes when we are using Linux in a project, which we can then provide upstream?

Notes

@Victor: SPDX ‘personas’ includes a safety profile

Initiative led by representative from NIST

Personas: which entities or roles have an influence in achieving particular goals.

Is this kind of thinking useful in examining what role(s) FOSS projects or contributors might play in achieving safety-related objectives?

Igor: It is striking that this kind of formalism is not present in Linux kernel development. How does any of this translate into actions or measures that we (specifically) can apply?

Paul: We can look at our mission statement: https://github.com/elisa-tech/wg-osep/blob/main/mission.md#planned-activities

Igor: What’s missing here are the objectives of what is described here and how we measure progress or success.

What would good look like?

  • Pete: Evidence that upstream have adopted any of the things we might recommend or recognise as providing appropriate evidence satisfying the expectations expressed by the safety standards
  • We did some of this as part of the work of the (former) Development Process WG

Paul: I expressed this as ‘claims’ rather than ‘compliant processes’, because we might argue that a given safety or engineering objective is achieved might not look like that?

Igor: What gaps have we identified? How effective have our efforts been towards closing them?

Example: Gab and Kate have attempted to promote a level of adding formalised requirements to the kernel, which was able to identify some bugs.

Igor: What is the goal? To find argumentation for the users of the kernel to use in defence of their use of Linux in safety applications.

Paul: If we change the focus to “we want to use Linux in our applications” then we no longer have to ‘move the needle’ in the sense of changing the Linux kernel community.

Igor: The ‘needle’ is making Linux usable in safety applications. This can be done by defining processes that achieve the goals of (or follow the processes described by) the standards.

Victor: Is there some proof that the processes achieve their objectives? Could we communicate the logic that backs up the claims about the process, to convince the kernel community to change?

Paul: It’s useful to think about the processes in these terms, but we don’t have to convince the kernel community to change: we can apply these processes ourselves (or describe how they can be used) and show that they achieve the desired goals when we use what we can get from the Linux kernel community (the code, the documentation, their discussions on the mailing lists).

Igor: Also we can show that by adding something to Linux, or making a change to it (since it is open source), we can achieve our safety goals irrespective of what we get from Linux.

Paul: This is a conclusion that I feel we’ve arrived at before. How can we establish it as a conclusion, or a proposal, and move forward with it?

Pete: We could write this up and present it to the TSC

Victor: There is also the CRA: https://digital-strategy.ec.europa.eu/en/policies/cra-open-source which has implications for open source ecosystems.

Dana: Individual contributors do not necessarily have responsibilities, but organisations or entities that provide the code do have some level of responsibility. So this would be e.g. the Linux Foundation, so it has some uncomfortable implications for open source.

Next time: Draft presentation on this for delivery to TSC