Eclipse Foundation Functional Safety Process
Version 1.0 (December 2025)
The document describes the Eclipse Foundation Functional Safety Process (EFFSP) for Eclipse open source projects.
The EFFSP leverages and augments the Eclipse Foundation Development Process (EDP). The EDP defines important concepts, including the Open Source Rules of Engagement, the organisational framework for open source projects and teams, releases, reviews, and more.
Applicable Documents and Processes:
In the event of any conflict between the terms set forth in this document and the terms of the documents listed above, the terms of those documents shall take precedence.
1. Goals
The goal of the Eclipse Foundation Functional Safety Process is to define a means by which safety-critical software can be developed following open source principles and governance of the Eclipse Foundation.
2. Terms and Definitions
- Functional Safety
-
Functional safety refers to the aspect of safety that ensures a system or equipment operates correctly in response to its inputs, particularly in the presence of faults or failures.
- Functional Safety Standard
-
A functional safety standard produced by a recognised international standards body (e.g., IEC 61508, IEC 62304, ISO 26262, and EN 50128).
- Functional Safety Artefacts
-
Documentation that provides verifiable evidence that the software was developed with rigorous safety measures throughout the entire life-cycle. See Functional Safety Artefacts.
- Functional Safety Committee
-
A Working Group committee that provides expert guidance to the Working Group Steering Committee and Eclipse Management Organization, and oversight for Functional Safety Projects. See Functional Safety Committee.
- Project
-
As defined in the Eclipse Foundation Development Process.
- Project Team
-
As defined in the Eclipse Foundation Development Process.
- Functional Safety Project
-
A Project that fully implements this process. See Functional Safety Project.
Other terms used in this document are defined in the Eclipse Foundation Development Process and Eclipse Foundation Working Group Process.
3. Functional Safety Project
A Functional Safety Project is a special type of Project which must:
-
Engage in practices that are consistent with this process;
-
Implement practices that are consistent with a Functional Safety Standard;
-
Implement the EDP, the Eclipse Foundation Intellectual Property Policy, and the Eclipse Foundation Security Policy;
-
Operate in an open, transparent, and meritocratic manner as defined by the Open Source Rules of Engagement defined in the EDP; and
-
Operate in a vendor neutral manner.
A Functional Safety Project may — but is not required to — operate under the purview of one Functional Safety Committee. When a Functional Safety Project requires resources beyond what is provided for all Projects from the Eclipse Foundation, then the project must operate under the purview of a Functional Safety Committee, and the corresponding Working Group must include such support in its program plan as defined within this process.
3.1. Standards and Confidentiality
A Functional Safety Project must use resources (e.g., source code repositories, issue trackers, and communication channels) provided or approved by the EMO. All project resources must be generally accessible per the Open Source Rules of Engagement.
On an exceptional basis, with approval by the EMO, the Eclipse Foundation may allocate confidential resources to provide the means for a Functional Safety Project to work on and discuss matters related to standards.
Confidential resources must only be used when terms restrict the ability of the project team to work on or discuss the implementation of the standard using public resources.
3.2. Functional Safety Artefacts
A Functional Safety Project must produce and maintain a set of artefacts that can be used by adopters to certify their derivative products.
These artefacts collectively provide verifiable evidence that the software was developed with rigorous safety measures throughout the entire life-cycle.
3.3. Functional Safety Framework
A Functional Safety Framework is a framework or methodology that describes a set of specific roles, processes, principles, practices, and/or guidelines used to manage the day-to-day activities of a project engaged in the development of safety-critical software.
|
This document describes only the governance aspects of safety-critical software development in open source. A Functional Safety Framework defines the practical day-to-day aspects of managing risk while building safety-critical software in accordance with the specific requirements of specific Functional Safety Standards. |
A Functional Safety Project must adopt a Functional Safety Framework that has been approved by the Eclipse Foundation for use by Functional Safety Projects.
A Functional Safety Project must define and document Project-specific functional safety practices that are consistent with the Functional Safety Framework and targeted Functional Safety Standards, and implement them accordingly throughout the project’s life-cycle.
|
The Eclipse Foundation Functional Safety Operations Guide provides a list of approved Functional Safety Frameworks and best practices. |
3.4. Roles
3.4.1. Standard Roles
Functional Safety Projects have the standard formal roles that are defined in the EDP.
- Contributors
-
Contributors are individuals who contribute code, fixes, tests, documentation, or other work that is part of the Project.
- Committers
-
Committers, as defined by the EDP, are not just coders. Committers are responsible for planning, requirements, triaging and responding to community and adopter input (e.g., issues and discussion channels), building consensus within the community, deciding when contributors meet the criteria and nominating them to become committers, and documenting project practices. Standard committer elections are the means by which Committer status is granted.
- Project Leads
-
Project Leads serve primarily as a liaison between the project team and the EMO. They have primary responsibility for ensuring that the project team is following good open source practices and are implementing the EDP, Eclipse Foundation IP and Security policies, etc. Project leads must also be committers. Standard project lead elections are the means by which Project Lead status is granted.
|
|
The means by which developers are granted Committer or Project Leads status is fundamentally no different from that of all Eclipse open source projects. Functional Safety Projects must document the standards by which formal and informal roles are granted. Employment status cannot be a part of the criteria by which project roles (formal or otherwise) are granted or retained. Standard roles are granted very specific privileges in an Eclipse open source project’s infrastructure, including GitHub and GitLab. It is standard practice to retire individuals from status when they cease to be active on a Project for an extended period (generally six months). Individuals must not be retired from a Project role (formal or otherwise) based exclusively on a change in employment status. Individuals may retire themselves from any role. |
3.4.2. Other Roles
Other roles (e.g., Functional Safety Lead, Technical Lead, or Code Owner) may be defined by the project team, along with open, transparent, and meritocratic criteria and process for determining who should be granted that role.
4. Functional Safety Committee
The Functional Safety Committee is established by a Working Group engaged in safety-critical software development, to provide expert guidance and oversight for those Projects that do safety-critical development under the purview of the Working Group. Its mandate is to ensure that Projects adhering to the Functional Safety Process do so with the highest level of rigour and consistency, and promoting best practices within the Eclipse ecosystem. The committee’s work is essential for building trust and confidence in the Functional Safety Artefacts generated by Functional Safety Projects.
4.1. Responsibilities
A Functional Safety Committee holds the following responsibilities:
- Advisory Role
-
Provide expert advice to the EMO regarding the adoption of Functional Safety Frameworks approved for use by Functional Safety Projects;
-
Provide expert advice to the EMO on matters concerning functional safety development by Functional Safety Projects; and
-
Provide expert advice to the Working Group Steering Committee on matters concerning functional safety development by Functional Safety Projects.
- Coordination and Support
-
Facilitate collaboration between Functional Safety Projects, the Functional Safety Committee, and EMO, ensuring smooth and efficient workflows;
-
Advise the Steering Committee in the case where a Working Group decides to pursue assessment or certification for a Functional Safety Project; and
-
Advise and support the EMO in the case where a Working Group decides to pursue assessment or certification for a Functional Safety Project.
In essence, this committee acts as a guardian of functional safety within the Eclipse open source environment, ensuring that Functional Safety Projects are developed with the necessary rigour.
The Functional Safety Committee is not responsible for the day-to-day operation of Functional Safety Projects, and does not have any responsibility or authority regarding the structure or organisation of Functional Safety Projects or corresponding top-level project.
4.2. Composition
The composition of the Functional Safety Committee is defined in the Working Group Charter.
|
|
The Eclipse Foundation Functional Safety Process Operations Guide provides recommendations regarding the composition of the Functional Safety Committee. |
5. Assessment
A Project must fully implement this process in order to pursue assessment.
Assessment is initiated at the request of the corresponding Working Group’s Steering Committee, and with the approval of the EMO(ED) or their delegate.
The Functional Safety Committee must support and provide assistance with the assessment process.
The result of an assessment is a report. The Eclipse Foundation owns all output from an assessment, and is responsible for dissemination.
The assessment effort must be funded.
6. Certification
Only the Eclipse Foundation can seek certification of the products of a Project.
|
|
We distinguish between the products of a Project and vendor products based on content from a Project. An adopter of a Project’s technology can seek certification of their own products based on the Eclipse technology. Products that are based on Eclipse project content must respect the Eclipse Foundation Trademark Usage Policy. |
In order to pursue certifications of the products of a Project, a Project must:
-
Fully implement this process in order to pursue certification; and
-
Have the support of a Functional Safety Committee in order to pursue certification.
Certification is initiated at the request of the corresponding Working Group’s Steering Committee, and with the approval of the EMO(ED) or their delegate.
|
|
Certification is a time consuming and expensive process. Distributing certified software comes with liabilities that must be managed by the Eclipse Foundation on behalf of the Working Group and Project (e.g., insurance). These costs must be considered when deciding to pursue certification. |
The Functional Safety Committee must support and provide assistance with the certification process.
The result of certification is a certificate. The certificate is owned by the Eclipse Foundation.
The certification effort must be funded.