Add machine readable lists covering all proposed tools and desired compiler features

[mhatzl]

This PR adds two YAML files containing

• list of desired compiler features for security and safety critical domains
• list of tools that may be helpful to develop safety critical software in Rust

closes #454
closes #453
closes #452
closes #422
closes #421
closes #420
closes #419
closes #403
closes #402
closes #401
closes #400
closes #381
closes #380
closes #377

For tools, the general form currently is:

- name: ""
  type: ""
  url: ""
  vendor: ""
  description: ""
  license: ""
  qualified: []

Note: For some commercial tools, I was not able to find information about standards the tool is qualified for. Also some tools may provide qualification kits, but they themselves are not qualified, so I currently left the qualification info empty.

I would also like to add something like a "status" field or "reliability" score to indicate the maturity, usefulness, maintenance, ... of a tool.
This will likely take some time to find something people in the consortium agree on, so I didn't want to block this PR.

[netlify]

✅ Deploy Preview for safety-critical-rust-consortium canceled.

Name	Link
🔨 Latest commit	26481fe
🔍 Latest deploy log	https://app.netlify.com/projects/safety-critical-rust-consortium/deploys/68f65415bcdafc0008bc6e93

[PLeVasseur]

Minor typo and questions. Thanks to the task force for putting this together.

[PLeVasseur]

Is this intended to be something like a "last modified date" of this file?

Suggested change

	date: "2025-10-01"
	date: "2025-10-01"

[mhatzl]

I'd say more like a "last time listed topics have been reviewed".

modified we can do with git history, but knowing when was the last time someone took the time to go through the listed topics and checked their latest status would be good to know.

[mhatzl]

for example in case nothing about the topics changed, the version should stay the same, but we'd still like to note that we have looked at the list.

if you agree I'd add a comment above the field.

[PLeVasseur]

I think it may be possible to have there be a priority listed.
However -- I think it's important to be clear on how such a field is populated.

I would like to discuss this in a meeting on how to capture this.

[mhatzl]

as discussed, we would likely keep it in for now, but will try to clarify what "high" means in this list and in regard to rustc.

[tshepang]

Ferrocene modifications to rustc retain the upstream license

Suggested change

	license: "commercial"
	license: "Apache 2.0 & MIT"

[mhatzl]

as discussed, we might need to split the license field into source-license and product-license, because even though the Ferrocene source is Apache 2.0 & MIT, to get the docs for Ferrocene to be qualified, you'll need to pay so "commercial".

but I don't like this split of the license field, because it only really makes sense for commercial products.

maybe we make the license field accept either String or an object?
e.g.

license: "Apache 2.0"

license:
  - source: "Apache 2.0"
  - product: "commercial"

or we have license and cost and tools could either be

• cost: "free"
• cost: "commercial"

[tshepang]

maybe we make the license field accept either String or an object

looks like an improvement

[mhatzl]

product might be a bit confusing, because it somewhat overlaps with source.

maybe we name the field qual-kit, meaning qualification kit.
because commonly that is what customers must pay for even if the source is open source licensed and publicly available

[tshepang]

thinking further on this, and inspired by your comment, I think we should leave license as plain text, and we can add an optional field, example

# Ferrocene entry
license: "Apache 2.0 & MIT"
additional-details: binaries and support available with a monthly/yearly subscription, and qualification kit available for an additional fee

we can also leave "additional-details" off for now, to avoid slowing forward movement of this pr

[tshepang]

would keep description basic to avoid marketing speak (and this applies to descriptions of the other toolchains)

Suggested change

	description: "Open-source qualified Rust compiler toolchain for safety- and mission-critical systems"
	description: "Compiler toolchain"

[mhatzl]

I think one or two short sentences as description is fine.
Otherwise, this field becomes quite useless, because the type is already compiler.

This list will be the base for the website and having a short paragraph per tool as description probably looks quite good.

I think a bit of marketing speak in this field is ok.

[tshepang]

if we allow a bit of marketing...

# Ferrocene entry
description: "Rust compiler toolchain developed in the open"

that is for 2 reaons

• it being open source is already shown in the license field
  as sidenote, you can develop in private and only make your software to paying customers while retaining an open source license
• it being suitable for mission-critical use is not relevant to the safety-critical domain

if we avoid the marketing part, we could maybe mention qualified targets (which will easily get stale), or some other thing about Ferrocene... not sure what