Re: OpenChain meeting today
Shane Martin Coughlan <shane@...>
On 2016 Oct 19, at 7:39, Jeremiah Foster <email@example.com> wrote:As Mark and Dave said, at this juncture the idea is to discuss whether a modular architecture approach for OpenChain makes sense, and what may be included in a series of experimental modules that may later graduate to extensions of OpenChain for areas beyond compliance. Contribution processes, Security processes, Export Compliance and ISO 26262 (functional safety) were all included as possible avenues in our discussion of experimental modules.
I believe it is important to stress that we are not talking about "trying to justify an additional field in the already verbose SPDX output that might hold a hash to a CVE database entry.” As you correctly pointed out, security and compliance teams (and export or development teams) often operate separately inside organizations. However, I would equally stress that SPDX and OpenChain are two different things. OpenChain has had a wider scope from inception. More specifically, SPDX is a standard format for communicating the components, licenses and copyrights associated with software packages. Meanwhile, OpenChain’s mission is to establish requirements to achieve effective management of free/open source software (FOSS) for software supply chain participants.
In OpenChain we are always trying to describe the minimal process required to accomplish a goal around Open Source. In the first instance, we have created a specification describing the minimal process required for what is necessary for due diligence around compliance. Any extensions to OpenChain (or experimental modules that might take a later life of their own) would follow a similar pattern. When talking about security, the idea would not to be to attempt to describe a Software Development Security Domain (ref: http://resources.infosecinstitute.com/cissp-2015-update-software-development-security/) but rather to talk about the type of minimal process required to address security vulnerabilities around Open Source Software (ref:
By the same thinking, any extensions to address Export Compliance focused on cryptography or ISO 26262 would not be intended to replace or compete with existing standards, but rather to describe the minimal set of processes we would expect to see around companies deploying Open Source software in these contexts. Anyone adhering to existing standards and best practices would essentially already surpass the minimal requirements laid out. As always, the real goal is to make sure that even the smallest stakeholder in Open Source can introduce or complex with the type of best practices that the largest and most experienced entities have access to, and in the process we gradually transform the global supply chain.
In conclusion, the question is really whether we explore processes beyond compliance. The consensus at our face-to-face was that such further development should not be part of the core specification, but may be worthwhile as extensions. This is not a firm decision that OpenChain should go beyond license compliance. We may come to consensus that OpenChain as a process specification should remain compliance-only and we would cease work on any extensions after a period of experimentation or - as Jonas referenced - such experimental modules may take on a life of their own as another process specification for minimal adherence to requirements for accomplishing other goals around Open Source.
I believe we are all on the same page:
(1) Let’s not confuse compliance with other things
(2) Let’s keep the OpenChain specification clear and focused
(3) But let’s keep an open mind regarding other ways we can make a difference around Open Source in the supply chain