comments on OpenChain Compliance 2016-H1 Specification


Karen Sandler
 

Hi OpenChain participants!

I'm pleased to provide comments on the published draft spec (these are in large part the comments I provided informally on a working group call prior to publication).

* 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.

Thanks for making this public call for comments!

karen


Karen M. Sandler
Executive Director, Software Freedom Conservancy
__________
Become a Supporter today! http://sfconservancy.org/supporter/


Mike Linksvayer
 

+1 to all of Karen's comments.

I've been finding the double usage of compliance in this context confusing, both for people I'm talking to, and for me -- I'm not confident they get it. Conformance seems like the right word for OpenChain, but not only to remove double usage. https://www.whittingtonassociates.com/2002/06/conformity-conformance-or-compliance/ explains why ISO 9000 uses "conformity" rather than "compliance" (but not why "conformity" rather than "conformance"; latter seems adequate to me). Final paragraph:

Conformity can be viewed as internally driven, such as our voluntary, consensus-based standards. Compliance can be viewed as externally imposed. So, we should use conformity, not conformance or compliance, when referring to fulfilling product and process requirements. Of course, if customers impose conformity to ISO 9001, your organization may feel like it has to comply rather than conform.

Conform[ance] seems right for OpenChain, compliance for open source licenses.

Mike

On Mon, Jun 6, 2016 at 4:57 AM, Karen Sandler <karen@...> wrote:
Hi OpenChain participants!

I'm pleased to provide comments on the published draft spec (these are in large part the comments I provided informally on a working group call prior to publication).

* 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.

Thanks for making this public call for comments!

karen


Karen M. Sandler
Executive Director, Software Freedom Conservancy
__________
Become a Supporter today! http://sfconservancy.org/supporter/



_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Karen Sandler
 

On 2016-06-20 19:03, Mike Linksvayer wrote:
+1 to all of Karen's comments.
I've been finding the double usage of compliance in this context
confusing, both for people I'm talking to, and for me -- I'm not
confident they get it. Conformance seems like the right word for
OpenChain, but not only to remove double
usage. https://www.whittingtonassociates.com/2002/06/conformity-conformance-or-compliance/
[3] explains why ISO 9000 uses "conformity" rather than "compliance"
(but not why "conformity" rather than "conformance"; latter seems
adequate to me). Final paragraph:
_Conformity_ can be viewed as internally driven, such as our
voluntary, consensus-based standards. _Compliance_ can be viewed as
externally imposed. So, we should use _conformity_, not conformance or
compliance, when referring to fulfilling product and process
requirements. Of course, if customers impose conformity to ISO 9001,
your organization may feel like it has to _comply_ rather
than _conform_.
Conform[ance] seems right for OpenChain, compliance for open source licenses.
Reviewing the FAQ, I think it all looks even more confusing with the double meaning of the term compliance. For example:

"Does all software in an organization need to be covered by an OpenChain Compliance program to achieve program compliance?"

karen


J Lovejoy
 

I think we decided on the call today to use "conformance" and "conforms to" in the spec so the FAQs will need to also be updated to reflect that change. 

Sent from my phone, please excuse my brevity

On Jun 20, 2016, at 7:11 PM, Karen Sandler <karen@...> wrote:

On 2016-06-20 19:03, Mike Linksvayer wrote:
+1 to all of Karen's comments.
I've been finding the double usage of compliance in this context
confusing, both for people I'm talking to, and for me -- I'm not
confident they get it. Conformance seems like the right word for
OpenChain, but not only to remove double
usage. https://www.whittingtonassociates.com/2002/06/conformity-conformance-or-compliance/
[3] explains why ISO 9000 uses "conformity" rather than "compliance"
(but not why "conformity" rather than "conformance"; latter seems
adequate to me). Final paragraph:
_Conformity_ can be viewed as internally driven, such as our
voluntary, consensus-based standards. _Compliance_ can be viewed as
externally imposed. So, we should use _conformity_, not conformance or
compliance, when referring to fulfilling product and process
requirements. Of course, if customers impose conformity to ISO 9001,
your organization may feel like it has to _comply_ rather
than _conform_.
Conform[ance] seems right for OpenChain, compliance for open source licenses.

Reviewing the FAQ, I think it all looks even more confusing with the double meaning of the term compliance. For example:

"Does all software in an organization need to be covered by an OpenChain Compliance program to achieve program compliance?"

karen


_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Till Jaeger
 

Hi all,

I know it is not very well received starting comments after (most of) the
work is done. I apologize for having reviewed the Specification so late.

I'm very happy with the current draft but I have one major issue for
consideration (in this or a later version): in my experience, it is a common
problem that companies do not (properly) identify the license conditions of
the applicable licenses.

Thus, I recommend to add something in the specification like "(process for)
identifying license conditions of applicable FOSS licenses".

This could be a subsection of "Review and Approve FOSS Content" or an own
main section ("Knowing License Conditions").

What do you think?

Best regards,

Till

--
Dr. Till Jaeger
Certified Copyright and Media Law Attorney


JBB Rechtsanwälte
Jaschinski Biere Brexl Partnerschaft mbB
Christinenstraße 18/19 | 10119 Berlin
Tel. +49.30.443 765 0 | Fax +49.30.443 765 22
Sitz der Gesellschaft: Berlin | Registergericht AG Charlottenburg | PR 609 B
www.jbb.de


Mark Gisi
 

Hi Till,

You provide an excellent piece of feedback which appears to be consistent with the spec design principles. That is, it identifies an important (core) step in the compliance process that should (probably) be represented without committing to a specific method or practice for achieving it.

Although the first version of the specification has been finalized, your feedback is still timely in that we are embarking on the next revision round in September. I added your comments to the issues list for consideration.

Keep the feedback coming...

Best,
Mark

-----Original Message-----
From: openchain-bounces@lists.linuxfoundation.org [mailto:openchain-bounces@lists.linuxfoundation.org] On Behalf Of Till Jaeger
Sent: Friday, August 26, 2016 8:42 AM
To: openchain@lists.linuxfoundation.org
Subject: [OpenChain] comments on OpenChain Compliance 2016-H1 Specification

Hi all,

I know it is not very well received starting comments after (most of) the work is done. I apologize for having reviewed the Specification so late.

I'm very happy with the current draft but I have one major issue for consideration (in this or a later version): in my experience, it is a common problem that companies do not (properly) identify the license conditions of the applicable licenses.

Thus, I recommend to add something in the specification like "(process for) identifying license conditions of applicable FOSS licenses".

This could be a subsection of "Review and Approve FOSS Content" or an own main section ("Knowing License Conditions").

What do you think?

Best regards,

Till

--
Dr. Till Jaeger
Certified Copyright and Media Law Attorney


JBB Rechtsanwälte
Jaschinski Biere Brexl Partnerschaft mbB Christinenstraße 18/19 | 10119 Berlin Tel. +49.30.443 765 0 | Fax +49.30.443 765 22 Sitz der Gesellschaft: Berlin | Registergericht AG Charlottenburg | PR 609 B www.jbb.de _______________________________________________
OpenChain mailing list
OpenChain@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/openchain