|
Public Comments link for OpenChain Spec version 2016-H1
Mark Gisi
You can review all the public comments received at the following link:
https://wiki.linuxfoundation.org/openchain/spec-2016-h1-public-comments
- Mark
Mark Gisi | Wind River | Director, IP & Open Source Tel (510) 749-2016 | Fax (510) 749-4552
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
OpenChain agenda 6/20
Kelly Williams
Hi Everyone,
Reminder the focus on the upcoming call on Monday, 6/20 at 5pm PST will be on the Specification and Curriculum. Agenda: https://wiki.linuxfoundation.org/openchain/minutes
Join the call: https://www.uberconference.com/katestewart Optional dial in number: 877-297-7470 Alternate number: 512-910-4433 No PIN needed
If you need to use a local phone number, please consult: https://www.uberconference.com/international for the specific country numbers.
1. Dial the local number based on your location. 2. Enter 512 910 4433, then #.
Regards, Kelly
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Re: Curriculum next steps
Shane Martin Coughlan <shane@...>
Dear all
toggle quoted messageShow quoted text
In advance of our call next Monday please find the latest version of our draft slides here: https://1drv.ms/p/s!AsXJVqby5kpnhh_DyKoOkwZUnBVC Please note this is a “living document” and everyone should feel free to jump in, refine and improve. Our source material can be found here: https://onedrive.live.com/redir?resid=674AE6F2A656C9C5!709&authkey=!APTnTvWbiPQLJsc&ithint=folder%2cdoc Thank you once again to everyone who contributed slides under CC-0 and thank you in advance to everyone who will help us refine the initial OpenChain Curriculum slides over the coming month. Regards Shane
On Jun 6, 2016, at 9:34 PM, Shane Martin Coughlan <shane@...> wrote:
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Re: specification feedback
Shane Martin Coughlan <shane@...>
Hi Jilayne
On Jun 13, 2016, at 04:48 , J Lovejoy <opensource@...> wrote:Happy to explore the creation of a template test after we complete our training slides. Regards Shane
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Re: specification feedback
Jeremiah Foster <jeremiah.foster@...>
On Sun, Jun 12, 2016 at 9:48 PM, J Lovejoy <opensource@...> wrote:
This is an important issue where I work for example, we often have to separate software created on dependencies from upstream versus work created in-house. Each can have a different license strategy so the ability to clearly define what is "supplied software" and what is not is useful for any compliance officer at our office.
In distributed software development teams flung across multiple time zones, we rely on things like recorded video, video meetings, messaging platforms and email. While these are not difficult to track they do often require printed material. We develop a lot of that in house so having material from OpenChain that we can incorporate for training would be very helpful.
We go through a "launch process" when we release software under open source licenses -- would this process, which can go quite deep into licenses and compliance, perhaps qualify as a a kind of "continuing education unit" for engineers who've already gone through training? I don't imagine it is a substitute for the training itself. Cheers, Jeremiah
Jeremiah C. Foster GENIVI COMMUNITY MANAGER Pelagicore AB Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden M: +46 (0)73 093 0506 
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Certification: First Draft and next steps
Miriam Ballhausen <Ballhausen@...>
Hi OpenChain participants,
attached to this email you will find a first draft of a certification document. As discussed during our last call, I created this document using the “Verification Artefacts” the specification document refers to.
In my opinion it is likely that we’ll have to add some “introductory” questions. For some questions, I already added them (i.e. questions 5.3 “Does the FOSS contribution policy permit contributions to FOSS projects by employees on behalf of the company?” The answer to these questions alone doesn’t have any relevance for the company’s compliance, thus introductory question. It only puts the following questions (those that are relevant) in context.
I am looking forward to your comments and discussing them during our next call on July 11th.
Regards,
Miriam
______________________________________________________________ Dr. Miriam Ballhausen Rechtsanwältin
JBB Rechtsanwälte Jaschinski Biere Brexl Partnerschaft mbB Christinenstraße 18/19 | 10119 Berlin Tel. +49.30.443 765 0 | Fax +49.30.443 765 22 Sitz der Gesellschaft: Berlin | Registergericht AG Charlottenburg | PR 609 B
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
specification feedback
J Lovejoy
Hi All,
I was going through the specification more closely and also thinking about how I might explain or how it might read to people being exposed to it for the first time. As a result, I have a few questions or comments: definition of Supplied Software - is so broad that it would include software provided as open source software by the organization. I don’t think we really intended it to be that way, and references to “Supplied Software” in several of the goals and verification artifacts are really referring to the use of third party FOSS in the distribution of products, not FOSS projects created by the organization. I’d think that FOSS that is created by the organization would be covered under G5, not so much as G2-4 - ?? Should we narrow the definition of Supplied Software as such? (also consider impact on definition of Software Staff) 1.2 re: mandatory training - includes verification artifacts of a method of tracking completion of the course by all Software Staff - I’d be curious to hear of some example of “methods of tracking” that would be acceptable and realistic. The only thing I can come up with is to have either live training with attendance taken, or recorded training with a tracking mechanism - nothing wrong with either of these, but what if some engineers would prefer to read the material? I can’t think of anyway to track that, but for some people this is a preferred way of learning. Just wondered if anyone had thoughts on that. 1.2 and 1.2.3 - 85% must of all Software Staff must have done training within last 24 mos; can have test to satisfy training - thinking about this realistically, should the OpenChain curriculum team create a template of what the test might be along with standard training materials? The 85% within 24 mos could be a big challenge and really annoying for software staff who know this stuff, so the test could be key, but then we also may want to consider some way to not let the test option get too watered down?? 2.1 - first bullet, “assign individual responsible for receiving FOSS compliance inquiries…" I think we should add "from third parties” - it says this in the rationale, but adding this would make it clear from the get-go that this section is dealing with a more public-facing role, versus internal role, which is dealt with later. - FOSS liaison “must have an email-capalbe communications system” - um, so does this simply mean, I have an email address you can contact me at? This wording is a bit odd and sounds a bit over-complicated 2.1.1 FOSS Liaison function is publicly identified (including an email address). - remove the word “function” - is listing this person on the organization’s website enough? Above we reference the LF Open Compliance Directory, which is great, but seems like a narrow example, no? Maybe add a couple other example as to how this might be achieved in the bullets in 2.1? 2.2 FOSS Compliance Role - I think the intent here is this part is dealing more with the internal role - we might want to explicitly state that to better contrast to 2.1 2.2.4 “documented procedure exists that identifies an escalation path for issue resolution” - this starts to sound like the above section and FOSS Liaison role. I’m not entirely sure what escalation this is talking about - internally? I think we need some clarifying language here. 3.1 and 3.2 - it kind of seems like these could be collapsed, such that 3.2.1 becomes 3.1.2 and the description of 3.1 simply includes use case. I’m not sure what is achieved by making these separate, as they are part and parcel of the same function in my eyes. G5 - I think this should cover code that the organization provides as open source (i.e., it’s own FOSS projects). Given the vast number of FOSS projects that have crappy license information - in terms of easily and clearly identifying both the inbound and outbound license - this would be a great help to everyone downstream as well. We could consider if this might eventually simply reference compliance with the requirements that the CII initiative is coming up with. Thanks, Jilayne
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Re: Comment for Specification/ Definitions
Dave Marr
Hi Miriam,
I may not be understanding the question but in case it's helpful would illustrate that:
The FOSS Liaison function and the FOSS compliance role can be the same person(s) but in some orgs they are different people. For example at Qualcomm they are different people but on the same team.
As to whether an edit should be made to add a reply function I initially thought Kate's proposed edit could address the concern but need to understand better how it doesn't. Also others may have caught what I missed.
Thanks,
Dave
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Re: Comment for Specification/ Definitions
Miriam Ballhausen <Ballhausen@...>
Hi Kate,
That makes it better and more congruent, however, I am not sure, because the definition is limited to input from the FOSS community, whereas compliance inquiries might be brought by anyone and especially someone who might have any contact with any open source community. I personally see the FOSS Liaison as someone who is assigned to receive and reply any and all inquiries related to open source issues, especially compliance inquiries.
All the best, Miriam ______________________________________________________________ Dr. Miriam Ballhausen Rechtsanwältin
JBB Rechtsanwälte Jaschinski Biere Brexl Partnerschaft mbB Christinenstraße 18/19 | 10119 Berlin Tel. +49.30.443 765 0 | Fax +49.30.443 765 22 Sitz der Gesellschaft: Berlin | Registergericht AG Charlottenburg | PR 609 B
Von: Kate Stewart [mailto:kstewart@...]
Hi Miriam, Mark,
On Fri, Jun 10, 2016 at 5:14 AM, Miriam Ballhausen <Ballhausen@...> wrote:
Hi Mark,
while re-organizing the specification into a certification document I took a closer look at the definitions. Is it possible that the definition for “FOSS Liaison” does not (at least not entirely) correspond with the way the term is used in the specification?
The definition reads:
FOSS Liaison - a designated person who is assigned to receive input from the FOSS community.
In 2.1 it then says:
Assign individual(s) responsible for receiving FOSS compliance inquiries
I understand that the FOSS Liaison’s job may cover more than just dealing with FOSS compliance inquiries. However, I find it unlikely that it is limited to just receiving input from the FOSS community, but then doesn’t cover giving feedback to the FOSS community.
That's a good point.
Will adding "and reply to" to the definition and 2.1 address the point you raise?
ie. Definition:
Thanks, Kate
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Re: Comment for Specification/ Definitions
Kate Stewart
Hi Miriam, Mark, On Fri, Jun 10, 2016 at 5:14 AM, Miriam Ballhausen <Ballhausen@...> wrote:
That's a good point. Will adding "and reply to" to the definition and 2.1 address the point you raise? ie. Definition:FOSS Liaison - a designated person who is assigned to receive and reply to input from the FOSS community. For 2.1: Assign individual(s) responsible for receiving and replying to FOSS compliance inquiries Thanks, Kate
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Comment for Specification/ Definitions
Miriam Ballhausen <Ballhausen@...>
Hi Mark,
while re-organizing the specification into a certification document I took a closer look at the definitions. Is it possible that the definition for “FOSS Liaison” does not (at least not entirely) correspond with the way the term is used in the specification?
The definition reads:
FOSS Liaison - a designated person who is assigned to receive input from the FOSS community.
In 2.1 it then says:
Assign individual(s) responsible for receiving FOSS compliance inquiries
I understand that the FOSS Liaison’s job may cover more than just dealing with FOSS compliance inquiries. However, I find it unlikely that it is limited to just receiving input from the FOSS community, but then doesn’t cover giving feedback to the FOSS community.
Cheers, Miriam ______________________________________________________________ Dr. Miriam Ballhausen Rechtsanwältin
JBB Rechtsanwälte Jaschinski Biere Brexl Partnerschaft mbB Christinenstraße 18/19 | 10119 Berlin Tel. +49.30.443 765 0 | Fax +49.30.443 765 22 Sitz der Gesellschaft: Berlin | Registergericht AG Charlottenburg | PR 609 B
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Re: Slides
Yagi, Martin, Vodafone Group <martin.yagi@...>
Dear all,
In my experience 3-6 months is nowhere near enough time for a new (large, FOSS-immature) acquisition to become compliant to the FOSS policies and practices of the new parent….even 6-12 months may not be achievable. I think it’s better to have the subsidiary distinct until its compliant.
Best regards,
Martin.
From: openchain-bounces@...
[mailto:openchain-bounces@...] On Behalf Of Marr, David
These comments resonate with me as well. As an attempt to capture the two related but distinct discussions on this point so far I’m seeing proposals to:
· Build a pre-set, standard time duration for an entity’s OpenChain Certification. An annual duration was proposed. Additional justification for setting a duration is because over time the person(s) in the FOSS Compliance Role might transition from that role, whether leaving the entity or changing job responsibilities within the entity.
· Consider either a distinction for companies that have been purchased or provide a period (such as three to six months) for the certifying company to certify that the new “subsidiary” can be considered compliant.
On the second point, I’m attracted to the suggestion of making a distinction. Perhaps any OpenChain Certification should extend to the entity and its subsidiaries at the time of certification (a snapshot in time), without automatic application to new subs, until the next annual(?) certification?
Dave
From:
openchain-bounces@... [mailto:openchain-bounces@...]
On Behalf Of Radcliffe, Mark
If the certification includes an identification of the person who is responsible (and I think that it should), I suggest that one requirement of certification is that they keep someone in that role during the period of certification.
From:
openchain-bounces@... [mailto:openchain-bounces@...]
On Behalf Of Armijn Hemel - Tjaldur Software Governance Solutions
On 06-06-16 21:03, Michael Dolan wrote:
armijn
--
Armijn Hemel, MSc
Tjaldur Software Governance Solutions
Please consider the environment before printing this email.
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Re: Slides
Dave Marr
These comments resonate with me as well. As an attempt to capture the two related but distinct discussions on this point so far I’m seeing proposals to:
· Build a pre-set, standard time duration for an entity’s OpenChain Certification. An annual duration was proposed. Additional justification for setting a duration is because over time the person(s) in the FOSS Compliance Role might transition from that role, whether leaving the entity or changing job responsibilities within the entity.
· Consider either a distinction for companies that have been purchased or provide a period (such as three to six months) for the certifying company to certify that the new “subsidiary” can be considered compliant.
On the second point, I’m attracted to the suggestion of making a distinction. Perhaps any OpenChain Certification should extend to the entity and its subsidiaries at the time of certification (a snapshot in time), without automatic application to new subs, until the next annual(?) certification?
Dave
From: openchain-bounces@... [mailto:openchain-bounces@...]
On Behalf Of Radcliffe, Mark
If the certification includes an identification of the person who is responsible (and I think that it should), I suggest that one requirement of certification is that they keep someone in that role during the period of certification.
From:
openchain-bounces@... [mailto:openchain-bounces@...]
On Behalf Of Armijn Hemel - Tjaldur Software Governance Solutions
On 06-06-16 21:03, Michael Dolan wrote:
armijn
-- Armijn Hemel, MSc Tjaldur Software Governance Solutions Please consider the environment before printing this email.
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Re: Slides
Mark Radcliffe
If the certification includes an identification of the person who is responsible (and I think that it should), I suggest that one requirement of certification is that they keep someone in that role during the period of certification.
From: openchain-bounces@... [mailto:openchain-bounces@...]
On Behalf Of Armijn Hemel - Tjaldur Software Governance Solutions
On 06-06-16 21:03, Michael Dolan wrote:
armijn
-- Armijn Hemel, MSc Tjaldur Software Governance SolutionsPlease consider the environment before printing this email. The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster@.... Thank you.
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Re: Slides
Armijn Hemel - Tjaldur Software Governance Solutions
On 06-06-16 21:03, Michael Dolan wrote:
One issue I know happens in supply chains based on hearing stories is that the person responsible for open source software compliance may leave the company, take a new role, etc and the company does not backfill them. This is *so* true and a major reason to put a time limit on certification. armijn -- Armijn Hemel, MSc Tjaldur Software Governance Solutions
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Re: Slides
Michael Dolan <mdolan@...>
One issue I know happens in supply chains based on hearing stories is that the person responsible for open source software compliance may leave the company, take a new role, etc and the company does not backfill them. So when you're talking about a compliance standard that will also be used with smaller vendors, I think many companies will want the assurance that the people/processes that were there a year ago exist after some key resource left. ---
On Mon, Jun 6, 2016 at 2:56 PM, Radcliffe, Mark <Mark.Radcliffe@...> wrote:
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Re: Slides
Mark Radcliffe
I think that it is a good idea.
If we are going to have certifications of large entities which may acquire other companies. Does the certification apply to the new entity (for example when Dell bought EMC if Dell was certified would the certification apply to EMC?). I think that we should consider either a distinction for companies that have been purchased or provide a period (three to six months) for the certifying company to certify that the new “subsidiary” can be considered compliant. I am open to suggestions.
From: openchain-bounces@... [mailto:openchain-bounces@...]
On Behalf Of Miriam Ballhausen
Hi Sami,
good point! My first impulse is to say yes. From my point of view it should’t be too much of a hassle for a company that has its processes in order, while it might increase the credibility and value of the certification/ assessment. But I’d like to get some feedback form other, especially those who deal with certification/ assessment in other cases. I’ll send out a summary of today’s call later this week and I’ll include your point
Best, Miriam ______________________________________________________________ Dr. Miriam Ballhausen Rechtsanwältin
JBB Rechtsanwälte Jaschinski Biere Brexl Partnerschaft mbB Christinenstraße 18/19 | 10119 Berlin Tel. +49.30.443 765 0 | Fax +49.30.443 765 22 Sitz der Gesellschaft: Berlin | Registergericht AG Charlottenburg | PR 609 B
Von: Sami Atabani [mailto:Sami.Atabani@...]
Hi Miriam,
We should also consider the frequency of the certification. Should it be annually renewed?
Thanks
Sami
From:
openchain-bounces@... [mailto:openchain-bounces@...]
On Behalf Of Miriam Ballhausen
Hi everyone,
Kelly asked me to circulate the slides for today’s call. Please find them attached.
All the best, Miriam ______________________________________________________________ Dr. Miriam Ballhausen Rechtsanwältin
JBB Rechtsanwälte Jaschinski Biere Brexl Partnerschaft mbB Christinenstraße 18/19 | 10119 Berlin Tel. +49.30.443 765 0 | Fax +49.30.443 765 22 Sitz der Gesellschaft: Berlin | Registergericht AG Charlottenburg | PR 609 B
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. The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster@.... Thank you.
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Re: Slides
Miriam Ballhausen <Ballhausen@...>
Hi Sami,
good point! My first impulse is to say yes. From my point of view it should’t be too much of a hassle for a company that has its processes in order, while it might increase the credibility and value of the certification/ assessment. But I’d like to get some feedback form other, especially those who deal with certification/ assessment in other cases. I’ll send out a summary of today’s call later this week and I’ll include your point
Best, Miriam ______________________________________________________________ Dr. Miriam Ballhausen Rechtsanwältin
JBB Rechtsanwälte Jaschinski Biere Brexl Partnerschaft mbB Christinenstraße 18/19 | 10119 Berlin Tel. +49.30.443 765 0 | Fax +49.30.443 765 22 Sitz der Gesellschaft: Berlin | Registergericht AG Charlottenburg | PR 609 B
Von: Sami Atabani
[mailto:Sami.Atabani@...]
Hi Miriam,
We should also consider the frequency of the certification. Should it be annually renewed?
Thanks
Sami
From:
openchain-bounces@... [mailto:openchain-bounces@...]
On Behalf Of Miriam Ballhausen
Hi everyone,
Kelly asked me to circulate the slides for today’s call. Please find them attached.
All the best, Miriam ______________________________________________________________ Dr. Miriam Ballhausen Rechtsanwältin
JBB Rechtsanwälte Jaschinski Biere Brexl Partnerschaft mbB Christinenstraße 18/19 | 10119 Berlin Tel. +49.30.443 765 0 | Fax +49.30.443 765 22 Sitz der Gesellschaft: Berlin | Registergericht AG Charlottenburg | PR 609 B
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: Slides
Sami Atabani
Hi Miriam,
We should also consider the frequency of the certification. Should it be annually renewed?
Thanks
Sami
From: openchain-bounces@...
[mailto:openchain-bounces@...] On Behalf Of Miriam Ballhausen
Hi everyone,
Kelly asked me to circulate the slides for today’s call. Please find them attached.
All the best, Miriam ______________________________________________________________ Dr. Miriam Ballhausen Rechtsanwältin
JBB Rechtsanwälte Jaschinski Biere Brexl Partnerschaft mbB Christinenstraße 18/19 | 10119 Berlin Tel. +49.30.443 765 0 | Fax +49.30.443 765 22 Sitz der Gesellschaft: Berlin | Registergericht AG Charlottenburg | PR 609 B
|
||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||
|
Updated Invitation: OpenChain (Specification & Certification ) @ Mon Jul 11, 2016 11am - 12pm (kstewart@linuxfoundation.org)
Kate Stewart
|
||||||||||||||||||||||||||||||||||||||||||
|
|