[trustable-software] What's happening?

[Shane Martin Coughlan]

Hi Paul

> On Jun 20, 2017, at 23:11, Paul Sherwood <paul.sherwood at codethink.co.uk> wrote:
> On 2017-06-20 15:19, Shane Martin Coughlan wrote:
>> OpenChain Project does focus on licensing. It is about “what do we
>> need a company to do for another company to easily be able to trust it
>> in this context?”
>> SPDX covers all aspects of “what’s in this software package?”
> 
> That's a big claim :)

Ok, lots of aspects ;)

>>> So, reading up on OpenChain (in fact colleagues had already thrown it into my inbox for Codethink to consider self-certifying), I'm immediately struck by the fact that there appears to be history/provenance information on your key document, i.e. https://wiki.linuxfoundation.org/_media/openchain/openchainspec-1.1.pdf
>>> Is there any chance this could be placed as text in git, with history and provenance? I'd be extremely interested to know who originated the content, how it came to be in the shape it's in, and what the review process was.
>> The document was created mostly through the OpenChain main mailing
>> list and the OpenChain Work Team calls.
>> The mailing list is public here:
>> https://lists.linuxfoundation.org/mailman/listinfo/openchain
> 
> "(The current archive is only available to the list members.)"
> I'm happy to join, but it's unnecessary friction imo.
> I'm sure it's not the case here, but I've seen other situations where a quango of 'major companies' created a closed culture while calling it open. "Sunlight is the best disinfectant”

Anyone can join, anyone can participate. While we could make the list archive open to non-members of the list, the friction of joining appears to be a small ask. I would much prefer to see people join the list, raise a question if they have any, and begin contribution in one form or another (or simply remain plugged in).

>> The call minutes are here:
>> https://wiki.linuxfoundation.org/openchain/minutes
>> It was also possible for people to submit comments directly to the
>> Specification Work Team Chair (Mark Gisi) if they wished. Drafts of
>> the spec were reviewed via both mailing list and calls before being
>> finalized into deliverables.I defer to Mark (in CC) for specifics, but
>> I believe each edit of the document was not a key focus so much as
>> building completely and consensus that each final release (1.0, 1.1)
>> accomplished the goals we had to outline the key requirements for a
>> quality open source compliance program.
>> There is discussion in the Specification Work Team about moving to new
>> formats such as Markdown for future versions of the Specification.
>> This discussion will be continued via the mailing list and calls
>> before a decision is made by the community.
> Great. Let's hope they make the smart move :)
>> It should probably be noted that while OpenChain has nine major
>> companies involved in the Governing Board we have around 170
>> individuals on the mailing list. If I recall correctly the 1.1 version
>> of the Spec received input from circa 100 people as it iterated over
>> six months according to Mark’s final pre-release update (we release
>> 1.1 end of April).
> 
> Excellent. I still recommend that the document itself (and any other content that you are aiming to get folks to comply with or conform to) moves to text/md/yaml and gets put into git with provenance.

It has been impressive to see how the community has expanded!

I would note that the choice to use Markdown or to remain in the current workflow is with the community (i.e. everyone who participates in the Work Teams). I would hesitate to frame the selection of one format as smarter than another. Different, with different utility, absolutely. But it depends on the precise problem being solved.

While there is an argument that some parties may wish to see each and every edit of a document, it has not been a priority for OpenChain community thus far, most likely attributable to the document in question containing a specification rather than source code. The OpenChain community is focused on creating the deliverables required to address the question of how a simple, adoptable standard for open source compliance in the supply chain can be realized. The ability for a wide range of parties to engage, to submit comments, participate in the work teams and to review the drafts of the specification, curriculum etc. is vital. The details of who suggests what less so.

Regards

Shane

> 
> br
> Paul
> 
> [1] https://lists.spdx.org/pipermail/spdx-tech/2017-February/003252.html