A note on some deliverables


Joseph Potvin
 

Hello all,

In today's OpenChain call I offered the following:

1. Prepare a couple of sample License Interaction Diagrams (LIDs ...To whom to we credit that clever name??) based on appropriate UML and/or BPL diagrams. This will be a topic for our next call.

2. Adapt and share a diagram that helps to visualize the role of a compliance management system in relation to reducing undercertainty and managing risk.

3. Share my script for the three first episodes of the "FLOW Video" series which focus on the core concepts and precise reasons for decision in the Alice Corp v. CLS Bank case which was decided in June 2014. The audio and animation video are being done presently by the communications service of University of Southern Queensland. I'll post the script onto the FLOW Syllabus wiki, and send that link tomorrow, along with some thoughts about the significance of the rationale in that decision for applied compliance management.

Regards,

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

Chair, OSI Management Education Working Group
Coordinator, The FLOW Syllabus
http://wiki.opensource.org/bin/Projects/flow-syllabus
The Open Source Initiative

Doctoral Candidate, Project Management
Université du Québec



Joseph Potvin
 

Items 2 and 3...

2. I've adapted a diagram that helps to visualize the role of a compliance management system in relation to reducing uncertainty and managing risk.
http://wiki.opensource.org/bin/download/Projects/Structuring+the+FLOW+of+Responsibility/Uncertainty%20Risk_ComplianceManagementPDF.pdf
Comments & suggestions are welcome, of course. 
(The paper I adapted this from is located here: http://wiki.opensource.org/bin/Projects/The+Methodological+Significance+of+Uncertainty )

3. As mentioned during yesterday's call, here is a link to the script for the three first episodes of the "FLOW Video" series which focus on the core concepts and precise reasons for decision in the Alice Corp v. CLS Bank case. First some caveats:
(a) Episode 2 is about Alice Corp v. CLS Bank but does not identify case particulars, so that those details do not distract viewers from the core rationale;
(b) The three episodes are about "software patents" but the script never uses the word "software" and never uses the word "patent". Terms are chosen to be explicit and literal, to work around very common legally inaccurate perceptions about what software is, and what a patent is.
(c) The overall perspective asserted in these three episodes expresses that part of the Open Source community which shares views on this topic with the Free Software Foundation and the Software Freedom Law Centre (which jointly submitted an Amicus Brief in this case). The Open Source community is a 'big tent' but we chose to place this script in a strong orthodox free/libre perspective while putting this and (soon-to-be-published) audio and animation under the CC-BY license, so that anyone who finds it generally useful but requiring some tweaks to fit their own organization's perspective, can readily adapt it to do so.
http://wiki.opensource.org/bin/download/Projects/Constraints+on+the+FLOW+of+Ideas/FLOW_Video_Series_FINAL_9sep2014PDF.pdf
Comments & suggestions, again would be appreciated.

Regards,

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

Chair, OSI Management Education Working Group
Coordinator, The FLOW Syllabus
http://wiki.opensource.org/bin/Projects/flow-syllabus
The Open Source Initiative

Doctoral Candidate, Project Management
Université du Québec



On Tue, Nov 4, 2014 at 3:34 PM, Joseph Potvin <jpotvin@...> wrote:
Hello all,

In today's OpenChain call I offered the following:

1. Prepare a couple of sample License Interaction Diagrams (LIDs ...To whom to we credit that clever name??) based on appropriate UML and/or BPL diagrams. This will be a topic for our next call.

2. Adapt and share a diagram that helps to visualize the role of a compliance management system in relation to reducing undercertainty and managing risk.

3. Share my script for the three first episodes of the "FLOW Video" series which focus on the core concepts and precise reasons for decision in the Alice Corp v. CLS Bank case which was decided in June 2014. The audio and animation video are being done presently by the communications service of University of Southern Queensland. I'll post the script onto the FLOW Syllabus wiki, and send that link tomorrow, along with some thoughts about the significance of the rationale in that decision for applied compliance management.

Regards,

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

Chair, OSI Management Education Working Group
Coordinator, The FLOW Syllabus
http://wiki.opensource.org/bin/Projects/flow-syllabus
The Open Source Initiative

Doctoral Candidate, Project Management
Université du Québec





Jeremiah Foster <jeremiah.foster@...>
 



On Wed, Nov 5, 2014 at 6:41 PM, Joseph Potvin <jpotvin@...> wrote:
Items 2 and 3...

2. I've adapted a diagram that helps to visualize the role of a compliance management system in relation to reducing uncertainty and managing risk.
http://wiki.opensource.org/bin/download/Projects/Structuring+the+FLOW+of+Responsibility/Uncertainty%20Risk_ComplianceManagementPDF.pdf
Comments & suggestions are welcome, of course. 

In your first diagram, the implication is that there is no way to ever be 100% certain about the delivered code base, there will always be residual uncertainty. But code is finite, so theoretically you can have 100% certainty. Yes, practically speaking it is expensive, but there are companies that do this, for very large code bases. Yes, these are very large, very well capitalized companies, but the fact that this is known to occur makes your first slide misleading. You should show that it is possible to be certain about your code base 100%, i.e. zero residual uncertainty. 


Regards,

Jeremiah
 

3. As mentioned during yesterday's call, here is a link to the script for the three first episodes of the "FLOW Video" series which focus on the core concepts and precise reasons for decision in the Alice Corp v. CLS Bank case. First some caveats:
(a) Episode 2 is about Alice Corp v. CLS Bank but does not identify case particulars, so that those details do not distract viewers from the core rationale;
(b) The three episodes are about "software patents" but the script never uses the word "software" and never uses the word "patent". Terms are chosen to be explicit and literal, to work around very common legally inaccurate perceptions about what software is, and what a patent is.
(c) The overall perspective asserted in these three episodes expresses that part of the Open Source community which shares views on this topic with the Free Software Foundation and the Software Freedom Law Centre (which jointly submitted an Amicus Brief in this case). The Open Source community is a 'big tent' but we chose to place this script in a strong orthodox free/libre perspective while putting this and (soon-to-be-published) audio and animation under the CC-BY license, so that anyone who finds it generally useful but requiring some tweaks to fit their own organization's perspective, can readily adapt it to do so.
http://wiki.opensource.org/bin/download/Projects/Constraints+on+the+FLOW+of+Ideas/FLOW_Video_Series_FINAL_9sep2014PDF.pdf
Comments & suggestions, again would be appreciated.

Regards,

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

Chair, OSI Management Education Working Group
Coordinator, The FLOW Syllabus
http://wiki.opensource.org/bin/Projects/flow-syllabus
The Open Source Initiative

Doctoral Candidate, Project Management
Université du Québec



On Tue, Nov 4, 2014 at 3:34 PM, Joseph Potvin <jpotvin@...> wrote:
Hello all,

In today's OpenChain call I offered the following:

1. Prepare a couple of sample License Interaction Diagrams (LIDs ...To whom to we credit that clever name??) based on appropriate UML and/or BPL diagrams. This will be a topic for our next call.

2. Adapt and share a diagram that helps to visualize the role of a compliance management system in relation to reducing undercertainty and managing risk.

3. Share my script for the three first episodes of the "FLOW Video" series which focus on the core concepts and precise reasons for decision in the Alice Corp v. CLS Bank case which was decided in June 2014. The audio and animation video are being done presently by the communications service of University of Southern Queensland. I'll post the script onto the FLOW Syllabus wiki, and send that link tomorrow, along with some thoughts about the significance of the rationale in that decision for applied compliance management.

Regards,

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

Chair, OSI Management Education Working Group
Coordinator, The FLOW Syllabus
http://wiki.opensource.org/bin/Projects/flow-syllabus
The Open Source Initiative

Doctoral Candidate, Project Management
Université du Québec





_______________________________________________
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


Kelly Williams
 

Hi Joseph,

Thanks for following up on the action items. 

 

All,

I’ve posted the meeting notes and an example of a license interaction diagram on the wiki https://wiki.linuxfoundation.org/openchain/start?&#meeting-materials

 

Thanks,
Kelly

 

From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Joseph Potvin
Sent: Wednesday, November 05, 2014 9:42 AM
To: openchain@...
Cc: Ken Udas; Patrick Masson
Subject: Re: [OpenChain] A note on some deliverables

 

Items 2 and 3...

2. I've adapted a diagram that helps to visualize the role of a compliance management system in relation to reducing uncertainty and managing risk.
http://wiki.opensource.org/bin/download/Projects/Structuring+the+FLOW+of+Responsibility/Uncertainty%20Risk_ComplianceManagementPDF.pdf

Comments & suggestions are welcome, of course. 
(The paper I adapted this from is located here: http://wiki.opensource.org/bin/Projects/The+Methodological+Significance+of+Uncertainty )


3. As mentioned during yesterday's call, here is a link to the script for the three first episodes of the "FLOW Video" series which focus on the core concepts and precise reasons for decision in the Alice Corp v. CLS Bank case. First some caveats:

(a) Episode 2 is about Alice Corp v. CLS Bank but does not identify case particulars, so that those details do not distract viewers from the core rationale;

(b) The three episodes are about "software patents" but the script never uses the word "software" and never uses the word "patent". Terms are chosen to be explicit and literal, to work around very common legally inaccurate perceptions about what software is, and what a patent is.

(c) The overall perspective asserted in these three episodes expresses that part of the Open Source community which shares views on this topic with the Free Software Foundation and the Software Freedom Law Centre (which jointly submitted an Amicus Brief in this case). The Open Source community is a 'big tent' but we chose to place this script in a strong orthodox free/libre perspective while putting this and (soon-to-be-published) audio and animation under the CC-BY license, so that anyone who finds it generally useful but requiring some tweaks to fit their own organization's perspective, can readily adapt it to do so.
http://wiki.opensource.org/bin/download/Projects/Constraints+on+the+FLOW+of+Ideas/FLOW_Video_Series_FINAL_9sep2014PDF.pdf
Comments & suggestions, again would be appreciated.

Regards,


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

Chair, OSI Management Education Working Group
Coordinator, The FLOW Syllabus
http://wiki.opensource.org/bin/Projects/flow-syllabus
The Open Source Initiative

Doctoral Candidate, Project Management
Université du Québec

 

On Tue, Nov 4, 2014 at 3:34 PM, Joseph Potvin <jpotvin@...> wrote:

Hello all,

In today's OpenChain call I offered the following:

1. Prepare a couple of sample License Interaction Diagrams (LIDs ...To whom to we credit that clever name??) based on appropriate UML and/or BPL diagrams. This will be a topic for our next call.

2. Adapt and share a diagram that helps to visualize the role of a compliance management system in relation to reducing undercertainty and managing risk.

3. Share my script for the three first episodes of the "FLOW Video" series which focus on the core concepts and precise reasons for decision in the Alice Corp v. CLS Bank case which was decided in June 2014. The audio and animation video are being done presently by the communications service of University of Southern Queensland. I'll post the script onto the FLOW Syllabus wiki, and send that link tomorrow, along with some thoughts about the significance of the rationale in that decision for applied compliance management.

Regards,


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

Chair, OSI Management Education Working Group
Coordinator, The FLOW Syllabus
http://wiki.opensource.org/bin/Projects/flow-syllabus
The Open Source Initiative

Doctoral Candidate, Project Management
Université du Québec

 


Claus-Peter Wiedemann
 

Von: openchain-bounces@lists.linuxfoundation.org [mailto:openchain-
bounces@lists.linuxfoundation.org] Im Auftrag von Jeremiah Foster
Gesendet: Mittwoch, 5. November 2014 20:17
An: Joseph Potvin
Cc: openchain@lists.linuxfoundation.org; Ken Udas; Patrick Masson
Betreff: Re: [OpenChain] A note on some deliverables



On Wed, Nov 5, 2014 at 6:41 PM, Joseph Potvin <jpotvin@opman.ca> wrote:
Items 2 and 3...

2. I've adapted a diagram that helps to visualize the role of a compliance
management system in relation to reducing uncertainty and managing risk.
http://wiki.opensource.org/bin/download/Projects/Structuring+the+FLOW+
of+Responsibility/Uncertainty%20Risk_ComplianceManagementPDF.pdf
Comments & suggestions are welcome, of course.

In your first diagram, the implication is that there is no way to ever be 100%
certain about the delivered code base, there will always be residual
uncertainty. But code is finite, so theoretically you can have 100% certainty.
Yes, practically speaking it is expensive, but there are companies that do this,
for very large code bases. Yes, these are very large, very well capitalized
companies, but the fact that this is known to occur makes your first slide
misleading. You should show that it is possible to be certain about your code
base 100%, i.e. zero residual uncertainty.
I think that 100% certainty about license compliance of a given code base is not possible. Even if you use the most sophisticated tools available today, there is no 100% certainty that they are able to detect all third party code. Their databases are huge, but definitely not complete. You may think that you have 100% certainty that the tools detect what is in their database. But even this is not 100% since there may be a bug in the tool that prevents a piece of code being detected properly. The other dimension is the imprecise language in many licenses. This leaves room for interpretation and grey areas. So even if you know about all third party code and applicable licenses, and you fulfill all license obligations to the best of your knowledge, there is still some remaining risk that your interpretation of the license does match the intention of the licensor and a court of law finds that you are not compliant.

Best regards
Claus-Peter





Regards,

Jeremiah

(The paper I adapted this from is located here:
http://wiki.opensource.org/bin/Projects/The+Methodological+Significance+
of+Uncertainty )

3. As mentioned during yesterday's call, here is a link to the script for the
three first episodes of the "FLOW Video" series which focus on the core
concepts and precise reasons for decision in the Alice Corp v. CLS Bank case.
First some caveats:
(a) Episode 2 is about Alice Corp v. CLS Bank but does not identify case
particulars, so that those details do not distract viewers from the core
rationale;
(b) The three episodes are about "software patents" but the script never
uses the word "software" and never uses the word "patent". Terms are
chosen to be explicit and literal, to work around very common legally
inaccurate perceptions about what software is, and what a patent is.
(c) The overall perspective asserted in these three episodes expresses that
part of the Open Source community which shares views on this topic with the
Free Software Foundation and the Software Freedom Law Centre (which
jointly submitted an Amicus Brief in this case). The Open Source community
is a 'big tent' but we chose to place this script in a strong orthodox free/libre
perspective while putting this and (soon-to-be-published) audio and
animation under the CC-BY license, so that anyone who finds it generally
useful but requiring some tweaks to fit their own organization's perspective,
can readily adapt it to do so.
http://wiki.opensource.org/bin/download/Projects/Constraints+on+the+FL
OW+of+Ideas/FLOW_Video_Series_FINAL_9sep2014PDF.pdf
Comments & suggestions, again would be appreciated.
Regards,

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

Chair, OSI Management Education Working Group Coordinator, The FLOW
Syllabus http://wiki.opensource.org/bin/Projects/flow-syllabus
The Open Source Initiative

Doctoral Candidate, Project Management
Université du Québec

On Tue, Nov 4, 2014 at 3:34 PM, Joseph Potvin <jpotvin@opman.ca> wrote:
Hello all,

In today's OpenChain call I offered the following:
1. Prepare a couple of sample License Interaction Diagrams (LIDs ...To whom
to we credit that clever name??) based on appropriate UML and/or BPL
diagrams. This will be a topic for our next call.
2. Adapt and share a diagram that helps to visualize the role of a compliance
management system in relation to reducing undercertainty and managing
risk.
3. Share my script for the three first episodes of the "FLOW Video" series
which focus on the core concepts and precise reasons for decision in the
Alice Corp v. CLS Bank case which was decided in June 2014. The audio and
animation video are being done presently by the communications service of
University of Southern Queensland. I'll post the script onto the FLOW
Syllabus wiki, and send that link tomorrow, along with some thoughts about
the significance of the rationale in that decision for applied compliance
management.
Regards,

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

Chair, OSI Management Education Working Group Coordinator, The FLOW
Syllabus http://wiki.opensource.org/bin/Projects/flow-syllabus
The Open Source Initiative

Doctoral Candidate, Project Management
Université du Québec


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




--
Jeremiah C. Foster
GENIVI COMMUNITY MANAGER

Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18
Gothenburg, Sweden
M: +46 (0)73 093 0506
jeremiah.foster@pelagicore.com
________________________________
BearingPoint GmbH
Geschäftsführer: Marcel Nickler (Vorsitzender), Hans-Werner Wurzel (stellv. Vorsitzender), Kiumars Hamidian, Matthias Loebich, Kai Wächter, Dr. Robert Wagner
Vorsitzender des Aufsichtsrats: Beat Leimbacher
Sitz: Frankfurt am Main
Registergericht: Amtsgericht Frankfurt am Main HRB 55490


The information in this email is confidential and may be legally privileged. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.


Jeremiah Foster <jeremiah.foster@...>
 



On Thu, Nov 6, 2014 at 9:31 AM, Wiedemann, Claus-Peter <claus-peter.wiedemann@...> wrote:
> Von: openchain-bounces@... [mailto:openchain-
> bounces@...] Im Auftrag von Jeremiah Foster
> Gesendet: Mittwoch, 5. November 2014 20:17
> An: Joseph Potvin
> Cc: openchain@...; Ken Udas; Patrick Masson
> Betreff: Re: [OpenChain] A note on some deliverables
>
>
>
> On Wed, Nov 5, 2014 at 6:41 PM, Joseph Potvin <jpotvin@...> wrote:
> Items 2 and 3...
>
> 2. I've adapted a diagram that helps to visualize the role of a compliance
> management system in relation to reducing uncertainty and managing risk.
> http://wiki.opensource.org/bin/download/Projects/Structuring+the+FLOW+
> of+Responsibility/Uncertainty%20Risk_ComplianceManagementPDF.pdf
> Comments & suggestions are welcome, of course.
>
> In your first diagram, the implication is that there is no way to ever be 100%
> certain about the delivered code base, there will always be residual
> uncertainty. But code is finite, so theoretically you can have 100% certainty.
> Yes, practically speaking it is expensive, but there are companies that do this,
> for very large code bases. Yes, these are very large, very well capitalized
> companies, but the fact that this is known to occur makes your first slide
> misleading. You should show that it is possible to be certain about your code
> base 100%, i.e. zero residual uncertainty.

I think that 100% certainty about license compliance of a given code base is not possible.

It is possible. You have a finite set. You can determine, concretely, exactly what you have. The exercise of then assigning a one-to-one corresponding license on your finite code base can then be done. Doing that is the hard part. 
 
Even if you use the most sophisticated tools available today, there is no 100% certainty that they are able to detect all third party code.

The concept of "third party code" is an artificial abstraction used to make understanding the supply chain easier. It has no bearing on understanding the bounds of your code base. The goal is to determine provenance, regardless of "party." There is 100% certainty that you can detect all code. Software has physical properties, it takes up space on silicon, so you can measure it. It is complex, but it can be done, and is done.
 
Their databases are huge, but definitely not complete.

I would argue that the databases can only be about 30% complete. There have been some studies showing that (roughly) over the last decade about 70% of software developed has been proprietary. I think that is shifting, but its impossible to know for sure. If that is the case, then Open Source only makes up about 30% of the available code for a given database. In addition, that database won't know anything about new code. So the database may be able to provide a fair measure of certainty, including false positives and false negatives, on 30% of the extant, open code. Lastly, the known code is not the code that would likely be encumbered by patents and other so-called IP. Despite the fact that IP is undergoing some fundamental changes, you're still much more at risk by copying something from the 70% than you are from getting caught copying something from the code in the 30% database, the business risk of knowingly copying patents without agreement is treble damages. The risk from the same from FOSS is infinitesimal in comparison.

My point is that the database is only slightly helpful in reducing risk. It reflects due diligence, but for overall risk mitigation I'd argue its a questionable value proposition.
 
You may think that you have 100% certainty that the tools detect what is in their database. But even this is not 100% since there may be a bug in the tool that prevents a piece of code being detected properly. The other dimension is the imprecise language in many licenses. This leaves room for interpretation and grey areas. So even if you  know about all third party code and applicable licenses, and you fulfill all license obligations to the best of your knowledge, there is still some remaining risk that your interpretation of the license does match the intention of the licensor and a court of law finds that you are not compliant.

What I'm arguing is that approach is fundamentally wrong for assessing risk. It is taking a short cut that will have residual risk built in. There are ways to do it that leaves zero residual risk, at least theoretically. Practically there are companies that have demonstrated that they can operate at scale with zero risk of non-compliance with FOSS licenses. There is a business reason that Apple sat at the table when GPLv3 was being composed. 

Not demonstrating the condition that residual risk can be reduced to zero in the material that is promoting a proposed standard is misleading. 

Regards,

Jeremiah
 

Best regards
Claus-Peter

>
>
>
>
> Regards,
>
> Jeremiah
>
> (The paper I adapted this from is located here:
> http://wiki.opensource.org/bin/Projects/The+Methodological+Significance+
> of+Uncertainty )
>
> 3. As mentioned during yesterday's call, here is a link to the script for the
> three first episodes of the "FLOW Video" series which focus on the core
> concepts and precise reasons for decision in the Alice Corp v. CLS Bank case.
> First some caveats:
> (a) Episode 2 is about Alice Corp v. CLS Bank but does not identify case
> particulars, so that those details do not distract viewers from the core
> rationale;
> (b) The three episodes are about "software patents" but the script never
> uses the word "software" and never uses the word "patent". Terms are
> chosen to be explicit and literal, to work around very common legally
> inaccurate perceptions about what software is, and what a patent is.
> (c) The overall perspective asserted in these three episodes expresses that
> part of the Open Source community which shares views on this topic with the
> Free Software Foundation and the Software Freedom Law Centre (which
> jointly submitted an Amicus Brief in this case). The Open Source community
> is a 'big tent' but we chose to place this script in a strong orthodox free/libre
> perspective while putting this and (soon-to-be-published) audio and
> animation under the CC-BY license, so that anyone who finds it generally
> useful but requiring some tweaks to fit their own organization's perspective,
> can readily adapt it to do so.
> http://wiki.opensource.org/bin/download/Projects/Constraints+on+the+FL
> OW+of+Ideas/FLOW_Video_Series_FINAL_9sep2014PDF.pdf
> Comments & suggestions, again would be appreciated.
> Regards,
>
> Joseph Potvin
> Operations Manager | Gestionnaire des opérations The Opman Company |
> La compagnie Opman jpotvin@...
> Mobile: 819-593-5983M.Phil. MCPM
>
> Chair, OSI Management Education Working Group Coordinator, The FLOW
> Syllabus http://wiki.opensource.org/bin/Projects/flow-syllabus
> The Open Source Initiative
>
> Doctoral Candidate, Project Management
> Université du Québec
>
> On Tue, Nov 4, 2014 at 3:34 PM, Joseph Potvin <jpotvin@...> wrote:
> Hello all,
>
> In today's OpenChain call I offered the following:
> 1. Prepare a couple of sample License Interaction Diagrams (LIDs ...To whom
> to we credit that clever name??) based on appropriate UML and/or BPL
> diagrams. This will be a topic for our next call.
> 2. Adapt and share a diagram that helps to visualize the role of a compliance
> management system in relation to reducing undercertainty and managing
> risk.
> 3. Share my script for the three first episodes of the "FLOW Video" series
> which focus on the core concepts and precise reasons for decision in the
> Alice Corp v. CLS Bank case which was decided in June 2014. The audio and
> animation video are being done presently by the communications service of
> University of Southern Queensland. I'll post the script onto the FLOW
> Syllabus wiki, and send that link tomorrow, along with some thoughts about
> the significance of the rationale in that decision for applied compliance
> management.
> Regards,
>
> Joseph Potvin
> Operations Manager | Gestionnaire des opérations The Opman Company |
> La compagnie Opman jpotvin@...
> Mobile: 819-593-5983M.Phil. MCPM
>
> Chair, OSI Management Education Working Group Coordinator, The FLOW
> Syllabus http://wiki.opensource.org/bin/Projects/flow-syllabus
> The Open Source Initiative
>
> Doctoral Candidate, Project Management
> Université du Québec
>
>
> _______________________________________________
> 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
> jeremiah.foster@...

________________________________
 BearingPoint GmbH
Geschäftsführer: Marcel Nickler (Vorsitzender), Hans-Werner Wurzel (stellv. Vorsitzender), Kiumars Hamidian, Matthias Loebich, Kai Wächter, Dr. Robert Wagner
Vorsitzender des Aufsichtsrats: Beat Leimbacher
Sitz: Frankfurt am Main
Registergericht: Amtsgericht Frankfurt am Main HRB 55490


The information in this email is confidential and may be legally privileged. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.



--
Jeremiah C. Foster
GENIVI COMMUNITY MANAGER

Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18
Gothenburg, Sweden
M: +46 (0)73 093 0506


Oliver Fendt
 

Hi all,


On Wed, Nov 5, 2014 at 6:41 PM, Joseph Potvin <jpotvin@opman.ca> wrote:
Items 2 and 3...

2. I've adapted a diagram that helps to visualize the role of a
compliance management system in relation to reducing uncertainty and managing risk.
http://wiki.opensource.org/bin/download/Projects/Structuring+the+FLOW+
of+Responsibility/Uncertainty%20Risk_ComplianceManagementPDF.pdf
Comments & suggestions are welcome, of course.

In your first diagram, the implication is that there is no way to ever
be 100% certain about the delivered code base, there will always be
residual uncertainty. But code is finite, so theoretically you can have 100% certainty.
Yes, practically speaking it is expensive, but there are companies
that do this, for very large code bases. Yes, these are very large,
very well capitalized companies, but the fact that this is known to
occur makes your first slide misleading. You should show that it is
possible to be certain about your code base 100%, i.e. zero residual uncertainty.
I think that 100% certainty about license compliance of a given code base is not
possible. Even if you use the most sophisticated tools available today, there is no 100%
certainty that they are able to detect all third party code. Their databases are huge,
but definitely not complete. You may think that you have 100% certainty that the tools
detect what is in their database. But even this is not 100% since there may be a bug in
the tool that prevents a piece of code being detected properly. The other dimension is
the imprecise language in many licenses. This leaves room for interpretation and grey
areas. So even if you know about all third party code and applicable licenses, and you
fulfill all license obligations to the best of your knowledge, there is still some
remaining risk that your interpretation of the license does match the intention of the
licensor and a court of law finds that you are not compliant.

Best regards
Claus-Peter

[Oliver] I fully agree to Claus-Peter. Looking at an existing code base you never can be sure whether you know the real origin of every line of code and the "real" License of it. You can't be sure whether it is licensed by the copyright holder or whether it was copied by a person from one program to another program (which is licensed differently).
And as Claus-Peter pointed out all tools which we use or will use have errors. This is the nature of un-trivial programs (and such programs are not trivial). And last but not least no human being is able to identify all licenses and all origins of the code of a complex package like chromium (only as example) by "hand" this effort will take years and the result will be full of errors (random errors).
So uncertainty is normal, even in our lives.

Btw. The name "License Interaction Diagrams" was contributed by me. :-)

Best regards
Oliver




(The paper I adapted this from is located here:
http://wiki.opensource.org/bin/Projects/The+Methodological+Significanc
e+
of+Uncertainty )

3. As mentioned during yesterday's call, here is a link to the script
for the three first episodes of the "FLOW Video" series which focus on
the core concepts and precise reasons for decision in the Alice Corp v. CLS Bank case.
First some caveats:
(a) Episode 2 is about Alice Corp v. CLS Bank but does not identify
case particulars, so that those details do not distract viewers from
the core rationale;
(b) The three episodes are about "software patents" but the script
never uses the word "software" and never uses the word "patent". Terms
are chosen to be explicit and literal, to work around very common
legally inaccurate perceptions about what software is, and what a patent is.
(c) The overall perspective asserted in these three episodes expresses
that part of the Open Source community which shares views on this
topic with the Free Software Foundation and the Software Freedom Law
Centre (which jointly submitted an Amicus Brief in this case). The
Open Source community is a 'big tent' but we chose to place this
script in a strong orthodox free/libre perspective while putting this
and (soon-to-be-published) audio and animation under the CC-BY
license, so that anyone who finds it generally useful but requiring
some tweaks to fit their own organization's perspective, can readily adapt it to do so.
http://wiki.opensource.org/bin/download/Projects/Constraints+on+the+FL
OW+of+Ideas/FLOW_Video_Series_FINAL_9sep2014PDF.pdf
Comments & suggestions, again would be appreciated.
Regards,

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

Chair, OSI Management Education Working Group Coordinator, The FLOW
Syllabus http://wiki.opensource.org/bin/Projects/flow-syllabus
The Open Source Initiative

Doctoral Candidate, Project Management Université du Québec

On Tue, Nov 4, 2014 at 3:34 PM, Joseph Potvin <jpotvin@opman.ca> wrote:
Hello all,

In today's OpenChain call I offered the following:
1. Prepare a couple of sample License Interaction Diagrams (LIDs ...To
whom to we credit that clever name??) based on appropriate UML and/or
BPL diagrams. This will be a topic for our next call.
2. Adapt and share a diagram that helps to visualize the role of a
compliance management system in relation to reducing undercertainty
and managing risk.
3. Share my script for the three first episodes of the "FLOW Video"
series which focus on the core concepts and precise reasons for
decision in the Alice Corp v. CLS Bank case which was decided in June
2014. The audio and animation video are being done presently by the
communications service of University of Southern Queensland. I'll post
the script onto the FLOW Syllabus wiki, and send that link tomorrow,
along with some thoughts about the significance of the rationale in
that decision for applied compliance management.
Regards,

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

Chair, OSI Management Education Working Group Coordinator, The FLOW
Syllabus http://wiki.opensource.org/bin/Projects/flow-syllabus
The Open Source Initiative

Doctoral Candidate, Project Management Université du Québec


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




--
Jeremiah C. Foster
GENIVI COMMUNITY MANAGER

Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18
Gothenburg, Sweden
M: +46 (0)73 093 0506
jeremiah.foster@pelagicore.com
________________________________
BearingPoint GmbH
Geschäftsführer: Marcel Nickler (Vorsitzender), Hans-Werner Wurzel (stellv. Vorsitzender), Kiumars Hamidian, Matthias Loebich, Kai Wächter, Dr. Robert Wagner
Vorsitzender des Aufsichtsrats: Beat Leimbacher
Sitz: Frankfurt am Main
Registergericht: Amtsgericht Frankfurt am Main HRB 55490


The information in this email is confidential and may be legally privileged. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
_______________________________________________
OpenChain mailing list
OpenChain@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/openchain


Jeremiah Foster <jeremiah.foster@...>
 



On Thu, Nov 6, 2014 at 10:09 AM, Fendt, Oliver <oliver.fendt@...> wrote:
Hi all,

>>
>> On Wed, Nov 5, 2014 at 6:41 PM, Joseph Potvin <jpotvin@...> wrote:
>> Items 2 and 3...
>>
>> 2. I've adapted a diagram that helps to visualize the role of a
>> compliance management system in relation to reducing uncertainty and managing risk.
>> http://wiki.opensource.org/bin/download/Projects/Structuring+the+FLOW+
>> of+Responsibility/Uncertainty%20Risk_ComplianceManagementPDF.pdf
>> Comments & suggestions are welcome, of course.
>>
>> In your first diagram, the implication is that there is no way to ever
>> be 100% certain about the delivered code base, there will always be
>> residual uncertainty. But code is finite, so theoretically you can have 100% certainty.
>> Yes, practically speaking it is expensive, but there are companies
>> that do this, for very large code bases. Yes, these are very large,
>> very well capitalized companies, but the fact that this is known to
>> occur makes your first slide misleading. You should show that it is
>> possible to be certain about your code base 100%, i.e. zero residual uncertainty.
>
> I think that 100% certainty about license compliance of a given code base is not
> possible. Even if you use the most sophisticated tools available today, there is no 100%
> certainty that they are able to detect all third party code. Their databases are huge,
> but definitely not complete. You may think that you have 100% certainty that the tools
> detect what is in their database. But even this is not 100% since there may be a bug in
> the tool that prevents a piece of code being detected properly. The other dimension is
> the imprecise language in many licenses. This leaves room for interpretation and grey
> areas. So even if you  know about all third party code and applicable licenses, and you
> fulfill all license obligations to the best of your knowledge, there is still some
> remaining risk that your interpretation of the license does match the intention of the
> licensor and a court of law finds that you are not compliant.
>
> Best regards
> Claus-Peter


[Oliver] I fully agree to Claus-Peter. Looking at an existing code base you never can be sure whether you know the real origin of every line of code and the "real" License of it. You can't be sure whether it is licensed by the copyright holder or whether it was copied by a person from one program to another program (which is licensed differently).
And as Claus-Peter pointed out all tools which we use or will use have errors. This is the nature of un-trivial programs (and such programs are not trivial). And last but not least no human being is able to identify all licenses and all origins of the code of a complex package like chromium (only as example) by "hand" this effort will take years and the result will be full of errors (random errors).

I'm glad you chose Chromium. :-) I would argue that there are humans able to identify *all* licenses associated with Chromium. I would argue that this person or persons could be identified were it not for business reasons. I would argue that the company they work for could likely determine with effectively zero residual business risk every line of code in the project, at least in its released state on Google Code.
 
So uncertainty is normal, even in our lives.

There's no way to disagree with this statement and appear reasonable. But it is no my intent to argue that uncertainty, at least in the form of business risk, isn't normal. What I will say is that the vagueness of the terminology and the chart is misleading and that it is not accurate in measuring residual risk. 

This is important to me because I've been using GNU/Linux long, long before Microsoft's recent slides saying they "heart" Linux. Fear, uncertainty, doubt, and of course, business risk, has been used constantly against the projects I've worked on during my journey. I know its purpose and I know that it has to be addressed directly. That's why I'm arguing now that the concept of residual risk needs to be much better quantified than it is currently.

Regards,

Jeremiah
 

Btw. The name  "License Interaction Diagrams" was contributed by me. :-)

Best regards
Oliver



>
> (The paper I adapted this from is located here:
> http://wiki.opensource.org/bin/Projects/The+Methodological+Significanc
> e+
> of+Uncertainty )
>
> 3. As mentioned during yesterday's call, here is a link to the script
> for the three first episodes of the "FLOW Video" series which focus on
> the core concepts and precise reasons for decision in the Alice Corp v. CLS Bank case.
> First some caveats:
> (a) Episode 2 is about Alice Corp v. CLS Bank but does not identify
> case particulars, so that those details do not distract viewers from
> the core rationale;
> (b) The three episodes are about "software patents" but the script
> never uses the word "software" and never uses the word "patent". Terms
> are chosen to be explicit and literal, to work around very common
> legally inaccurate perceptions about what software is, and what a patent is.
> (c) The overall perspective asserted in these three episodes expresses
> that part of the Open Source community which shares views on this
> topic with the Free Software Foundation and the Software Freedom Law
> Centre (which jointly submitted an Amicus Brief in this case). The
> Open Source community is a 'big tent' but we chose to place this
> script in a strong orthodox free/libre perspective while putting this
> and (soon-to-be-published) audio and animation under the CC-BY
> license, so that anyone who finds it generally useful but requiring
> some tweaks to fit their own organization's perspective, can readily adapt it to do so.
> http://wiki.opensource.org/bin/download/Projects/Constraints+on+the+FL
> OW+of+Ideas/FLOW_Video_Series_FINAL_9sep2014PDF.pdf
> Comments & suggestions, again would be appreciated.
> Regards,
>
> Joseph Potvin
> Operations Manager | Gestionnaire des opérations The Opman Company |
> La compagnie Opman jpotvin@...
> Mobile: 819-593-5983M.Phil. MCPM
>
> Chair, OSI Management Education Working Group Coordinator, The FLOW
> Syllabus http://wiki.opensource.org/bin/Projects/flow-syllabus
> The Open Source Initiative
>
> Doctoral Candidate, Project Management Université du Québec
>
> On Tue, Nov 4, 2014 at 3:34 PM, Joseph Potvin <jpotvin@...> wrote:
> Hello all,
>
> In today's OpenChain call I offered the following:
> 1. Prepare a couple of sample License Interaction Diagrams (LIDs ...To
> whom to we credit that clever name??) based on appropriate UML and/or
> BPL diagrams. This will be a topic for our next call.
> 2. Adapt and share a diagram that helps to visualize the role of a
> compliance management system in relation to reducing undercertainty
> and managing risk.
> 3. Share my script for the three first episodes of the "FLOW Video"
> series which focus on the core concepts and precise reasons for
> decision in the Alice Corp v. CLS Bank case which was decided in June
> 2014. The audio and animation video are being done presently by the
> communications service of University of Southern Queensland. I'll post
> the script onto the FLOW Syllabus wiki, and send that link tomorrow,
> along with some thoughts about the significance of the rationale in
> that decision for applied compliance management.
> Regards,
>
> Joseph Potvin
> Operations Manager | Gestionnaire des opérations The Opman Company |
> La compagnie Opman jpotvin@...
> Mobile: 819-593-5983M.Phil. MCPM
>
> Chair, OSI Management Education Working Group Coordinator, The FLOW
> Syllabus http://wiki.opensource.org/bin/Projects/flow-syllabus
> The Open Source Initiative
>
> Doctoral Candidate, Project Management Université du Québec
>
>
> _______________________________________________
> 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
> jeremiah.foster@...

________________________________
 BearingPoint GmbH
Geschäftsführer: Marcel Nickler (Vorsitzender), Hans-Werner Wurzel (stellv. Vorsitzender), Kiumars Hamidian, Matthias Loebich, Kai Wächter, Dr. Robert Wagner
Vorsitzender des Aufsichtsrats: Beat Leimbacher
Sitz: Frankfurt am Main
Registergericht: Amtsgericht Frankfurt am Main HRB 55490


The information in this email is confidential and may be legally privileged. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
_______________________________________________
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


Joseph Potvin
 

RE: "What I will say is that the vagueness of the terminology and the chart is misleading and that it is not accurate in measuring residual risk."

If that's a bug report about the terminology, let's determine how to fix it. Keep in mind however that this chart has nothing to do with "measurement" -- the axes are labelled as "subjective scales" relevant to a chain of trust. Its purpose is nothing more than to provide a mental map to assist communication. 

Permit me to point out that the draft chart makes no reference to license type, nor even to software -- that's intentional. It's intended to be applicable to any compliance management scenario. It expresses no bias about the risks of free/libre/open software relative to, say, operating a public transit system, or undertaking a construction project.


RE: "You should show that it is possible to be certain about your code base 100%, i.e. zero residual uncertainty"

This seems to me a very useful discussion. Risk of what? Uncertainty about what? That holding responsibility for some source code (under any sort of license arrangement) will never get your organization involved in any real, apparent or potential software license compliance headaches that end up costing lots of time and money?

(a) There will always remain residual uncertainty about whether at some time vexatious litigation might be directed at code you have responsibiity for (under any sort of license arrangement). The SCO litigation was surely the most astonishing flagship scenario for how far an utterly baseless case can be pushed for the sole purpose of creating FUD, showing how much cost that can impose on entities who have practiced all due diligence: http://www.groklaw.net/staticpages/index.php?page=20080803065719599  

(b) There will always remain residual uncertainty about whether the relevant software patents in all relevant jurisdictions have been studied (including patents not yet issued by some happy patent officers who have little regard for "prior art" or "novelty").

(c) An HR team responsible for hiring and contracting personnel are limited in their ability to screen for ethical pre-disposition. A useful baseline on ethical norms in business that can be borrowed for this context can be inferred from the various annual integrity/fraud surveys, e.g.:
http://www.kpmg.com/CN/en/IssuesAndInsights/ArticlesPublications/Documents/Integrity-Survey-2013-O-201307.pdf
http://www.pwc.com/gx/en/economic-crime-survey/
http://fraud.kroll.com/wp-content/uploads/2013/10/FraudReport_2011-2012.pdf
A flagship case in this space involved Goldman Sachs:
http://www.computerworld.com/s/article/9137161/Question_in_Goldman_Sachs_case_Can_open_source_software_be_stolen_
It remains to debate whether the employee in that case didn't understand the license, or knowingly sought to circumvent it. Either way, suppose Goldman Sachs didn't notice for 3 years, and the source code in question was committed into the many Linux distros, thereby also making it into the BlackDuck/Protecode/etc repos. Time goes on, XYZ Corp's compliance management system clears the code, and puts a bunch of investment into advancing it. Then somebody at Goldman Sach notices. I'd like to emphasize again that this scenario is hardly unique to free/libre/open, and that free/libre/open makes transgressions quicker and easier to contain. Repeat: "Free/libre/open makes transgressions quicker and easier to contain."  Just as this approach enables spotting and fixing bugs more quickly and easily.

***

Jumping right along, this leads me to suggest the following strawman statement for OpenChain, an admittedly ambitious attempt to express in a single sentence: a context, a goal, and a process.

Each organization's Accession Letter to the OpenChain Protocol expresses its commitment to optimize its operations to prevent and resolve any real, apparent or potential software license compliance issues, and to thereby maintain a chain of trust throughout the multi-organizational community in which it operates.

Regards,

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

  Chair, OSI Management Education Working Group
  Coordinator, The FLOW Syllabus http://wiki.opensource.org/bin/Projects/flow-syllabus
  The Open Source Initiative

  Doctoral Candidate, M.Phil. MCPM
  Project Management Université du Québec


On Thu, Nov 6, 2014 at 4:26 AM, Jeremiah Foster <jeremiah.foster@...> wrote:


On Thu, Nov 6, 2014 at 10:09 AM, Fendt, Oliver <oliver.fendt@...> wrote:
Hi all,

>>
>> On Wed, Nov 5, 2014 at 6:41 PM, Joseph Potvin <jpotvin@...> wrote:
>> Items 2 and 3...
>>
>> 2. I've adapted a diagram that helps to visualize the role of a
>> compliance management system in relation to reducing uncertainty and managing risk.
>> http://wiki.opensource.org/bin/download/Projects/Structuring+the+FLOW+
>> of+Responsibility/Uncertainty%20Risk_ComplianceManagementPDF.pdf
>> Comments & suggestions are welcome, of course.
>>
>> In your first diagram, the implication is that there is no way to ever
>> be 100% certain about the delivered code base, there will always be
>> residual uncertainty. But code is finite, so theoretically you can have 100% certainty.
>> Yes, practically speaking it is expensive, but there are companies
>> that do this, for very large code bases. Yes, these are very large,
>> very well capitalized companies, but the fact that this is known to
>> occur makes your first slide misleading. You should show that it is
>> possible to be certain about your code base 100%, i.e. zero residual uncertainty.
>
> I think that 100% certainty about license compliance of a given code base is not
> possible. Even if you use the most sophisticated tools available today, there is no 100%
> certainty that they are able to detect all third party code. Their databases are huge,
> but definitely not complete. You may think that you have 100% certainty that the tools
> detect what is in their database. But even this is not 100% since there may be a bug in
> the tool that prevents a piece of code being detected properly. The other dimension is
> the imprecise language in many licenses. This leaves room for interpretation and grey
> areas. So even if you  know about all third party code and applicable licenses, and you
> fulfill all license obligations to the best of your knowledge, there is still some
> remaining risk that your interpretation of the license does match the intention of the
> licensor and a court of law finds that you are not compliant.
>
> Best regards
> Claus-Peter


[Oliver] I fully agree to Claus-Peter. Looking at an existing code base you never can be sure whether you know the real origin of every line of code and the "real" License of it. You can't be sure whether it is licensed by the copyright holder or whether it was copied by a person from one program to another program (which is licensed differently).
And as Claus-Peter pointed out all tools which we use or will use have errors. This is the nature of un-trivial programs (and such programs are not trivial). And last but not least no human being is able to identify all licenses and all origins of the code of a complex package like chromium (only as example) by "hand" this effort will take years and the result will be full of errors (random errors).

I'm glad you chose Chromium. :-) I would argue that there are humans able to identify *all* licenses associated with Chromium. I would argue that this person or persons could be identified were it not for business reasons. I would argue that the company they work for could likely determine with effectively zero residual business risk every line of code in the project, at least in its released state on Google Code.
 
So uncertainty is normal, even in our lives.

There's no way to disagree with this statement and appear reasonable. But it is no my intent to argue that uncertainty, at least in the form of business risk, isn't normal. What I will say is that the vagueness of the terminology and the chart is misleading and that it is not accurate in measuring residual risk. 

This is important to me because I've been using GNU/Linux long, long before Microsoft's recent slides saying they "heart" Linux. Fear, uncertainty, doubt, and of course, business risk, has been used constantly against the projects I've worked on during my journey. I know its purpose and I know that it has to be addressed directly. That's why I'm arguing now that the concept of residual risk needs to be much better quantified than it is currently.

Regards,

Jeremiah
 

Btw. The name  "License Interaction Diagrams" was contributed by me. :-)

Best regards
Oliver



>
> (The paper I adapted this from is located here:
> http://wiki.opensource.org/bin/Projects/The+Methodological+Significanc
> e+
> of+Uncertainty )
>
> 3. As mentioned during yesterday's call, here is a link to the script
> for the three first episodes of the "FLOW Video" series which focus on
> the core concepts and precise reasons for decision in the Alice Corp v. CLS Bank case.
> First some caveats:
> (a) Episode 2 is about Alice Corp v. CLS Bank but does not identify
> case particulars, so that those details do not distract viewers from
> the core rationale;
> (b) The three episodes are about "software patents" but the script
> never uses the word "software" and never uses the word "patent". Terms
> are chosen to be explicit and literal, to work around very common
> legally inaccurate perceptions about what software is, and what a patent is.
> (c) The overall perspective asserted in these three episodes expresses
> that part of the Open Source community which shares views on this
> topic with the Free Software Foundation and the Software Freedom Law
> Centre (which jointly submitted an Amicus Brief in this case). The
> Open Source community is a 'big tent' but we chose to place this
> script in a strong orthodox free/libre perspective while putting this
> and (soon-to-be-published) audio and animation under the CC-BY
> license, so that anyone who finds it generally useful but requiring
> some tweaks to fit their own organization's perspective, can readily adapt it to do so.
> http://wiki.opensource.org/bin/download/Projects/Constraints+on+the+FL
> OW+of+Ideas/FLOW_Video_Series_FINAL_9sep2014PDF.pdf
> Comments & suggestions, again would be appreciated.
> Regards,
>
> Joseph Potvin
> Operations Manager | Gestionnaire des opérations The Opman Company |
> La compagnie Opman jpotvin@...
> Mobile: 819-593-5983M.Phil. MCPM
>
> Chair, OSI Management Education Working Group Coordinator, The FLOW
> Syllabus http://wiki.opensource.org/bin/Projects/flow-syllabus
> The Open Source Initiative
>
> Doctoral Candidate, Project Management Université du Québec
>
> On Tue, Nov 4, 2014 at 3:34 PM, Joseph Potvin <jpotvin@...> wrote:
> Hello all,
>
> In today's OpenChain call I offered the following:
> 1. Prepare a couple of sample License Interaction Diagrams (LIDs ...To
> whom to we credit that clever name??) based on appropriate UML and/or
> BPL diagrams. This will be a topic for our next call.
> 2. Adapt and share a diagram that helps to visualize the role of a
> compliance management system in relation to reducing undercertainty
> and managing risk.
> 3. Share my script for the three first episodes of the "FLOW Video"
> series which focus on the core concepts and precise reasons for
> decision in the Alice Corp v. CLS Bank case which was decided in June
> 2014. The audio and animation video are being done presently by the
> communications service of University of Southern Queensland. I'll post
> the script onto the FLOW Syllabus wiki, and send that link tomorrow,
> along with some thoughts about the significance of the rationale in
> that decision for applied compliance management.
> Regards,
>
> Joseph Potvin
> Operations Manager | Gestionnaire des opérations The Opman Company |
> La compagnie Opman jpotvin@...
> Mobile: 819-593-5983M.Phil. MCPM
>
> Chair, OSI Management Education Working Group Coordinator, The FLOW
> Syllabus http://wiki.opensource.org/bin/Projects/flow-syllabus
> The Open Source Initiative
>
> Doctoral Candidate, Project Management Université du Québec
>
>
> _______________________________________________
> 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
> jeremiah.foster@...

________________________________
 BearingPoint GmbH
Geschäftsführer: Marcel Nickler (Vorsitzender), Hans-Werner Wurzel (stellv. Vorsitzender), Kiumars Hamidian, Matthias Loebich, Kai Wächter, Dr. Robert Wagner
Vorsitzender des Aufsichtsrats: Beat Leimbacher
Sitz: Frankfurt am Main
Registergericht: Amtsgericht Frankfurt am Main HRB 55490


The information in this email is confidential and may be legally privileged. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
_______________________________________________
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




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


Jeremiah Foster <jeremiah.foster@...>
 



On Thu, Nov 6, 2014 at 12:16 PM, Joseph Potvin <jpotvin@...> wrote:
RE: "What I will say is that the vagueness of the terminology and the chart is misleading and that it is not accurate in measuring residual risk."

If that's a bug report about the terminology, let's determine how to fix it. Keep in mind however that this chart has nothing to do with "measurement" -- the axes are labelled as "subjective scales" relevant to a chain of trust. Its purpose is nothing more than to provide a mental map to assist communication. 

Reasonable and fair. But if we can at all convey the *possibility* of completeness (to use a term other than risk,) I feel that would send a more positive, accurate message.
 

Permit me to point out that the draft chart makes no reference to license type, nor even to software -- that's intentional. It's intended to be applicable to any compliance management scenario. It expresses no bias about the risks of free/libre/open software relative to, say, operating a public transit system, or undertaking a construction project.

Point taken. :-) 


RE: "You should show that it is possible to be certain about your code base 100%, i.e. zero residual uncertainty"

This seems to me a very useful discussion. Risk of what? Uncertainty about what? That holding responsibility for some source code (under any sort of license arrangement) will never get your organization involved in any real, apparent or potential software license compliance headaches that end up costing lots of time and money? 

Excellent questions that I think we as a group ought to endeavor to provide reasonable answers to. 

(a) There will always remain residual uncertainty about whether at some time vexatious litigation might be directed at code you have responsibiity for (under any sort of license arrangement). The SCO litigation was surely the most astonishing flagship scenario for how far an utterly baseless case can be pushed for the sole purpose of creating FUD, showing how much cost that can impose on entities who have practiced all due diligence: http://www.groklaw.net/staticpages/index.php?page=20080803065719599   

(b) There will always remain residual uncertainty about whether the relevant software patents in all relevant jurisdictions have been studied (including patents not yet issued by some happy patent officers who have little regard for "prior art" or "novelty").

(c) An HR team responsible for hiring and contracting personnel are limited in their ability to screen for ethical pre-disposition. A useful baseline on ethical norms in business that can be borrowed for this context can be inferred from the various annual integrity/fraud surveys, e.g.:
http://www.kpmg.com/CN/en/IssuesAndInsights/ArticlesPublications/Documents/Integrity-Survey-2013-O-201307.pdf
http://www.pwc.com/gx/en/economic-crime-survey/
http://fraud.kroll.com/wp-content/uploads/2013/10/FraudReport_2011-2012.pdf
A flagship case in this space involved Goldman Sachs:
http://www.computerworld.com/s/article/9137161/Question_in_Goldman_Sachs_case_Can_open_source_software_be_stolen_
It remains to debate whether the employee in that case didn't understand the license, or knowingly sought to circumvent it. Either way, suppose Goldman Sachs didn't notice for 3 years, and the source code in question was committed into the many Linux distros, thereby also making it into the BlackDuck/Protecode/etc repos. Time goes on, XYZ Corp's compliance management system clears the code, and puts a bunch of investment into advancing it. Then somebody at Goldman Sach notices. I'd like to emphasize again that this scenario is hardly unique to free/libre/open, and that free/libre/open makes transgressions quicker and easier to contain. Repeat: "Free/libre/open makes transgressions quicker and easier to contain."  Just as this approach enables spotting and fixing bugs more quickly and easily.

***

Jumping right along, this leads me to suggest the following strawman statement for OpenChain, an admittedly ambitious attempt to express in a single sentence: a context, a goal, and a process.

Each organization's Accession Letter to the OpenChain Protocol expresses its commitment to optimize its operations to prevent and resolve any real, apparent or potential software license compliance issues, and to thereby maintain a chain of trust throughout the multi-organizational community in which it operates.

Hmm. Quite good actually. I look forward to hearing other's feedback.

Regards,

Jeremiah
 
[snip]


Joseph Potvin
 

RE: "if we can at all convey the *possibility* of completeness"

Well, that's about as deep a philosophical matter as we might get into! 

To briefly segway into the deep end of that pool, permit me to borrow from a formal information theory section of a paper I wrote a few years ago, to say: "If a compliance management system of some degree of rigor is put in place, the organization will only gain access to knowledge about those things which this particular system has been designed to detect and convey. Limitations in the rigor of their compliance management system reflects the uncertainty of the management team regarding how to design the methods and criteria of their approach."

<deepend>

I adapted the above from the same document that I re-purposed the chart from. The original text is somewhat harsh on the point (but I was younger then):
"The common notion in orthodox economic analysis of "perfect knowledge" (as well as "imperfect knowledge" which depends upon it conceptually) is an absurdity that has no place in decision strategy. [Claude] Shannon's measure of information H = -Σ pi log pi , where the message Mi is assigned probability pi (Shannon 1948), when he states that "if a channel of capacity H is installed, then the individual knows the state of the world (Arrow 1984: 109)".  Rather, if a channel of such capacity is installed, the observer will only gain access to knowledge about whatever this particular channel has been designed to convey.  [Edwin] Jaynes even proposes that "Shannon's H measures the degree of ignorance of the communication engineer when he designs the technical equipment in the channel (Jaynes 1979: 38)."

ARROW, K. 1971 [1984]. The value of and demand for information. Reprinted in: The Economics of Information: Collected Papers of Kenneth J. Arrow. London: Basil Blackwell. 106-114.

JAYNES, E.T. 1979. Where do we stand on maximum entropy?. In: R. LEVINE and M. TRIBUS (eds). The Maximum Entropy Formalism. Cambridge: MIT Press. 15-118.

SHANNON, C. 1948. Bell Systems Technical Journal 27.  Reprinted in: C. SHANNON & W. WEAVER. The Mathematical Theory of Communication. Urbana: University of Illinois Press. 21-56.

</deepend>


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

  Chair, OSI Management Education Working Group
  Coordinator, The FLOW Syllabus http://wiki.opensource.org/bin/Projects/flow-syllabus
  The Open Source Initiative

  Doctoral Candidate, M.Phil. MCPM
  Project Management Université du Québec



On Thu, Nov 6, 2014 at 7:29 AM, Jeremiah Foster <jeremiah.foster@...> wrote:


On Thu, Nov 6, 2014 at 12:16 PM, Joseph Potvin <jpotvin@...> wrote:
RE: "What I will say is that the vagueness of the terminology and the chart is misleading and that it is not accurate in measuring residual risk."

If that's a bug report about the terminology, let's determine how to fix it. Keep in mind however that this chart has nothing to do with "measurement" -- the axes are labelled as "subjective scales" relevant to a chain of trust. Its purpose is nothing more than to provide a mental map to assist communication. 

Reasonable and fair. But if we can at all convey the *possibility* of completeness (to use a term other than risk,) I feel that would send a more positive, accurate message.
 

Permit me to point out that the draft chart makes no reference to license type, nor even to software -- that's intentional. It's intended to be applicable to any compliance management scenario. It expresses no bias about the risks of free/libre/open software relative to, say, operating a public transit system, or undertaking a construction project.

Point taken. :-) 


RE: "You should show that it is possible to be certain about your code base 100%, i.e. zero residual uncertainty"

This seems to me a very useful discussion. Risk of what? Uncertainty about what? That holding responsibility for some source code (under any sort of license arrangement) will never get your organization involved in any real, apparent or potential software license compliance headaches that end up costing lots of time and money? 

Excellent questions that I think we as a group ought to endeavor to provide reasonable answers to. 

(a) There will always remain residual uncertainty about whether at some time vexatious litigation might be directed at code you have responsibiity for (under any sort of license arrangement). The SCO litigation was surely the most astonishing flagship scenario for how far an utterly baseless case can be pushed for the sole purpose of creating FUD, showing how much cost that can impose on entities who have practiced all due diligence: http://www.groklaw.net/staticpages/index.php?page=20080803065719599   

(b) There will always remain residual uncertainty about whether the relevant software patents in all relevant jurisdictions have been studied (including patents not yet issued by some happy patent officers who have little regard for "prior art" or "novelty").

(c) An HR team responsible for hiring and contracting personnel are limited in their ability to screen for ethical pre-disposition. A useful baseline on ethical norms in business that can be borrowed for this context can be inferred from the various annual integrity/fraud surveys, e.g.:
http://www.kpmg.com/CN/en/IssuesAndInsights/ArticlesPublications/Documents/Integrity-Survey-2013-O-201307.pdf
http://www.pwc.com/gx/en/economic-crime-survey/
http://fraud.kroll.com/wp-content/uploads/2013/10/FraudReport_2011-2012.pdf
A flagship case in this space involved Goldman Sachs:
http://www.computerworld.com/s/article/9137161/Question_in_Goldman_Sachs_case_Can_open_source_software_be_stolen_
It remains to debate whether the employee in that case didn't understand the license, or knowingly sought to circumvent it. Either way, suppose Goldman Sachs didn't notice for 3 years, and the source code in question was committed into the many Linux distros, thereby also making it into the BlackDuck/Protecode/etc repos. Time goes on, XYZ Corp's compliance management system clears the code, and puts a bunch of investment into advancing it. Then somebody at Goldman Sach notices. I'd like to emphasize again that this scenario is hardly unique to free/libre/open, and that free/libre/open makes transgressions quicker and easier to contain. Repeat: "Free/libre/open makes transgressions quicker and easier to contain."  Just as this approach enables spotting and fixing bugs more quickly and easily.

***

Jumping right along, this leads me to suggest the following strawman statement for OpenChain, an admittedly ambitious attempt to express in a single sentence: a context, a goal, and a process.

Each organization's Accession Letter to the OpenChain Protocol expresses its commitment to optimize its operations to prevent and resolve any real, apparent or potential software license compliance issues, and to thereby maintain a chain of trust throughout the multi-organizational community in which it operates.

Hmm. Quite good actually. I look forward to hearing other's feedback.

Regards,

Jeremiah
 
[snip]



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