|
Re: Draft FOSS compliance program
Ibrahim Haddad <ibrahim.h@...>
Thank you Kelly.
toggle quoted messageShow quoted text
I will be participating in an offsite starting tomorrow for 3 days. I won’t be able to join the call. However, I will be in JP the week after and I am available to discuss with the OpenChain folks participating in the Linux Foundation Open Compliance Summit. Best regards to all, Ibrahim
—
Ibrahim Haddad, Ph.D. Open Source Group Samsung Research America
On Nov 3, 2014, at 2:32 PM, Williams, Kelly <kellyw@...> wrote:
|
||
|
|
||
|
Re: Draft FOSS compliance program
Mark Radcliffe
Sorry I am at the OpenStack Summit and will not make it
Sent from my BlackBerry 10 smartphone.
Hi Everyone,
I’ll go ahead and add this to the agenda for tomorrow’s meeting. Please take some time to review Ibrahim’s slides posted on https://wiki.linuxfoundation.org/openchain and provide your feedback on the call.
Thanks, Kelly
From: openchain-bounces@... [mailto:openchain-bounces@...]
On Behalf Of Williams, Kelly
Hi Everyone,
Would folks like to spend part of the next session in a follow up discussion to Ibrahim’s presentation on the draft FOSS compliance program? The slides are posted on the wiki https://wiki.linuxfoundation.org/openchain below the meeting materials dated 2014-10-21.
Thoughts appreciated!
Thanks, Kelly
The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster@.... Thank you.
|
||
|
|
||
|
OpenChain meeting tomorrow 11/4
Kelly Williams
Hi Everyone,
Here’s the agenda for the meeting tomorrow at 8am PT, 11am ET, 3pm UTC, 5pm CEST.
The meeting materials are posted on the wiki https://wiki.linuxfoundation.org/openchain.
Phone bridge info:
Conference Number: +1 (415) 906-5657 Pin: 88326
For international call instructions, please visit the website below. Please note you will have to enter the US Conference number as part of the instructions: Screen share (if used): go to http://uberconference.com/mdolan
Regards, Kelly
|
||
|
|
||
|
Re: Draft FOSS compliance program
Dave Marr
Ibrahim, I’ll be at the Compliance Summit and can provide you an update.
All, as a possible thought exercise for tomorrow, one idea is to take a look at the materials from last week through the lens of, “what would *prevent* me from adopting this proposal today?” This might shed light on where the team should focus our next steps.
For those on the list who are interested in providing services to enterprises that may adopt this approach, perhaps a different question, “if this proposal was adopted today, what would cause me to *not want to* provide my services (e.g., process consulting, open source training, code scanning service, etc.) to enterprises in this ecosystem?”
Again this is just a proposed thought exercise to queue tomorrow’s discussion, to improve the specification and certainly not a discussion of actual adoption.
From: openchain-bounces@... [mailto:openchain-bounces@...]
On Behalf Of Ibrahim Haddad
Thank you Kelly.
I will be participating in an offsite starting tomorrow for 3 days. I won’t be able to join the call. However, I will be in JP the week after and I am available to discuss with the OpenChain folks participating in the Linux Foundation Open Compliance Summit.
Best regards to all, Ibrahim
—
On Nov 3, 2014, at 2:32 PM, Williams, Kelly <kellyw@...> wrote:
|
||
|
|
||
|
materials from last meeting - open format
J Lovejoy
Hi All,
I just uploaded an .odp and .odt version of Ibrahim’s slide deck and document from last call. I checked the view and all looked the same in both formats as the originals that Ibrahim sent. As to Jeremiah’s question re: why MS Office is so prevalent (in this population) - my view as to that is that it is sometimes not really a choice. If you are a lawyer negotiating contracts, it’s possible that the lawyer on the other side has never heard of Libre or Open Office and the midst of a negotiation is not really the time to try and teach someone about MS alternatives or free software options. :) Probably not the answer you wanted to hear, but the reality that many of us (legal folks) operate in. cheers, Jilayne
|
||
|
|
||
|
Re: materials from last meeting - open format
Jeremiah Foster <jeremiah.foster@...>
Many thanks Jilayne! I appreciate the difficulty of changing document formats in the middle of negotiations and I wouldn't ask anyone to go through that. But I'm not going to give up here that easily. :-) Firstly, at least in the cozy confines of our Linux Foundation lists, we should likely walk the walk and not just talk the talk. I think adding open document formats to our emails for those who live a completely free software lifestyle gives us a touch of credibility with the unwashed software developer masses. I say that in the most loving way possible as I count myself amongst them. Secondly, there is a very strong connection between FOSS and privacy. Many FOSS developers are passionate security activists. As legal folks, I'm a wee bit surprised that you'd trust your data to an insecure platform. Especially knowing what we all know, e.g. http://en.wikipedia.org/wiki/Dual_EC_DRBG Now I'm sure that's not the response anyone wants to hear, but the reality is that we all operate in. Fortunately, there is a more secure alternative. Cheers, Jeremiah
On Tuesday, November 4, 2014, J Lovejoy <opensource@...> wrote:
Hi All,
|
||
|
|
||
|
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
|
||
|
|
||
|
Re: materials from last meeting - open format
Claus-Peter Wiedemann
Hi Jeremiah,
Very well said. I’d love to work with open formats, too. But experience tells me that it is just not practical unless all of my peers would also switch. Interoperability is bad, really bad. It only works without glitches if you have plain text. Otherwise it is a nightmare and I just don’t have the time to tweak formatting all the time. BTW, for plain text, I’d prefer to use “vi” J
Just my (reality inspired) 2 cts.
Best regards Claus-Peter
Von: openchain-bounces@... [mailto:openchain-bounces@...]
Im Auftrag von Jeremiah Foster
Many thanks Jilayne!
I appreciate the difficulty of changing document formats in the middle of negotiations and I wouldn't ask anyone to go through that. But I'm not going to give up here that easily. :-)
Firstly, at least in the cozy confines of our Linux Foundation lists, we should likely walk the walk and not just talk the talk. I think adding open document formats to our emails for those who live a completely free software lifestyle gives us a touch of credibility with the unwashed software developer masses. I say that in the most loving way possible as I count myself amongst them.
Secondly, there is a very strong connection between FOSS and privacy. Many FOSS developers are passionate security activists. As legal folks, I'm a wee bit surprised that you'd trust your data to an insecure platform. Especially knowing what we all know, e.g. http://en.wikipedia.org/wiki/Dual_EC_DRBG
Now I'm sure that's not the response anyone wants to hear, but the reality is that we all operate in. Fortunately, there is a more secure alternative.
Cheers,
Jeremiah
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.
|
||
|
|
||
|
Re: A note on some deliverables
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:
|
||
|
|
||
|
Re: A note on some deliverables
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 
|
||
|
|
||
|
Re: A note on some deliverables
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
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:
|
||
|
|
||
|
Re: A note on some deliverables
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.
|
||
|
|
||
|
Re: A note on some deliverables
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 
|
||
|
|
||
|
Re: A note on some deliverables
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
|
||
|
|
||
|
Re: A note on some deliverables
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 
|
||
|
|
||
|
Re: A note on some deliverables
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
|
||
|
|
||
|
Re: A note on some deliverables
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]
|
||
|
|
||
|
Re: A note on some deliverables
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
|
||
|
|
||
|
OpenChain meeting tomorrow 11/18
Kelly Williams
Hi Everyone,
Here’s the agenda for the meeting tomorrow at 8am PT, 11am ET, 3pm UTC, 5pm CEST.
Please take some time to review Ibrahim’s slides posted on the wiki (2014-10-21) and provide your feedback on the call. The meeting materials are posted on the wiki https://wiki.linuxfoundation.org/openchain.
Phone bridge info:
Conference Number: +1 (415) 906-5657 Pin: 88326
For international call instructions, please visit the website below. Please note you will have to enter the US Conference number as part of the instructions: Screen share (if used): go to http://uberconference.com/mdolan
Regards, Kelly
|
||
|
|
||
|
Re: OpenChain meeting tomorrow 11/18
Jilayne Lovejoy <Jilayne.Lovejoy@...>
Hi Everyone,
For the discussion on the draft FOSS compliance program that Ibrahim introduced two meetings ago, I would encourage you all to look at the document version of Ibrahim’s materials (posted on both .doc and .odt formats) on the page Kelly linked to below. I think the document has a bit more details than the slides, so both are helpful.
I think we all agreed that this draft proposal that Ibrahim wrote whilst working at the Linux Foundation is a great starting point. So, now the question becomes how would we go about implementation, focusing on a few initial steps: 1) This is a draft, as such, it needs refining and tweaking – what areas would you change and how? (feel free to edit and upload to the wiki) 2) Where do we begin and how – what is a logical starting point? a. Levels – what should level 1 look like? How does it ramp up from there? Are the suggested level 1 goals too much, too little? b. Training – this seems like a critical starting point; how to define purpose, syllabus, frequency?
Thanks, Jilayne
Jilayne Lovejoy | Open Source Counsel | ARM jilayne.lovejoy@... | Skype: lovejoylids | Twitter: @jilaynelovejoy Direct: +1-720-412-9472
From: openchain-bounces@... [mailto:openchain-bounces@...]
On Behalf Of Williams, Kelly
Hi Everyone,
Here’s the agenda for the meeting tomorrow at 8am PT, 11am ET, 3pm UTC, 5pm CEST.
Please take some time to review Ibrahim’s slides posted on the wiki (2014-10-21) and provide your feedback on the call. The meeting materials are posted on the wiki https://wiki.linuxfoundation.org/openchain.
Phone bridge info:
Conference Number: +1 (415) 906-5657 Pin: 88326
For international call instructions, please visit the website below. Please note you will have to enter the US Conference number as part of the instructions: Screen share (if used): go to http://uberconference.com/mdolan
Regards, Kelly
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
|
||
|
|
||
