diff --git a/Open-Source-Policy-Templates/ISO-IEC-5230-(OpenChain 2.1)/en/Example-Generic-Company-Policy-Text.md b/Open-Source-Policy-Templates/ISO-IEC-5230-(OpenChain 2.1)/en/Example-Generic-Company-Policy-Text.md index b15bc41b..285a5560 100644 --- a/Open-Source-Policy-Templates/ISO-IEC-5230-(OpenChain 2.1)/en/Example-Generic-Company-Policy-Text.md +++ b/Open-Source-Policy-Templates/ISO-IEC-5230-(OpenChain 2.1)/en/Example-Generic-Company-Policy-Text.md @@ -1,6 +1,6 @@ #### 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-08-10. 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 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-09-25. 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. @@ -51,7 +51,7 @@ This document is not intended to be a complete or prescriptive or recommended op | The Open Source Compliance Lead \[and <list supporting persons, groups and their functions as set out in Appendix 1>\] shall be primarily responsible for the resolution of day-to-day internal compliance issues, as well as updating and reviewing this policy.

The Open Source Compliance Lead shall be responsible for
• Reviewing, implementing and communicating this policy;
• Reviewing and implementing training and assessment for open source compliance related issues (in conjunction with HR);
• Overseeing the activities of the Open Source Liaison;
• Categorising identified licenses;
• Keeping themselves appraised of up-to-date issues around open source compliance, including involvement with appropriate forums, user groups and mailing lists, and keeping in regular contact with the external legal \[and compliance\] advisors as set out in Appendix 1;
• Keeping the Board, and in particular, the Open Source Compliance Board Member, up to date with activities affected by this open source policy;
• \[list any additional persons, groups and their responsibilities as further set out in Appendix 1\] | | Should a non-compliance issue be raised, the Open Source Compliance Lead shall:

1\. Acknowledge receipt of the query and state a reasonable time for resolution;
2\. Determine whether the query discloses a genuine issue or not (and if not, respond to the querier accordingly);
3\. If the issue is genuine, apply \[Appendix 4: incident severity criteria\] to prioritise;
4\. Determine the appropriate response according to \[Appendix 4: incident response criteria\];
5\. Carry out response in accordance with criteria, changing client terms of business etc. as appropriate; and
6\. Document the above in the open source log. | | **Open source content review and approval** | -| We have a process for ensuring that only code meeting our quality, licensing, provenance and functional requirements is incorporated into our code base and supplied software. All code must be approved before incorporation, and all code use (and the decisions that led to its inclusion) must be properly documented in the open source log. | +| We have a process [insert link to process] for ensuring that all code components incorporated into any supplied software are recorded in a software bill of materials [in SPDX format] accompanying each version of supplied software.

Only code meeting our quality, licensing, provenance and functional requirements is incorporated into our code base and supplied software. All code must be approved before incorporation, and all code use (and the decisions that led to its inclusion) must be properly documented in the associated software bill of materials and the open source log.| | All decisions carried out under this policy shall be recorded in the open source log, with details of the background, decision made, date, source of request, and name of the decision maker.

The open source log shall be reviewed annually, and any entries relating to code which is no longer currently used or distributed shall be flagged. All such entries shall be archived after \[three years\] of being flagged, and shall be anonymised after \[six years\]. | | The open source log shall be maintained so as to ensure that each entry is cross referenced to the supplied software release or releases it referred to, to enable it to be sorted so that a subset of all log entries for a specific release can be produced, demonstrating that this procedure has been properly followed. | | **License compliance** | diff --git a/Open-Source-Policy-Templates/ISO-IEC-5230-(OpenChain 2.1)/en/Example-Generic-Foundation-Policy-Text.md b/Open-Source-Policy-Templates/ISO-IEC-5230-(OpenChain 2.1)/en/Example-Generic-Foundation-Policy-Text.md index 3d5ba7ae..6729641f 100644 --- a/Open-Source-Policy-Templates/ISO-IEC-5230-(OpenChain 2.1)/en/Example-Generic-Foundation-Policy-Text.md +++ b/Open-Source-Policy-Templates/ISO-IEC-5230-(OpenChain 2.1)/en/Example-Generic-Foundation-Policy-Text.md @@ -1,6 +1,6 @@ #### 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-08-10. 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 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-09-25. 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. @@ -51,7 +51,9 @@ This document is not intended to be a complete or prescriptive or recommended op | The Open Source Compliance Lead \[and <list supporting persons, groups and their functions as set out in Appendix 1>\] shall be primarily responsible for the resolution of day-to-day internal compliance issues, as well as updating and reviewing this policy.

The Open Source Compliance Lead shall be responsible for
• Reviewing, implementing and communicating this policy;
• Reviewing and implementing training and assessment for open source compliance related issues (in conjunction with \[FOUNDATION\]'s HR or Equivalent\];
• Overseeing the activities of the Open Source Liaison;
• Categorising identified licenses;
• Keeping themselves appraised of up-to-date issues around open source compliance, including involvement with appropriate forums, user groups and mailing lists, and keeping in regular contact with the external legal \[and compliance\] advisors as set out in Appendix 1;
• Keeping the Board, and in particular, the Open Source Compliance Board Member, up to date with activities affected by this open source policy;
• \[list any additional persons, groups and their responsibilities as further set out in Appendix 1\] | | Should a non-compliance issue be raised, the Open Source Compliance Lead shall:

1\. Acknowledge receipt of the query and state a reasonable time for resolution;
2\. Determine whether the query discloses a genuine issue or not (and if not, respond to the querier accordingly);
3\. If the issue is genuine, apply \[Appendix 4: incident severity criteria\] to prioritise;
4\. Determine the appropriate response according to \[Appendix 4: incident response criteria\];
5\. Carry out response in accordance with criteria, changing client terms of business etc. as appropriate; and
6\. Document the above in the open source log. | | **Open source content review and approval** | -| We have a process for ensuring that only code meeting our quality, licensing, provenance and functional requirements is incorporated into our code base and supplied software. All code must be approved before incorporation, and all code use (and the decisions that led to its inclusion) must be properly documented in the open source log.

All projects which are within the scope of this program will consider contributions from third parties provided that those third parties have entered into the standard \[Contributor License Agreement/Developer Certificate of Origin\] and are not otherwise excluded. Where an external contributor requests to incorporate any third party code, that code shall only be incorporated into the codebase by the Open Source Compliance Lead or other authorised program participant in accordance with the code selection procedure \[set out in Appendix 3\] and other requirements set out in this policy.

Although external contributors are not required to adhere to this policy, they are encouraged to read it and familiarise themselves with it. They will be asked to provide information about the provenance of any third party code which they propose to incorporate into the code base, so that the Open Source Compliance Lead (or authorised program participant) can make a determination, in accordance with this policy, as to whether it should be included or not. Understanding the criteria for inclusion (and asking appropriate questions before starting to consider third party code) will save time for both the contributor and the Open Source Compliance Lead. | +| We have a process [insert link to process] for ensuring that all code components incorporated into any supplied software are recorded in a software bill of materials [in SPDX format] accompanying each version of supplied software.

+Only code meeting our quality, licensing, provenance and functional requirements is incorporated into our code base and supplied software. All code must be approved before incorporation, and all code use (and the decisions that led to its inclusion) must be properly documented in the associated software bill of materials and the open source log. +

All projects which are within the scope of this program will consider contributions from third parties provided that those third parties have entered into the standard \[Contributor License Agreement/Developer Certificate of Origin\] and are not otherwise excluded. Where an external contributor requests to incorporate any third party code, that code shall only be incorporated into the codebase by the Open Source Compliance Lead or other authorised program participant in accordance with the code selection procedure \[set out in Appendix 3\] and other requirements set out in this policy.

Although external contributors are not required to adhere to this policy, they are encouraged to read it and familiarise themselves with it. They will be asked to provide information about the provenance of any third party code which they propose to incorporate into the code base, so that the Open Source Compliance Lead (or authorised program participant) can make a determination, in accordance with this policy, as to whether it should be included or not. Understanding the criteria for inclusion (and asking appropriate questions before starting to consider third party code) will save time for both the contributor and the Open Source Compliance Lead. | | All decisions carried out under this policy shall be recorded in the open source log, with details of the background, decision made, date, source of request, and name of the decision maker.

The open source log shall be reviewed annually, and any entries relating to code which is no longer currently used or distributed shall be flagged. All such entries shall be archived after \[three years\] of being flagged, and shall be anonymised after \[six years\]. | | The open source log shall be maintained so as to ensure that each entry is cross referenced to the supplied software release or releases it referred to, to enable it to be sorted so that a subset of all log entries for a specific release can be produced, demonstrating that this procedure has been properly followed. | | **License compliance** | diff --git a/Open-Source-Policy-Templates/ISO-IEC-5230-(OpenChain 2.1)/en/Open-Source-Policy-Template-en-OpenChain2.1-ISO5230-2025-09-25.xlsx b/Open-Source-Policy-Templates/ISO-IEC-5230-(OpenChain 2.1)/en/Open-Source-Policy-Template-en-OpenChain2.1-ISO5230-2025-09-25.xlsx new file mode 100644 index 00000000..9e9a0c0c Binary files /dev/null and b/Open-Source-Policy-Templates/ISO-IEC-5230-(OpenChain 2.1)/en/Open-Source-Policy-Template-en-OpenChain2.1-ISO5230-2025-09-25.xlsx differ diff --git a/Open-Source-Policy-Templates/ISO-IEC-5230-(OpenChain 2.1)/en/Open-Source-Policy-Template-en-OpenChain2.1-ISO5230-2025-09-10.xlsx b/Open-Source-Policy-Templates/ISO-IEC-5230-(OpenChain 2.1)/en/old/Open-Source-Policy-Template-en-OpenChain2.1-ISO5230-2025-09-10.xlsx similarity index 100% rename from Open-Source-Policy-Templates/ISO-IEC-5230-(OpenChain 2.1)/en/Open-Source-Policy-Template-en-OpenChain2.1-ISO5230-2025-09-10.xlsx rename to Open-Source-Policy-Templates/ISO-IEC-5230-(OpenChain 2.1)/en/old/Open-Source-Policy-Template-en-OpenChain2.1-ISO5230-2025-09-10.xlsx