Wiki

This is the FAQ for the OpenChain specification. We highly recommend all contributors to specification's development review these questions and answers as a first step to contributing.

To define a core set of requirements a Open Source compliance program should satisfy to achieve: a level of trust that an organization provides the artifacts required to achieve Open Source license compliance for software it shares with others. Compliance artifacts consist of: source code, build scripts, license copies, attribution notices, modification notices, SPDX data and other materials open source licenses governing a software deliverable may require.

There are four principles that guide the development of the specification:

1. Build trust around the use of open source in constructing software solutions that are shared with others (with a focus on license compliance).
2. Less is More
   • 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
   • If we could remove words and still preserve meaning and value then use fewer words
3. Focus of the what and why (avoid the how and when)
   • Embrace the implementation of different practices to solve a given requirement
   • Avoid providing specific legal advice or specific common practices
4. 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.

• current version of the specification can be found here: OpenChain Compliance Specification

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.

An organizaition's Supplied Software itself is not identified as being OpenChain Conforming. An Open Source compliance program which the software is prepared under is a candidate for OpenChain conformance. When a software supplier states they are OpenChain conforming it means they have a program that satisfies all the requirements of the OpenChain specification. A software supplier may declare the software offered was prepared under an OpenChain conforming program. Similarly, a software recipient may ask the supplier if the software they received was prepared under an OpenChain conforming program.

No. Organizations are sometimes composed of different groups and/or departments which may have different programs and release procedures (e.g., engineering vs professional services). One Open Source program within an organization can be classified as OpenChain conforming if it satisfies the specification requirements while another program may not. One should not associate software with OpenChain conformance if it has not been reviewed under a program that has been assessed to be OpenChain conforming.

No. The main objective of the specification provides a set of requirements that would help one evaluate whether an existing Open Source compliance program is sufficient. It focuses on the “what and why” aspects of a program and not the how or when. There are many different ways to construct a Open Source compliance program (how and when) such that each way would satisfy the specification. The specification provides a method of measuring whether a program has obtained a base line level of quality and consistency. This allows a software supplier to represent to their users that the compliance artifacts they provided were prepared under a Open Source program that satisfied a core set of requirements.

The Linux Foundation OpenChain working group functions like an open source project by obtaining input from scores 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 five categories were:

1. Program Foundation [i.e., “Policy and Training”]
2. Relevant Tasks
3. Open Source Content Review and Approval
4. Compliance Artifact Creation and Delivery
5. Understand Open Source Community Engagement

A number of references that document the history of the specs development include:

• specification mailing list
• github issue tracking
• This FAQs

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.

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, but it significantly increases the probability that license compliance will be achieved for software releases prepared under a OpenChain conforming program.

The OpenChain Curriculum working group has developed training reference materials that greatly facilitate the creation (or enhancement) of a Open Source compliance training program. The OpenChain Conformance working group has developed a questionnaire to guide an organization in self-certifying a program to be OpenChain conforming. The Linux Foundation sponsors various open source projects and initiatives that provide useful tools and compliance program resources that can help implement an OpenChain Open Source compliance program (e.g., SPDX, FOSSology, …). These resources can be found in the Linux Foundation Open Compliance Program.

The specification is licensed under the Creative Commons Attribution License 4.0 (CC-BY-4.0). A copy of the license can be obtained here: CC-BY-4.0

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.