Date
1 - 11 of 11
A note on some deliverables
|
Joseph Potvin
Hello all, 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.In today's OpenChain call I offered the following: 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 |
|
|
|
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: 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:
|
|
|
|
Jeremiah Foster <jeremiah.foster@...>
On Wed, Nov 5, 2014 at 6:41 PM, Joseph Potvin <jpotvin@...> wrote:
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
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,
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... Comments & suggestions are welcome, of course.
(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. Regards,
On Tue, Nov 4, 2014 at 3:34 PM, Joseph Potvin <jpotvin@...> wrote:
|
|
|
|
Claus-Peter Wiedemann
Von: openchain-bounces@... [mailto:openchain-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 ________________________________ 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- 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
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,
I think that 100% certainty about license compliance of a given code base is not [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 ________________________________ 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 Foster <jeremiah.foster@...>
On Thu, Nov 6, 2014 at 10:09 AM, Fendt, Oliver <oliver.fendt@...> wrote: Hi all, 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
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? 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 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. *** 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:
--
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:
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.
Point taken. :-)
Excellent questions that I think we as a group ought to endeavor to provide reasonable answers to.
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! 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:
--
Joseph Potvin
Operations Manager | Gestionnaire des opérations The Opman Company | La compagnie Opman jpotvin@... Mobile: 819-593-5983 |
|
|
