One of the first tools that we bring when working with OSPOs is the OpenChain 2.1 / ISO/IEC 5230 standard. OpenChain is an international standard for open source programs, helping companies create compliant processes. But what does OpenChain mean for your OSPO?
OpenChain is about managing open source processes
The OpenChain Project is a project focused on improving open source processes in the supply chain. Many people may not realize the importance of this issue, but good processes are key to making open source code accessible, useful, and mitigating any risks that may result from compliance failures.
OpenChain works to build trust between organizations and address open source compliance issues in a systematic way. It standardizes process checks and outcomes across organizations, allowing you understand and maintain compliance throughout the entire open source supply chain.
The OpenChain specification does not specify tools to use or specific processes to follow. Instead, it addresses the foundational aspects of open source management that will lead to effective processes and compliance. For example, the first requirement of the OpenChain specification is that companies have an open source policy and that they communicate it to the people in the organization:
3.1.1 Policy
A written open source policy shall exist that governs open source license compliance of the supplied software. The policy shall be internally communicated.
Verification material(s):
- 3.1.1.1 A documented open source policy.
- 3.1.1.2 A documented procedure that makes program participants aware of the existence of the open source policy (e.g., via training, internal wiki, or other practical communication method).
Rationale:
To ensure steps are taken to create, record and make program participants aware of the existence of an open source policy. Although no requirements are provided here on what should be included in the policy, other sections may impose requirements on the policy.
Note the "Rationale." The OpenChain specification is in this fashion like ISO 9001, a familiar standard for many companies. If a company has gone through the effort of creating a policy and they actively make sure that people see it, then the policy is likely to pay appropriate attention to use of open source, compliance with licenses, and necessary legal review.
The OpenChain standard then identifies the need for processes to identify the open source used in the organization, comply with license obligations, and respond to inquiries from third parties.
OpenChain for your vendors
We recommend (and help companies implement) OpenChain for themselves. It is a structured way to make sure that all the necessary parts of your organization are participating in your open source program. But the real power in OpenChain is in its applicability to all parts of your supply chain.
Part of the difficulty of real-world open source compliance is due to the realities of global supply chains, where many companies are involved in the development of hardware, software, or both. Keeping track of these different components and ensuring compliance can be difficult, but is necessary for the successful use of open source.
The challenge of compliance in the software supply chain is not necessarily due to the complexity of open source itself, but rather the varying levels of exposure and domain knowledge among companies. The problem is that open source mistakes by second- or third-tier vendors can bubble up through your supply chain, exposing your organization to risk without your knowledge.
The typical tool for dealing with this issue is an open source compliance clause in your vendor agreements, such as:
Open Source Compliance. Each of Sellers, the Company and the Related Subsidiaries have taken commercially reasonable steps, including by implementing and enforcing commercially reasonable policies to identify and regulate the use, modification, and distribution of Open Source Software in connection with the Business, the Products and any Seller/Company Software in compliance with the applicable licenses.
This is good, and quite a bit shorter than most open source compliance clauses. But a better path is to use the OpenChain standard to define what is "commercially reasonable" for a company to do. Further, the OpenChain standard also identifies acceptable "verification materials" for each part of the standard, allowing for easy verification.
For example, the following sample clauses can be put into your vendor contracts:
OpenChain 2.1/ ISO/IEC 5230 Compliance ("OpenChain"). The Company and its Subsidiaries have implemented the OpenChain standard for open source management and can produce the verification materials for each portion of the standard on demand.
If further assurances are needed, the OpenChain project identifies third party certification authorities that can be referenced:
Verification of OpenChain Compliance. The company will have achieved and maintained OpenChain certification from a third party, and since implementation of the OpenChain standard and receipt of such certification, the Company and its Subsidiaries have complied in all materials respects with such standards and there is no pending or, to the Company’s Knowledge, threatened, audit, repeal, failure to renew or challenge to any such certifications.