Date   

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

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:

Hi Arnold, thank you very much for your contribution!

All, the various slides and handout materials are now uploaded here:
https://onedrive.live.com/redir?resid=674AE6F2A656C9C5!709&authkey=!APTnTvWbiPQLJsc&ithint=folder%2cdoc

The current goal is to place the core content from the various slides into the 'OpenChain-Curriculum-Core-Open-Source-Compliance-SLIDES/pptx’ document. Everyone should be able to open and edit files without signing in.

Later we will circle back to the two handout files to create our OpenChain handout.

Regards

Shane

On Jun 3, 2016, at 21:49 , Niessen, Arnold <arnold.niessen@...> wrote:

Dear Shane, all,

Could you please add me to the list too? The calls are at a slightly difficult time (2am CET) but I'd still like to contribute where I can.

I have seen some very high quality materials already. I'd like to attach one of our internal documents that doesn't have too much overlap with the previous materials. This document tries to catch most of the compliance obligations at a high level in a few pages but without explaining any background, so it isn't overwhelming from its size, but it aims to whet the appetite for the background materials.

Kind regards / Met vriendelijke groeten,
Arnold Niessen
IP Counsel
Nederlands Octrooigemachtigde / European Patent Attorney
Philips Intellectual Property & Standards

High Tech Campus 5.5.0.41, 5656 AE, Eindhoven, The Netherlands
Mail Address: P.O. Box 220, 5600 AE Eindhoven, The Netherlands
GSM/SMS: +31 6 1177 3134 (Mobex 93837)
E-mail: arnold.niessen@...
Assistant: Sandra Hermans, +31 6 5282 4722 (mobex 95034)
Intranet: pww.ips.philips.com
Internet: www.ip.philips.com
Free on Wednesdays

-----Original Message-----
From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Shane Martin Coughlan
Sent: dinsdag 24 mei 2016 4:22
To: Marr, David <dmarr@...>
Cc: openchain@...
Subject: Re: [OpenChain] Curriculum next steps

Hi Dave

Thanks for confirming!

The list of people who have explicitly stepped forward to participate in building out the curriculum so far is:
Dave Marr
Jilayne Lovejoy
Kate Stewart
Ramesh Jain
Shane Coughlan
Tom Arcidiacono
If anyone else is interested in contributing just message me or step into our calls and drafting at any point.

All, the donated slides from Dave (Qualcomm) and Ibrahim (Samsung) have been uploaded to OneDrive and can be edited by anyone without any log-in via this URL:
https://onedrive.live.com/redir?resid=674AE6F2A656C9C5!801&authkey=!AALECDkajmrhNWw&ithint=folder%2c

There are three files:
(1) Dave’s slides
(2) Ibrahim’s slide
(3) A placeholder document for the OpenChain Curriculum Core Open Source Compliance slides

As per our last call, the Curriculum Work Team aims to:
(A) Review (1) and (2) to remove any corporate branding or extra slides
(B) Combine them into (3)
(C) Before working on reducing the slide count to result in a presentation that takes less than an hour.

We are going to aim to get the first rough cut ready in time for our next call in the third week of June. The end result should support the goals outlined here:
https://wiki.linuxfoundation.org/_media/openchain/openchainspec-2016-05-16-1.pdf
In particular, we want to help support Section 1.2, the 'Mandatory FOSS training’ requirements. Ideally our slides would help people get started in this area.

The process is simple. Just open the link, click a file, and select “Edit in Browser” to get started. I am personally going to get started on (A) later this week and would appreciate help to trim any remaining corporate branding or slides which are unnecessary.

Of course we are still accepting submissions of additional material so just reach out if you want to donate under CC-0.

Regards

Shane

NOTE #1: Why OneDrive and PowerPoint Online? The original slides were in PowerPoint format. A search for online systems with easy import and collaborative editing of these documents resulted in a shortlist of Google Slides or PowerPoint Online. PowerPoint Online appears to work in China while Google services are more challenging to access. If anyone strongly wants us to use another system I am happy to discuss that too.

NOTE #2: Why a public link that anyone can access? Because we want to encourage everyone to step in and lend a hand. Our goal, as per the minutes from the last call, is to make a simple, clear set of slides to support Open Source compliance in the context of OpenChain, and to help “on-board” people into both compliance best practice and deployment of OpenChain.

On May 22, 2016, at 7:00 AM, Marr, David <dmarr@...> wrote:

Shane please add me as a member of the curriculum work team.

Thanks,
Dave

-----Original Message-----
From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Shane Martin Coughlan
Sent: Thursday, May 19, 2016 10:51 PM
To: openchain@...
Subject: [OpenChain] Curriculum next steps

Dear OpenChain project members

Thank you to everyone who contributed to our last call and to many others who expressed interest in contributing to our curriculum work team.

The specific proposals to launch the work team were:
(1) We provide high level process management slides that can be adopted and expanded by any company seeking to undertake Open Source compliance;
(2) We will create the first iteration of these slides in a three month (3 call) window, with most of the actual work happening offline;
(3) We re-use existing material that is available (or can be made available) under a CC-0 license;
(4) We keep things simple to make adoption, translation and understand as straightforward as possible.

These proposals were accepted by the curriculum work team members present.

What this means for the team is:
(1) An initial version of the slides going online for editing next week;
(2) The team working on the slides for the next month to prepare the first draft;
(3) Review of the slides will take place on our second call to assess status and where we need to focus energy;
(4) The subsequent month will apply focus to these points before resulting in our first deliverable for consideration in the third call.

I will send an email next week with details of how we will collaborate online.

Regards

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

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
<20160603_Readme_for_SourceCode_WrittenOffer_Licenses_Acknowledgements.doc>


Re: specification feedback

Shane Martin Coughlan <shane@...>
 

Hi Jilayne

On Jun 13, 2016, at 04:48 , J Lovejoy <opensource@...> wrote:
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??
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:
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)

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. 
 

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.

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. 

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

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 

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





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




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

www.jbb.de

 

 


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

On Jun 10, 2016, at 6:12 AM, Miriam Ballhausen <Ballhausen@...> wrote:

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

www.jbb.de

 

 

Von: Kate Stewart [mailto:kstewart@...]
Gesendet: Freitag, 10. Juni 2016 15:08
An: Miriam Ballhausen
Cc: Gisi, Mark; openchain@...
Betreff: Re: [OpenChain] Comment for Specification/ Definitions

 

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

 

 

 

 

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


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

www.jbb.de

 

 

Von: Kate Stewart [mailto:kstewart@...]
Gesendet: Freitag, 10. Juni 2016 15:08
An: Miriam Ballhausen
Cc: Gisi, Mark; openchain@...
Betreff: Re: [OpenChain] Comment for Specification/ Definitions

 

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

 

 

 

 


Re: Comment for Specification/ Definitions

Kate Stewart
 

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

www.jbb.de

 

 


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
Sent: 07 June 2016 00:03
To: Radcliffe, Mark; Armijn Hemel - Tjaldur Software Governance Solutions; openchain@...
Subject: Re: [OpenChain] Slides

 

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
Sent: Monday, June 06, 2016 1:01 PM
To: Armijn Hemel - Tjaldur Software Governance Solutions <armijn@...>; openchain@...
Subject: Re: [OpenChain] Slides

 

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
Sent: Monday, June 06, 2016 12:14 PM
To: openchain@...
Subject: Re: [OpenChain] Slides

 

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

Please 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

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
Sent: Monday, June 06, 2016 1:01 PM
To: Armijn Hemel - Tjaldur Software Governance Solutions <armijn@...>; openchain@...
Subject: Re: [OpenChain] Slides

 

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
Sent: Monday, June 06, 2016 12:14 PM
To: openchain@...
Subject: Re: [OpenChain] Slides

 

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

Please 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

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
Sent: Monday, June 06, 2016 12:14 PM
To: openchain@...
Subject: Re: [OpenChain] Slides

 

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


---
Mike Dolan
VP of Strategic Programs
The Linux Foundation
Office: +1.330.460.3250   Cell: +1.440.552.5322  Skype: michaelkdolan
mdolan@...
---


On Mon, Jun 6, 2016 at 2:56 PM, Radcliffe, Mark <Mark.Radcliffe@...> wrote:

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
Sent: Monday, June 06, 2016 10:08 AM
To: 'Sami Atabani'; openchain@...
Subject: Re: [OpenChain] Slides

 

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

www.jbb.de

 

 

 

Von: Sami Atabani [mailto:Sami.Atabani@...]
Gesendet: Montag, 6. Juni 2016 19:04
An: Miriam Ballhausen; openchain@...

Betreff: RE: [OpenChain] Slides

 

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
Sent: 06 June 2016 17:06
To: openchain@...
Subject: [OpenChain] Slides

 

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

www.jbb.de

 

 

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.

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

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



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
Sent: Monday, June 06, 2016 10:08 AM
To: 'Sami Atabani'; openchain@...
Subject: Re: [OpenChain] Slides

 

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

www.jbb.de

 

 

 

Von: Sami Atabani [mailto:Sami.Atabani@...]
Gesendet: Montag, 6. Juni 2016 19:04
An: Miriam Ballhausen; openchain@...

Betreff: RE: [OpenChain] Slides

 

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
Sent: 06 June 2016 17:06
To: openchain@...
Subject: [OpenChain] Slides

 

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

www.jbb.de

 

 

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.

Please 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

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

www.jbb.de

 

 

 

Von: Sami Atabani [mailto:Sami.Atabani@...]
Gesendet: Montag, 6. Juni 2016 19:04
An: Miriam Ballhausen; ope
nchain@...
Betreff: RE: [OpenChain] Slides

 

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
Sent: 06 June 2016 17:06
To: openchain@...
Subject: [OpenChain] Slides

 

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

www.jbb.de

 

 

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
Sent: 06 June 2016 17:06
To: openchain@...
Subject: [OpenChain] Slides

 

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

www.jbb.de

 

 

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.


Updated Invitation: OpenChain (Specification & Certification ) @ Mon Jul 11, 2016 11am - 12pm (kstewart@linuxfoundation.org)

Kate Stewart
 

This event has been changed.

OpenChain (Specification & Certification )

Welcome to the Open Chain call for the Specification & Certification working groups

Agenda and Minutes: 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 #.

When
Changed: Mon Jul 11, 2016 11am – 12pm Central Time
Where
https://www.uberconference.com/katestewart (map)
Calendar
kstewart@...
Who
Kate Stewart - organizer
oliver.fendt@...
Mark.Gisi@...
jbuttura@...
eileen.evans@...
ballhausen@...
cmaracke@...
openchain@...
hung.chang@...
shane@...
mikeyang@...
kellyw@...
ibrahim.h@...
jilayne.lovejoy@...
dmarr@...
gunnar.nilsson@...

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account openchain@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More.