[Improvement] Require a procedure to create a SBOM

[kappapiana]

Describe the improvement

Policy template: require a procedure to make a SBOM for each distribution artifact

Additional context

Section 3.3.1 requires that a SBOM is made, but under that heading the policy language does not require the existence of a procedure to create a SBOM. I believe that -- while an actual SBOM is not required for conformance -- having a procedure that mandates its creation before distribution is.

Consulting with @andrewjskatz I have added language he suggests in a PR that is linked to this issue.

Apart from accepting the PR, I suggest that these steps are required:

• align the Excel file
• align the ODS file
• align the Markdown example generic policy text.

[shanecoughlan]

Bringing @myagi2019 into this as Chair of Education.

I merged the pull request, which was related to this document:
https://github.com/OpenChain-Project/Reference-Material/blob/master/Open-Source-Policy-Templates/ISO-IEC-5230-(OpenChain%202.1)/en/referenced_policy_template.yml

The specific changes were:
8a06bf9

@kappapiana am I correct in thinking this document is another format of the material originally created in the Excel, and would therefore need the merging outlined above?

[kappapiana]

@kappapiana am I correct in thinking this document is another format of the material originally created in the Excel, and would therefore need the merging outlined above?

That's correct. The change was indeed suggested by @andrewjskatz in a private conversation. I hesitate touching the Excel file since I would use a non native app, but if instructed I could provide a new version. I see the OSD file has been removed.

To be clear, the file is a YAML translation of exactly the second tab of the Excel file (including the two example text for company and foundation). I have crated a simple python script that takes the field and can re-create a policy document in markdown using a very simple mustache template, and from there to many formats through pandoc, while retaining the very useful references to the policy and conformance questions later on and with the added bonus that every change is kept in git.

I remain available to maintain this format in the future, should the changes occur in the excel version first.

[shanecoughlan]

Thanks @kappapiana It's really appreciated to have this contribution!

For the OSD file, I didn't remove? Not sure what happened there.

@myagi2019 because this touches the Education material, handing over to you for sync.

[myagi2019]

I think the change should at least be communicated to the Education WG to allow for comment (I will send round email). What is the benefit of additionally having the yaml file version on github as it seems to me that it complicates further the maintenance. E.g. for the .md versions we are very clear...
"Please note
This document is generated from the full OpenChain Policy Template Spreadsheet document at this URL: https://github.com/OpenChain-Project/Reference-Material/tree/master/Open-Source-Policy-Templates/ISO-IEC-5230-(OpenChain%202.1)/en and that this link is current as of 2025-06-16. If the full URL does not work, you should be able to find the full policy template using the instruction in the README file at this link: https://github.com/OpenChain-Project/Reference-Material

This document is not intended to be a complete or prescriptive or recommended open source policy. It is provided as an example only."
@shanecoughlan can please update the "this link is current as of 2025-06-16" to "this link is current as of 2025-08-10" in both .md files?

[shanecoughlan]

"@shanecoughlan can please update the "this link is current as of 2025-06-16" to "this link is current as of 2025-08-10" in both .md files?"

Done.

Also, @myagi2019 added you as a maintainer.

[kappapiana]

@myagi2019 the markdown texts are the equivalent of the third tab of the policy document, I submit that they are a (stripped down) output of the second tab. The YAML file is a machine-readable version of the second tab, retaining the same fundamental information that link the sample text to the specification.

Therefore, you can arbitrarily change the text of the policy document, add entire paragraphs to it, track it in git repository, end up with a different document, but yet you can be sure which part of the document is a direct implementation of which section of the standard. You just have to look above. Admittedly, it's not as readable as a PDF, but you have a host of information and can harness the power of git at the same time (including, collaborative modifications).