OpenChain for projects


Jonas Oberg <jonas@...>
 

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
projects:

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


Sincerely,

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


Mark Gisi
 

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:
https://wiki.linuxfoundation.org/_media/openchain/openchainspec-1.1.draft.pdf

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.

cheers,
- 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
projects:

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


Sincerely,

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

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


Jilayne Lovejoy <Jilayne.Lovejoy@...>
 

Agreed - thanks so much for sharing, Jonas - very cool!

I will also be at the Open Source Leadership Summit and look forward to
your talk,

Jilayne

On 1/11/17, 8:00 AM, "openchain-bounces@... on
behalf of Gisi, Mark" <openchain-bounces@... on
behalf of Mark.Gisi@...> wrote:

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:

https://wiki.linuxfoundation.org/_media/openchain/openchainspec-1.1.draft.
pdf

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.

cheers,
- 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
projects:

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


Sincerely,

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

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Dave Marr
 

Jonas, +1 in appreciation for the additional application, also we are planning to submit a talk as an "Introduction to OpenChain" session for the summit, in case you wanted to mention (and our proposed talk being accepted of course).

Thanks,
Dave

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

Agreed - thanks so much for sharing, Jonas - very cool!

I will also be at the Open Source Leadership Summit and look forward to your talk,

Jilayne

On 1/11/17, 8:00 AM, "openchain-bounces@... on behalf of Gisi, Mark" <openchain-bounces@... on behalf of Mark.Gisi@...> wrote:

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:

https://wiki.linuxfoundation.org/_media/openchain/openchainspec-1.1.draft.
pdf

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.

cheers,
- 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
projects:

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


Sincerely,

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

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Jim Hutchison
 

Hi,

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)?

Regards,

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:
https://wiki.linuxfoundation.org/_media/openchain/openchainspec-
1.1.draft.pdf

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.

cheers,
- 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
projects:

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


Sincerely,

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

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


Sami Atabani
 

Hi Jim,

Very interesting Jim and I would agree that legacy OSS does get distributed for several years and some are no longer supported/maintained but still required/used to date and we might need to consider how do we deal with this if we are uncertain and unable to find more details or clarity! If as a supplier you make a judgement what do you pass on and will you need to provide the rationale for you decision/conclusion?

Probably worth having this as an agenda point for discussion and see if we can come up with options to deal with such cases.

Thanks

Sami

-----Original Message-----
From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Hutchison, Jim
Sent: 24 January 2017 00:24
To: Gisi, Mark; Jonas Oberg; openchain@...
Subject: Re: [OpenChain] OpenChain for projects

Hi,

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)?

Regards,

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:
https://wiki.linuxfoundation.org/_media/openchain/openchainspec-
1.1.draft.pdf

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.

cheers,
- 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
projects:

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


Sincerely,

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

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Marcel Kurzmann
 

Hi,
in my point of view, there is no "uncertain". "Uncertain" would mean that you do not know the component, as there is missing information about source, status, copyrights or else. As you cannot guarantee that you have the right to use and distribute it, you cannot use it.
That leaves only two options: good or bad.
Good is: I have 100% transparency about the component and know that I have the right to use, change and distribute it.
Bad is: all the rest

I like this discussion nevertheless, because it hits the nail on the head.
In the long run, there is no alternative but having an OpenChain standard end-to-end. A huge "Continuous Improvement Program".
And if you have legacy code with "uncertainties", the one who finds it, needs to resolve it (or at least mark it). This is a real invest.
If you want to avoid the maintenance of "private" internal patch branches, you need the ability to contribute the changes back to the original open source project.
But if this project was not maintained for several years, this might be a challenge.

You could tell the developers to avoid such FOSS-components, but that's only possible for "direct dependencies".
In case of "transitive dependencies", you need the ability to contribute to the used open source project to fix the dependency (e.g. update to a newer - cleared - version).
But again - if this project was not maintained for several years, this might be a challenge.

If the beginning of the "chain" (the original Open Source Project) didn't adhere to the Open Chain Standard and thus important metadata is missing (non-functional requirements not fulfilled), someone needs to fix this "bug".
It would be great, if not everyone needs to do this on his own, but if the community could collaborate on this and share the results (E.g. a central meta-database, where you can share the information, that an old - formerly "ugly" - OSS-component was cleared - kind of "Quality Check").


Mit freundlichen Grüßen / Best regards

Marcel Kurzmann

Open Source Officer
Bosch Software Innovations GmbH
Quality Management (INST/QMM)
Ziegelei 7
88090 Immenstaad
GERMANY
www.bosch-si.de

Tel. +49 7545 202-279
Fax +49 7545 202-301
marcel.kurzmann@...

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing.Rainer Kallenbach, Michael Hahn






-----Ursprüngliche Nachricht-----
Von: openchain-bounces@... [mailto:openchain-bounces@...] Im Auftrag von Hutchison, Jim
Gesendet: Dienstag, 24. Januar 2017 01:24
An: Gisi, Mark <Mark.Gisi@...>; Jonas Oberg <jonas@...>; openchain@...
Betreff: Re: [OpenChain] OpenChain for projects

Hi,

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)?

Regards,

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:
https://wiki.linuxfoundation.org/_media/openchain/openchainspec-
1.1.draft.pdf

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.

cheers,
- 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
projects:

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


Sincerely,

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

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


Jeremiah Foster <jeremiah.foster@...>
 

Hi,

One approach that safety-critical software takes in determining compliance is "compliant non-compliance". This approach essentially does a gap analysis between a project with a compliant certification and a non-compliant project. If, for example, the project was using something like the best practices badge (https://bestpractices.coreinfrastructure.org/) then one might assume that the gap with OpenChain is small. In other cases, due diligence ought to be performed. But this due diligence is a matter of course I've found when looking for appropriate, compliant software to fill a specific need. 

In fact, I've found this need so pervasive that I've created a document that I use and I've distributed in GENIVI that provides a simple way to rank open source projects to get an idea of whether they'd make it through a compliance process along the lines of OpenChain. I've attached it to this email and am happy for feedback. It may not necessarily fit the OpenChain approach but I think that it points to a path that may allow one a degree of certainty with software that is no longer in OpenChain compliance or which may never have gone through it.

Cheers,

Jeremiah

On Tue, Jan 24, 2017 at 3:51 AM, Sami Atabani <Sami.Atabani@...> wrote:
Hi Jim,

Very interesting Jim and I would agree that legacy OSS does get distributed for several years and some are no longer supported/maintained but still required/used to date and we might need to consider how do we deal with this if we are uncertain and unable to find more details or clarity! If as a supplier you make a judgement what do you pass on and will you need to provide the rationale for you decision/conclusion?

Probably worth having this as an agenda point for discussion and see if we can come up with options to deal with such cases.

Thanks

Sami

-----Original Message-----
From: openchain-bounces@lists.linuxfoundation.org [mailto:openchain-bounces@lists.linuxfoundation.org] On Behalf Of Hutchison, Jim
Sent: 24 January 2017 00:24
To: Gisi, Mark; Jonas Oberg; openchain@lists.linuxfoundation.org
Subject: Re: [OpenChain] OpenChain for projects

Hi,

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)?

Regards,

Jim Hutchison

> -----Original Message-----
> From: openchain-bounces@lists.linuxfoundation.org [mailto:openchain-
> bounces@....org] On Behalf Of Gisi, Mark
> Sent: Wednesday, January 11, 2017 12:01 AM
> To: Jonas Oberg <jonas@...>; openchain@lists.linuxfoundation.org
> 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:
>     https://wiki.linuxfoundation.org/_media/openchain/openchainspec-
> 1.1.draft.pdf
>
>  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.
>
> cheers,
> - Mark
>
> -----Original Message-----
> From: openchain-bounces@lists.linuxfoundation.org [mailto:openchain-
> bounces@....org] On Behalf Of Jonas Oberg
> Sent: Tuesday, January 10, 2017 11:35 PM
> To: openchain@lists.linuxfoundation.org
> 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
> projects:
>
>  - 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.
>
>
> Sincerely,
>
> --
> Jonas Öberg, Styrelseordförande
> Morus konsult AB | jonas@...
> E-mail is the fastest way to my attention
>


--
Jeremiah C. Foster
GENIVI COMMUNITY MANAGER

Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18
Gothenburg, Sweden
M: +1.860.772.9242


Jeremiah Foster <jeremiah.foster@...>
 



On Tue, Jan 24, 2017 at 9:33 AM, Kurzmann Marcel (INST/QMM) <Marcel.Kurzmann@...> wrote:
Hi,
in my point of view, there is no "uncertain". "Uncertain" would mean that you do not know the component, as there is missing information about source, status, copyrights or else. As you cannot guarantee that you have the right to use and distribute it, you cannot use it.
That leaves only two options: good or bad.
Good is: I have 100% transparency about the component and know that I have the right to use, change and distribute it.
Bad is: all the rest

I like this discussion nevertheless, because it hits the nail on the head.
In the long run, there is no alternative but having an OpenChain standard end-to-end. A huge "Continuous Improvement Program".
And if you have legacy code with "uncertainties", the one who finds it, needs to resolve it (or at least mark it). This is a real invest.
If you want to avoid the maintenance of "private" internal patch branches, you need the ability to contribute the changes back to the original open source project.
But if this project was not maintained for several years, this might be a challenge.

​This is a key point! In fact, it almost always is a very big challenge, and that challenge is getting bigger. Look at the astonishing pace of Linux kernel development. If you are not working against the latest mainline or supported LTS, you are going to have a lot of work porting your software. The same is true of other large projects, like Qt or GTK+. This points to the way that OpenChain is pushing folks to follow best practices in software development as well as license compliance and I think OpenChain ought to be aware of that implication. Many industries are not necessarily submerged in modern open source development practices like DevOps or Continuous Improvement and becoming software companies and not just hardware or service companies can be a challenge.​
 
​Regards,

Jeremiah​



You could tell the developers to avoid such FOSS-components, but that's only possible for "direct dependencies".
In case of "transitive dependencies", you need the ability to contribute to the used open source project to fix the dependency (e.g. update to a newer - cleared - version).
But again - if this project was not maintained for several years, this might be a challenge.

If the beginning of the "chain" (the original Open Source Project) didn't adhere to the Open Chain Standard and thus important metadata is missing (non-functional requirements not fulfilled), someone needs to fix this "bug".
It would be great, if not everyone needs to do this on his own, but if the community could collaborate on this and share the results (E.g. a central meta-database, where you can share the information, that an old - formerly "ugly" - OSS-component was cleared - kind of "Quality Check").


Mit freundlichen Grüßen / Best regards

Marcel Kurzmann

Open Source Officer
Bosch Software Innovations GmbH
Quality Management (INST/QMM)
Ziegelei 7
88090 Immenstaad
GERMANY
www.bosch-si.de

Tel. +49 7545 202-279
Fax +49 7545 202-301
marcel.kurzmann@...

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing.Rainer Kallenbach, Michael Hahn






-----Ursprüngliche Nachricht-----
Von: openchain-bounces@lists.linuxfoundation.org [mailto:openchain-bounces@lists.linuxfoundation.org] Im Auftrag von Hutchison, Jim
Gesendet: Dienstag, 24. Januar 2017 01:24
An: Gisi, Mark <Mark.Gisi@...>; Jonas Oberg <jonas@...>; openchain@lists.linuxfoundation.org
Betreff: Re: [OpenChain] OpenChain for projects

Hi,

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)?

Regards,

Jim Hutchison

> -----Original Message-----
> From: openchain-bounces@lists.linuxfoundation.org [mailto:openchain-
> bounces@....org] On Behalf Of Gisi, Mark
> Sent: Wednesday, January 11, 2017 12:01 AM
> To: Jonas Oberg <jonas@...>; openchain@lists.linuxfoundation.org
> 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:
>     https://wiki.linuxfoundation.org/_media/openchain/openchainspec-
> 1.1.draft.pdf
>
>  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.
>
> cheers,
> - Mark
>
> -----Original Message-----
> From: openchain-bounces@lists.linuxfoundation.org [mailto:openchain-
> bounces@....org] On Behalf Of Jonas Oberg
> Sent: Tuesday, January 10, 2017 11:35 PM
> To: openchain@lists.linuxfoundation.org
> 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
> projects:
>
>  - 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.
>
>
> Sincerely,
>
> --
> Jonas Öberg, Styrelseordförande
> Morus konsult AB | jonas@...
> E-mail is the fastest way to my attention
>
> _______________________________________________
> OpenChain mailing list
> OpenChain@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/openchain
> _______________________________________________
> OpenChain mailing list
> OpenChain@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/openchain



--
Jeremiah C. Foster
GENIVI COMMUNITY MANAGER

Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18
Gothenburg, Sweden
M: +1.860.772.9242


Steve Cropper
 

Couldn't agree more. I have just been looking at T&Q implications as part of the PLM ( formal Supply Chain SQA step which has plenty of rigor associated with it to address catastrophic failure of HW fit for purpose etc.).

In a Supply Chain context you don't put a pet on a Product that is not fit for purpose. You never open up a computer, for example, and point to a component and say "I'm not sure where I got this component", or "I don't know what it does", or "I don't know what who to go to when it breaks or how to fix it" etc. You get the point.

The same should be true for ANY software embedded in your product. So the criteria should be "fit for purpose" and that has a Yes/No answer to it. You don't have a maybe or not sure option :-).

Steve
Steve Cropper
+33 (0)6 68 22 42 49

On Jan 24, 2017, at 6:33 AM, Kurzmann Marcel (INST/QMM) <Marcel.Kurzmann@...> wrote:

Hi,
in my point of view, there is no "uncertain". "Uncertain" would mean that you do not know the component, as there is missing information about source, status, copyrights or else. As you cannot guarantee that you have the right to use and distribute it, you cannot use it.
That leaves only two options: good or bad.
Good is: I have 100% transparency about the component and know that I have the right to use, change and distribute it.
Bad is: all the rest

I like this discussion nevertheless, because it hits the nail on the head.
In the long run, there is no alternative but having an OpenChain standard end-to-end. A huge "Continuous Improvement Program".
And if you have legacy code with "uncertainties", the one who finds it, needs to resolve it (or at least mark it). This is a real invest.
If you want to avoid the maintenance of "private" internal patch branches, you need the ability to contribute the changes back to the original open source project.
But if this project was not maintained for several years, this might be a challenge.

You could tell the developers to avoid such FOSS-components, but that's only possible for "direct dependencies".
In case of "transitive dependencies", you need the ability to contribute to the used open source project to fix the dependency (e.g. update to a newer - cleared - version).
But again - if this project was not maintained for several years, this might be a challenge.

If the beginning of the "chain" (the original Open Source Project) didn't adhere to the Open Chain Standard and thus important metadata is missing (non-functional requirements not fulfilled), someone needs to fix this "bug".
It would be great, if not everyone needs to do this on his own, but if the community could collaborate on this and share the results (E.g. a central meta-database, where you can share the information, that an old - formerly "ugly" - OSS-component was cleared - kind of "Quality Check").


Mit freundlichen Grüßen / Best regards

Marcel Kurzmann

Open Source Officer
Bosch Software Innovations GmbH
Quality Management (INST/QMM)
Ziegelei 7
88090 Immenstaad
GERMANY
www.bosch-si.de

Tel. +49 7545 202-279
Fax +49 7545 202-301
marcel.kurzmann@...

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing.Rainer Kallenbach, Michael Hahn






-----Ursprüngliche Nachricht-----
Von: openchain-bounces@... [mailto:openchain-bounces@...] Im Auftrag von Hutchison, Jim
Gesendet: Dienstag, 24. Januar 2017 01:24
An: Gisi, Mark <Mark.Gisi@...>; Jonas Oberg <jonas@...>; openchain@...
Betreff: Re: [OpenChain] OpenChain for projects

Hi,

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)?

Regards,

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:
https://wiki.linuxfoundation.org/_media/openchain/openchainspec-
1.1.draft.pdf

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.

cheers,
- 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
projects:

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


Sincerely,

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

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


Jilayne Lovejoy <Jilayne.Lovejoy@...>
 

Just to highlight something Jim first touched upon and the subsequent
comments on knowing provenance, but also dealing with the reality of
uncertainty: If upstream projects generated SPDX docs or at least, were
diligent about putting license information in a format that makes it easy
to compile into an SPDX document (e.g., using SPDX license identifiers in
each source file, as recommended in Appendix V of the SPDX spec, v2.1 -
https://spdx.org/spdx-specification-21-web-version#h.twlc0ztnng3b) then
some of the issues that come up later downstream would be resolved.
Likewise, if upstream project didn’t do this, but companies downstream do
this diligence (which we all know, many of us spend a fair amount of
effort doing so) generated an SPDX document, and then made that publicly
available… well, that would help.

Also, for those of you who are not intimately familiar with the SPDX
specification, there is a different field for the license information that
is actually found/exists in a file or package and the “concluded license”.
This was critical, because of the many files that have no license info at
all, in which case you might “conclude” that the license is the same as
the declared package license; and, another common example, many files that
have some kind of license notice, which is not concise or clear. In these
cases, you could conclude what you think the license is and then make a
comment in the comment section as to why/how you reached this conclusion.
If I understand the comments correctly, this might be considered software
of a “uncertain” licensing - so long as you can articulate what is
uncertain and how you came to the conclusion, I think that’s the best we
can do.

But maybe I’ve missed the point here?

As for using OpenChain requirements for open source projects - I’m very
excited to hear Jonas’ talk and second Mark’s encouragement that this
could provide useful input for Goal 5. But I think it should be clear
that the requirements of OpenChain were not written with an open source
project in mind, I think CII badging has that covered, but for software
vendors in the supply chain. And while there are commonalties, it’s
probably good to remember that, no?

Jilayne

On 1/24/17, 9:21 AM, "openchain-bounces@... on
behalf of Steve Cropper" <openchain-bounces@... on
behalf of stcroppe@...> wrote:

Couldn't agree more. I have just been looking at T&Q implications as part
of the PLM ( formal Supply Chain SQA step which has plenty of rigor
associated with it to address catastrophic failure of HW fit for purpose
etc.).

In a Supply Chain context you don't put a pet on a Product that is not
fit for purpose. You never open up a computer, for example, and point to
a component and say "I'm not sure where I got this component", or "I
don't know what it does", or "I don't know what who to go to when it
breaks or how to fix it" etc. You get the point.

The same should be true for ANY software embedded in your product. So the
criteria should be "fit for purpose" and that has a Yes/No answer to it.
You don't have a maybe or not sure option :-).

Steve




Sent from my iPhone
Steve Cropper
+33 (0)6 68 22 42 49


On Jan 24, 2017, at 6:33 AM, Kurzmann Marcel (INST/QMM)
<Marcel.Kurzmann@...> wrote:

Hi,
in my point of view, there is no "uncertain". "Uncertain" would mean
that you do not know the component, as there is missing information
about source, status, copyrights or else. As you cannot guarantee that
you have the right to use and distribute it, you cannot use it.
That leaves only two options: good or bad.
Good is: I have 100% transparency about the component and know that I
have the right to use, change and distribute it.
Bad is: all the rest

I like this discussion nevertheless, because it hits the nail on the
head.
In the long run, there is no alternative but having an OpenChain
standard end-to-end. A huge "Continuous Improvement Program".
And if you have legacy code with "uncertainties", the one who finds it,
needs to resolve it (or at least mark it). This is a real invest.
If you want to avoid the maintenance of "private" internal patch
branches, you need the ability to contribute the changes back to the
original open source project.
But if this project was not maintained for several years, this might be
a challenge.

You could tell the developers to avoid such FOSS-components, but that's
only possible for "direct dependencies".
In case of "transitive dependencies", you need the ability to
contribute to the used open source project to fix the dependency (e.g.
update to a newer - cleared - version).
But again - if this project was not maintained for several years, this
might be a challenge.

If the beginning of the "chain" (the original Open Source Project)
didn't adhere to the Open Chain Standard and thus important metadata is
missing (non-functional requirements not fulfilled), someone needs to
fix this "bug".
It would be great, if not everyone needs to do this on his own, but if
the community could collaborate on this and share the results (E.g. a
central meta-database, where you can share the information, that an old
- formerly "ugly" - OSS-component was cleared - kind of "Quality Check").


Mit freundlichen Grüßen / Best regards

Marcel Kurzmann

Open Source Officer
Bosch Software Innovations GmbH
Quality Management (INST/QMM)
Ziegelei 7
88090 Immenstaad
GERMANY
www.bosch-si.de

Tel. +49 7545 202-279
Fax +49 7545 202-301
marcel.kurzmann@...

Registered office: Berlin, Register court: Amtsgericht Charlottenburg,
HRB 148411 B
Executives: Dr.-Ing.Rainer Kallenbach, Michael Hahn






-----Ursprüngliche Nachricht-----
Von: openchain-bounces@...
[mailto:openchain-bounces@...] Im Auftrag von
Hutchison, Jim
Gesendet: Dienstag, 24. Januar 2017 01:24
An: Gisi, Mark <Mark.Gisi@...>; Jonas Oberg <jonas@...>;
openchain@...
Betreff: Re: [OpenChain] OpenChain for projects

Hi,

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)?

Regards,

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:
https://wiki.linuxfoundation.org/_media/openchain/openchainspec-
1.1.draft.pdf

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.

cheers,
- 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
projects:

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


Sincerely,

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

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Matija Šuklje
 

Die 25. 01. 17 et hora 19.12.09 Jilayne Lovejoy scripsit:
If upstream projects generated SPDX docs or at least, were
diligent about putting license information in a format that makes it easy
to compile into an SPDX document (e.g., using SPDX license identifiers in
each source file, as recommended in Appendix V of the SPDX spec, v2.1 -
https://spdx.org/spdx-specification-21-web-version#h.twlc0ztnng3b) then
some of the issues that come up later downstream would be resolved.
Likewise, if upstream project didn’t do this, but companies downstream do
this diligence (which we all know, many of us spend a fair amount of
effort doing so) generated an SPDX document, and then made that publicly
available… well, that would help.
This is of course very true. But it leaves open the question, how we can
motivate the upstream FOSS projects to generate the SPDX files or at the very
least properly mark the licenses of the source code (preferably with SPDX
identifiers).

I know some of us on this list, do in our private time ask (and assist)
projects to at least somewhat properly mark the licenses of their projects –
and even that is not an easy task to achieve in some cases.

One option would be intermediaries such as distributions and code repository
providers. Some distributions already do this to some extent (e.g. Debian,
Gentoo …I’m pretty sure the commercial distros as well), but 1) the data
quality still depends on the upstream, 2) I don’t think any of them distribute
the SPDX files as well (does Debian do so already?), and 3) it’s still a
humongous cost of resources, which someone has to cover.


cheers,
Matija
--
gsm: tel:+386.41.849.552
www: http://matija.suklje.name
xmpp: matija.suklje@...
sip: sip:matija_suklje@...


Jeremiah Foster <jeremiah.foster@...>
 


On Wed, Jan 25, 2017 at 2:27 PM, Matija Šuklje <matija@...> wrote:
Die 25. 01. 17 et hora 19.12.09 Jilayne Lovejoy scripsit:
> If upstream projects generated SPDX docs or at least, were
> diligent about putting license information in a format that makes it easy
> to compile into an SPDX document (e.g., using SPDX license identifiers in
> each source file, as recommended in Appendix V of the SPDX spec, v2.1 -
> https://spdx.org/spdx-specification-21-web-version#h.twlc0ztnng3b) then
> some of the issues that come up later downstream would be resolved.

​Where it's needed is in source build tools like Yocto which also is a Linux Foundation project and would benefit significantly from this type of work. This can be done with Yocto and SPDX (http://www.pelagicore.com/using-yocto-and-fossology-to-get-spdx-licence-output/) but it is very heavy weight adding a lot of time for builds which makes it hard to adopt. 
 
> Likewise, if upstream project didn’t do this, but companies downstream do
> this diligence (which we all know, many of us spend a fair amount of
> effort doing so) generated an SPDX document, and then made that publicly
> available… well, that would help.

This is of course very true. But it leaves open the question, how we can
motivate the upstream FOSS projects to generate the SPDX files or at the very
least properly mark the licenses of the source code (preferably with SPDX
identifiers).

I know some of us on this list, do in our private time ask (and assist)
projects to at least somewhat properly mark the licenses of their projects –
and even that is not an easy task to achieve in some cases.

One option would be intermediaries such as distributions and code repository
providers. Some distributions already do this to some extent (e.g. Debian,
Gentoo …I’m pretty sure the commercial distros as well), but 1) the data
quality still depends on the upstream, 2) I don’t think any of them distribute
the SPDX files as well (does Debian do so already?), and 3) it’s still a
humongous cost of resources, which someone has to cover.

​One interesting thing here is that Debian has all the metadate required already for generating SPDX files: http://dep.debian.net/deps/dep5/
All one needs is a tool to go over the metadata and create SPDX file. I think there may be a tool to do that in Debian already in fact, but if not it should be pretty easy. Then, once you can do this from Debian you'd be able to do it for the Debian derivatives (Ubuntu, Mint, etc.) which would cover a lot of the distro space. 

​Cheers,

Jeremiah​


Kate Stewart
 



On Wed, Jan 25, 2017 at 1:27 PM, Matija Šuklje <matija@...> wrote:
Die 25. 01. 17 et hora 19.12.09 Jilayne Lovejoy scripsit:
> If upstream projects generated SPDX docs or at least, were
> diligent about putting license information in a format that makes it easy
> to compile into an SPDX document (e.g., using SPDX license identifiers in
> each source file, as recommended in Appendix V of the SPDX spec, v2.1 -
> https://spdx.org/spdx-specification-21-web-version#h.twlc0ztnng3b) then
> some of the issues that come up later downstream would be resolved.
> Likewise, if upstream project didn’t do this, but companies downstream do
> this diligence (which we all know, many of us spend a fair amount of
> effort doing so) generated an SPDX document, and then made that publicly
> available… well, that would help.

This is of course very true. But it leaves open the question, how we can
motivate the upstream FOSS projects to generate the SPDX files or at the very
least properly mark the licenses of the source code (preferably with SPDX
identifiers).

First step is to make sure they have an open source freely available tool
to help them.   FOSSology generating SPDX has been a big step forward 
in the last year.  Before that there were only commercial offerings, which wouldn't
work for upstream communities.  

I know some of us on this list, do in our private time ask (and assist)
projects to at least somewhat properly mark the licenses of their projects –
and even that is not an easy task to achieve in some cases.

One option would be intermediaries such as distributions and code repository
providers. Some distributions already do this to some extent (e.g. Debian,
Gentoo …I’m pretty sure the commercial distros as well), but 1) the data
quality still depends on the upstream,

Improving the transparency about the quality of licensing in upstream projects
by providing them free tools, is a step to improve this.   They are after all the
ones that can authoritatively fix any problems that automatic scanners can't recognize.

We had a bit of a breakthrough last year when github included the SPDX identifiers
in their license API associated with projects. 
 
2) I don’t think any of them distribute
the SPDX files as well (does Debian do so already?),

Debsources stores the information to be able to generate SPDX files,
and Debian has recognized the SPDX license identifiers since the start. 

Fedora/Red Hat is contemplating (at least there have been some discussions)
on standardizing on the SPDX license identifiers but hasn't committed to doing it yet.

Yocto has been prototyping generating SPDX files for a couple of years, and 
there are new tools emerging to help this effort (ie.  see: ELC talk about LiD next
month for instance... )

and 3) it’s still a
humongous cost of resources, which someone has to cover.

Its a step by step, we add what we can to reduce the cost for everyone type of activity. 
Each contributes what they can (and scratches their own itch), and eventually we'll 
get the automation working as it should.  

Thomas and I will be talking about this topic in our FOSDEM talk.   We've
got some ideas on how to help solve this problem we'll be presenting. 
Happy to collaborate with others who have ideas on how to move this along further.   ;-)

Thanks, Kate



cheers,
Matija
--
gsm:    tel:+386.41.849.552
www:    http://matija.suklje.name
xmpp:   matija.suklje@...
sip:    sip:matija_suklje@...

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




--
Kate Stewart
Sr. Director of Strategic Programs,  The Linux Foundation
Mobile: +1.512.657.3669
Email / Google Talk: kstewart@...


Jeremiah Foster <jeremiah.foster@...>
 



On Wed, Jan 25, 2017 at 3:05 PM, Kate Stewart <kstewart@...> wrote:
>
> On Wed, Jan 25, 2017 at 1:27 PM, Matija Šuklje <matija@...> wrote:
>>
>> Die 25. 01. 17 et hora 19.12.09 Jilayne Lovejoy scripsit:

<snip>
   
>>
>> 2) I don’t think any of them distribute
>> the SPDX files as well (does Debian do so already?),
>
>
> Debsources stores the information to be able to generate SPDX files,
> and Debian has recognized the SPDX license identifiers since the start.
>
> Fedora/Red Hat is contemplating (at least there have been some discussions)
> on standardizing on the SPDX license identifiers but hasn't committed to doing it yet.
>
> Yocto has been prototyping generating SPDX files for a couple of years, and
> there are new tools emerging to help this effort (ie.  see: ELC talk about LiD next
> month for instance... )

​Is there a code repo for LiD? I don't see it via Google. It is an open source project no?​

>> and 3) it’s still a
>> humongous cost of resources, which someone has to cover.
>
>
> Its a step by step, we add what we can to reduce the cost for everyone type of activity.
> Each contributes what they can (and scratches their own itch), and eventually we'll
> get the automation working as it should.  

​+1​  Great work done so far!

> Thomas and I will be talking about this topic in our FOSDEM talk.   We've
> got some ideas on how to help solve this problem we'll be presenting.
> Happy to collaborate with others who have ideas on how to move this along further.   ;-)

​I'm still interested in having the blockchain utilized for assurance in the supply chain. I see that there are a couple of Hyperledger projects doing something similar, namely storing a hash of a document in the blockchain which I think would be useful and fairly easy to implement. ​This way each stage of the supply chain could sign the SPDX document ensuring that there is traceability to the origin.

​Cheers,

Jeremiah​



Kate Stewart
 



Hi Jeremiah,
On Wed, Jan 25, 2017 at 1:53 PM, Jeremiah Foster <jeremiah.foster@...> wrote:


​One interesting thing here is that Debian has all the metadate required already for generating SPDX files: http://dep.debian.net/deps/dep5/

DEP5 isn't quite SPDX,  its missing a few fields, but is certainly very similar to the SPDX tag:value format.   In fact,  we effectively started with DEP5 and added fields to it that the lawyers felt essential to accurately capture the information and be able to tell if a file in the project has been updated or not since the licensing information was generated.   

Debian has captured all the necessary fields though to generate SPDX files in the debsources project last year. [1]
 
All one needs is a tool to go over the metadata and create SPDX file. I think there may be a tool to do that in Debian already in fact, but if not it should be pretty easy. Then, once you can do this from Debian you'd be able to do it for the Debian derivatives (Ubuntu, Mint, etc.) which would cover a lot of the distro space. 

Agree with you,  if Debian starts generating SPDX part of builds automatically, the distros will pick it up,  esp. if their customers start asking for it (via OpenChain).   However we're going to need a proof of concept, and get FOSSology more robust interacting with the command line to make this possible.     Step by open source step.... ;-)

Kate


Kate Stewart
 



On Wed, Jan 25, 2017 at 2:18 PM, Jeremiah Foster <jeremiah.foster@...> wrote:


On Wed, Jan 25, 2017 at 3:05 PM, Kate Stewart <kstewart@...> wrote:
>
> On Wed, Jan 25, 2017 at 1:27 PM, Matija Šuklje <matija@...> wrote:
>>
>> Die 25. 01. 17 et hora 19.12.09 Jilayne Lovejoy scripsit:

<snip>
   
>>
>> 2) I don’t think any of them distribute
>> the SPDX files as well (does Debian do so already?),
>
>
> Debsources stores the information to be able to generate SPDX files,
> and Debian has recognized the SPDX license identifiers since the start.
>
> Fedora/Red Hat is contemplating (at least there have been some discussions)
> on standardizing on the SPDX license identifiers but hasn't committed to doing it yet.
>
> Yocto has been prototyping generating SPDX files for a couple of years, and
> there are new tools emerging to help this effort (ie.  see: ELC talk about LiD next
> month for instance... )

​Is there a code repo for LiD? I don't see it via Google. It is an open source project no?​

I've talked to the authors and their going through internal approvals to publish the code.
Expectation is that the source repository open before their talk.
 

>> and 3) it’s still a
>> humongous cost of resources, which someone has to cover.
>
>
> Its a step by step, we add what we can to reduce the cost for everyone type of activity.
> Each contributes what they can (and scratches their own itch), and eventually we'll
> get the automation working as it should.  

​+1​  Great work done so far!

> Thomas and I will be talking about this topic in our FOSDEM talk.   We've
> got some ideas on how to help solve this problem we'll be presenting.
> Happy to collaborate with others who have ideas on how to move this along further.   ;-)

​I'm still interested in having the blockchain utilized for assurance in the supply chain. I see that there are a couple of Hyperledger projects doing something similar, namely storing a hash of a document in the blockchain which I think would be useful and fairly easy to implement. ​This way each stage of the supply chain could sign the SPDX document ensuring that there is traceability to the origin.

Completely agree,  and Mark Gisi does too.  ;-)  His talk at OSLS is  going to be on this.    
So,  if we're all reaching this conclusion independently, it must be a good one,  now to figure out
how to make this real!

Kate


Matija Šuklje
 

Die 25. 01. 17 et hora 14.25.44 Kate Stewart scripsit:
​I'm still interested in having the blockchain utilized for assurance in
the supply chain.
[…]
Completely agree, and Mark Gisi does too. ;-) His talk at OSLS
<http://sched.co/9Khj> is going to be on this.
FWIW, as do I. There are of course issues that the blockchain as a DB brings
with it, but it is a path worth exploring. Very happy to hear others think
alike :)

Will Mark’s talk be recorded and available online?


cheers,
Matija
--
gsm: tel:+386.41.849.552
www: http://matija.suklje.name
xmpp: matija.suklje@...
sip: sip:matija_suklje@...


Matija Šuklje
 

Die 25. 01. 17 et hora 14.05.59 Kate Stewart scripsit:
First step is to make sure they have an open source freely available tool
to help them. FOSSology generating SPDX has been a big step forward
in the last year.
Indeed and kudos to the whole FOSSology team for that!

Improving the transparency about the quality of licensing in upstream
projects
by providing them free tools, is a step to improve this. They are after
all the
ones that can authoritatively fix any problems that automatic scanners
can't recognize.
Exactly.

Debsources stores the information to be able to generate SPDX files,
and Debian has recognized the SPDX license identifiers since the start.
Agreed.

And great to hear such news about Fedora/RH and Yocto!

and 3) it’s still a
humongous cost of resources, which someone has to cover.
Its a step by step, we add what we can to reduce the cost for everyone type
of activity.
Each contributes what they can (and scratches their own itch), and
eventually we'll
get the automation working as it should.
It’s not an unsolvable issue. But as you state yourself, it is one where we
have to collaborate and cooperate within a wider community of stakeholders.
This group is one of the very drivers, which is why I brought it up.

Thomas and I will be talking about this topic in our FOSDEM talk
<https://fosdem.org/2017/schedule/event/license_compliance_easy/>. We've
got some ideas on how to help solve this problem we'll be presenting.
Happy to collaborate with others who have ideas on how to move this along
further. ;-)
I saw. I hope to catch it.


cheers,
Matija
--
gsm: tel:+386.41.849.552
www: http://matija.suklje.name
xmpp: matija.suklje@...
sip: sip:matija_suklje@...


Marcel Kurzmann
 

Hi,
as I saw the following discussion about all that tooling and SPDX-format and the statement " the requirements of OpenChain were not written with an open source project in mind", let's take a step back.
In my point of view the Open Source World changed heavily in the last years as more and more companies using OSS and even start to contribute. Simplified, you could divide the Open Source Communities in at least two sections:
1st section: Open Source Communities that develop for their fun (main contributors: hobbyist, students, etc.)
2nd section: Open Source Communities that develop core functionality for the leading-edge technology (main contributors: SW-professionals, often paid by their companies + hobbyists, students, etc.)
Most interesting projects are probably starting in section 1 and the going to section 2.

The OSS Components of section 2 replace proprietary SW components in the companies. For those formerly proprietary SW components there are high quality standards - for functional requirements as well as for non-functional requirements.
For the functional requirements you probably cannot expect, that an Open Source Community is performing 100% coverage tests and integration tests for every use case you can think of etc. (even if that would be nice).
But for the non-functional requirements, I think it should be feasible to motivate everyone in the chain to adhere at least to a standard like Open Chain.

I think tooling is necessary for enabling, but in my point of view, the Open Source Projects need an incentive to use them. Otherwise it will always hit the next one down the chain.
For the Open Source Communities in section 2, the incentive is "compliance" driven by the SW-companies who want to use the OSS Components. There is no real choice, it must be done.
But for FOSS Communities in section 1, they would probably not care about this, as they do it for fun. Nevertheless they care about clean code, unwritten policies etc. not to disgrace themselves for bad programming.
If we can establish the Open Chain standard as a "must-have" for OSS Projects who have the ambition to spread their Components all over the internet, the OSS projects would probably try by themselves to reach that standard (Pull instead of Push).

Thus, if some of us start to request an "Open Chain stamp" (good) as acceptance criteria for Open Source Components in our companies or at least degrading the components that do not have this "stamp" (bad or ugly), this could start a "chain"-reaction. :-)

Mit freundlichen Grüßen / Best regards

Marcel Kurzmann
INST/QMM-Open Source Officer

Tel. +49 7545 202-279
Fax. +49 7545 202-301
Mobil +49 172 1499942


-----Ursprüngliche Nachricht-----
Von: Jilayne Lovejoy [mailto:Jilayne.Lovejoy@...]
Gesendet: Mittwoch, 25. Januar 2017 20:12
An: Steve Cropper <stcroppe@...>; Kurzmann Marcel (INST/QMM) <Marcel.Kurzmann@...>
Cc: openchain@...
Betreff: Re: [OpenChain] OpenChain for projects

Just to highlight something Jim first touched upon and the subsequent comments on knowing provenance, but also dealing with the reality of
uncertainty: If upstream projects generated SPDX docs or at least, were diligent about putting license information in a format that makes it easy to compile into an SPDX document (e.g., using SPDX license identifiers in each source file, as recommended in Appendix V of the SPDX spec, v2.1 -
https://spdx.org/spdx-specification-21-web-version#h.twlc0ztnng3b) then some of the issues that come up later downstream would be resolved.
Likewise, if upstream project didn’t do this, but companies downstream do this diligence (which we all know, many of us spend a fair amount of effort doing so) generated an SPDX document, and then made that publicly available… well, that would help.

Also, for those of you who are not intimately familiar with the SPDX specification, there is a different field for the license information that is actually found/exists in a file or package and the “concluded license”.
This was critical, because of the many files that have no license info at all, in which case you might “conclude” that the license is the same as the declared package license; and, another common example, many files that have some kind of license notice, which is not concise or clear. In these cases, you could conclude what you think the license is and then make a comment in the comment section as to why/how you reached this conclusion.
If I understand the comments correctly, this might be considered software of a “uncertain” licensing - so long as you can articulate what is uncertain and how you came to the conclusion, I think that’s the best we can do.

But maybe I’ve missed the point here?

As for using OpenChain requirements for open source projects - I’m very excited to hear Jonas’ talk and second Mark’s encouragement that this could provide useful input for Goal 5. But I think it should be clear that the requirements of OpenChain were not written with an open source project in mind, I think CII badging has that covered, but for software vendors in the supply chain. And while there are commonalties, it’s probably good to remember that, no?

Jilayne

On 1/24/17, 9:21 AM, "openchain-bounces@... on behalf of Steve Cropper" <openchain-bounces@... on behalf of stcroppe@...> wrote:

Couldn't agree more. I have just been looking at T&Q implications as
part of the PLM ( formal Supply Chain SQA step which has plenty of
rigor associated with it to address catastrophic failure of HW fit for
purpose etc.).

In a Supply Chain context you don't put a pet on a Product that is not
fit for purpose. You never open up a computer, for example, and point
to a component and say "I'm not sure where I got this component", or "I
don't know what it does", or "I don't know what who to go to when it
breaks or how to fix it" etc. You get the point.

The same should be true for ANY software embedded in your product. So
the criteria should be "fit for purpose" and that has a Yes/No answer to it.
You don't have a maybe or not sure option :-).

Steve




Sent from my iPhone
Steve Cropper
+33 (0)6 68 22 42 49


On Jan 24, 2017, at 6:33 AM, Kurzmann Marcel (INST/QMM)
<Marcel.Kurzmann@...> wrote:

Hi,
in my point of view, there is no "uncertain". "Uncertain" would mean
that you do not know the component, as there is missing information
about source, status, copyrights or else. As you cannot guarantee that
you have the right to use and distribute it, you cannot use it.
That leaves only two options: good or bad.
Good is: I have 100% transparency about the component and know that I
have the right to use, change and distribute it.
Bad is: all the rest

I like this discussion nevertheless, because it hits the nail on the
head.
In the long run, there is no alternative but having an OpenChain
standard end-to-end. A huge "Continuous Improvement Program".
And if you have legacy code with "uncertainties", the one who finds
it, needs to resolve it (or at least mark it). This is a real invest.
If you want to avoid the maintenance of "private" internal patch
branches, you need the ability to contribute the changes back to the
original open source project.
But if this project was not maintained for several years, this might
be a challenge.

You could tell the developers to avoid such FOSS-components, but
that's only possible for "direct dependencies".
In case of "transitive dependencies", you need the ability to
contribute to the used open source project to fix the dependency (e.g.
update to a newer - cleared - version).
But again - if this project was not maintained for several years,
this might be a challenge.

If the beginning of the "chain" (the original Open Source Project)
didn't adhere to the Open Chain Standard and thus important metadata
is missing (non-functional requirements not fulfilled), someone needs
to fix this "bug".
It would be great, if not everyone needs to do this on his own, but
if the community could collaborate on this and share the results (E.g.
a central meta-database, where you can share the information, that an
old
- formerly "ugly" - OSS-component was cleared - kind of "Quality Check").


Mit freundlichen Grüßen / Best regards

Marcel Kurzmann

Open Source Officer
Bosch Software Innovations GmbH
Quality Management (INST/QMM)
Ziegelei 7
88090 Immenstaad
GERMANY
www.bosch-si.de

Tel. +49 7545 202-279
Fax +49 7545 202-301
marcel.kurzmann@...

Registered office: Berlin, Register court: Amtsgericht
Charlottenburg, HRB 148411 B
Executives: Dr.-Ing.Rainer Kallenbach, Michael Hahn






-----Ursprüngliche Nachricht-----
Von: openchain-bounces@...
[mailto:openchain-bounces@...] Im Auftrag von
Hutchison, Jim
Gesendet: Dienstag, 24. Januar 2017 01:24
An: Gisi, Mark <Mark.Gisi@...>; Jonas Oberg
<jonas@...>; openchain@...
Betreff: Re: [OpenChain] OpenChain for projects

Hi,

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)?

Regards,

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:
https://wiki.linuxfoundation.org/_media/openchain/openchainspec-
1.1.draft.pdf

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.

cheers,
- 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
projects:

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


Sincerely,

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

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.