Inside the OpenChain 1.1 specification

Reading specifications can be hard work; it's like experiencing all those hours of grim committee meetings in a single concentrated dose. In this case, though, it turns out that the entire document is a mere twelve pages long, including title page, table of contents, definitions, etc. It shouldn't take more than one extra pot of coffee to get through it, and a single beer might be enough to recover afterward. There was, in other words, little excuse for not wading in.

The introduction clarifies a crucial point that hasn't necessarily been all that well explained elsewhere: why this specification exists in the first place. It comes down to supply chains. Some companies obtain free software directly from the development repositories and distribute it to their customers, but far more of them obtain that software from some other company. There is already plenty of evidence that compliance problems up the chain can create misery for companies further downstream. If, for example, a company ships a home router running a non-compliant Linux distribution obtained from a supplier, that company may find itself facing an enforcement effort, even though the real fault can be said to be with the supplier.

Worries about being burned by suppliers in this manner have led the more aware companies to do a great deal of expensive due-diligence work on the software they receive from their suppliers. Life would be a lot easier — and cheaper — if companies knew which suppliers they could trust to have their act together with regard to compliance with free-software licenses. OpenChain is an attempt to lay down a set of rules that, if followed, will allow a company to certify itself as having a sufficient degree of competence in this area. Customers that trust a company's certification should be able to redistribute software received from that company with a relatively high degree of confidence.

OpenChain, in other words, is all about reducing costs and risks for companies dealing with free software. It is not concerned with details like keeping the development community healthy or preserving the freedoms associated with free software. But, arguably, that is the right approach to take when trying to convince corporate management to take compliance more seriously.

So what does it take for a company to be able to claim that its word can be trusted on compliance matters? The first step is for the company to actually understand what that means. To that end, the specification requires that the company have an actual, written policy on license compliance, and that this policy is communicated to its staff. It requires training every 24 months, mandatory for "all Software Staff" (defined to include contractors and marketing people), on the policy, on the "basics of intellectual property law" in this area, and the process for tracking free-software components. The Software Staff will, doubtless, be thrilled to have yet another training module to work through every two years. The specification also requires the creation of a process for reviewing the licenses for software supplied by the company.

Next, the company must assign responsibilities for compliance; these come down to two roles. There is the "FOSS Liaison", who is responsible for dealing with queries from outside the company, and there are people who are responsible for ensuring compliance within the company. The internal effort must be "sufficiently resourced", have legal expertise available when needed, and must have a written policy for the management of compliance issues. The specification does not get into the acceptable form for that policy; one assumes that the common "ignore complaints and deny the existence of a problem" model does not qualify, though.

To claim adherence to the specification, the company must have a process to review each free-software component in a product's bill of materials. It must also establish procedures for meeting the obligations associated with each license it deals with, and with each mode of distribution it employs. There needs to be a documented procedure for the creation of the "compliance artifacts" (source, license notifications, etc.) for each distributed project.

Contribution back to free-software projects is not necessarily a compliance issue, but the specification has a couple of requirements — policy-documentation requirements, not contribution requirements — in that area. The company's policy on how it contributes to projects must be documented, and a process must exist to implement that policy. The specification is clear that the policy can read "contributions to free-software projects are not allowed under any circumstances", all that matters is that the policy is written down and enforced.

Finally, the company has to affirm that it has met all of the above requirements; at that point, it can claim to be in conformance for the next 18 months. There is no form of external review to confirm a company's claims in this area, so receiving a software distribution from a company claiming OpenChain compliance will still involve a certain degree of trust. A supplier claiming that compliance will be showing a certain degree of awareness of the problem, which is a start, but down-chain companies will still have the choice of accepting the supplier's word that the specification has been followed or continuing to do its own due-diligence work.

For companies that are not steeped in the values of the free-software community, the OpenChain specification is likely to be useful as checklist documenting the things that need to be done to stay out of trouble. That, alone, is a useful contribution. Whether OpenChain succeeds in increasing supply-chain compliance and reducing costs will depend on how seriously companies take it. If down-chain companies start insisting on certification and, possibly, third-party certification, it could lead to better license compliance throughout the industry. If few companies bother, or if bogus self-certifications appear, then OpenChain will likely never gain any real relevance.