Comments on OpenChain Specification

by Karen Sandler on June 6, 2016

Today I submitted comments to the OpenChain specification. OpenChain is a working group formed under the Linux Foundation by companies to collaboratively come up with standards and shared materials around compliance. As community-oriented GPL enforcers, we applaud efforts to improve compliance and have been following the effort with interest to the extent we can with our limited resources. The working group recently put out a public call for comment on the OpenChain specification, which is open until June 17. We encourage people to take a look, perhaps echo our comments if they agree, and even join the calls if they are interested (there's a call today).

Here are the comments I submitted:

I think text should be added in the introductory section about the value of compliance, generally. Perhaps something like: Complying with the terms of the free and open source licenses used in industry is not only important for minimizing risk to individual companies, but is also a necessary step towards the preservation, collaboration and improvement of the software infrastructure we all rely on.
Text should also be added to clarify that completely following the spec does not guarantee full compliance and that the (obvious) intention is that companies need to tailor the guidelines to their own procedures. I think this would fit well in the second to last paragraph on page 3 and perhaps should also be added to G6.1.
In the definitions, I think the term OpenChain Compliant is confusing, and can be fixed by using a term other than compliant. We don't want people to think that following these recommendations is any attestation as to actual compliance (though of course I agree that they will help if followed fully). Calling it OpenChain Conforming or OpenChain Accordant would work, for example.
G4.1 should refer to complete and corresponding source code instead of just source code.
Also in G4.1, a bullet point should be added saying scripts used to control compilation and installation, as per GPLv2 Section 3 and GPLv3 Section 1 (we may also want to include some reference to this in G3.2, along with a reference to complete and corresponding source code as well). Even though scripts are included in CCS under GPL I think it makes sense to give this its own bullet point to highlight the requirement which is sometimes overlooked. GPLv2 and GPLv3 ensure not only that users receive software freedom in the abstract, but have the technically necessary information to make practical use of those freedoms. Ability to rebuild the binaries from source code, and knowing that everything necessary to produce the binary are present is what matters most in copyleft compliance (this is why, for example, copyleft and security go hand in hand).
In G5.2, it may be appropriate to recommend considering a Code of Conduct for a company's participation in any community (right now the language is weak anyway and says might include). This is becoming increasingly common in companies, as I understand it, as a way to limit liability for inappropriate communications by employees in the public and is something they should actively consider.