This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
openchain:specification-questions-and-answers [2019/02/23 15:25] mgisi [Does the specification serve as a best practice guide?] |
openchain:specification-questions-and-answers [2019/11/17 19:12] mgisi [Does the specification describe how to comply with the most popular Open Source licenses?] |
||
---|---|---|---|
Line 13: | Line 13: | ||
* Avoid boiling the ocean - Focus specifically on providing the necessary and sufficient requirements of a “high quality” compliance program | * Avoid boiling the ocean - Focus specifically on providing the necessary and sufficient requirements of a “high quality” compliance program | ||
* Focus on meaningful pain points based on practical use cases | * Focus on meaningful pain points based on practical use cases | ||
+ | * If we could remove words and still preserve meaning and value then use fewer words | ||
- Focus of the what and why (avoid the how and when) | - Focus of the what and why (avoid the how and when) | ||
* 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 common practices | * Avoid providing specific legal advice or specific common practices | ||
- | - 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. | + | - 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 an open development approach. |
Line 50: | Line 51: | ||
- Understand Open Source Community Engagement | - Understand Open Source Community Engagement | ||
A number of references that document the history of the specs development include: | A number of references that document the history of the specs development include: | ||
- | * {{https://lists.linuxfoundation.org/mailman/listinfo/openchain-specification | specification mailing list}} | + | * {{ https://lists.openchainproject.org/g/specification | specification mailing list}} |
* {{ https://github.com/OpenChain-Project/Specification/issues | github issue tracking}} | * {{ https://github.com/OpenChain-Project/Specification/issues | github issue tracking}} | ||
* This FAQs | * This FAQs | ||
Line 56: | Line 57: | ||
====Is a third party audit required to declare an Open Source Compliance program to be OpenChain Conforming?==== | ====Is a third party audit required to declare an Open Source Compliance program to be OpenChain Conforming?==== | ||
- | No. The [[https://wiki.linuxfoundation.org/_media/openchain/openchainspec-1.2.pdf|OpenChain 1.2 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 evidence that must exist in order for one to determine the specific requirement has been met. Although evidence 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. 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 materials, and the willingness to do so, is determined by the relationship entered into by two parties. | + | No. The specification was designed 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 an Open Source Compliance program must satisfy. The Verification Materials for a requirement represent a collection of evidence that must exist in order for one to determine the specific requirement has been met. Although evidence 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. 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 materials, and the willingness to do so, is determined by the relationship entered into by two parties. |
====Does the specification describe how to comply with the most popular Open Source 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. |
====Does OpenChain program conformance guarantee license compliance?==== | ====Does OpenChain program conformance guarantee license compliance?==== | ||
Line 77: | Line 78: | ||
==== What is the different between Conformance vs Compliance ==== | ==== What is the different between Conformance vs Compliance ==== | ||
- | In the specification text we do *not* use the term "Compliance" with respect to satisfying the spec requirements not to confuse it with "license compliance" or "Open Source Compliance program" which is frequently mentioned through out the spec. We use the term "Conformance" instead to mean a program has satisfied all the spec's requirements. It is possible that someone might make reference to the fact that their program "complies" with version X of the spec or that the program is "compliant" with version X of the spec which would be equivalent to stating the program "conforms" or has achieved "conformance" with version X. | + | In the specification text we do *not* use the term "Compliance" with respect to satisfying the spec requirements - so not to confuse it with "license compliance" or "Open Source Compliance program" which is frequently mentioned through out the spec. We use the term "Conformance" instead to mean a program has satisfied all the spec's requirements. It is possible that someone might make reference to the fact that their program "complies" with version X of the spec or that the program is "compliant" with version X of the spec which would be equivalent to stating the program "conforms"; "is conformant"; or "has achieved conformance" with version X. |