Linux Foundation Wiki

project collaboration site

User Tools

Site Tools


openchain:specification-questions-and-answers

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
openchain:specification-questions-and-answers [2018/05/17 19:23]
mgisi
openchain:specification-questions-and-answers [2018/10/06 16:37] (current)
mgisi [Is a third party audit required to declare an Open Source Compliance program to be OpenChain Conforming?]
Line 9: Line 9:
 ==== What are the Specification Guiding Principles? ==== ==== What are the Specification Guiding Principles? ====
  There are four principles that guide the development of the specification:​  There are four principles that guide the development of the specification:​
-   - Build trust around the use of open source in constructing software solutions that are shared with others.+   - Build trust around the use of open source in constructing software solutions that are shared with others ​(with a focus on license compliance).
    - Less is More    - Less is More
      * Avoid boiling the ocean - Focus specifically on providing the necessary and sufficient requirements of a “quality” compliance program      * Avoid boiling the ocean - Focus specifically on providing the necessary and sufficient requirements of a “quality” compliance program
Line 16: Line 16:
     * Embrace the implementation of different practices to solve a given requirement     * Embrace the implementation of different practices to solve a given requirement
     * Avoid providing specific legal advice or specific best practices     * Avoid providing specific legal advice or specific best practices
-  - Function as an open development initiative - open to all to contribute - inclusion via discussion and consensus that adhere to these guiding principles+  - Function as an open development initiative - open to all to contribute - inclusion via discussion and consensus that adhere to these guiding principles. Consider adopting best practices from standard initiatives which complement the open development approach.
  
  
Line 24: Line 24:
  
  
-==== Does a FOSS program need to satisfy all the requirements of the specification to be considered OpenChain Conforming? ====+==== Does an Open Source Compliance ​program need to satisfy all the requirements of the specification to be considered OpenChain Conforming? ====
  
 Yes. The specification was designed to provide a core set of requirements to ensure a certain level of program quality has been achieved. In order to ensure there are no significant gaps in an OpenChain conforming program that could lead to poor quality output, a program must satisfy all the requirements to be considered OpenChain conforming. Yes. The specification was designed to provide a core set of requirements to ensure a certain level of program quality has been achieved. In order to ensure there are no significant gaps in an OpenChain conforming program that could lead to poor quality output, a program must satisfy all the requirements to be considered OpenChain conforming.
Line 47: Line 47:
  
 The Linux Foundation OpenChain working group functions like an open source project by obtaining input from dozens of individuals,​ companies and organizations that have experiences preparing for and/or exchanging software in the software supply chain. There are no specific requirements for participating. The working group identified 6 main categories of a compliance program and then had contributors identify important tasks and deliverable for each category. The six categories were: The Linux Foundation OpenChain working group functions like an open source project by obtaining input from dozens of individuals,​ companies and organizations that have experiences preparing for and/or exchanging software in the software supply chain. There are no specific requirements for participating. The working group identified 6 main categories of a compliance program and then had contributors identify important tasks and deliverable for each category. The six categories were:
-  - Know Your Free and Open Source ​(FOSS) ​Responsibilities [i.e., “Policy and Training”]+  - Know Your Free and Open Source Responsibilities [i.e., “Policy and Training”]
   - Assign Responsibility for Achieving Compliance   - Assign Responsibility for Achieving Compliance
-  - Deliver ​FOSS Content Documentation and Artifacts +  - Deliver ​Open Source ​Content Documentation and Artifacts 
-  - Review and approve ​FOSS content +  - Review and approve ​Open Source ​content 
-  - Understand ​FOSS Community Engagement+  - Understand ​Open Source ​Community Engagement
   - Certify Adherence to OpenChain Requirements   - Certify Adherence to OpenChain Requirements
 A number of reference documents were prepared and used as important sources of input into identifying core requirements of a quality compliance program. Several of those documents include: A number of reference documents were prepared and used as important sources of input into identifying core requirements of a quality compliance program. Several of those documents include:
Line 58: Line 58:
   * The Supplier License Compliance Audit (SLCA)   * The Supplier License Compliance Audit (SLCA)
  
-====Is a third party audit required to declare ​a FOSS program to be OpenChain Conforming?​====+====Is a third party audit required to declare ​an Open Source Compliance ​program to be OpenChain Conforming?​====
  
-No. At least not yet. The [[https://​wiki.linuxfoundation.org/​_media/​openchain/​openchainspec-1.0.pdf|OpenChain 1.specification]] is simply structured to provide a list of requirements where each requirement maintains a set of acceptance criteria (Verification ​Artifacts). Each requirement is a description of an important quality a Open Source program must maintain. The Verification ​Artifacts ​for a requirement represent a list of tangible artifacts that must exist in order for one to determine the specific requirement has been met. Although artifacts must exist, one is not required to make them public. The key goal of the specification is to foster trust around Open Source compliance between two parties exchanging software. Although currently an audit by a third party is not a requirement of the OpenChain specification, a partner or customer may ask for evidence of the Verification ​Artifacts ​as a condition for doing business (e.g., under an Non-Disclosure agreement). That is, the obligation to provide evidence of the existence of the artifacts, and the willingness to do so, is determined by the relationship entered into by two parties. ​It has been discussed ​that future version of the specification may provide more specific guidelines on how to obtain ​third party certification.+No. The [[https://​wiki.linuxfoundation.org/​_media/​openchain/​openchainspec-1.2.pdf|OpenChain 1.specification]] is simply structured to provide a list of requirements where each requirement maintains a set of acceptance criteria (Verification ​Materials). Each requirement is a description of an important quality a Open Source ​Compliance ​program must satisfy. The Verification ​Materials ​for a requirement represent a list of tangible artifacts that must exist in order for one to determine the specific requirement has been met. Although artifacts must exist, one is not required to make them public. The key goal of the specification is to foster trust around Open Source compliance between two parties exchanging software. Although currently an audit by a third party is not an available option, a partner or customer may ask for evidence of the Verification ​Materials ​as a condition for doing business (e.g., under an Non-Disclosure agreement). That is, the obligation to provide evidence of the existence of the artifacts, and the willingness to do so, is determined by the relationship entered into by two parties. ​A third party auditing program ​has been discussed ​several times but there currently is no formal program yet. If program existed ​to support audits by a third party then audited compliance program would be classified as "​certified"​. The self-certification ​approach allows one to declare their compliance program to be "​conforming.
  
-====Does the specification describe how to comply with the most popular ​FOSS licenses?​====+====Does the specification describe how to comply with the most popular ​Open Source ​licenses?​====
  
 No. The specification does not provide legal guidance. It does require an organization to designate a legal expert who can assist with legal guidance. Furthermore the specification requires that a process exists that ensures the appropriate attention is given to license obligation analysis and and fulfillment. No. The specification does not provide legal guidance. It does require an organization to designate a legal expert who can assist with legal guidance. Furthermore the specification requires that a process exists that ensures the appropriate attention is given to license obligation analysis and and fulfillment.
openchain/specification-questions-and-answers.1526585039.txt.gz · Last modified: 2018/05/17 19:23 by mgisi