Date   

Re: OpenChain specification licensing

Mark Gisi
 

Thanks Shane.

I wanted to send a png on the Specification licensing topic for 1.1 as this topic is required for translators.
The missing license was discussed at the Berlin meeting. It was decided to add CC-BY 4.0 to version 1.1. In addition to the appendix, there is already a brief mention of the license on page 2 of the version 1.1 draft. A Translation appendix was added to the spec (draft 1.1 rc5) that points one to the OpenChain website for more info.

I propose we explicitly confirm CC-BY as the license of the specification, and include
this statement on the website and the PDF for clarity.
I prefer not to update version 1.0 of the spec unless we are willing to up rev it to 1.0.1. I prefer to wait for 1.1 which is due out in March. To accommodate version 1.0 I have added a note to the OpenChain Spec webpage (and the FAQ) that specifies the license to be CC-BY 4.0.

- Mark


-----Original Message-----
From: Shane Martin Coughlan [mailto:shane@...]
Sent: Thursday, January 26, 2017 8:23 PM
To: Gisi, Mark
Cc: openchain@...
Subject: Re: OpenChain specification licensing

Dear Mark, Specification Team

I wanted to send a ping on the Specification licensing topic for 1.1 as this topic is required for translators.

Our current status is the the 1.0 PDF distribution document has no explicit license and the website makes no explicit reference to the license of the Specification. As per our previous thread on the matter, I propose we explicitly confirm CC-BY as the license of the specification, and include this statement on the website and the PDF for clarity.

I note that the 1.1 draft include a CC-BY 4.0 in an Appendix. My suggestion is to include a statement on the first page that:
“This document is licensed under the Creative Commons Attribution 4.0 International (CC-BY 4.0) license. This means you can freely use, share, improve and translate this document. Please see Appendix I for more details."

Regards

Shane

On Jan 11, 2017, at 16:57, Shane Coughlan <shane@...> wrote:

Dear all

Happy new year!

I wanted to flag that the website, specification FAQ and 1.0 specification PDF appear to be pending explicit copyright licensing information for the specification. See for example the PDF:
https://wiki.linuxfoundation.org/_media/openchain/openchainspec-1.0.pd
f This issue was flagged by a potential Japanese translation volunteer
who wanted to confirm terms.

The OpenChain curriculum has licensing information on its dedicated page and on the slides but there may be room for improvement in this area too:
https://www.openchainproject.org/curriculum

I propose that for 1.1 we seek to have an explicit licensing statement on the website landing page for all of our materials. I also propose that the specification document contains an explicit licensing statement to clarify grants with regards sharing (assumed yes), ability to translate (assumed yes) or modify (assumed no). The latter item is because the specification PDF - as with the curriculum slides - will probably be passed around extensively over time.

Regards

Shane
Original thread on specification licensing:


On Oct 24, 2016, at 0:19, Gisi, Mark <Mark.Gisi@...> wrote:

Thank you Matija and Joseph for your input on the spec licensing. We will discuss it at the next working meeting on November 7 @ 9am Pacific Standard Time (PST). All are welcome. After having a discussion and obtaining guidance from the Linux Foundation we will present the license choice and the rationale to this group.

How to Participate: For those new to the OpenChain project we meet on the first and third Monday of each month. On the first Monday we meet at 9am PST to accommodate EMEA (Europe, the Middle East and Africa) and discuss the spec and spec conformance. For the third Monday we meet at 5pm PST to accommodate Asia and discuss the spec and curriculum.

Best,
- Mark


From: openchain-bounces@...
[mailto:openchain-bounces@...] On Behalf Of
Joseph Potvin
Sent: Sunday, October 23, 2016 2:22 AM
To: openchain@...
Subject: Re: [OpenChain] What is the license of the openchain comformance specification 1.0 ?

RE: CC-BY 3.0

Should it not be updated to CC-BY 4.0?
https://creativecommons.org/licenses/by/4.0/

(BTW, Kudos to all for advancing this to v1.0, and apologies for
going from active participant at the beginning to just a quiet
observer due to workload. Wonderful to see it's now an industry
reference.)

Joseph Potvin
Operations Manager | Gestionnaire des opérations The Opman Company |
La compagnie Opman jpotvin@...
Mobile: 819-593-5983
LinkedIn

On Sat, Oct 22, 2016 at 5:02 PM, Matija Šuklje <matija@...> wrote:
Die 21. 10. 16 et hora 19.53.35 fu7mu4 scripsit:
I want to translate the specification into Japanese.
But I could not find the license of the specification.
Please tell me the license of that.
According to the standard LF’s ToS
<https://www.linuxfoundation.org/terms>
that the website seems to be under:

“Except as otherwise provided, Content on this site, including all
materials posted by the The Linux Foundation, is licensed under a
Creative Commons Attribution 3.0 License.”

As the specification’s PDF doesn’t seem to mention any other licence
I’d say it’s under CC-By 3.0.

I’d be very happy to be corrected by people who are much more involved than I.


cheers,
Matija
--
gsm: tel:+386.41.849.552
www: http://matija.suklje.name
xmpp: matija.suklje@...
sip: sip:matija_suklje@...
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


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


Re: OpenChain Specification 1.0 Korean Translation Ready

Mark Gisi
 

Hi Shane,

I agree translations are critical to growing adoption. I would like to thank Haksung for all his efforts. Translations are not a trivial task.

However we did briefly discuss recently (Berlin?) about the need for both the importance of i) having translations and ii) defining a process to ensure the integrity of a given translation. Some of the suggestions included:
o Having multiple different sources contribute to a given language translation to assurance accuracy and completeness. For example, have at least two sets of eyes to review and approve a translation before considering it to be official.

o Official translations should include a disclaimer that if there is confusion between the English version and the translated one that the English version would take precedence.

o The OpenChain project needs to create a policy doc that provides the guidelines on how translations should be perform for the various deliverables of the different working groups. The above two items are potential examples of what might go into a policy doc.

Currently there are no official translations for the specification. Translations are considered one of the next priority items for the spec but it will be taken up once i) we have a translation policy and ii) version 1.1 is released. The policy could be something as simple as a list of a half dozen or so requirements or guidelines. I will add an appendix to version 1.1 that references the OpenChain Spec webpage for additional information about the availability of official translations. This will provide the spec with the needed clarity and flexibility to add official translations as they become available.

- Mark

-----Original Message-----
From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Shane Martin Coughlan
Sent: Thursday, January 26, 2017 8:38 PM
To: openchain@...
Cc: Haksung Jang
Subject: [OpenChain] OpenChain Specification 1.0 Korean Translation Ready

Hi Mark, Specification Team

Haksung Jang from LG Electronics, who previously translated Release 1 of the OpenChain Curriculum, has completed translating the OpenChain Specification 1.0. This marks our second major contribution regarding international accessibility for the project.

Haksung's translation can be found here:
https://github.com/hakssung/openchainspec-1.0-kor
He would like some assistance in “packaging” it in the appropriate document template for release.

Haksung will next work on a translation of the OpenChain Curriculum Release 2 slides. As he mentioned in a direct mail he sees OpenChain as helping both individual companies and the broader Open Source Community. I couldn’t agree more!

Regards

Shane

--
Shane Coughlan
Opendawn
e: shane@...
p: +81 (0) 80 4035 8083
w: www.opendawn.com

Professional profile: http://www.linkedin.com/in/shanecoughlan

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


OpenChain Specification 1.0 Korean Translation Ready

Shane Martin Coughlan <shane@...>
 

Hi Mark, Specification Team

Haksung Jang from LG Electronics, who previously translated Release 1 of the OpenChain Curriculum, has completed translating the OpenChain Specification 1.0. This marks our second major contribution regarding international accessibility for the project.

Haksung's translation can be found here:
https://github.com/hakssung/openchainspec-1.0-kor
He would like some assistance in “packaging” it in the appropriate document template for release.

Haksung will next work on a translation of the OpenChain Curriculum Release 2 slides. As he mentioned in a direct mail he sees OpenChain as helping both individual companies and the broader Open Source Community. I couldn’t agree more!

Regards

Shane

--
Shane Coughlan
Opendawn
e: shane@...
p: +81 (0) 80 4035 8083
w: www.opendawn.com

Professional profile: http://www.linkedin.com/in/shanecoughlan


Re: Conformance Check Call on Monday, December 5: Summary

Shane Martin Coughlan <shane@...>
 

Hi Gary, Miriam

I noticed the Conformance FAQ is still a little light:
https://wiki.linuxfoundation.org/openchain/conformance-questions-and-answers

Can I assist with preparing for our March release of OpenChain 1.1 spec?

Regards

Shane

On Dec 9, 2016, at 9:15, Shane Coughlan <shane@...> wrote:

Thanks Gary! Just ping me when I can assist.

Shane

On 9 Dec 2016, at 08:41, <gary@...> <gary@...> wrote:

Thanks Shane for the offer for assistance on the FAQ. I hope to get a structure setup in the next couple of days and some initial FAQ’s related to the website.

Gary

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Shane Coughlan
Sent: Wednesday, December 7, 2016 6:43 PM
To: Miriam Ballhausen
Cc: openchain@...
Subject: Re: [OpenChain] Conformance Check Call on Monday, December 5: Summary

Thanks for the great overview Miriam!

Gary, if I can assist with the FAQ, please let me know.

Regards

Shane

On 8 Dec 2016, at 05:03, Miriam Ballhausen <Miriam.Ballhausen@...> wrote:

Hi all,

thanks again for the productive call on Monday. We are making good progress. Here’s a short summary of what we discussed and agreed on:

1. Validation

We agreed on an exception process, where we’ll only intervene in case of problems. Otherwise companies will be able to sign up without further validation. Reasons to intervene are mostly complaints, i.e. someone, who is on the list complains that they shouldn’t be on it; someone submits their compliance check, but isn’t put on the list and complains; someone is on the list and a third party complains that they shouldn’t be on it.

We’ll adapt the terms of use to describe the processes such complaints will entail.

2. Inbound Licensing

We’ll also adapt the terms of use to reflect that inbound material is licensed under CC0.

3. Editing

We’ll allow editing and going back to change answers. We’ll also reserve the right to remove companies from the list, if they are not compliant any more based on the answers they gave when making the changes to their previous answers. This will be clarified in the terms of use.

4. “Rejections”

If someone tries to submit a conformance check, but doesn’t succeed, as they don’t answer all the questions correctly, the feedback will not be that they were rejected. Instead we’ll tell them that they need to take further steps to achieve conformance.

5. E-mail alias

We’ll create an e-mail alias for conformance check purposes. The alias is tbd. Complaints as mentioned above can be sent to this alias as well as notifications about new companies signing up.

Please reply to me, if you want to be added to the list of recipients for this alias.

Two of those on the list will be in charge of handling incoming complaints, notifications etc. We’ll rotate monthly. Expected response time is one week. This response time will be communicated via the terms of use.

6. Artifacts

We’ll add another question to the conformance check, where companies can indicate, which artifacts they have available. Discussion will be continued offline. I will send out an e-mail to start this off.

7. Printing

Printing will not be possible. However, it will be possible to excerpt the data and pull it into a spreadsheet. The FAQs will explain how to do that.

8. FAQs

We need to create the FAQs. Gary offered to take a first go at it. Thanks Gary!

Kind regards,
Miriam

--
Dr. Miriam Ballhausen
Legal Counsel

Telefon: +49 30 200 566 205
Mobil: +49 173 38 567 56
miriam.ballhausen@...


Alte Jakobstraße 85/86,
10179 Berlin
Deutschland
Telefonzentrale +49 30 200 566 0 Fax +49 30 200 566 1

www.lumesse.de


<image001.png>


Lumesse GmbH,
Sitz der Gesellschaft: Flughafenstraße 103, 40474 Düsseldorf
Amtsgericht Düsseldorf, HRB 40857
Geschäftsführer: Dr. Carsten Busch, Michael Hunt.

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


Re: Section 5 of the Specification Draft for Version 1.1

Shane Martin Coughlan <shane@...>
 

Thank you for taking my comments and suggestions into account. Delighted to help as we move towards the March release.

Do you have a specific date in mind? I would like to sync Release 3 of the Curriculum with 1.1 of the Specification.

Regards

Shane

On Jan 26, 2017, at 17:07, Gisi, Mark <Mark.Gisi@...> wrote:

Thanks Shane for the insightful follow up to the last meeting. I will add your suggested modifications to the current draft for review and discussion at our next meeting.

Due to a lack of strong consensus on how to overall section 5 at this point, it is expected that we will largely retain much of what existed in the previous version and only make minor changes in version 1.1. Shane - your feedback is in the spirit of what I would consider minor changes. We are targeting to release version 1.1 in March.

The current draft can be found here (which is also easy to locate on both the project home page and project wiki):
https://wiki.linuxfoundation.org/_media/openchain/openchainspec-1.1.draft.pdf

- Mark


-----Original Message-----
From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Shane Martin Coughlan
Sent: Monday, January 23, 2017 6:33 PM
To: openchain@...
Subject: [OpenChain] Section 5 of the Specification Draft for Version 1.1

Hi Mark, Specification Team

Following our recent call I wanted to share some thoughts on Section 5 of the specification. These are intended to contribute to reducing any potential for confusion regarding OpenChain’s scope of "identifying and sharing the core components of a high quality Free and Open Source Software (FOSS) compliance program."

I think Section 5.1 fits well into this scope and only suggest cosmetic adjustments to make things easier for non-native speakers:

== Current Section 5.1 ==

• 5.1 A written policy exists that governs contributions to publicly accessible FOSS projects by employees on behalf of the organization where, as a minimum, it must be internally communicated.
Verification Artifact(s):
• ð 5.1.1 A documented FOSS contribution policy exists;
• ð 5.1.2 A documented procedure exists that makes all Software Staff aware of the existence of the FOSS contribution policy (e.g., via training, internal wiki, or other practical communication method).

Rationale:
Ensure an organization has given reasonable consideration to developing a policy with respect to publicly contributing to FOSS. The FOSS contribution policy can be made a part of the overall FOSS policy of an organization or be its own separate policy. In the situation where contributions are not permitted at all, a policy should exist making that position clear.

== Suggestions for Section 5.1 ==

• 5.1 A written policy exists that governs contributions to publicly accessible FOSS projects by the organization and its employees. This policy is internally communicated and may also be publicly communicated.
Verification Artifact(s):
• ð 5.1.1 A documented FOSS contribution policy exists;
• ð 5.1.2 A documented procedure exists that makes all Software Staff aware of the existence of the FOSS contribution policy (e.g., via training, internal wiki, or other practical communication method).

Rationale:
Ensure an organization has given reasonable consideration to developing a policy for public contributions to FOSS. The FOSS contribution policy can be part of the overall FOSS policy of an organization or a separate policy. In situations where contributions are not permitted a policy should exist making this position clear.
I think there is some potential for misunderstanding aspects of Section 5.2. As well as legal compliance it references business decisions, technical decisions and what may be interpreted as community norms. On the call we discussed that any potential for confusion can largely be addressed by referencing precisely what “contribution” means in the context of OpenChain. That said, there may be an opportunity for the specification language to be tightened too.

I would additionally note that the difference between considering "a project’s Code of Conduct or equivalent” and considering "adherence to project-specific contribution requirements” may be hard to understand for new participants (see 5.2 below).

Some ideas below:

== Current Section 5.2 ==

• 5.2 Provided the FOSS contribution policy permits such contributions, a process exists for confirming contributions adhere to the FOSS contribution policy, which might include (but is not limited to) the following considerations:
• § legal approval for license considerations
• § business rationale or approval
• § technical review of code to be contributed
• § community engagement and interaction, including a project’s Code of Conduct or equivalent
• § adherence to project-specific contribution requirements

Verification Artifact(s):

ð 5.2.1 Provided the FOSS contribution policy permits contributions, a documented procedure exists that describes the FOSS contribution process.

Rationale:
Ensure an organization has a documented process for how the organization publicly contributes FOSS. A policy may exist such that contributions are not permitted at all. In that specific situation it is understood that no process may exist and this requirement would nevertheless be met.

== Suggestions for Section 5.2 ==

• 5.2 If an organization permits contributions to FOSS projects then a process must exist for confirming these contributions adhere to the FOSS contribution policy outlined in Section 5.1. The process should include the following considerations:
• § legal approval for license considerations
• § adherence to project-specific contribution requirements The
process may also (but is not required) to include non-compliance considerations such as:
• § business rationale or approval
• § technical review of code to be contributed
• § community engagement and interaction

Verification Artifact(s):

ð 5.2.1 Provided the FOSS contribution policy permits contributions, a documented procedure exists that describes the FOSS contribution process.

Rationale:
Ensure an organization has a documented process for public contributions to FOSS projects. A policy may exist that says contributions are not permitted at all. In that specific situation it is understood that no process may exist and this requirement would nevertheless be met.
Regards

Shane

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


Re: OpenChain specification licensing

Shane Martin Coughlan <shane@...>
 

Dear Mark, Specification Team

I wanted to send a ping on the Specification licensing topic for 1.1 as this topic is required for translators.

Our current status is the the 1.0 PDF distribution document has no explicit license and the website makes no explicit reference to the license of the Specification. As per our previous thread on the matter, I propose we explicitly confirm CC-BY as the license of the specification, and include this statement on the website and the PDF for clarity.

I note that the 1.1 draft include a CC-BY 4.0 in an Appendix. My suggestion is to include a statement on the first page that:
“This document is licensed under the Creative Commons Attribution 4.0 International (CC-BY 4.0) license. This means you can freely use, share, improve and translate this document. Please see Appendix I for more details."

Regards

Shane

On Jan 11, 2017, at 16:57, Shane Coughlan <shane@...> wrote:

Dear all

Happy new year!

I wanted to flag that the website, specification FAQ and 1.0 specification PDF appear to be pending explicit copyright licensing information for the specification. See for example the PDF:
https://wiki.linuxfoundation.org/_media/openchain/openchainspec-1.0.pdf
This issue was flagged by a potential Japanese translation volunteer who wanted to confirm terms.

The OpenChain curriculum has licensing information on its dedicated page and on the slides but there may be room for improvement in this area too:
https://www.openchainproject.org/curriculum

I propose that for 1.1 we seek to have an explicit licensing statement on the website landing page for all of our materials. I also propose that the specification document contains an explicit licensing statement to clarify grants with regards sharing (assumed yes), ability to translate (assumed yes) or modify (assumed no). The latter item is because the specification PDF - as with the curriculum slides - will probably be passed around extensively over time.

Regards

Shane
Original thread on specification licensing:


On Oct 24, 2016, at 0:19, Gisi, Mark <Mark.Gisi@...> wrote:

Thank you Matija and Joseph for your input on the spec licensing. We will discuss it at the next working meeting on November 7 @ 9am Pacific Standard Time (PST). All are welcome. After having a discussion and obtaining guidance from the Linux Foundation we will present the license choice and the rationale to this group.

How to Participate: For those new to the OpenChain project we meet on the first and third Monday of each month. On the first Monday we meet at 9am PST to accommodate EMEA (Europe, the Middle East and Africa) and discuss the spec and spec conformance. For the third Monday we meet at 5pm PST to accommodate Asia and discuss the spec and curriculum.

Best,
- Mark


From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Joseph Potvin
Sent: Sunday, October 23, 2016 2:22 AM
To: openchain@...
Subject: Re: [OpenChain] What is the license of the openchain comformance specification 1.0 ?

RE: CC-BY 3.0

Should it not be updated to CC-BY 4.0?
https://creativecommons.org/licenses/by/4.0/

(BTW, Kudos to all for advancing this to v1.0, and apologies for going from active participant at the beginning to just a quiet observer due to workload. Wonderful to see it's now an industry reference.)

Joseph Potvin
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@...
Mobile: 819-593-5983
LinkedIn

On Sat, Oct 22, 2016 at 5:02 PM, Matija Šuklje <matija@...> wrote:
Die 21. 10. 16 et hora 19.53.35 fu7mu4 scripsit:
I want to translate the specification into Japanese.
But I could not find the license of the specification.
Please tell me the license of that.
According to the standard LF’s ToS <https://www.linuxfoundation.org/terms>
that the website seems to be under:

“Except as otherwise provided, Content on this site, including all materials
posted by the The Linux Foundation, is licensed under a Creative Commons
Attribution 3.0 License.”

As the specification’s PDF doesn’t seem to mention any other licence I’d say
it’s under CC-By 3.0.

I’d be very happy to be corrected by people who are much more involved than I.


cheers,
Matija
--
gsm: tel:+386.41.849.552
www: http://matija.suklje.name
xmpp: matija.suklje@...
sip: sip:matija_suklje@...
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain


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


Re: OpenChain for projects

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.


Re: Section 5 of the Specification Draft for Version 1.1

Mark Gisi
 

Thanks Shane for the insightful follow up to the last meeting. I will add your suggested modifications to the current draft for review and discussion at our next meeting.

Due to a lack of strong consensus on how to overall section 5 at this point, it is expected that we will largely retain much of what existed in the previous version and only make minor changes in version 1.1. Shane - your feedback is in the spirit of what I would consider minor changes. We are targeting to release version 1.1 in March.

The current draft can be found here (which is also easy to locate on both the project home page and project wiki):
https://wiki.linuxfoundation.org/_media/openchain/openchainspec-1.1.draft.pdf

- Mark

-----Original Message-----
From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Shane Martin Coughlan
Sent: Monday, January 23, 2017 6:33 PM
To: openchain@...
Subject: [OpenChain] Section 5 of the Specification Draft for Version 1.1

Hi Mark, Specification Team

Following our recent call I wanted to share some thoughts on Section 5 of the specification. These are intended to contribute to reducing any potential for confusion regarding OpenChain’s scope of "identifying and sharing the core components of a high quality Free and Open Source Software (FOSS) compliance program."

I think Section 5.1 fits well into this scope and only suggest cosmetic adjustments to make things easier for non-native speakers:

== Current Section 5.1 ==

• 5.1 A written policy exists that governs contributions to publicly accessible FOSS projects by employees on behalf of the organization where, as a minimum, it must be internally communicated.
Verification Artifact(s):
• ð 5.1.1 A documented FOSS contribution policy exists;
• ð 5.1.2 A documented procedure exists that makes all Software Staff aware of the existence of the FOSS contribution policy (e.g., via training, internal wiki, or other practical communication method).

Rationale:
Ensure an organization has given reasonable consideration to developing a policy with respect to publicly contributing to FOSS. The FOSS contribution policy can be made a part of the overall FOSS policy of an organization or be its own separate policy. In the situation where contributions are not permitted at all, a policy should exist making that position clear.

== Suggestions for Section 5.1 ==

• 5.1 A written policy exists that governs contributions to publicly accessible FOSS projects by the organization and its employees. This policy is internally communicated and may also be publicly communicated.
Verification Artifact(s):
• ð 5.1.1 A documented FOSS contribution policy exists;
• ð 5.1.2 A documented procedure exists that makes all Software Staff aware of the existence of the FOSS contribution policy (e.g., via training, internal wiki, or other practical communication method).

Rationale:
Ensure an organization has given reasonable consideration to developing a policy for public contributions to FOSS. The FOSS contribution policy can be part of the overall FOSS policy of an organization or a separate policy. In situations where contributions are not permitted a policy should exist making this position clear.
I think there is some potential for misunderstanding aspects of Section 5.2. As well as legal compliance it references business decisions, technical decisions and what may be interpreted as community norms. On the call we discussed that any potential for confusion can largely be addressed by referencing precisely what “contribution” means in the context of OpenChain. That said, there may be an opportunity for the specification language to be tightened too.

I would additionally note that the difference between considering "a project’s Code of Conduct or equivalent” and considering "adherence to project-specific contribution requirements” may be hard to understand for new participants (see 5.2 below).

Some ideas below:

== Current Section 5.2 ==

• 5.2 Provided the FOSS contribution policy permits such contributions, a process exists for confirming contributions adhere to the FOSS contribution policy, which might include (but is not limited to) the following considerations:
• § legal approval for license considerations
• § business rationale or approval
• § technical review of code to be contributed
• § community engagement and interaction, including a project’s Code of Conduct or equivalent
• § adherence to project-specific contribution requirements

Verification Artifact(s):

ð 5.2.1 Provided the FOSS contribution policy permits contributions, a documented procedure exists that describes the FOSS contribution process.

Rationale:
Ensure an organization has a documented process for how the organization publicly contributes FOSS. A policy may exist such that contributions are not permitted at all. In that specific situation it is understood that no process may exist and this requirement would nevertheless be met.

== Suggestions for Section 5.2 ==

• 5.2 If an organization permits contributions to FOSS projects then a process must exist for confirming these contributions adhere to the FOSS contribution policy outlined in Section 5.1. The process should include the following considerations:
• § legal approval for license considerations
• § adherence to project-specific contribution requirements The
process may also (but is not required) to include non-compliance considerations such as:
• § business rationale or approval
• § technical review of code to be contributed
• § community engagement and interaction

Verification Artifact(s):

ð 5.2.1 Provided the FOSS contribution policy permits contributions, a documented procedure exists that describes the FOSS contribution process.

Rationale:
Ensure an organization has a documented process for public contributions to FOSS projects. A policy may exist that says contributions are not permitted at all. In that specific situation it is understood that no process may exist and this requirement would nevertheless be met.
Regards

Shane

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


Re: OpenChain for projects

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


Re: OpenChain for projects

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


Re: OpenChain for projects

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


Re: OpenChain for projects

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


Re: OpenChain for projects

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​



Re: OpenChain for projects

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


Re: OpenChain for projects

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​


Re: OpenChain for projects

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


Re: OpenChain for projects

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.


Re: OpenChain for projects

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


Re: OpenChain for projects

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


Re: OpenChain for projects

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

4421 - 4440 of 5043