Merge pull request #51 from OpenChain-Project/piana-patch-audit

fist draft audit right

Author: shanecoughlan

Adoption-Preparation/Model-Provisions/openchain-standards-model-provisions.0.4.md

@@ -5,88 +5,88 @@ https://github.com/OpenChain-Project/Reference-Material/blob/master/General-Comp
 
 The goal of this document is to ensure people can understand options. We will not be prescriptive and these model provisions will remain part of the OpenChain reference material. They will not be included in the OpenChain standards themselves.
 
-## Version 0.4
-
+## Version 0.4
+
 # Series of Questions to Result in a Supplier Information Pack
 
 ## 1. This is a sequence of questions designed to determine what parts (if any) of the OpenChain ISO/IEC 5230:2020 standard a Supplier has implemented.
 
-### 1.1.　General 
+### 1.1.　General
 
 #### 1.1.1.　All capitalized terms in this Section [1] are, unless defined elsewhere in this Agreement, to be interpreted in line with the definitions in the OpenChain Specification 2.1 (ISO 5230:2020) (“OpenChain”).
-
+
 #### 1.1.2.　“Software” means Supplied Software delivered or to be delivered to the Customer.
-
-#### 1.1.3.　“Supplier Information Pack” means information supplied in writing and appended to this Agreement detailing various aspects of the Software, its specification, development, and compliance process. 
-
-#### 1.1.4.　“Use Case” means the Use Case which the Customer has specified as being its intended use of the Software (for example, installation of the software onto an embedded device which is distributed to an end-user) 
-
+
+#### 1.1.3.　“Supplier Information Pack” means information supplied in writing and appended to this Agreement detailing various aspects of the Software, its specification, development, and compliance process.
+
+#### 1.1.4.　“Use Case” means the Use Case which the Customer has specified as being its intended use of the Software (for example, installation of the software onto an embedded device which is distributed to an end-user)
+
 #### 1.1.5.　The Supplier affirms that the Software is developed subject to a Program which is OpenChain conformant.
-
+
 #### 1.1.6.　The Supplier affirms that it has obtained and holds an OpenChain conformance validation document issued within the past 18 months, a copy of which is appended to the Supplier Information Pack.
-
-#### 1.1.7. Where in this Section [1] or pursuant to OpenChain the Supplier is required to have any policy, process or procedure, it further warrants that it shall maintain and enforce any such policy, process and procedure throughout the [term of this Agreement] 
+
+#### 1.1.7. Where in this Section [1] or pursuant to OpenChain the Supplier is required to have any policy, process or procedure, it further warrants that it shall maintain and enforce any such policy, process and procedure throughout the [term of this Agreement]
 
 ### 1.2.　Policy
-
+
 #### 1.2.1.　The Supplier has a written Open Source policy that governs Open Source compliance of the Software a copy of which is appended to the Supplier Information Pack.
-
+
 #### 1.2.2.　The Supplier has (i) appointed persons responsible for the Supplier’s compliance with its Open Source policy; (ii) determined the necessary competence of such persons; (iii) ensured and taken action to ensure that such persons are competent on the basis of appropriate education, training, and/or experience; and (iv) retained documented information as evidence of competence. Copies of documents evidencing the above are appended to the Supplier Information Pack.
-
+
 #### 1.2.3.　The Supplier has documented a procedure for making its Program Participants of its Open Source policy, has ensured that its Program Participants are aware of the Supplier’s Open Source policy, the relevant Open Source objectives, their contribution to the effectiveness of the compliance program, and the implications of non-compliance. Copies of documents evidencing the above are appended to the Supplier Information Pack.
-
+
 #### 1.2.4.　Where different Open Source compliance programs are governed by their different levels of scope and limits, the Supplier has declared the scope designation for each program applicable to Supplied Software, copies of which are appended to the Supplier Information Pack.
-
+
 #### 1.2.5.　The Supplier has adopted a process for reviewing the Identified Licenses to determine the obligations, restrictions and rights granted by each license. Details of the process are appended to the Supplier Information Pack.
 
 ### 1.3.　Access & Resourcing
-
+
 #### 1.3.1.　The Supplier has (i) adopted and maintained a process to effectively respond to external Open Source inquiries, details of which are appended to the Supplier Information Pack; and (ii) publicly identified a means by which a third party can make an Open Source compliance inquiry.
-
+
 #### 1.3.2.　The Supplier has (i) assigned accountability to its Program Participants officers to ensure the successful execution of compliance Program tasks; (ii) ensured that compliance Program tasks have been provided with sufficient execution time and funding resources; (iii) adopted a process for reviewing and updating the policy and the supporting tasks; (iv) ensured that legal expertise pertaining to Open Source license compliance is accessible to those who may need such guidance; and (v) adopted a process for the resolution of Open Source license compliance issues. Details of the above are appended to the Supplier Information Pack.
 
 ### 1.4.　Content Review & Approval
-
+
 #### 1.4.1.　The Supplier has adopted and documented a process for creating and managing a bill of materials that includes each Open Source component (and its identified licenses) from which the supplied software is comprised. Details of the process are appended to the Supplier Information Pack.
-
+
 #### 1.4.2.　The Supplier has adopted and documented a process to ensure that its compliance program is capable of handling the common Open Source licence use cases for the Open Source components of the supplied software. Details of the documented process are appended to the Supplier Information Pack.
 
 ### 1.5.　Compliance Artefacts
-
+
 #### 1.5.1.　The Supplier has adopted and documented a process for creating a set of Compliance Artefacts (such as legal notices or source code) that represent the output of a compliance Program and accompany the Software. Copies of this procedure and records evidencing that it has been followed are appended to the Supplier Information Pack.
-
-#### 1.5.2.　The Compliance Artefacts are prepared in such a way as to ensure that use and/or distribution of the Software in accordance with the Use Case will be compliant. 
+
+#### 1.5.2.　The Compliance Artefacts are prepared in such a way as to ensure that use and/or distribution of the Software in accordance with the Use Case will be compliant.
 
 ### 1.6.　Contributions
-
-#### 1.6.1.　The Supplier has a policy governing the contribution to third party Open Source projects, a copy of which is appended to the Supplier Information Pack 
+
+#### 1.6.1.　The Supplier has a policy governing the contribution to third party Open Source projects, a copy of which is appended to the Supplier Information Pack
 
 ### 1.7.　Ongoing Obligations
-
+
 #### 1.7.1.　The Customer shall be entitled on request to receive a copy of any Verification Materials or Compliance Artifacts applicable to Software or to any version of the Software currently in development.
-
+
 #### 1.7.2.　The Supplier shall notify the Customer promptly should any practice, policy or procedure comprising part of the Program change in any material respect.
-
+
 #### 1.7.3.　[Access to software/repo as it is in development]
-
+
 #### 1.7.4.　[Access to logs showing queries and breaches of policies]
-
+
 ### 1.8.　Warranties and Indemnities
-
+
 #### 1.8.1.　The Supplier warrants that any Open Source components contained within the Software are fully and accurately listed on the Software Bill of Materials
-
+
 #### 1.8.2.　Are accompanied by all Compliance Artifacts necessary to fully comply with the terms of the Open Source licenses applicable to all components contained within the Software when the Software is
-
+
 #### 1.8.2.1.　Delivered to the Customer; and
-
+
 #### 1.8.2.2.　Delivered to any downstream distributor of the Customer; and
-
+
 #### 1.8.2.3.　Delivered to any End User [either as an installer package, a binary, a packaged delivered and installed through an app store, or delivered pre-installed into any device].
-
+
 #### 1.8.3.　[usual warranties as to general IP compliance, right to supply to customer, conformance with specification etc.]
-
+
 #### 1.8.4.　[usual ongoing obligations as to awareness of breaches etc.]
-
+
 #### 1.8.5.　[usual indemnity wording]
 
 # Below is a Series of Optional Model Language Issues in Original Risk Grid Format:
@@ -119,7 +119,7 @@ None listed.
 
 #### Sample Wording　
 
-The Supplier warrants that the [Software] [defined components of the Software] originate[s] from an OpenChain ISO/IEC 5230:2000 Conformant Program [or Programs] [, with the OpenChain ISO/IEC 5230:2000 Conformant Program being specified in the Supplier Information Pack]. 
+The Supplier warrants that the [Software] [defined components of the Software] originate[s] from an OpenChain ISO/IEC 5230:2000 Conformant Program [or Programs] [, with the OpenChain ISO/IEC 5230:2000 Conformant Program being specified in the Supplier Information Pack].
 
 or
 
@@ -151,9 +151,9 @@ Supplier.
 
 None listed.
 
-#### Sample Wording
-
-The Supplier warrants that the [Software] [defined components of the Software] originate[s] from an OpenChain ISO/IEC DIS 18974 Conformant Program [or Programs] [, with the OpenChain ISO/IEC DIS 18974 Conformant Program being specified in the Supplier Information Pack]. 
+#### Sample Wording
+
+The Supplier warrants that the [Software] [defined components of the Software] originate[s] from an OpenChain ISO/IEC DIS 18974 Conformant Program [or Programs] [, with the OpenChain ISO/IEC DIS 18974 Conformant Program being specified in the Supplier Information Pack].
 
 or
 
@@ -203,5 +203,46 @@ None.
 
 #### Customer's Arguments　
 
-The Customer requires clarity regarding the type of certification that the Supplier has undergone to contextualize their risk. A Customer may regard third-party certification as preferable due to the inherent audit involved. Alternatively, a Customer may be satisfied that self-certification is sufficient given that OpenChain ISO/IEC 5230:2000 or ISO/IEC DIS 18974 both require the party with a conformant program to maintain documentation on how they accomplished their conformance.  
+The Customer requires clarity regarding the type of certification that the Supplier has undergone to contextualize their risk. A Customer may regard third-party certification as preferable due to the inherent audit involved. Alternatively, a Customer may be satisfied that self-certification is sufficient given that OpenChain ISO/IEC 5230:2000 or ISO/IEC DIS 18974 both require the party with a conformant program to maintain documentation on how they accomplished their conformance.
+
+
+### Issue - Risk that the Declaration is just pro-forma, how to verify?
+
+#### Commentary　
+
+None listed.
+
+#### Who is best placed to bear risk?　
+
+Supplier
+
+#### Best mechanism to tackle risk　
+
+Audit rights
+
+#### Sample Wording　
+
+Customer may request that an audit be carried out to verify compliance to ISO/IEC 5230:2000 by a Third party auditor (**"Audit"**) that shall be approved by Supplier and such approval shall not be unreasonably withheld.
+
+The Audit is subject to the following conditions:
+
+a. it must only concern Supplier's OpenChain-related material, processes, policies and other relevant Artefact as provided for by ISO/IEC 5230:2000 that are used to demonstrate compliance.
+a. the auditor shall undertake a formal non disclosure agreement if it was not bound to professional secrecy by operation of the law;
+a. it must be carried out no more than once a year;
+a. it must come with an adequate advance notice, in no case less than 5 business days, and may be carried out during normal working hours, without interrupting the continuity of Supplier's activities or causing Supplier excessive burden and inconvenience, and in compliance with Supplier's safety policies;
+a. Customer shall bear all expenses arising out of or in connection with Audits at Supplier's premises, unless such Audits reveal that Supplier is not acting in compliance ISO/IEC 5230:2000, in which case all expenses shall be borne by Supplier.  Customer may prepare an audit report summarizing the results and observations of the Audits (**"Audit Report"**);
+a. If at all possible, the Audit shall be documental, but the auditor may interview personnel of the Supplier to verify the level of compliance.
+
+Audit Reports are confidential information of Supplier and Customer undertakes not to disclose them to third parties, with the exception of its own consultants, including legal consultants and its own employees.
+
+Supplier can respond to a request to carry out an audit by handing over a recent Audit Report performed by a reputable third part; such handing over may carry reasonably confidentiality conditions. A recent Audit Report is a report that was formed no more than 10 months prior to the request to carry over the audit. Customer shall not unreasonably refuse to accept such Audit Report *in lieu* of a full audit, but can demand to carry over an audit on areas which have not been accurately described or which have not been covered by the Audit Report.
+
+[in case Supplier is self-certified] Supplier may retain the auditor for becoming third-party certified or to renew third-party certification, but any such request may not be made earlier than one calendar month after the Audit Report has been delivered.
+
+#### Supplier's Arguments　
+
+Cost and complication of an audit process, confidentiality.
+
+#### Customer's Arguments　
 
+Costs are borne mainly by Customer, confidentiality is tackled by NDA and the process is run by a third party, frequency is limited and the audit can be done by showing a reliable audit done by a reputable third party.