Date   

Re: OpenChain - A Call for Case Studies

Dave Marr
 

Ditto! Also I think the Case Studies has the potential to get into some meaty topics, such as how one handles architectural analysis for copyleft effect; how deep one needs to dive into a hierarchical folder structure before believing the top level license; when to draw a line in the sand re a go/no go decision, and more. If there's opportunity this would surely be a good session at either this one or the next one.

Maybe we could discuss at one of our upcoming calls as well.

Dave

-----Original Message-----
From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Shane Coughlan
Sent: Monday, February 26, 2018 12:43 PM
To: Malcolm Bain <malcolm.bain@...>
Cc: openchain@...; Polina Malaja <polina@...>
Subject: Re: [OpenChain] OpenChain - A Call for Case Studies

Thank you Malcolm!

On Feb 26, 2018, at 12:38, Malcolm Bain <malcolm.bain@...> wrote:

If we can, leta have 2 open chain based workships at llw: case studies and processes. I have proposed the processes, I'll see if there is a case study one, and if not make a late proposal.



Saludos/Regards
Malcolm (from my cell phone)

-------- Mensaje original --------
De: Shane Coughlan <coughlan@...>
Fecha: 26/2/18 20:07 (GMT+01:00)
Para: Malcolm Bain <malcolm.bain@...>
Cc: openchain@..., Polina Malaja
<polina@...>
Asunto: Re: [OpenChain] OpenChain - A Call for Case Studies

Hi Malcolm!

We seem to have a lot of interest around both case studies and example processes, but we are not yet seeing much organic community contribution in these areas. It would be great if we could explore using the Legal Network event as a way to sit everyone down and get some stuff reviewed. I am adding Polina, the coordinator, to this thread for reference.

On a related note, thanks for sharing the big questions you are
getting, and I can immediately respond that I am finding questions
elsewhere much along these lines. Perhaps an opportunity for Team
OpenChain to provide some answers :)

Regards

Shane

On Feb 22, 2018, at 3:15, Malcolm Bain <malcolm.bain@...> wrote:

Ha! That was going to be one of my proposals for a workshop at LLW18...
building collaboratively a battery of OC case studies (in a 2 h
sprint...) to then be published.

We did this in the ASTP (tech transfer association) software SIG at
the annual event in Portugal; and came up with 8 case studies (on
the basis of a
template) within 2 hours, and 25 tech transfer officers having a
very intense dose of software IPR management and licensing - very
educational. I then had to write the bloody things up into more or
less proper English. :-)

In the end I did not propose this for the LLW - needed more OC-list
support (you guys) and didn't have time to drum up interest (I know
you are keen!), but if we don't move forward offline on Shane's call
to arms, and if there are a number of us at the LLW, we could try
offering this as a session (the CFP is "closed", but always wiggle
room for sending something in a bit late). I think it would be both
instructive for those attending (both OC experts and passive listeners) and useful in terms of output.

I'll try to put in some text relating to my current OC audit
(dragging on..) but need OK for company name to be released.

Re. answering questions, the big questions I am getting (that could
be considered within a case study) are:
- what are the biggest challenges?
- how much of this can be "automated"?
- Is there any (FOSS) (SaaS) "workflow management" software adapted
to OC processes and templates?
- how much time do we have to invest in this?
- who should be / has to be involved? (e.g. QA guys)
- where can I find templates for OC documents and processes? (e.g.
process maps, thank you Armijn/Shane, or FOSS policy templates
(thank you Linux
Fondation)
- what skills are needed for "OC coordinator team"?
- what are the quick wins that can help me sell this around the
organization?
- what clauses can I put in my supply contracts to require upstream
conformance?

Best

malcolm


-----Mensaje original-----
De: openchain-bounces@... [mailto:openchain-
bounces@...] En nombre de Shane Coughlan
Enviado el: jueves, 22 de febrero de 2018 11:30
Para: openchain@...
Asunto: [OpenChain] OpenChain - A Call for Case Studies

Dear All

I wanted to announce a call for case studies. This is one of the
number one items raised by potential participants. Some of you have
already volunteered to create such case studies. Now I would like
to throw open the doors a little more widely.

What we are looking for are short, concise overviews of how and why
OrganizationX is interested in and engaged with OpenChain
educational material, the specification and/or conformance. In
providing this overviews we can fulfill the need to answer one of
the most important questions around our project: “how do I get
started?"

Here is the Case Studies document:
https://docs.google.com/document/d/15I4xvB-
UNXG_z4q0LFUhiwZaj2ehLJYwXqMwURomZCk/edit#heading=h.6l9ziyuob6dq
(Edit at will!)

Regards

Shane

--
Shane Coughlan
OpenChain Project Director
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

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

Get my free book on open source compliance here:
https://www.linuxfoundation.org/news-media/research/practical-gpl-
compliance

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


Re: [Openchain-conformance] OpenChain: The questions about Conformance

Dave Marr
 

Cool. These seem to be a great set of natural questions that one encounters in that time after one understands:

1. why license compliance is important, and
2. therefore let's approach license compliance in an efficient, consistent way (hence OpenChain), and then arrives at:

3. ...so how do I roll it out at my company.

My comments to Shane's capture of Malcolm's questions, offered as just my opinions:

- what are the biggest challenges to conformance?

DM: top level support and executive buy-in

- how much of this can be "automated"?

DM: lots, but we tended to begin with manual processes and simple automation, and redesigned from there. My team adopted workflow tools that our engineering teams already were using. Approach was to mesh the compliance process into the natural engineering process where possible, rather than make engineers come out of their process to follow a legal process. Legal adopted engineering milestones.

- Is there any (FOSS) (SaaS) "workflow management" software adapted to OC processes and templates?

DM: I'm reluctant to endorse a specific tool here, but the workflow tool my eng teams happened to already be using was Jira, so we based our process off of that.

- how much time do we have to invest in this?

DM: over time it's quite a bit, but it's one bite at a time, improving incrementally to add automation and integrating with product development workflow.

- who should be / has to be involved? (e.g. QA guys)

DM: eng, product management, program management, engineering leadership, legal, IT

- where can I find templates for OC documents and processes? (e.g. process maps or FOSS policy templates)

DM: should we set up a donation bin? Perhaps an option for folks to scrub off their company name and let others adapt? Just an idea but it seemed to work for curriculum donations under CC0.

- what skills are needed for "OC coordinator team"?

DM: for a team that functions as a review board for open source matters, including designing process and making the tough calls for borderline issues, I would say (1) experience in reviewing open source issues, along with a blend of (2) engineering/programming skills and (3) legal skills.

- what are the quick wins that can help me sell this around the organization?

DM: for me, I invited some senior execs to participate in a video that was used for required internal training on open source for software engs and PMs. Having folks watch a video of the CEO tell them that open source was important and to please pay attention to the training was a big early win. That was pre-OpenChain, but the ongoing training discipline is now the vehicle for introducing additional content such as any added elements from OpenChain.

-----Original Message-----
From: openchain-conformance-bounces@... [mailto:openchain-conformance-bounces@...] On Behalf Of Shane Coughlan
Sent: Monday, February 26, 2018 11:45 AM
To: openchain@...
Cc: Openchain-conformance@...
Subject: [Openchain-conformance] OpenChain: The questions about Conformance

Dear All

Malcolm raised some interesting questions that he is receiving from clients. These align neatly with the types of question I am encountering in Japan.

Here they are. Thoughts, comments and suggestions regarding answering these items are most welcome. I suspect that if we put our heads together we can get the best results:
- what are the biggest challenges to conformance?
- how much of this can be "automated"?
- Is there any (FOSS) (SaaS) "workflow management" software adapted to OC processes and templates?
- how much time do we have to invest in this?
- who should be / has to be involved? (e.g. QA guys)
- where can I find templates for OC documents and processes? (e.g. process maps or FOSS policy templates)
- what skills are needed for "OC coordinator team"?
- what are the quick wins that can help me sell this around the organization?

Regards

Shane


--
Shane Coughlan
OpenChain Project Director
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

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

Get my free book on open source compliance here:
https://www.linuxfoundation.org/news-media/research/practical-gpl-compliance

_______________________________________________
Openchain-conformance mailing list
Openchain-conformance@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain-conformance


The OpenChain Partner Program - A Request For Comments

Shane Coughlan <coughlan@...>
 

Dear OpenChain Community (and especially a pilot partners)

The OpenChain Specification will always be centered around self-certification that is free of cost and has a low barrier to entry for entities of all sizes. Adjacent to this we expect to see companies explore with other methods of having “verified” conformance or one type or another. One avenue is the concept of expert partners who can help entities through a guided form of conformance. To this end we are currently running a pilot partner program centered around a handful of consultancies and law firms that are deeply connected with our volunteer community.

In its early phase this pilot is focused on having knowledgeable entities with a strong commitment to OpenChain explore how conformance can work towards their community and clients. This is a great start. However, if we continue this program in the long-term we need to discuss how and when the requirements for partners might be modified.

For example, if we move the program from pilot to deployment, do we gradually increase the series of requirements for an entity to be an “official partner”, and what should be the criteria for continued participation?

How about an annual performance review? Would it be useful if it tracked some concrete metrics (e.g. an certain number of public talks per year)?

I would value your feedback around this issue. As always, OpenChain is *your* project and how we approach long-term engagement is very important. Many organizations have said they would like the opportunity for verified conformance as well as self-certification. Our opportunity is to make this verification a natural, useful fit for our community.

Regards

Shane

--
Shane Coughlan
OpenChain Project Director
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

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

Get my free book on open source compliance here:
https://www.linuxfoundation.org/news-media/research/practical-gpl-compliance


OpenChain Work Team Minutes - Minutes of the call on 2-19-2018

Shane Coughlan <coughlan@...>
 

Dear Community!

Please find below the minutes from our latest Work Team meeting. I would like to take a moment to thank everyone who attended and especially Mark for leading a great discussion around the Spec.

Regards

Shane


== Attendees ==

Shane Coughlan
Mark Gisi
Imada San
Kate Stewart
Nathan Kumagai
Gary O'Neill
Stanley Bernstein
Endo San
Matsumoto San
Takimi San

== Project Update ==

Shane outlined developments in the following areas:
• Activity in the China, Japan and Korea (CJK) region
• Engagement from consumer product and medical providers
• OpenChain Japan Work Group
• OpenChain @ Open Source Leadership Summit

== Specification Work Team ==

Mark noted that we are close to a 1.2 version of the spec. Our
meeting in March will be when we finalize the document. Our release
is scheduled for April.

We proceeded to open the specification document to run through
items. The first was page four, adding the FAQ link under
"Additional clarification of the specification can be obtained by
reviewing the Specification Frequently" to help keep it clear.

We proceeded to examine page 5, "Identified Licenses - a set of FOSS
licenses identified as a result of following an appropriate method
of identifying such licenses that govern the supplied software."
This was a clarification to help frame things for our audience.

We proceeded to note that one page 6, Section 1.1 a word has been deleted for consistency:
"Verification Material Artifact(s):
1.1.1 A documented FOSS policy--exists--.

1.1.2 A documented procedure --exists-- that makes all Software Staff aware of the existence of
the FOSS policy (e.g., via training, internal wiki, or other practical communication method)."

In 1.2 we clarified what precisely "current" meant and we moved it
to uppercase to make it clear that there is a definition.

In 1.2.3 we adjusted the language quite significantly to improve
clarity around the term "Current"

"The 85% may not necessarily apply to the entire organization, but
to the totality of those specifically responsible for the design,

development and delivery of each Supplied Software release reviewed
under an OpenChain conforming program. That is, all of the Software
Staff participating in the conforming program represents 100%."

The rationale around Section 1.2 was also adjusted for clarity.

We proceeded to explore Section 1.3.1, removing the word "exists"
and making it clear that there must be information to document
obligations etc. We deleted the phrase "governing the Supplied
Software" to more clearly frame the task.

Mark noted that the specification does not have any radical changes
over version 1.1. The changes are all about making things clear.

We proceeded to review section 6. In 6.1 there is an alteration of
"certified" to Certified. The challenge is whether an organization
is conforming or a piece of software that has passed through an
OpenChain Certified program.

Mark drew a connection between having Organic labeling for food.
Gary raised a question about how and if we could have clarity for
which products are conformant. Mark clarified that at this juncture
there is a focus on a conformant PROCESS rather than a conformant
PRODUCT. He further noted that we might have to address this, and
continued that if products are released that are not conformant with
the process it can be confusing and dilute the meaning of the mark.

Shane raised the concern that if we equated conformance with a whole
entity rather than a program it would prove challenging for
multinationals to conform.

Mark concurred and noted we are killing two birds with one stone,
improving the clarity, and how it fits to a specific release.

= Onboarding =

The Onboarding team is looking for final feedback or edits for:
1) OpenChain Handout content -
https://docs.google.com/document/d/1tcXITiwFbUqK9JTEwz_J LJhtG9GRPyQa4cLdSULKn0I/edit?usp=sharing
2) Checklist Handout -
https://docs.google.com/document/d/1LFx9mK0ZaZMLZzZ2mjl HAqgFdQNuYrCXVnFfmgFZdcU/edit?usp=sharing

= Any Other Business =

No further business was raised and the call closed.


Re: OpenChain - A Call for Case Studies

Shane Coughlan <coughlan@...>
 

Thank you Malcolm!

On Feb 26, 2018, at 12:38, Malcolm Bain <malcolm.bain@...> wrote:

If we can, leta have 2 open chain based workships at llw: case studies and processes. I have proposed the processes, I'll see if there is a case study one, and if not make a late proposal.



Saludos/Regards
Malcolm (from my cell phone)

-------- Mensaje original --------
De: Shane Coughlan <coughlan@...>
Fecha: 26/2/18 20:07 (GMT+01:00)
Para: Malcolm Bain <malcolm.bain@...>
Cc: openchain@..., Polina Malaja <polina@...>
Asunto: Re: [OpenChain] OpenChain - A Call for Case Studies

Hi Malcolm!

We seem to have a lot of interest around both case studies and example processes, but we are not yet seeing much organic community contribution in these areas. It would be great if we could explore using the Legal Network event as a way to sit everyone down and get some stuff reviewed. I am adding Polina, the coordinator, to this thread for reference.

On a related note, thanks for sharing the big questions you are getting, and I can immediately respond that I am finding questions elsewhere much along these lines. Perhaps an opportunity for Team OpenChain to provide some answers :)

Regards

Shane

On Feb 22, 2018, at 3:15, Malcolm Bain <malcolm.bain@...> wrote:

Ha! That was going to be one of my proposals for a workshop at LLW18...
building collaboratively a battery of OC case studies (in a 2 h sprint...)
to then be published.

We did this in the ASTP (tech transfer association) software SIG at the
annual event in Portugal; and came up with 8 case studies (on the basis of a
template) within 2 hours, and 25 tech transfer officers having a very
intense dose of software IPR management and licensing - very educational. I
then had to write the bloody things up into more or less proper English. :-)

In the end I did not propose this for the LLW - needed more OC-list support
(you guys) and didn't have time to drum up interest (I know you are keen!),
but if we don't move forward offline on Shane's call to arms, and if there
are a number of us at the LLW, we could try offering this as a session (the
CFP is "closed", but always wiggle room for sending something in a bit
late). I think it would be both instructive for those attending (both OC
experts and passive listeners) and useful in terms of output.

I'll try to put in some text relating to my current OC audit (dragging on..)
but need OK for company name to be released.

Re. answering questions, the big questions I am getting (that could be
considered within a case study) are:
- what are the biggest challenges?
- how much of this can be "automated"?
- Is there any (FOSS) (SaaS) "workflow management" software adapted to OC
processes and templates?
- how much time do we have to invest in this?
- who should be / has to be involved? (e.g. QA guys)
- where can I find templates for OC documents and processes? (e.g. process
maps, thank you Armijn/Shane, or FOSS policy templates (thank you Linux
Fondation)
- what skills are needed for "OC coordinator team"?
- what are the quick wins that can help me sell this around the
organization?
- what clauses can I put in my supply contracts to require upstream
conformance?

Best

malcolm


-----Mensaje original-----
De: openchain-bounces@... [mailto:openchain-
bounces@...] En nombre de Shane Coughlan
Enviado el: jueves, 22 de febrero de 2018 11:30
Para: openchain@...
Asunto: [OpenChain] OpenChain - A Call for Case Studies

Dear All

I wanted to announce a call for case studies. This is one of the number
one
items raised by potential participants. Some of you have already
volunteered
to create such case studies. Now I would like to throw open the doors a
little
more widely.

What we are looking for are short, concise overviews of how and why
OrganizationX is interested in and engaged with OpenChain educational
material, the specification and/or conformance. In providing this
overviews
we can fulfill the need to answer one of the most important questions
around
our project: “how do I get started?"

Here is the Case Studies document:
https://docs.google.com/document/d/15I4xvB-
UNXG_z4q0LFUhiwZaj2ehLJYwXqMwURomZCk/edit#heading=h.6l9ziyuob6dq
(Edit at will!)

Regards

Shane

--
Shane Coughlan
OpenChain Project Director
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

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

Get my free book on open source compliance here:
https://www.linuxfoundation.org/news-media/research/practical-gpl-
compliance

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


Re: OpenChain - A Call for Case Studies

Malcolm Bain
 

If we can, leta have 2 open chain based workships at llw: case studies and processes. I have proposed the processes, I'll see if there is a case study one, and if not make a late  proposal. 



Saludos/Regards
Malcolm (from my cell phone)

-------- Mensaje original --------
De: Shane Coughlan <coughlan@...>
Fecha: 26/2/18 20:07 (GMT+01:00)
Para: Malcolm Bain <malcolm.bain@...>
Cc: openchain@..., Polina Malaja <polina@...>
Asunto: Re: [OpenChain] OpenChain - A Call for Case Studies

Hi Malcolm!

We seem to have a lot of interest around both case studies and example processes, but we are not yet seeing much organic community contribution in these areas. It would be great if we could explore using the Legal Network event as a way to sit everyone down and get some stuff reviewed. I am adding Polina, the coordinator, to this thread for reference.

On a related note, thanks for sharing the big questions you are getting, and I can immediately respond that I am finding questions elsewhere much along these lines. Perhaps an opportunity for Team OpenChain to provide some answers :)

Regards

Shane

> On Feb 22, 2018, at 3:15, Malcolm Bain <malcolm.bain@...> wrote:
>
> Ha! That was going to be one of my proposals for a workshop at LLW18...
> building collaboratively a battery of OC case studies (in a 2 h sprint...)
> to then be published.
>
> We did this in the ASTP (tech transfer association) software SIG at the
> annual event in Portugal; and came up with 8 case studies (on the basis of a
> template) within 2 hours, and 25 tech transfer officers having a very
> intense dose of software IPR management and licensing - very educational. I
> then had to write the bloody things up into more or less proper English. :-)
>
> In the end I did not propose this for the LLW - needed more OC-list support
> (you guys) and didn't have time to drum up interest (I know you are keen!),
> but if we don't move forward offline on Shane's call to arms, and if there
> are a number of us at the LLW, we could try offering this as a session (the
> CFP is "closed", but always wiggle room for sending something in a bit
> late). I think it would be both instructive for those attending (both OC
> experts and passive listeners) and useful in terms of output.
>
> I'll try to put in some text relating to my current OC audit (dragging on..)
> but need OK for company name to be released.
>
> Re. answering questions, the big questions I am getting (that could be
> considered within a case study) are:
> - what are the biggest challenges?
> - how much of this can be "automated"?
> - Is there any (FOSS) (SaaS) "workflow management" software adapted to OC
> processes and templates?
> - how much time do we have to invest in this?
> - who should be / has to be involved?  (e.g. QA guys)
> - where can I find templates for OC documents and processes? (e.g. process
> maps, thank you Armijn/Shane, or FOSS policy templates (thank you Linux
> Fondation)
> - what skills are needed for "OC coordinator team"?
> - what are the quick wins that can help me sell this around the
> organization?
> - what clauses can I put in my supply contracts to require upstream
> conformance?
>
> Best
>
> malcolm
>
>
>> -----Mensaje original-----
>> De: openchain-bounces@... [mailto:openchain-
>> bounces@...] En nombre de Shane Coughlan
>> Enviado el: jueves, 22 de febrero de 2018 11:30
>> Para: openchain@...
>> Asunto: [OpenChain] OpenChain - A Call for Case Studies
>>
>> Dear All
>>
>> I wanted to announce a call for case studies. This is one of the number
>> one
>> items raised by potential participants. Some of you have already
>> volunteered
>> to create such case studies. Now I would like to throw open the doors a
>> little
>> more widely.
>>
>> What we are looking for are short, concise overviews of how and why
>> OrganizationX is interested in and engaged with OpenChain educational
>> material, the specification and/or conformance. In providing this
>> overviews
>> we can fulfill the need to answer one of the most important questions
>> around
>> our project: “how do I get started?"
>>
>> Here is the Case Studies document:
>> https://docs.google.com/document/d/15I4xvB-
>> UNXG_z4q0LFUhiwZaj2ehLJYwXqMwURomZCk/edit#heading=h.6l9ziyuob6dq
>> (Edit at will!)
>>
>> Regards
>>
>> Shane
>>
>> --
>> Shane Coughlan
>> OpenChain Project Director
>> e: coughlan@...
>> p: +81 (0) 80 4035 8083
>> w: www.openchainproject.org
>>
>> Professional profile: http://www.linkedin.com/in/shanecoughlan
>>
>> Get my free book on open source compliance here:
>> https://www.linuxfoundation.org/news-media/research/practical-gpl-
>> compliance
>>
>> _______________________________________________
>> OpenChain mailing list
>> OpenChain@...
>> https://lists.linuxfoundation.org/mailman/listinfo/openchain


OpenChain: The questions about Conformance

Shane Coughlan <coughlan@...>
 

Dear All

Malcolm raised some interesting questions that he is receiving from clients. These align neatly with the types of question I am encountering in Japan.

Here they are. Thoughts, comments and suggestions regarding answering these items are most welcome. I suspect that if we put our heads together we can get the best results:
- what are the biggest challenges to conformance?
- how much of this can be "automated"?
- Is there any (FOSS) (SaaS) "workflow management" software adapted to OC
processes and templates?
- how much time do we have to invest in this?
- who should be / has to be involved? (e.g. QA guys)
- where can I find templates for OC documents and processes? (e.g. process
maps or FOSS policy templates)
- what skills are needed for "OC coordinator team"?
- what are the quick wins that can help me sell this around the
organization?

Regards

Shane


--
Shane Coughlan
OpenChain Project Director
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

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

Get my free book on open source compliance here:
https://www.linuxfoundation.org/news-media/research/practical-gpl-compliance


OpenChain Report: Summary of the Japan Work Group meeting on the 22nd February

Shane Coughlan <coughlan@...>
 

This report comes thanks to Imada San of Hitachi. Thank you Imada San!

==

I summarized the discussion points about the certification at the last Japan WG meeting,
because this discussion contains good points.

At the Japan WG meeting, the question was raised:
"Why did not the number of the OpenChain compliant company increase?
Are there obstacles to be overcome?"

The members discussed:
(1)
Even if staff think their practices are good,
staff cannot judge their practices are good enough and do not know what quality they have,
because there is no consensus, or common practices shared by their industry.
Staff always are afraid that their practices are not good on the level, and their self-check is not precise.
Nobody gives advice. There are no measure of the quality.

An idea to resolve this issue is to share practices and knowledge about compliance within the trusted environment/relationship.
In this way, we can make and share common sense or common knowledge about OSS compliance.

Another idea is the certification by a third party company.
A third party certification company can give the authority.
A third party certification company can collect and store common knowledge through its certification with many companies.
(But this can only be taken by affordable companies.)

(2)
Big Japanese companies usually do not have an appropriate Officer to authorize OSS compliance.

Even if staff like us perform self-test of conformance, nobody can authorize its conformance on behalf of its company.
To declare conformance may cause usage of company logo and external inquiries.
But staff cannot undertake such responsibilities.

The members think these two are the obstacles peculiar to Japan. (but not everyone is in consensus)

I think this is not the conclusion and we should analyze these points deeper and more precise.


OpenChain Update: New version of the Conformance Web App available

Shane Coughlan <coughlan@...>
 

Dear OpenChain Community!

I wanted to flag that Gary and his team have released a new version of the OpenChain Conformance Web App. This version introduces support for conformance with different versions of the OpenChain Specification. Today it supports OpenChain Spec 1.0 and 1.1, and naturally we will introduce support for 1.2 when we reach formal release in April.

As always the Conformance Web App can be accessed easily online:
https://certification.openchainproject.org

We would like to encourage everyone with an interest in OpenChain to take a look and to consider self-certifying. It is free, quick and private with no time limit or obligation required. Only conforming organizations are listed on our site.

Regards

Shane


Re: OpenChain - A Call for Case Studies

Shane Coughlan <coughlan@...>
 

Hi Malcolm!

We seem to have a lot of interest around both case studies and example processes, but we are not yet seeing much organic community contribution in these areas. It would be great if we could explore using the Legal Network event as a way to sit everyone down and get some stuff reviewed. I am adding Polina, the coordinator, to this thread for reference.

On a related note, thanks for sharing the big questions you are getting, and I can immediately respond that I am finding questions elsewhere much along these lines. Perhaps an opportunity for Team OpenChain to provide some answers :)

Regards

Shane

On Feb 22, 2018, at 3:15, Malcolm Bain <malcolm.bain@...> wrote:

Ha! That was going to be one of my proposals for a workshop at LLW18...
building collaboratively a battery of OC case studies (in a 2 h sprint...)
to then be published.

We did this in the ASTP (tech transfer association) software SIG at the
annual event in Portugal; and came up with 8 case studies (on the basis of a
template) within 2 hours, and 25 tech transfer officers having a very
intense dose of software IPR management and licensing - very educational. I
then had to write the bloody things up into more or less proper English. :-)

In the end I did not propose this for the LLW - needed more OC-list support
(you guys) and didn't have time to drum up interest (I know you are keen!),
but if we don't move forward offline on Shane's call to arms, and if there
are a number of us at the LLW, we could try offering this as a session (the
CFP is "closed", but always wiggle room for sending something in a bit
late). I think it would be both instructive for those attending (both OC
experts and passive listeners) and useful in terms of output.

I'll try to put in some text relating to my current OC audit (dragging on..)
but need OK for company name to be released.

Re. answering questions, the big questions I am getting (that could be
considered within a case study) are:
- what are the biggest challenges?
- how much of this can be "automated"?
- Is there any (FOSS) (SaaS) "workflow management" software adapted to OC
processes and templates?
- how much time do we have to invest in this?
- who should be / has to be involved? (e.g. QA guys)
- where can I find templates for OC documents and processes? (e.g. process
maps, thank you Armijn/Shane, or FOSS policy templates (thank you Linux
Fondation)
- what skills are needed for "OC coordinator team"?
- what are the quick wins that can help me sell this around the
organization?
- what clauses can I put in my supply contracts to require upstream
conformance?

Best

malcolm


-----Mensaje original-----
De: openchain-bounces@... [mailto:openchain-
bounces@...] En nombre de Shane Coughlan
Enviado el: jueves, 22 de febrero de 2018 11:30
Para: openchain@...
Asunto: [OpenChain] OpenChain - A Call for Case Studies

Dear All

I wanted to announce a call for case studies. This is one of the number
one
items raised by potential participants. Some of you have already
volunteered
to create such case studies. Now I would like to throw open the doors a
little
more widely.

What we are looking for are short, concise overviews of how and why
OrganizationX is interested in and engaged with OpenChain educational
material, the specification and/or conformance. In providing this
overviews
we can fulfill the need to answer one of the most important questions
around
our project: “how do I get started?"

Here is the Case Studies document:
https://docs.google.com/document/d/15I4xvB-
UNXG_z4q0LFUhiwZaj2ehLJYwXqMwURomZCk/edit#heading=h.6l9ziyuob6dq
(Edit at will!)

Regards

Shane

--
Shane Coughlan
OpenChain Project Director
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

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

Get my free book on open source compliance here:
https://www.linuxfoundation.org/news-media/research/practical-gpl-
compliance

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


Re: Software Evidence Archive (SEvA)

JC Herz <jc.herz@...>
 

Hi -

The intent is to prevent an entity from assembling, packaging and charging for SEVAs as a free rider. So for instance: load a bunch of projects into Ion Channel via API, extract the result and resell as a commercial product. 

Any commercial entity would be able to use SEVAs for their own internal security purposes, but not as third-party certification or attestation to sell their product. If they want that (i.e. it has business value) it makes sense for them to sign up for a subscription that confers that right.

If there’s a narrower non-resale license that serves that purpose, would be grateful for a link or reference to it.



JC



On Feb 22, 2018, at 7:09 PM, John Scott <john@...> wrote:

SPDX seemed to only contain data around licensing and bills of materials (for dependencies) but didn’t include data around what tests were run, virus scanning, etc. results for a particular build of software or source  code. 

the main part for non-commercial was to limit license forking 


-------------------------------------------
John Scott, President
Selection Pressure LLC
 240.401.6574 @johnmscott
< john@...  >

On February 22, 2018 at 6:39:57 PM, Alan Tse (alan.tse@...) wrote:

Thanks for sharing.  Some questions:

1.      Is your intent with the non-commercial use provision to mean no commercial entities can use the format?  Or was it to prohibit people from charging?  If it’s the latter, the license choice may be too broad.  An issue I see with a NC license is that this may limit any potential adoption because commercial entities are primarily the entities that would use this type of data.

2.      Have you taken a look at SPDX for the license meta-data?  While SEvA is a broader solution, there may be some duplication in efforts on the license side that can be avoided.

 

Alan D. Tse

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of John Scott
Sent: Thursday, February 22, 2018 2:55 PM
To: openchain@...
Subject: [OpenChain] Software Evidence Archive (SEvA)

 

Hi All:

I’ve been on the list for a while and wanted to share some work we’re been doing. The issues we’ve been trying to solve is the portability and sharing of meta-data around a piece of software. For instance analysis that is completed in one place and needs to move with the software.

 

To solve that we’ve come up a with a XML/JSON format to ship results around, GitHub repo here: 

thanks, js

 

Software Evidence Archive (SEvA)

SEvA is specification for encapsulating software supply chain metadata and delivering with a clear and concise schema for parsing using automation. The SEvA definition is divided into several sections. There is a brief description of each section listed below.

License

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License.

Product and version information

Contains any product naming or version related information.

File and mime type information

Contains any file types detected within the source artifact or source repository. It also contains the related mime types for each file detected.

Authoritative source information

Contains any information about what is to be considered the authoritative source for ad given artifact or source repository. This includes a URL, hash of the source and whether or not the source has been signed.

Ecosystem and community information

Contains information pertaining to a software projects ecosystem (programming languages, urls, etc.) and community information (number of committers, mailing list activity, overall sentiment, etc).

Dependency information

Contains a list of dependencies (naming, versions, vulnerabilities) for a given software project derived directly from the artifact or source dependency definition file.

License information

Contains any license information detected from a given artifact or source.

Vulnerability and virus information

Contains any vulnerability or virus definitions detected from the artifact or source repository.

Result of GRC information

Contains the calculated risk and compliance to governance from the analysis of the software artifact or source repository.

Delivery information

Contains any delivery information including the target url and last delivered date and time. This will not include any information for the current delivery as the seva is signed prior to delivery.

 

-------------------------------------------

John Scott, President

Selection Pressure LLC

 240.401.6574 @johnmscott

< john@...  >



Re: Software Evidence Archive (SEvA)

Steve Cropper
 

Hi John:

Some good work here.

SPDX version 2.0... was created with a software supply chain in mind. 

It seems to me that SPDX would be a subset of the data you want to track but should form a basis for what you want to do. There is flexibility in the spec to allow additional information, similar to that you have indicated, using the File or Annotation properties. 

Using the “File Information” you could supplement the SPDX content with an xml/rdf or other file with your specific meta data additions and use the file meta data to describe the file it’s usage and licensing.

Using the “Annotations” property you can provide package “review” type information or “other” information that can contain the information you intend to capture. Since the “Annotation Comment” is free form text you can insert formatted meta data if you wish.

As Kate and others have said, if you think the meta data you are capturing has a wider application then I would encourage participation in the SPDX working group to propose spec enhancements.

Best Regards
Steve

Steve Cropper
+44 7982 525 965


On Feb 23, 2018, at 00:09, John Scott <john@...> wrote:

SPDX seemed to only contain data around licensing and bills of materials (for dependencies) but didn’t include data around what tests were run, virus scanning, etc. results for a particular build of software or source  code. 

the main part for non-commercial was to limit license forking 


-------------------------------------------
John Scott, President
Selection Pressure LLC
 240.401.6574 @johnmscott
< john@...  >

On February 22, 2018 at 6:39:57 PM, Alan Tse (alan.tse@...) wrote:

Thanks for sharing.  Some questions:

1.      Is your intent with the non-commercial use provision to mean no commercial entities can use the format?  Or was it to prohibit people from charging?  If it’s the latter, the license choice may be too broad.  An issue I see with a NC license is that this may limit any potential adoption because commercial entities are primarily the entities that would use this type of data.

2.      Have you taken a look at SPDX for the license meta-data?  While SEvA is a broader solution, there may be some duplication in efforts on the license side that can be avoided.

 

Alan D. Tse

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of John Scott
Sent: Thursday, February 22, 2018 2:55 PM
To: openchain@...
Subject: [OpenChain] Software Evidence Archive (SEvA)

 

Hi All:

I’ve been on the list for a while and wanted to share some work we’re been doing. The issues we’ve been trying to solve is the portability and sharing of meta-data around a piece of software. For instance analysis that is completed in one place and needs to move with the software.

 

To solve that we’ve come up a with a XML/JSON format to ship results around, GitHub repo here: 

thanks, js

 

Software Evidence Archive (SEvA)

SEvA is specification for encapsulating software supply chain metadata and delivering with a clear and concise schema for parsing using automation. The SEvA definition is divided into several sections. There is a brief description of each section listed below.

License

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License.

Product and version information

Contains any product naming or version related information.

File and mime type information

Contains any file types detected within the source artifact or source repository. It also contains the related mime types for each file detected.

Authoritative source information

Contains any information about what is to be considered the authoritative source for ad given artifact or source repository. This includes a URL, hash of the source and whether or not the source has been signed.

Ecosystem and community information

Contains information pertaining to a software projects ecosystem (programming languages, urls, etc.) and community information (number of committers, mailing list activity, overall sentiment, etc).

Dependency information

Contains a list of dependencies (naming, versions, vulnerabilities) for a given software project derived directly from the artifact or source dependency definition file.

License information

Contains any license information detected from a given artifact or source.

Vulnerability and virus information

Contains any vulnerability or virus definitions detected from the artifact or source repository.

Result of GRC information

Contains the calculated risk and compliance to governance from the analysis of the software artifact or source repository.

Delivery information

Contains any delivery information including the target url and last delivered date and time. This will not include any information for the current delivery as the seva is signed prior to delivery.

 

-------------------------------------------

John Scott, President

Selection Pressure LLC

 240.401.6574 @johnmscott

< john@...  >

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


Re: Software Evidence Archive (SEvA)

Camille Moulin
 

Hi Scott,

Thanks for sharing, tt seems very interesting.

One question about the licence, though: why the NC clause in your CC-BY-NC-SA-3.0 licence ?

Best,

Camille


Le 22/02/2018 à 23:54, John Scott a écrit :

Hi All:
I’ve been on the list for a while and wanted to share some work we’re been doing. The issues we’ve been trying to solve is the portability and sharing of meta-data around a piece of software. For instance analysis that is completed in one place and needs to move with the software.

To solve that we’ve come up a with a XML/JSON format to ship results around, GitHub repo here: 
thanks, js

Software Evidence Archive (SEvA)

SEvA is specification for encapsulating software supply chain metadata and delivering with a clear and concise schema for parsing using automation. The SEvA definition is divided into several sections. There is a brief description of each section listed below.

License

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License.

Product and version information

Contains any product naming or version related information.

File and mime type information

Contains any file types detected within the source artifact or source repository. It also contains the related mime types for each file detected.

Authoritative source information

Contains any information about what is to be considered the authoritative source for ad given artifact or source repository. This includes a URL, hash of the source and whether or not the source has been signed.

Ecosystem and community information

Contains information pertaining to a software projects ecosystem (programming languages, urls, etc.) and community information (number of committers, mailing list activity, overall sentiment, etc).

Dependency information

Contains a list of dependencies (naming, versions, vulnerabilities) for a given software project derived directly from the artifact or source dependency definition file.

License information

Contains any license information detected from a given artifact or source.

Vulnerability and virus information

Contains any vulnerability or virus definitions detected from the artifact or source repository.

Result of GRC information

Contains the calculated risk and compliance to governance from the analysis of the software artifact or source repository.

Delivery information

Contains any delivery information including the target url and last delivered date and time. This will not include any information for the current delivery as the seva is signed prior to delivery.


-------------------------------------------
John Scott, President
Selection Pressure LLC
 240.401.6574 @johnmscott
< john@...  >


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


Re: Software Evidence Archive (SEvA)

Kate Stewart
 

Hi John,
    Thanks for sharing the information on SEvA.   

    In scanning through the repository,  its not clear to me that when you're using <licenses>3DFX</licenses>, are you expecting them to licenses 
off the SPDX license list?   are SPDX license expressions ok?

Also,   for the fields that are in common with SPDX (Software Package Data eXchange),  
to promote interoperability,  are you using the same data formatting/parsing constraints?
I can't quite tell from the descriptions I'm finding, but feel free to point me to details. :-)
The package level fields that are likely to overlap with SPDX are described in

Also, If you want to propose the format for some of the fields that the SPDX
specification doesn't have,  we're working on the 2.2 version of the specification
at the moment, and submitting issues to the github repository, gets the proposal
on the discussion list. 

Kate


On Thu, Feb 22, 2018 at 6:09 PM, John Scott <john@...> wrote:
SPDX seemed to only contain data around licensing and bills of materials (for dependencies) but didn’t include data around what tests were run, virus scanning, etc. results for a particular build of software or source  code. 

the main part for non-commercial was to limit license forking 


-------------------------------------------
John Scott, President
Selection Pressure LLC
 240.401.6574 @johnmscott
< john@...  >

On February 22, 2018 at 6:39:57 PM, Alan Tse (alan.tse@...) wrote:

Thanks for sharing.  Some questions:

1.      Is your intent with the non-commercial use provision to mean no commercial entities can use the format?  Or was it to prohibit people from charging?  If it’s the latter, the license choice may be too broad.  An issue I see with a NC license is that this may limit any potential adoption because commercial entities are primarily the entities that would use this type of data.

2.      Have you taken a look at SPDX for the license meta-data?  While SEvA is a broader solution, there may be some duplication in efforts on the license side that can be avoided.

 

Alan D. Tse

 

From: openchain-bounces@lists.linuxfoundation.org [mailto:openchain-bounces@lists.linuxfoundation.org] On Behalf Of John Scott
Sent: Thursday, February 22, 2018 2:55 PM
To: openchain@lists.linuxfoundation.org
Subject: [OpenChain] Software Evidence Archive (SEvA)

 

Hi All:

I’ve been on the list for a while and wanted to share some work we’re been doing. The issues we’ve been trying to solve is the portability and sharing of meta-data around a piece of software. For instance analysis that is completed in one place and needs to move with the software.

 

To solve that we’ve come up a with a XML/JSON format to ship results around, GitHub repo here: 

thanks, js

 

Software Evidence Archive (SEvA)

SEvA is specification for encapsulating software supply chain metadata and delivering with a clear and concise schema for parsing using automation. The SEvA definition is divided into several sections. There is a brief description of each section listed below.

License

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License.

Product and version information

Contains any product naming or version related information.

File and mime type information

Contains any file types detected within the source artifact or source repository. It also contains the related mime types for each file detected.

Authoritative source information

Contains any information about what is to be considered the authoritative source for ad given artifact or source repository. This includes a URL, hash of the source and whether or not the source has been signed.

Ecosystem and community information

Contains information pertaining to a software projects ecosystem (programming languages, urls, etc.) and community information (number of committers, mailing list activity, overall sentiment, etc).

Dependency information

Contains a list of dependencies (naming, versions, vulnerabilities) for a given software project derived directly from the artifact or source dependency definition file.

License information

Contains any license information detected from a given artifact or source.

Vulnerability and virus information

Contains any vulnerability or virus definitions detected from the artifact or source repository.

Result of GRC information

Contains the calculated risk and compliance to governance from the analysis of the software artifact or source repository.

Delivery information

Contains any delivery information including the target url and last delivered date and time. This will not include any information for the current delivery as the seva is signed prior to delivery.

 

-------------------------------------------

John Scott, President

Selection Pressure LLC

 240.401.6574 @johnmscott

< john@...  >


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



Re: Software Evidence Archive (SEvA)

john
 

SPDX seemed to only contain data around licensing and bills of materials (for dependencies) but didn’t include data around what tests were run, virus scanning, etc. results for a particular build of software or source  code. 

the main part for non-commercial was to limit license forking 


-------------------------------------------
John Scott, President
Selection Pressure LLC
 240.401.6574 @johnmscott
< john@...  >
www.selectpress.net

On February 22, 2018 at 6:39:57 PM, Alan Tse (alan.tse@...) wrote:

Thanks for sharing.  Some questions:

1.      Is your intent with the non-commercial use provision to mean no commercial entities can use the format?  Or was it to prohibit people from charging?  If it’s the latter, the license choice may be too broad.  An issue I see with a NC license is that this may limit any potential adoption because commercial entities are primarily the entities that would use this type of data.

2.      Have you taken a look at SPDX for the license meta-data?  While SEvA is a broader solution, there may be some duplication in efforts on the license side that can be avoided.

 

Alan D. Tse

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of John Scott
Sent: Thursday, February 22, 2018 2:55 PM
To: openchain@...
Subject: [OpenChain] Software Evidence Archive (SEvA)

 

Hi All:

I’ve been on the list for a while and wanted to share some work we’re been doing. The issues we’ve been trying to solve is the portability and sharing of meta-data around a piece of software. For instance analysis that is completed in one place and needs to move with the software.

 

To solve that we’ve come up a with a XML/JSON format to ship results around, GitHub repo here: 

thanks, js

 

Software Evidence Archive (SEvA)

SEvA is specification for encapsulating software supply chain metadata and delivering with a clear and concise schema for parsing using automation. The SEvA definition is divided into several sections. There is a brief description of each section listed below.

License

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License.

Product and version information

Contains any product naming or version related information.

File and mime type information

Contains any file types detected within the source artifact or source repository. It also contains the related mime types for each file detected.

Authoritative source information

Contains any information about what is to be considered the authoritative source for ad given artifact or source repository. This includes a URL, hash of the source and whether or not the source has been signed.

Ecosystem and community information

Contains information pertaining to a software projects ecosystem (programming languages, urls, etc.) and community information (number of committers, mailing list activity, overall sentiment, etc).

Dependency information

Contains a list of dependencies (naming, versions, vulnerabilities) for a given software project derived directly from the artifact or source dependency definition file.

License information

Contains any license information detected from a given artifact or source.

Vulnerability and virus information

Contains any vulnerability or virus definitions detected from the artifact or source repository.

Result of GRC information

Contains the calculated risk and compliance to governance from the analysis of the software artifact or source repository.

Delivery information

Contains any delivery information including the target url and last delivered date and time. This will not include any information for the current delivery as the seva is signed prior to delivery.

 

-------------------------------------------

John Scott, President

Selection Pressure LLC

 240.401.6574 @johnmscott

< john@...  >


Re: Software Evidence Archive (SEvA)

Alan Tse
 

Thanks for sharing.  Some questions:

1.      Is your intent with the non-commercial use provision to mean no commercial entities can use the format?  Or was it to prohibit people from charging?  If it’s the latter, the license choice may be too broad.  An issue I see with a NC license is that this may limit any potential adoption because commercial entities are primarily the entities that would use this type of data.

2.      Have you taken a look at SPDX for the license meta-data?  While SEvA is a broader solution, there may be some duplication in efforts on the license side that can be avoided.

 

Alan D. Tse

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of John Scott
Sent: Thursday, February 22, 2018 2:55 PM
To: openchain@...
Subject: [OpenChain] Software Evidence Archive (SEvA)

 

Hi All:

I’ve been on the list for a while and wanted to share some work we’re been doing. The issues we’ve been trying to solve is the portability and sharing of meta-data around a piece of software. For instance analysis that is completed in one place and needs to move with the software.

 

To solve that we’ve come up a with a XML/JSON format to ship results around, GitHub repo here: 

thanks, js

 

Software Evidence Archive (SEvA)

SEvA is specification for encapsulating software supply chain metadata and delivering with a clear and concise schema for parsing using automation. The SEvA definition is divided into several sections. There is a brief description of each section listed below.

License

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License.

Product and version information

Contains any product naming or version related information.

File and mime type information

Contains any file types detected within the source artifact or source repository. It also contains the related mime types for each file detected.

Authoritative source information

Contains any information about what is to be considered the authoritative source for ad given artifact or source repository. This includes a URL, hash of the source and whether or not the source has been signed.

Ecosystem and community information

Contains information pertaining to a software projects ecosystem (programming languages, urls, etc.) and community information (number of committers, mailing list activity, overall sentiment, etc).

Dependency information

Contains a list of dependencies (naming, versions, vulnerabilities) for a given software project derived directly from the artifact or source dependency definition file.

License information

Contains any license information detected from a given artifact or source.

Vulnerability and virus information

Contains any vulnerability or virus definitions detected from the artifact or source repository.

Result of GRC information

Contains the calculated risk and compliance to governance from the analysis of the software artifact or source repository.

Delivery information

Contains any delivery information including the target url and last delivered date and time. This will not include any information for the current delivery as the seva is signed prior to delivery.

 

-------------------------------------------

John Scott, President

Selection Pressure LLC

 240.401.6574 @johnmscott

< john@...  >


Software Evidence Archive (SEvA)

john
 

Hi All:
I’ve been on the list for a while and wanted to share some work we’re been doing. The issues we’ve been trying to solve is the portability and sharing of meta-data around a piece of software. For instance analysis that is completed in one place and needs to move with the software.

To solve that we’ve come up a with a XML/JSON format to ship results around, GitHub repo here: 
thanks, js

Software Evidence Archive (SEvA)

SEvA is specification for encapsulating software supply chain metadata and delivering with a clear and concise schema for parsing using automation. The SEvA definition is divided into several sections. There is a brief description of each section listed below.

License

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License.

Product and version information

Contains any product naming or version related information.

File and mime type information

Contains any file types detected within the source artifact or source repository. It also contains the related mime types for each file detected.

Authoritative source information

Contains any information about what is to be considered the authoritative source for ad given artifact or source repository. This includes a URL, hash of the source and whether or not the source has been signed.

Ecosystem and community information

Contains information pertaining to a software projects ecosystem (programming languages, urls, etc.) and community information (number of committers, mailing list activity, overall sentiment, etc).

Dependency information

Contains a list of dependencies (naming, versions, vulnerabilities) for a given software project derived directly from the artifact or source dependency definition file.

License information

Contains any license information detected from a given artifact or source.

Vulnerability and virus information

Contains any vulnerability or virus definitions detected from the artifact or source repository.

Result of GRC information

Contains the calculated risk and compliance to governance from the analysis of the software artifact or source repository.

Delivery information

Contains any delivery information including the target url and last delivered date and time. This will not include any information for the current delivery as the seva is signed prior to delivery.


-------------------------------------------
John Scott, President
Selection Pressure LLC
 240.401.6574 @johnmscott
< john@...  >
www.selectpress.net


Re: OpenChain - A Call for Case Studies

Malcolm Bain
 

Ha! That was going to be one of my proposals for a workshop at LLW18...
building collaboratively a battery of OC case studies (in a 2 h sprint...)
to then be published.

We did this in the ASTP (tech transfer association) software SIG at the
annual event in Portugal; and came up with 8 case studies (on the basis of a
template) within 2 hours, and 25 tech transfer officers having a very
intense dose of software IPR management and licensing - very educational. I
then had to write the bloody things up into more or less proper English. :-)

In the end I did not propose this for the LLW - needed more OC-list support
(you guys) and didn't have time to drum up interest (I know you are keen!),
but if we don't move forward offline on Shane's call to arms, and if there
are a number of us at the LLW, we could try offering this as a session (the
CFP is "closed", but always wiggle room for sending something in a bit
late). I think it would be both instructive for those attending (both OC
experts and passive listeners) and useful in terms of output.

I'll try to put in some text relating to my current OC audit (dragging on..)
but need OK for company name to be released.

Re. answering questions, the big questions I am getting (that could be
considered within a case study) are:
- what are the biggest challenges?
- how much of this can be "automated"?
- Is there any (FOSS) (SaaS) "workflow management" software adapted to OC
processes and templates?
- how much time do we have to invest in this?
- who should be / has to be involved? (e.g. QA guys)
- where can I find templates for OC documents and processes? (e.g. process
maps, thank you Armijn/Shane, or FOSS policy templates (thank you Linux
Fondation)
- what skills are needed for "OC coordinator team"?
- what are the quick wins that can help me sell this around the
organization?
- what clauses can I put in my supply contracts to require upstream
conformance?

Best

malcolm

-----Mensaje original-----
De: openchain-bounces@... [mailto:openchain-
bounces@...] En nombre de Shane Coughlan
Enviado el: jueves, 22 de febrero de 2018 11:30
Para: openchain@...
Asunto: [OpenChain] OpenChain - A Call for Case Studies

Dear All

I wanted to announce a call for case studies. This is one of the number
one
items raised by potential participants. Some of you have already
volunteered
to create such case studies. Now I would like to throw open the doors a
little
more widely.

What we are looking for are short, concise overviews of how and why
OrganizationX is interested in and engaged with OpenChain educational
material, the specification and/or conformance. In providing this
overviews
we can fulfill the need to answer one of the most important questions
around
our project: “how do I get started?"

Here is the Case Studies document:
https://docs.google.com/document/d/15I4xvB-
UNXG_z4q0LFUhiwZaj2ehLJYwXqMwURomZCk/edit#heading=h.6l9ziyuob6dq
(Edit at will!)

Regards

Shane

--
Shane Coughlan
OpenChain Project Director
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

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

Get my free book on open source compliance here:
https://www.linuxfoundation.org/news-media/research/practical-gpl-
compliance

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


OpenChain - A Call for Case Studies

Shane Coughlan <coughlan@...>
 

Dear All

I wanted to announce a call for case studies. This is one of the number one items raised by potential participants. Some of you have already volunteered to create such case studies. Now I would like to throw open the doors a little more widely.

What we are looking for are short, concise overviews of how and why OrganizationX is interested in and engaged with OpenChain educational material, the specification and/or conformance. In providing this overviews we can fulfill the need to answer one of the most important questions around our project: “how do I get started?"

Here is the Case Studies document:
https://docs.google.com/document/d/15I4xvB-UNXG_z4q0LFUhiwZaj2ehLJYwXqMwURomZCk/edit#heading=h.6l9ziyuob6dq
(Edit at will!)

Regards

Shane

--
Shane Coughlan
OpenChain Project Director
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

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

Get my free book on open source compliance here:
https://www.linuxfoundation.org/news-media/research/practical-gpl-compliance


OpenChain - Reference Open Source Compliance Tooling

Shane Coughlan <coughlan@...>
 

Hi Team OpenChain!

I took a spin at revisiting our Reference Open Source Compliance Tooling and splitting things between Inside Organizations vs Between Organizations. Feedback and further improvements most welcome.

Open Source - Open Source Compliance Tooling
https://docs.google.com/document/d/1rzOs8JJtsvKIJ0kxO3uJVERtcEj87BtA5AjT2SaulhY/edit#

Regards

Shane


--
Shane Coughlan
OpenChain Project Director
e: coughlan@...
p: +81 (0) 80 4035 8083
w: www.openchainproject.org

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

Get my free book on open source compliance here:
https://www.linuxfoundation.org/news-media/research/practical-gpl-compliance

3421 - 3440 of 4814