<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>The original DefCore goals did place a high priority on Bylaws changes and getting those in to the 2015 individual election cycle. That is where this round of revisions relating to DefCore started. Earlier this year, the Bylaws Subcommittee did de-prioritize this work in favor of getting further along in the process of defining the other elements of DefCore (which I agreed was the right approach). There was not a clear timeframe decided then on how long it would be de-prioritized or when the work should resume, if was being postponed past the 2015 elections, etc, which is probably why there’s some confusion on where in the sequence this work should fall.</div><div><br></div><div>We are approaching the last few Board meetings of the year, and Mark R re-surfaced the Bylaws revisions as we are running up against the clock to have something in the 2015 election cycle. He sent them out before the July Board meeting where Josh pointed out there had not been a review process around them. We didn’t really discuss the issue much further there in the Board meeting. After the Board meeting I asked him to forward them to the DefCore committee as the next step in determining what the Committee thought about them and wanted to do with them, so if we did want to move forward we could begin to get broader feedback as well. I also called Eileen a few days ago to talk with her about this as she was leading that Subcommittee. The Foundation has not spent significant funds on it during this time period.</div><div><br></div><div>This thread is kind of going sideways, but maybe we can get some clarity around the right next steps (this was my original goal in talking to Eileen and asking Mark to send this along to DefCore). From Rob’s earlier post it sounds like the DefCore process appendix is an absolute pre-requisite before further review of Bylaws changes, even if that pushes the Bylaws changes out past 2015 Individual Member elections. Is that correct?</div><div><br></div><div>Jonathan</div><div><br></div><div><br></div><br><div><div>On Sep 10, 2014, at 11:23 PM, Joshua McKenty <<a href="mailto:joshua@pistoncloud.com">joshua@pistoncloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="auto" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div>Who is the "we" in this thread?</div><div><br></div><div>The legal affairs committee has no mandate to propose Bylaws changes. </div><div><br></div><div>You, personally, are not a board member. </div><div><br></div><div>And the DefCore committee has been very clear about our belief that we are not yet ready to pursue Bylaws amendments. </div><div><br></div><div>Are you acting under the direction of the foundation executive staff? Or a specific board member that I'm not aware of?</div><div><br></div><div>Jonathan, can you provide clarification, please? It's upsetting to see foundation funds being spent on complex legal actions without any clear board or executive approval. <br><br>Sent from my iPhone</div><div><br>On Sep 10, 2014, at 12:34 AM, "Radcliffe, Mark" <<a href="mailto:Mark.Radcliffe@dlapiper.com" style="color: purple; text-decoration: underline;">Mark.Radcliffe@dlapiper.com</a>> wrote:<br><br></div><blockquote type="cite"><div class="WordSection1" style="page: WordSection1;"><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="color: rgb(31, 73, 125);">I think that we have a misunderstanding about the list. Issue. As I noted in my email, we are trying to get input from the DefCore Committee (after we got input from the Legal Affairs Committee) so we can make the best possible draft available to the community for their comments. I sent it to the CoChairs of DefCore Committee so they could determine how best to get those comments. Just a reminder that we need to have the draft ready for the vote of the Individual Members which would normally mean that it would be voted on approval at the September 22 meeting. If not, we will need to hold a special Board meeting. We need to get community input prior to Board review and then we need to get Board approval (which may require some additional changes and more community input). We will have a significant challenge with the timeline unless we get DefCore Committee comments this week.<o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="color: rgb(31, 73, 125);"> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="color: rgb(31, 73, 125);">Given this timeline, I recommend against tying the bylaws review to the DefCore Process Appendix. The Appendix is not part of the Bylaws, but the Bylaws need to be amended in order to approve the Appendix. Since the revised Bylaws permit the Board to adopt any process, the Appendix does not need to be drafted prior to approval of the revised bylaws. Ultimately, the Appendix is a document which the DefCore needs to get approved by the Board. I am concerned that the DefCore Committee continues to have discussions about basic issues and this discussion precludes drafting an Appendix now.<o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="color: rgb(31, 73, 125);"> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="color: rgb(31, 73, 125);">I recommend that we find a way to get coordinated and final comments from the DefCore Committee on the bylaws.<o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="color: rgb(31, 73, 125);"> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="color: rgb(31, 73, 125);">On the issue of multiple issues dealt with in the bylaws we have drafted the bylaws for review by the Board and it may contain some changes which are not relevant to DefCore Committee, but it would inefficient to create separate drafts.<o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="color: rgb(31, 73, 125);"> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="color: rgb(31, 73, 125);"> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="color: rgb(31, 73, 125);"> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="color: rgb(31, 73, 125);"><o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="color: rgb(31, 73, 125);"> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="color: rgb(31, 73, 125);"><o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="color: rgb(31, 73, 125);"> </span></div><div><div style="border-style: solid none none; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in;"><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif;">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif;"><span class="Apple-converted-space"> </span><a href="mailto:Rob_Hirschfeld@Dell.com" style="color: purple; text-decoration: underline;">Rob_Hirschfeld@Dell.com</a><span class="Apple-converted-space"> </span>[<a href="mailto:Rob_Hirschfeld@Dell.com" style="color: purple; text-decoration: underline;">mailto:Rob_Hirschfeld@Dell.com</a>]<span class="Apple-converted-space"> </span><br><b>Sent:</b><span class="Apple-converted-space"> </span>Tuesday, September 09, 2014 8:53 PM<br><b>To:</b><span class="Apple-converted-space"> </span>Radcliffe, Mark;<span class="Apple-converted-space"> </span><a href="mailto:joshua@pistoncloud.com" style="color: purple; text-decoration: underline;">joshua@pistoncloud.com</a><br><b>Cc:</b><span class="Apple-converted-space"> </span><a href="mailto:defcore-committee@lists.openstack.org" style="color: purple; text-decoration: underline;">defcore-committee@lists.openstack.org</a>; Roay, Leslie;<span class="Apple-converted-space"> </span><a href="mailto:eileen.evans@hp.com" style="color: purple; text-decoration: underline;">eileen.evans@hp.com</a>;<span class="Apple-converted-space"> </span><a href="mailto:aclark@suse.com" style="color: purple; text-decoration: underline;">aclark@suse.com</a>;<a href="mailto:jonathan@openstack.org" style="color: purple; text-decoration: underline;">jonathan@openstack.org</a><br><b>Subject:</b><span class="Apple-converted-space"> </span>RE: Updated Bylaws<o:p></o:p></span></div></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">Mark and Josh,<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">I think this dialog is insightful and I appreciate the deep analysis. <o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">My comments/concerns:<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: -0.25in;"><span>1)<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman';"> <span class="Apple-converted-space"> </span></span></span>I agree with Josh’s concerns about the private/public lists and conflating changes such as ATC, Trademark, and Legal affairs.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: -0.25in;"><span>2)<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman';"> <span class="Apple-converted-space"> </span></span></span>My understanding was that we’d review the “DefCore process appendix” before any additional bylaws changes were reviewed.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: -0.25in;"><span>3)<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman';"> <span class="Apple-converted-space"> </span></span></span>Over all, I think that this change (overlooking that it was not anticipated yet) is closer to target language and intent.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">I’ll restate the official position from previous meetings: we’d like to have review of the formalization of the new process before make bylaws edits since that review may find issues and impact language choices in the bylaws.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">Any idea on when that document would be available for review?<o:p></o:p></div><p style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-bottom: 12pt;">> -----Original Message-----<br>> From: Radcliffe, Mark [<a href="mailto:Mark.Radcliffe@dlapiper.com" style="color: purple; text-decoration: underline;">mailto:Mark.Radcliffe@dlapiper.com</a>]<br>> Sent: Monday, September 08, 2014 2:09 PM<br>> To: Joshua McKenty<br>> Cc: Hirschfeld, Rob; defcore-committee; Roay, Leslie; Eileen Evans Esq.<br>> (<a href="mailto:eileen.evans@hp.com" style="color: purple; text-decoration: underline;">eileen.evans@hp.com</a>); Alan Clark; Jonathan Bryce<br>> Subject: RE: Updated Bylaws<br>><span class="Apple-converted-space"> </span><br>> Josh:<br>><span class="Apple-converted-space"> </span><br>> My apologies for any confusion. I sent this draft to you as the<span class="Apple-converted-space"> </span><br>> co-chair of the Defcore committee for you to share with the Defcore<span class="Apple-converted-space"> </span><br>> committee in the most appropriate manner. I did not mean to suggest<span class="Apple-converted-space"> </span><br>> that your comments would be private.<br>><span class="Apple-converted-space"> </span><br>> Your comments are very helpful and I have responded below. However,<span class="Apple-converted-space"> </span><br>> I think that it would be useful to have a coordinated set of comments<span class="Apple-converted-space"> </span><br>> by the Defcore committee. How can we achieve such a set of comments?<br>><span class="Apple-converted-space"> </span><br>> -----Original Message-----<br>> From: Joshua McKenty [<a href="mailto:joshua@pistoncloud.com" style="color: purple; text-decoration: underline;">mailto:joshua@pistoncloud.com</a>]<br>> Sent: Monday, September 08, 2014 10:56 AM<br>> To: Radcliffe, Mark<br>> Cc: Rob Hirschfeld; defcore-committee; Roay, Leslie; Eileen Evans Esq.<br>> (<a href="mailto:eileen.evans@hp.com" style="color: purple; text-decoration: underline;">eileen.evans@hp.com</a>); Alan Clark; Jonathan Bryce<br>> Subject: Re: Updated Bylaws<br>><span class="Apple-converted-space"> </span><br>> It is a violation of Board policy to discuss this off of a public<span class="Apple-converted-space"> </span><br>> mailing list. CCing the defcore mailing list for transparency.<br>><span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> 4.1(b)(i) changes are substantially out-of-line with the intended<span class="Apple-converted-space"> </span><br>> meaning of that clause - the TC is intended to manage the technical<span class="Apple-converted-space"> </span><br>> matters of all aspects of the openstack project, not just the<span class="Apple-converted-space"> </span><br>> integrated release. I believe these changes are unnecessary and have negative side effects.<br>><span class="Apple-converted-space"> </span><br>> RESPONSE: We will make this change.<br>><span class="Apple-converted-space"> </span><br>> 4.1(b)(ii) conflates the Integrated Release with the broader OpenStack<span class="Apple-converted-space"> </span><br>> project again.<br>><span class="Apple-converted-space"> </span><br>> RESPONSE: As above, we will change to OpenStack Project.<br>><span class="Apple-converted-space"> </span><br>> The introduction of the "OSP New Definition Date" into the Bylaws<span class="Apple-converted-space"> </span><br>> seems bizarre. Why don't we vote and approve these bylaw changes once<span class="Apple-converted-space"> </span><br>> the OSP process is ready, and then simply change the paragraph -<span class="Apple-converted-space"> </span><br>> instead of preserving THREE different definitions of core in the<span class="Apple-converted-space"> </span><br>> Bylaws? (In that vein, the second-to- last paragraph of this clause<span class="Apple-converted-space"> </span><br>> could be struck entirely.)<br>><span class="Apple-converted-space"> </span><br>> RESPONSE: These changes need to be approved by the Board and (i)<span class="Apple-converted-space"> </span><br>> two-thirds of the Gold Members, (ii) two-thirds of the Platinum<span class="Apple-converted-space"> </span><br>> Members, and (iii) a majority of the Individual Members voting (but<span class="Apple-converted-space"> </span><br>> only if at least 25% of the Individual Members vote at an annual or<span class="Apple-converted-space"> </span><br>> special meeting). Consequently, the actual date of "approval" may<span class="Apple-converted-space"> </span><br>> be difficult to determine. It is simpler to have the Board be able to choose the date for the cutover.<br>><span class="Apple-converted-space"> </span><br>> 4.1.(b)(iii) - Could we move the last sentence (posting to the<span class="Apple-converted-space"> </span><br>> website) into Section 7.3 for clarity?<br>><span class="Apple-converted-space"> </span><br>> RESPONSE: We have included it in Section 4.1(b)(ii) and need it in<span class="Apple-converted-space"> </span><br>> this section for parallelism. I think that we should keep in it in<span class="Apple-converted-space"> </span><br>> each provision. Section 7.3 deals with a different issue, the trademark policy.<br>><span class="Apple-converted-space"> </span><br>> Is it "Core OpenStack Project" or "OpenStack Core Project"?<span class="Apple-converted-space"> </span><br>> 4.13(c)(i) and 4.1 don't match. (Ditto 7.4)<br>><span class="Apple-converted-space"> </span><br>> RESPONSE: It is "Core OpenStack Project" and we will ensure that it<span class="Apple-converted-space"> </span><br>> is used consistently.<br>><span class="Apple-converted-space"> </span><br>> 4.13(c)(i) Seems like it could be simplified. Again, it seems like all<span class="Apple-converted-space"> </span><br>> of 4.13 would be simpler without the introduction of the OSP New Definition Date.<br>><span class="Apple-converted-space"> </span><br>> RESPONSE: See above about the OSP New Definition Date. I am open to<span class="Apple-converted-space"> </span><br>> suggestions on this provision. The key issue is that the Technical<span class="Apple-converted-space"> </span><br>> Committee cannot drop part of the Core OpenStack Project in developing<span class="Apple-converted-space"> </span><br>> the new version of the Integrated Release.<br>><span class="Apple-converted-space"> </span><br>> 4.15 - I strongly object to using DefCore-related bylaws changes to<span class="Apple-converted-space"> </span><br>> make non- cosmetic changes to the Legal Affairs committee. This should<span class="Apple-converted-space"> </span><br>> be a separate set of redlines and a separate vote.<br>><span class="Apple-converted-space"> </span><br>> RESPONSE: These changes are not DefCore only changes. We are changing<span class="Apple-converted-space"> </span><br>> a number of sections of the bylaws only some of which are relevant to<span class="Apple-converted-space"> </span><br>> DefCore. If they are not relevant to DefCore, you do not need to comment on them.<br>><span class="Apple-converted-space"> </span><br>> 4.15 - The legal affairs committee should strive to protect the entire<span class="Apple-converted-space"> </span><br>> OpenStack project ecosystem, not just the integrated release, no?<br>><span class="Apple-converted-space"> </span><br>> RESPONSE: We will change this back to the OpenStack Project.<br>><span class="Apple-converted-space"> </span><br>> 4.17(a) - Unnecessary change. The Integrated Release is *not* a<span class="Apple-converted-space"> </span><br>> replacement for the term "OpenStack project" - it's a subset of the<span class="Apple-converted-space"> </span><br>> OpenStack Project, in the same way that Core is a subset of the<span class="Apple-converted-space"> </span><br>> Integrated Release. (ditto 7.4)<br>><span class="Apple-converted-space"> </span><br>> RESPONSE: We will change this back to the OpenStack Project. Since<span class="Apple-converted-space"> </span><br>> we are changing Section 4(b), we will change Section 7.4.<br>><span class="Apple-converted-space"> </span><br>> Ditto for 7.1(c) - The OpenStack foundation distributes project<span class="Apple-converted-space"> </span><br>> software beyond the boundaries of the Integrated Release, and we<span class="Apple-converted-space"> </span><br>> should continue to target<br>> ASLv2.0 for that.<br>><span class="Apple-converted-space"> </span><br>> RESPONSE: This obligation is an absolute one, it is not "desirable".<span class="Apple-converted-space"> </span><br>> We can certainly encourage the use of ASLv2, but I think that the<span class="Apple-converted-space"> </span><br>> OpenStack Foundation needs more flexibility in licenses modules<span class="Apple-converted-space"> </span><br>> outside of the Integrated Release. Moreover, I understand that a<span class="Apple-converted-space"> </span><br>> number of these modules are in existence and the OpenStack Foundation<span class="Apple-converted-space"> </span><br>> would not have control over their license. We can make it a "desired" policy without making it part of the bylaws.<br>><span class="Apple-converted-space"> </span><br>> 7.3 - What does this mean? "The OpenStack trademarks shall only be<span class="Apple-converted-space"> </span><br>> used to promote the Foundation, the OpenStack Integrated Release or<span class="Apple-converted-space"> </span><br>> services related to the OpenStack Integrated Release as provided in<span class="Apple-converted-space"> </span><br>> the Trademark Policy." I would think that the entire point of a<span class="Apple-converted-space"> </span><br>> trademark license would be for the licensee to be able to use the<span class="Apple-converted-space"> </span><br>> trademark under license to promote their own product or services.<br>><span class="Apple-converted-space"> </span><br>> RESPONSE: This sentence does not prevent promotion of a licensee's<span class="Apple-converted-space"> </span><br>> products so long as they include the Integrated Release. In the last<span class="Apple-converted-space"> </span><br>> draft, the Trademark Policy was fixed (i.e. it was an exhibit). We<span class="Apple-converted-space"> </span><br>> have found that this approach does not work well, so we are giving<span class="Apple-converted-space"> </span><br>> discretion to the Board to change the policy. I thought that the<span class="Apple-converted-space"> </span><br>> community would be more comfortable by clarifying the scope of the discretion. However, we can delete this sentence.<br>><span class="Apple-converted-space"> </span><br>> Appendix 4, 3(b) - While I think this is an appropriate change, it's<span class="Apple-converted-space"> </span><br>> actually out of scope for us to change the definition of ATC from<span class="Apple-converted-space"> </span><br>> "Core contributor" to "Integrated Release contributor" without<span class="Apple-converted-space"> </span><br>> checking with the TC. (Personally, I think ecosystem contributors should be considered ATCs as well).<br>><span class="Apple-converted-space"> </span><br>> RESPONSE: We have discussed the changes in general with the TC.<span class="Apple-converted-space"> </span><br>> However, they may not have focused on this issue, I will make sure that we get their input.<br>><span class="Apple-converted-space"> </span><br>> Appendix 7 - Do we actually want to restrict the CLA to only cover<span class="Apple-converted-space"> </span><br>> contributions to the Integrated Release? We will have no way to<span class="Apple-converted-space"> </span><br>> promote code from Incubation to Integrated status with this approach.<span class="Apple-converted-space"> </span><br>> Again, see my comments regarding Integrated Release vs. Project, above.<br>><span class="Apple-converted-space"> </span><br>> RESPONSE: See my comment on Section 7.1(c). This change does not prevent<br>> promotion of code from Incubation to Integrated status, however anyone<span class="Apple-converted-space"> </span><br>> seeking to develop code that they want to eventually be part of the Integrated<br>> Release needs to understand that it will have to be under ASLv2. The CLA only<br>> requires that contributors to the Integrated Release have a CLA on<span class="Apple-converted-space"> </span><br>> file, it does not preclude other contributors from signing the CLA.<span class="Apple-converted-space"> </span><br>> If the terms for "incubation" are sufficiently established, we could<span class="Apple-converted-space"> </span><br>> add them to the requirement (so that it covers Integrated Release and<span class="Apple-converted-space"> </span><br>> "Incubation Projects"). However, I think that we need to keep a<span class="Apple-converted-space"> </span><br>> limitation narrower than the OpenStack Project because we could have<span class="Apple-converted-space"> </span><br>> situations where contributors provide contributions to the OpenStack<span class="Apple-converted-space"> </span><br>> Project, but not the Integrated Release and those contributions might<span class="Apple-converted-space"> </span><br>> be under a different license (not ASLv2). We should clarify that the CLA can apply to projects outside of the Integrated Release.<br>><span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> --<br>><span class="Apple-converted-space"> </span><br>> Joshua McKenty<br>> Chief Technology Officer<br>> Piston Cloud Computing, Inc.<br>> +1 (650) 242-5683<br>> +1 (650) 283-6846<br>><span class="Apple-converted-space"> </span><a href="http://www.pistoncloud.com/" style="color: purple; text-decoration: underline;">http://www.pistoncloud.com</a><br>><span class="Apple-converted-space"> </span><br>> "Oh, Westley, we'll never survive!"<br>> "Nonsense. You're only saying that because no one ever has."<br>><span class="Apple-converted-space"> </span><br>> On Sep 8, 2014, at 10:20 AM, Radcliffe, Mark<span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> wrote:<br>><span class="Apple-converted-space"> </span><br>> > I would like to get your comments by Wednesday COB so we can post it<span class="Apple-converted-space"> </span><br>> > for<br>> community comments. Thanks.<br>> ><br>> > From: Radcliffe, Mark<br>> > Sent: Tuesday, September 02, 2014 12:11 PM<br>> > To: Rob Hirschfeld (<a href="mailto:rob_hirschfeld@dell.com" style="color: purple; text-decoration: underline;">rob_hirschfeld@dell.com</a>); 'Joshua McKenty'<br>> > Cc: Roay, Leslie; Eileen Evans Esq. (<a href="mailto:eileen.evans@hp.com" style="color: purple; text-decoration: underline;">eileen.evans@hp.com</a>); 'Alan<span class="Apple-converted-space"> </span><br>> > Clark';<br>> 'Jonathan Bryce'<br>> > Subject: Updated Bylaws<br>> ><br>> > I am enclosing the revision to the bylaws based on our discussion<span class="Apple-converted-space"> </span><br>> > with the Rob<br>> to deal with issues from the Technical Committee. We have changed the<span class="Apple-converted-space"> </span><br>> approach to require the Technical Committee to get approval from the<span class="Apple-converted-space"> </span><br>> Board prior to making a change in the OpenStack Integrated Release<span class="Apple-converted-space"> </span><br>> which would delete any of the OpenStack Core Project. I also took<span class="Apple-converted-space"> </span><br>> another look the Standards provision in Section 7.4 and decided to<span class="Apple-converted-space"> </span><br>> make clear that it would not affect the new approach to determining<span class="Apple-converted-space"> </span><br>> the OpenStack Integrated Release and OpenStack Core Project. I am enclosing a markup to the existing version.<br>> ><br>> > This draft has been approved by the Legal Affairs Committee. Please<span class="Apple-converted-space"> </span><br>> > review it<br>> and provide any comments so we can put it on the website for community<span class="Apple-converted-space"> </span><br>> review prior to the September 22 Board meeting Thanks.<br>> ><br>> ><br>> > Please consider the environment before printing this email.<br>> ><br>> > The information contained in this email may be confidential and/or<span class="Apple-converted-space"> </span><br>> > legally<br>> privileged. It has been sent for the sole use of the intended<span class="Apple-converted-space"> </span><br>> recipient(s). If the reader of this message is not an intended<span class="Apple-converted-space"> </span><br>> recipient, you are hereby notified that any unauthorized review, use,<span class="Apple-converted-space"> </span><br>> disclosure, dissemination, distribution, or copying of this<span class="Apple-converted-space"> </span><br>> communication, or any of its contents, is strictly prohibited. If you<span class="Apple-converted-space"> </span><br>> have received this communication in error, please reply to the sender<span class="Apple-converted-space"> </span><br>> and destroy all copies of the message. To contact us directly, send to<span class="Apple-converted-space"> </span><a href="mailto:postmaster@dlapiper.com" style="color: purple; text-decoration: underline;">postmaster@dlapiper.com</a>. Thank you.<br>><span class="Apple-converted-space"> </span><br>> Please consider the environment before printing this email.<br>><span class="Apple-converted-space"> </span><br>> The information contained in this email may be confidential and/or<span class="Apple-converted-space"> </span><br>> legally privileged. It has been sent for the sole use of the intended<span class="Apple-converted-space"> </span><br>> recipient(s). If the reader of this message is not an intended<span class="Apple-converted-space"> </span><br>> recipient, you are hereby notified that any unauthorized review, use,<span class="Apple-converted-space"> </span><br>> disclosure, dissemination, distribution, or copying of this<span class="Apple-converted-space"> </span><br>> communication, or any of its contents, is strictly prohibited. If you<span class="Apple-converted-space"> </span><br>> have received this communication in error, please reply to the sender<span class="Apple-converted-space"> </span><br>> and destroy all copies of the message. To contact us directly, send to<span class="Apple-converted-space"> </span><a href="mailto:postmaster@dlapiper.com" style="color: purple; text-decoration: underline;">postmaster@dlapiper.com</a>. Thank you.<o:p></o:p></p></div><span style="font-size: 11px;"><font color="#008000" style="font-size: 11px;">Please consider the environment before printing this email.</font></span><font color="#008000" style="font-size: 11px;"><span class="Apple-converted-space"> </span><br><br><font color="#808080" size="1" face="Verdana">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<span class="Apple-converted-space"> </span><a href="mailto:postmaster@dlapiper.com" style="color: purple; text-decoration: underline;">postmaster@dlapiper.com</a>. Thank you.</font></font></blockquote></div></blockquote></div><br></body></html>