<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1978679607;
mso-list-type:hybrid;
mso-list-template-ids:7272698 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Mark and Josh,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I think this dialog is insightful and I appreciate the deep analysis. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">My comments/concerns:<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="mso-list:Ignore">1)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>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></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="mso-list:Ignore">2)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>My understanding was that we’d review the “DefCore process appendix” before any additional bylaws changes were reviewed.<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="mso-list:Ignore">3)<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>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></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Any idea on when that document would be available for review?<o:p></o:p></p>
<p style="margin-bottom:12.0pt">> -----Original Message-----<br>
> From: Radcliffe, Mark [mailto:Mark.Radcliffe@dlapiper.com]<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>
> (eileen.evans@hp.com); Alan Clark; Jonathan Bryce<br>
> Subject: RE: Updated Bylaws<br>
> <br>
> Josh:<br>
> <br>
> My apologies for any confusion. I sent this draft to you as the <br>
> co-chair of the Defcore committee for you to share with the Defcore <br>
> committee in the most appropriate manner. I did not mean to suggest <br>
> that your comments would be private.<br>
> <br>
> Your comments are very helpful and I have responded below. However, <br>
> I think that it would be useful to have a coordinated set of comments <br>
> by the Defcore committee. How can we achieve such a set of comments?<br>
> <br>
> -----Original Message-----<br>
> From: Joshua McKenty [mailto:joshua@pistoncloud.com]<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>
> (eileen.evans@hp.com); Alan Clark; Jonathan Bryce<br>
> Subject: Re: Updated Bylaws<br>
> <br>
> It is a violation of Board policy to discuss this off of a public <br>
> mailing list. CCing the defcore mailing list for transparency.<br>
> <br>
> <br>
> 4.1(b)(i) changes are substantially out-of-line with the intended <br>
> meaning of that clause - the TC is intended to manage the technical <br>
> matters of all aspects of the openstack project, not just the <br>
> integrated release. I believe these changes are unnecessary and have negative side effects.<br>
> <br>
> RESPONSE: We will make this change.<br>
> <br>
> 4.1(b)(ii) conflates the Integrated Release with the broader OpenStack <br>
> project again.<br>
> <br>
> RESPONSE: As above, we will change to OpenStack Project.<br>
> <br>
> The introduction of the "OSP New Definition Date" into the Bylaws <br>
> seems bizarre. Why don't we vote and approve these bylaw changes once <br>
> the OSP process is ready, and then simply change the paragraph - <br>
> instead of preserving THREE different definitions of core in the <br>
> Bylaws? (In that vein, the second-to- last paragraph of this clause <br>
> could be struck entirely.)<br>
> <br>
> RESPONSE: These changes need to be approved by the Board and (i) <br>
> two-thirds of the Gold Members, (ii) two-thirds of the Platinum <br>
> Members, and (iii) a majority of the Individual Members voting (but <br>
> only if at least 25% of the Individual Members vote at an annual or <br>
> special meeting). Consequently, the actual date of "approval" may <br>
> be difficult to determine. It is simpler to have the Board be able to choose the date for the cutover.<br>
> <br>
> 4.1.(b)(iii) - Could we move the last sentence (posting to the <br>
> website) into Section 7.3 for clarity?<br>
> <br>
> RESPONSE: We have included it in Section 4.1(b)(ii) and need it in <br>
> this section for parallelism. I think that we should keep in it in <br>
> each provision. Section 7.3 deals with a different issue, the trademark policy.<br>
> <br>
> Is it "Core OpenStack Project" or "OpenStack Core Project"? <br>
> 4.13(c)(i) and 4.1 don't match. (Ditto 7.4)<br>
> <br>
> RESPONSE: It is "Core OpenStack Project" and we will ensure that it <br>
> is used consistently.<br>
> <br>
> 4.13(c)(i) Seems like it could be simplified. Again, it seems like all <br>
> of 4.13 would be simpler without the introduction of the OSP New Definition Date.<br>
> <br>
> RESPONSE: See above about the OSP New Definition Date. I am open to <br>
> suggestions on this provision. The key issue is that the Technical <br>
> Committee cannot drop part of the Core OpenStack Project in developing <br>
> the new version of the Integrated Release.<br>
> <br>
> 4.15 - I strongly object to using DefCore-related bylaws changes to <br>
> make non- cosmetic changes to the Legal Affairs committee. This should <br>
> be a separate set of redlines and a separate vote.<br>
> <br>
> RESPONSE: These changes are not DefCore only changes. We are changing <br>
> a number of sections of the bylaws only some of which are relevant to <br>
> DefCore. If they are not relevant to DefCore, you do not need to comment on them.<br>
> <br>
> 4.15 - The legal affairs committee should strive to protect the entire <br>
> OpenStack project ecosystem, not just the integrated release, no?<br>
> <br>
> RESPONSE: We will change this back to the OpenStack Project.<br>
> <br>
> 4.17(a) - Unnecessary change. The Integrated Release is *not* a <br>
> replacement for the term "OpenStack project" - it's a subset of the <br>
> OpenStack Project, in the same way that Core is a subset of the <br>
> Integrated Release. (ditto 7.4)<br>
> <br>
> RESPONSE: We will change this back to the OpenStack Project. Since <br>
> we are changing Section 4(b), we will change Section 7.4.<br>
> <br>
> Ditto for 7.1(c) - The OpenStack foundation distributes project <br>
> software beyond the boundaries of the Integrated Release, and we <br>
> should continue to target<br>
> ASLv2.0 for that.<br>
> <br>
> RESPONSE: This obligation is an absolute one, it is not "desirable". <br>
> We can certainly encourage the use of ASLv2, but I think that the <br>
> OpenStack Foundation needs more flexibility in licenses modules <br>
> outside of the Integrated Release. Moreover, I understand that a <br>
> number of these modules are in existence and the OpenStack Foundation <br>
> would not have control over their license. We can make it a "desired" policy without making it part of the bylaws.<br>
> <br>
> 7.3 - What does this mean? "The OpenStack trademarks shall only be <br>
> used to promote the Foundation, the OpenStack Integrated Release or <br>
> services related to the OpenStack Integrated Release as provided in <br>
> the Trademark Policy." I would think that the entire point of a <br>
> trademark license would be for the licensee to be able to use the <br>
> trademark under license to promote their own product or services.<br>
> <br>
> RESPONSE: This sentence does not prevent promotion of a licensee's <br>
> products so long as they include the Integrated Release. In the last <br>
> draft, the Trademark Policy was fixed (i.e. it was an exhibit). We <br>
> have found that this approach does not work well, so we are giving <br>
> discretion to the Board to change the policy. I thought that the <br>
> community would be more comfortable by clarifying the scope of the discretion. However, we can delete this sentence.<br>
> <br>
> Appendix 4, 3(b) - While I think this is an appropriate change, it's <br>
> actually out of scope for us to change the definition of ATC from <br>
> "Core contributor" to "Integrated Release contributor" without <br>
> checking with the TC. (Personally, I think ecosystem contributors should be considered ATCs as well).<br>
> <br>
> RESPONSE: We have discussed the changes in general with the TC. <br>
> However, they may not have focused on this issue, I will make sure that we get their input.<br>
> <br>
> Appendix 7 - Do we actually want to restrict the CLA to only cover <br>
> contributions to the Integrated Release? We will have no way to <br>
> promote code from Incubation to Integrated status with this approach. <br>
> Again, see my comments regarding Integrated Release vs. Project, above.<br>
> <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 <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 <br>
> file, it does not preclude other contributors from signing the CLA. <br>
> If the terms for "incubation" are sufficiently established, we could <br>
> add them to the requirement (so that it covers Integrated Release and <br>
> "Incubation Projects"). However, I think that we need to keep a <br>
> limitation narrower than the OpenStack Project because we could have <br>
> situations where contributors provide contributions to the OpenStack <br>
> Project, but not the Integrated Release and those contributions might <br>
> be under a different license (not ASLv2). We should clarify that the CLA can apply to projects outside of the Integrated Release.<br>
> <br>
> <br>
> <br>
> <br>
> --<br>
> <br>
> Joshua McKenty<br>
> Chief Technology Officer<br>
> Piston Cloud Computing, Inc.<br>
> +1 (650) 242-5683<br>
> +1 (650) 283-6846<br>
> http://www.pistoncloud.com<br>
> <br>
> "Oh, Westley, we'll never survive!"<br>
> "Nonsense. You're only saying that because no one ever has."<br>
> <br>
> On Sep 8, 2014, at 10:20 AM, Radcliffe, Mark <br>
> <br>
> wrote:<br>
> <br>
> > I would like to get your comments by Wednesday COB so we can post it <br>
> > for<br>
> community comments. Thanks.<br>
> ><br>
> > From: Radcliffe, Mark<br>
> > Sent: Tuesday, September 02, 2014 12:11 PM<br>
> > To: Rob Hirschfeld (rob_hirschfeld@dell.com); 'Joshua McKenty'<br>
> > Cc: Roay, Leslie; Eileen Evans Esq. (eileen.evans@hp.com); 'Alan <br>
> > Clark';<br>
> 'Jonathan Bryce'<br>
> > Subject: Updated Bylaws<br>
> ><br>
> > I am enclosing the revision to the bylaws based on our discussion <br>
> > with the Rob<br>
> to deal with issues from the Technical Committee. We have changed the <br>
> approach to require the Technical Committee to get approval from the <br>
> Board prior to making a change in the OpenStack Integrated Release <br>
> which would delete any of the OpenStack Core Project. I also took <br>
> another look the Standards provision in Section 7.4 and decided to <br>
> make clear that it would not affect the new approach to determining <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 <br>
> > review it<br>
> and provide any comments so we can put it on the website for community <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 <br>
> > legally<br>
> privileged. It has been sent for the sole use of the intended <br>
> recipient(s). If the reader of this message is not an intended <br>
> recipient, you are hereby notified that any unauthorized review, use, <br>
> disclosure, dissemination, distribution, or copying of this <br>
> communication, or any of its contents, is strictly prohibited. If you <br>
> have received this communication in error, please reply to the sender <br>
> and destroy all copies of the message. To contact us directly, send to postmaster@dlapiper.com. Thank you.<br>
> <br>
> Please consider the environment before printing this email.<br>
> <br>
> The information contained in this email may be confidential and/or <br>
> legally privileged. It has been sent for the sole use of the intended <br>
> recipient(s). If the reader of this message is not an intended <br>
> recipient, you are hereby notified that any unauthorized review, use, <br>
> disclosure, dissemination, distribution, or copying of this <br>
> communication, or any of its contents, is strictly prohibited. If you <br>
> have received this communication in error, please reply to the sender <br>
> and destroy all copies of the message. To contact us directly, send to postmaster@dlapiper.com. Thank you.<o:p></o:p></p>
</div>
</body>
</html>