Charter

Purpose

Open source software is load-bearing in robots that can injure or kill people: industrial and collaborative arms, mobile robots in warehouses and factories, and autonomous vehicles and equipment on farms, mines, and work sites. Most of it, from middleware and drivers to perception and motion planning, was not written with those machines in mind, and the evidence needed to justify its use in them does not exist in any shared form.

The Open Source Safety Consortium exists to produce that evidence once, in the open, and maintain it as the underlying projects change. Where a safety function has no adequate open implementation, it builds one, with the evidence alongside.

Scope

The consortium's scope is robotics: machines that sense, decide, and move with some autonomy, where a failure can hurt people. Road vehicles, medical devices, and aircraft are outside it, although much of the work will carry over to them. Within robotics, the consortium works on four things:

• Assurance artifacts. Hazard analyses, failure mode catalogues, test evidence, and safety arguments for specific open source components at specific versions, in a common documented form.
• Practice. Guidance on how to qualify, integrate, monitor, and update open source components in robots subject to functional safety requirements.
• Reference implementations. Software components and hardware designs for safety functions the members need and cannot get in the open: firmware, protocol libraries, boards, enclosures, and the test rigs that exercise them. Each is built to be assessed, with a small core that can be safety-rated on its own and the assurance artifacts published with it. The first is a protective stop.
• Upstream contribution. Patches, tests, tooling, and documentation returned to the projects themselves, so the safety work compounds instead of forking.

The consortium does not certify products, does not act as an assessment body, and does not issue approvals. A reference implementation is not a certified product; it is a design and its evidence, which members and non-members carry into their own safety cases, under their own responsibility.

Principles

1. Evidence, not assertion

Every claim the consortium publishes is traceable to an analysis, a test, or a documented review. Reputation, adoption numbers, and maturity are not evidence of safety.

2. Shared assurance artifacts

Artifacts are published under open licenses, in machine-readable form where possible, versioned against the components they describe.

3. Upstream first

Where safety work implies a change to a component, the consortium works with maintainers to land it upstream. Private forks are a failure mode, not a deliverable.

4. Honest scope

Every artifact states its assumptions, its operational envelope, and what it does not cover. An assurance claim without stated limits is worse than no claim, because it invites unexamined reuse.

5. Maintainers are participants, not subjects

Open source maintainers did not sign up to carry safety obligations. The consortium brings them resources and findings; it does not transfer liability or impose process on volunteer projects.

Membership

Membership is open to organizations that build, deploy, or maintain open source software in safety-relevant robotic systems. Members commit to:

• producing assurance work as well as using what others publish;
• publishing artifacts they produce under the consortium's licenses;
• disclosing safety-relevant defects they discover in shared components;
• participating in technical review of others' artifacts.

Maintainers of in-scope open source projects participate without dues.

Governance

A technical steering committee drawn from member organizations sets the work programme and approves artifacts for publication. Decisions are made in public, with rationale recorded. No single member holds a veto, and no member's commercial interest determines what is published.

Full governance procedures are under development for member review.

Licensing

Documents and assurance artifacts are published under Creative Commons Attribution 4.0. Code, firmware, tooling, and test suites are published under Apache 2.0. Hardware designs, including schematics, board layouts, and mechanical files, are published under the CERN Open Hardware Licence Version 2, Permissive (CERN-OHL-P). All three permit commercial use in member and non-member products alike, and none requires derived work to be published. The consortium asks for upstream contribution as a principle; it does not compel it by licence.