Re: OpenChain for projects

Jim Hutchison


Looking back, this raises an interesting point:
How can properly identified "un-known compliance" software be distributed down-chain?
Clearly distributing out-of-governance would be undesirable, but what of merely "uncertain"?

A bit like the quality representation in GStreamer's base + "good", "bad", and "ugly" plug-ins.
If you need/use a plug-in clearly labeled as "bad" or "ugly", one is at least not blind to potential issues.

If I get code from a project without a code-of-conduct, perhaps it is too early to consider a warning. Is a deep/old project worth noting as good by age (e.g., it hasn't shown problems in >10 years)? Is it reasonable to just state what you know (e.g., packaged in an SPDX)?


Jim Hutchison

-----Original Message-----
From: openchain-bounces@... [mailto:openchain-
bounces@...] On Behalf Of Gisi, Mark
Sent: Wednesday, January 11, 2017 12:01 AM
To: Jonas Oberg <jonas@...>; openchain@...
Subject: Re: [OpenChain] OpenChain for projects

Hi Jonas,

This is great feedback. I look forward to attending your presentation in
February. It would be helpful to learn about what worked well as well as the
places to improve. By the way you can find the latest working draft for the
next version here:

We are heavily discussing how we can significantly improve section 5 which is
largely about contributing back. It would be of particular interest if you could
discuss your experiences working with section 5.

- Mark

-----Original Message-----
From: openchain-bounces@... [mailto:openchain-
bounces@...] On Behalf Of Jonas Oberg
Sent: Tuesday, January 10, 2017 11:35 PM
To: openchain@...
Subject: [OpenChain] OpenChain for projects

Hi everyone,

just a short note of thanks to everyone for your efforts on OpenChain. I
wanted to share with you a recent success story involving OpenChain.

A few months ago, I worked with an open source project from the transport
sector. The project was initially conceived by a municipal department but
later abandoned and taken up by a volunteer group. As they expanded the
scope of the project, they begun facing questions about the origin of the
software, it's license, and their own responsibilities towards other
contributors and users.

Working with this still largely volunteer driven open source project, I took
inspiration from the OpenChain specification and indeed, we discovered
most of the principal requirements apply equally to volunteer open source

- A documented policy for the project in relation to its software
- Awareness building of this policy (c.f. artifact 1.1.2 about training
for software staff)
- A consistent contact point
- Identfication of the FOSS compliance roles
- Release documentation to cover archiving of and preparation of the
compliance artifacts
- A contribution policy
- A process document for external contributions

As you may imagine, we went a bit lighter on the documentation side and
focused on putting reasonable practices in place. And while this is a project
which is not likely to claim OpenChain conformance, I thought it an
interesting practice to apply the OpenChain artifacts in this situation and it did
provide much needed clarity to the volunteers in the project.

At the Open Source Leadership Summit in mid February, I'll give a very short
overview of how we worked with this project to apply principal requirements
from OpenChain in a volunteer context to ensure a consistent and verifiable
management of their open source assets.


Jonas Öberg, Styrelseordförande
Morus konsult AB | jonas@...
E-mail is the fastest way to my attention

OpenChain mailing list
OpenChain mailing list

Join to automatically receive all group messages.