Create openchain-standards-model-provisions.0.5.md

Added by Andrew Katz as below:

- I have clarified the purpose of the original document, which was intended to be a set of representations as opposed to the questions to ask (which are contained in….)
- There is now a set of due diligence questions, also based on OpenChain
- I have avoided the issue with the Supplier Information Pack by repurposing it, so it is now *only* about the supplier’s conformance program, as opposed to the software itself, which would ordinarily be defined elsewhere in the contract in the normal way.
- It would be possible to have two sets of warranties – a longer one for suppliers which do not declare themselves OpenChain conformant, and a shorter one for suppliers that do (in the latter case, a lot of the reps will already be dealt with by the rep that they are OpenChain conformant).

Author: shanecoughlan

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

@@ -0,0 +1,244 @@
+# Overview
+
+This is a document to explore model provisions for OpenChain ISO/IEC 5230 or ISO/IEC DIS 18974 in procurement contracts and similar material. It is based on the public domain Risk Grid version 12 hosted in the OpenChain Reference Library on GitHub:
+https://github.com/OpenChain-Project/Reference-Material/blob/master/General-Compliance-Support-Material/Risk-Grid/risk-grid-12.md
+
+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.5
+
+# Series of Due Diligence Questions to be used prior to preparation of contract
+
+Note: this document is to be interpreted consistently with the OpenChain Specification 2.1 (ISO5230:2020) ("OpenChain"). For a copy of the OpenChain specification, please see here [insert link]. In each case, if the answer to a question below is *yes*, please provide details. 
+	
+### Q0.1: Do you have any formal certifications or conformance assessments relating to your open source compliance activities (e.g. OpenChain, ISO/IEC 5230:2020). These can be self certifications or external certifications.
+
+### Q0.2 If yes, is the software to be developed for us developed under a program which conforms to these certifications or assessments? 
+
+### Q1:	Do you have a policy for selecting, using and deploying free and open source software (FOSS) components?
+
+### Q2:	Do you provide training to staff on selecting and incorporating FOSS into your products?
+
+### Q3:	Do you have a process for reviewing FOSS licences and categorising the obligations/conditions attached to them? 
+
+### Q3.1 Do you have a method of recording decisions made as to whether a particular component should be incorporated or not? 
+
+### Q3.2 Are these records attributable to specific version(s) or release(s) of software?
+
+### Q3.3 How long are the records archived for?
+
+### Q4:	Do you use any software tools or services to assist with open source license compliance? (For example, Black Duck, Scancode, White Source, FOSSology, SW360)
+
+### Q5.1: Have you appointed individuals with overall responsibility for open source license compliance policies, practice and procedures?
+
+### Q5.2: Have you appointed individuals with overall responsibility for responding to open source queries from outside the organization?
+
+### Q6: Can you provide a complete list of open source components and their respective licensing information used in any software you use or ship?
+
+### Q7:	Do you provide customers with all materials required by the relevant open source software licenses (e.g. source code or offers to provide source, attribution notices, installation instructions)?
+
+### Q8:	Does your organization contribute to external open source projects? Do you have a policy for handling this?
+
+
+# OpenChain based representations for use in a procurement contract
+
+*Note: This is a set of representations and obligations to be incorporated in a procurement contract. The structure follows ISO:5230:2020. The representations may also be modified to take effect as warranties and/or indemnities depending on local law and as agreed between the parties.* 
+
+*If due diligence determines that the supplier claims to be ISO 5230:2020 compliant, the following warranties apply. If the customer is **not** compliant with ISO 5230:2020 then extra care should be taken in selecting this supplier (and they should be encouraged to implement the relevant requirements, and ideally comply with ISO 5230:2020 in its entirety, and the warranties marked with an asterisk (\*) can be deleted* 
+
+[Note: Alternatively, we can produce shortened set of reps applying to companies which have already confirmed they are OpenChain conformant] 
+
+### 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 providing information about the Supplier's Open Source Conformance Program. 
+
+#### 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 represents that it has any policy, process or procedure, it further represents 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 license 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.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.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 each Software Bill of Materials made available to the Customer from time to time;
+
+#### 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] as anticipated by the Use Case
+
+#### 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:
+
+Each issue is formatted as follows:
+
+- Issue　
+- Commentary　
+- Who is best placed to bear risk?　
+- Best mechanism to tackle risk　
+- Sample Wording　
+- Supplier's Arguments　
+- Customer's Arguments　
+
+## Overarching Topics
+
+### Issue - Inclusion of OpenChain ISO/IEC 5230
+
+#### Commentary　
+
+None listed.
+
+#### Who is best placed to bear risk?　
+
+Supplier.
+
+#### Best mechanism to tackle risk　
+
+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]. 
+
+or
+
+The Supplier warrants that the [Software] [defined components of the Software] originate[s] from a Program [or Programs] adhering to aspects of an OpenChain ISO/IEC 5230:2000 Conformant Program as specified in the Supplier Information Pack].
+
+and
+
+[The Supplier does not warrant that use, modification or further distribution by the Customer of the Software constitutes a continuation of adherence to an OpenChain ISO/IEC 5230:2000 Conformant Program].
+
+#### Supplier's Arguments　
+
+The Supplier may argue that the inclusion of these requirements or the extent of the requirements included introduce a cost-burden that need to be offset.
+
+#### Customer's Arguments　
+
+The Customer is receiving a potential liability regarding third-party intellectual property along with the Software deliverable from the Supplier. As such, it is reasonable to request that the Supplier adheres to international standards related to the licensing of this third-party intellectual property.
+
+### Issue - Inclusion of OpenChain ISO/IEC DIS 18974
+
+#### Commentary　
+
+None listed.
+
+#### Who is best placed to bear risk?　
+
+Supplier.
+
+#### Best mechanism to tackle risk　
+
+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]. 
+
+or
+
+The Supplier warrants that the [Software] [defined components of the Software] originate[s] from a Program [or Programs] adhering to aspects of an OpenChain ISO/IEC DIS 18974 Conformant Program as specified in the Supplier Information Pack].
+
+and
+
+[The Supplier does not warrant that use, modification or further distribution by the Customer of the Software constitutes a continuation of adherence to an OpenChain ISO/IEC DIS 18974 Conformant Program].　
+
+#### Supplier's Arguments　
+
+The Supplier may argue that the inclusion of these requirements or the extent of the requirements included introduce a cost-burden that need to be offset.
+
+#### Customer's Arguments　
+
+The Customer is receiving a potential liability regarding security along with the Software deliverable from the Supplier. As such, it is reasonable to request that the Supplier adheres to international standards related to the managing of security assurance related to the Software.
+
+### Issue - Determining if the OpenChain Conformant Program is self-certified or third-party certified
+
+#### Commentary　
+
+None listed.
+
+#### Who is best placed to bear risk?　
+
+Supplier
+
+#### Best mechanism to tackle risk　
+
+None listed.
+
+#### Sample Wording　
+
+The Supplier warrants that the OpenChain [ISO/IEC 5230:2000][ISO/IEC DIS 18974] Conformant Program [or Programs] referenced in the relevant [purchasing agreement[s]] [contract[s]] is self-certified as per the checklists or questionnaires provided by the OpenChain Project.
+
+or
+
+The Supplier warrants that the OpenChain [ISO/IEC 5230:2000][ISO/IEC DIS 18974] Conformant Program [or Programs] referenced in the relevant [purchasing agreement[s]] [contract[s]] is third-party certified by [registered] [licensed] third-party certified.
+
+and
+
+[The Supplier will produce documentation to verify that the OpenChain [ISO/IEC 5230:2000][ISO/IEC DIS 18974] Conformant Program [or Programs] has undergone the disclosed certification process.]
+
+#### Supplier's Arguments　
+
+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.  
+