Open Stack

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.

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.

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?

Jonathan



On Sep 10, 2014, at 11:23 PM, Joshua McKenty <joshua at pistoncloud.com> wrote:

> Who is the "we" in this thread?
> 
> The legal affairs committee has no mandate to propose Bylaws changes. 
> 
> You, personally, are not a board member. 
> 
> And the DefCore committee has been very clear about our belief that we are not yet ready to pursue Bylaws amendments. 
> 
> Are you acting under the direction of the foundation executive staff? Or a specific board member that I'm not aware of?
> 
> 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. 
> 
> Sent from my iPhone
> 
> On Sep 10, 2014, at 12:34 AM, "Radcliffe, Mark" <Mark.Radcliffe at dlapiper.com> wrote:
> 
>> 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.
>>  
>> 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.
>>  
>> I recommend that we find a way to get coordinated and final comments from the DefCore Committee on the bylaws.
>>  
>> 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.
>>  
>>  
>>  
>>  
>>  
>> From: Rob_Hirschfeld at Dell.com [mailto:Rob_Hirschfeld at Dell.com] 
>> Sent: Tuesday, September 09, 2014 8:53 PM
>> To: Radcliffe, Mark; joshua at pistoncloud.com
>> Cc: defcore-committee at lists.openstack.org; Roay, Leslie; eileen.evans at hp.com; aclark at suse.com;jonathan at openstack.org
>> Subject: RE: Updated Bylaws
>>  
>> Mark and Josh,
>>  
>> I think this dialog is insightful and I appreciate the deep analysis.   
>>  
>> My comments/concerns:
>> 1)      I agree with Josh’s concerns about the private/public lists and conflating changes such as ATC, Trademark, and Legal affairs.
>> 2)      My understanding was that we’d review the “DefCore process appendix” before any additional bylaws changes were reviewed.
>> 3)      Over all, I think that this change (overlooking that it was not anticipated yet) is closer to target language and intent.
>>  
>> 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.
>>  
>> Any idea on when that document would be available for review?
>> > -----Original Message-----
>> > From: Radcliffe, Mark [mailto:Mark.Radcliffe at dlapiper.com]
>> > Sent: Monday, September 08, 2014 2:09 PM
>> > To: Joshua McKenty
>> > Cc: Hirschfeld, Rob; defcore-committee; Roay, Leslie; Eileen Evans Esq.
>> > (eileen.evans at hp.com); Alan Clark; Jonathan Bryce
>> > Subject: RE: Updated Bylaws
>> > 
>> > Josh:
>> > 
>> > My apologies for any confusion. I sent this draft to you as the 
>> > co-chair of the Defcore committee for you to share with the Defcore 
>> > committee in the most appropriate manner. I did not mean to suggest 
>> > that your comments would be private.
>> > 
>> > Your comments are very helpful and I have responded below. However, 
>> > I think that it would be useful to have a coordinated set of comments 
>> > by the Defcore committee. How can we achieve such a set of comments?
>> > 
>> > -----Original Message-----
>> > From: Joshua McKenty [mailto:joshua at pistoncloud.com]
>> > Sent: Monday, September 08, 2014 10:56 AM
>> > To: Radcliffe, Mark
>> > Cc: Rob Hirschfeld; defcore-committee; Roay, Leslie; Eileen Evans Esq.
>> > (eileen.evans at hp.com); Alan Clark; Jonathan Bryce
>> > Subject: Re: Updated Bylaws
>> > 
>> > It is a violation of Board policy to discuss this off of a public 
>> > mailing list. CCing the defcore mailing list for transparency.
>> > 
>> > 
>> > 4.1(b)(i) changes are substantially out-of-line with the intended 
>> > meaning of that clause - the TC is intended to manage the technical 
>> > matters of all aspects of the openstack project, not just the 
>> > integrated release. I believe these changes are unnecessary and have negative side effects.
>> > 
>> > RESPONSE: We will make this change.
>> > 
>> > 4.1(b)(ii) conflates the Integrated Release with the broader OpenStack 
>> > project again.
>> > 
>> > RESPONSE: As above, we will change to OpenStack Project.
>> > 
>> > The introduction of the "OSP New Definition Date" into the Bylaws 
>> > seems bizarre. Why don't we vote and approve these bylaw changes once 
>> > the OSP process is ready, and then simply change the paragraph - 
>> > instead of preserving THREE different definitions of core in the 
>> > Bylaws? (In that vein, the second-to- last paragraph of this clause 
>> > could be struck entirely.)
>> > 
>> > RESPONSE: These changes need to be approved by the Board and (i) 
>> > two-thirds of the Gold Members, (ii) two-thirds of the Platinum 
>> > Members, and (iii) a majority of the Individual Members voting (but 
>> > only if at least 25% of the Individual Members vote at an annual or 
>> > special meeting). Consequently, the actual date of "approval" may 
>> > be difficult to determine. It is simpler to have the Board be able to choose the date for the cutover.
>> > 
>> > 4.1.(b)(iii) - Could we move the last sentence (posting to the 
>> > website) into Section 7.3 for clarity?
>> > 
>> > RESPONSE: We have included it in Section 4.1(b)(ii) and need it in 
>> > this section for parallelism. I think that we should keep in it in 
>> > each provision. Section 7.3 deals with a different issue, the trademark policy.
>> > 
>> > Is it "Core OpenStack Project" or "OpenStack Core Project"? 
>> > 4.13(c)(i) and 4.1 don't match. (Ditto 7.4)
>> > 
>> > RESPONSE: It is "Core OpenStack Project" and we will ensure that it 
>> > is used consistently.
>> > 
>> > 4.13(c)(i) Seems like it could be simplified. Again, it seems like all 
>> > of 4.13 would be simpler without the introduction of the OSP New Definition Date.
>> > 
>> > RESPONSE: See above about the OSP New Definition Date. I am open to 
>> > suggestions on this provision. The key issue is that the Technical 
>> > Committee cannot drop part of the Core OpenStack Project in developing 
>> > the new version of the Integrated Release.
>> > 
>> > 4.15 - I strongly object to using DefCore-related bylaws changes to 
>> > make non- cosmetic changes to the Legal Affairs committee. This should 
>> > be a separate set of redlines and a separate vote.
>> > 
>> > RESPONSE: These changes are not DefCore only changes. We are changing 
>> > a number of sections of the bylaws only some of which are relevant to 
>> > DefCore. If they are not relevant to DefCore, you do not need to comment on them.
>> > 
>> > 4.15 - The legal affairs committee should strive to protect the entire 
>> > OpenStack project ecosystem, not just the integrated release, no?
>> > 
>> > RESPONSE: We will change this back to the OpenStack Project.
>> > 
>> > 4.17(a) - Unnecessary change. The Integrated Release is *not* a 
>> > replacement for the term "OpenStack project" - it's a subset of the 
>> > OpenStack Project, in the same way that Core is a subset of the 
>> > Integrated Release. (ditto 7.4)
>> > 
>> > RESPONSE: We will change this back to the OpenStack Project. Since 
>> > we are changing Section 4(b), we will change Section 7.4.
>> > 
>> > Ditto for 7.1(c) - The OpenStack foundation distributes project 
>> > software beyond the boundaries of the Integrated Release, and we 
>> > should continue to target
>> > ASLv2.0 for that.
>> > 
>> > RESPONSE: This obligation is an absolute one, it is not "desirable". 
>> > We can certainly encourage the use of ASLv2, but I think that the 
>> > OpenStack Foundation needs more flexibility in licenses modules 
>> > outside of the Integrated Release. Moreover, I understand that a 
>> > number of these modules are in existence and the OpenStack Foundation 
>> > would not have control over their license. We can make it a "desired" policy without making it part of the bylaws.
>> > 
>> > 7.3 - What does this mean? "The OpenStack trademarks shall only be 
>> > used to promote the Foundation, the OpenStack Integrated Release or 
>> > services related to the OpenStack Integrated Release as provided in 
>> > the Trademark Policy." I would think that the entire point of a 
>> > trademark license would be for the licensee to be able to use the 
>> > trademark under license to promote their own product or services.
>> > 
>> > RESPONSE: This sentence does not prevent promotion of a licensee's 
>> > products so long as they include the Integrated Release. In the last 
>> > draft, the Trademark Policy was fixed (i.e. it was an exhibit). We 
>> > have found that this approach does not work well, so we are giving 
>> > discretion to the Board to change the policy. I thought that the 
>> > community would be more comfortable by clarifying the scope of the discretion. However, we can delete this sentence.
>> > 
>> > Appendix 4, 3(b) - While I think this is an appropriate change, it's 
>> > actually out of scope for us to change the definition of ATC from 
>> > "Core contributor" to "Integrated Release contributor" without 
>> > checking with the TC. (Personally, I think ecosystem contributors should be considered ATCs as well).
>> > 
>> > RESPONSE: We have discussed the changes in general with the TC. 
>> > However, they may not have focused on this issue, I will make sure that we get their input.
>> > 
>> > Appendix 7 - Do we actually want to restrict the CLA to only cover 
>> > contributions to the Integrated Release? We will have no way to 
>> > promote code from Incubation to Integrated status with this approach. 
>> > Again, see my comments regarding Integrated Release vs. Project, above.
>> > 
>> > RESPONSE: See my comment on Section 7.1(c). This change does not prevent
>> > promotion of code from Incubation to Integrated status, however anyone 
>> > seeking to develop code that they want to eventually be part of the Integrated
>> > Release needs to understand that it will have to be under ASLv2. The CLA only
>> > requires that contributors to the Integrated Release have a CLA on 
>> > file, it does not preclude other contributors from signing the CLA. 
>> > If the terms for "incubation" are sufficiently established, we could 
>> > add them to the requirement (so that it covers Integrated Release and 
>> > "Incubation Projects"). However, I think that we need to keep a 
>> > limitation narrower than the OpenStack Project because we could have 
>> > situations where contributors provide contributions to the OpenStack 
>> > Project, but not the Integrated Release and those contributions might 
>> > be under a different license (not ASLv2). We should clarify that the CLA can apply to projects outside of the Integrated Release.
>> > 
>> > 
>> > 
>> > 
>> > --
>> > 
>> > Joshua McKenty
>> > Chief Technology Officer
>> > Piston Cloud Computing, Inc.
>> > +1 (650) 242-5683
>> > +1 (650) 283-6846
>> > http://www.pistoncloud.com
>> > 
>> > "Oh, Westley, we'll never survive!"
>> > "Nonsense. You're only saying that because no one ever has."
>> > 
>> > On Sep 8, 2014, at 10:20 AM, Radcliffe, Mark 
>> > 
>> > wrote:
>> > 
>> > > I would like to get your comments by Wednesday COB so we can post it 
>> > > for
>> > community comments. Thanks.
>> > >
>> > > From: Radcliffe, Mark
>> > > Sent: Tuesday, September 02, 2014 12:11 PM
>> > > To: Rob Hirschfeld (rob_hirschfeld at dell.com); 'Joshua McKenty'
>> > > Cc: Roay, Leslie; Eileen Evans Esq. (eileen.evans at hp.com); 'Alan 
>> > > Clark';
>> > 'Jonathan Bryce'
>> > > Subject: Updated Bylaws
>> > >
>> > > I am enclosing the revision to the bylaws based on our discussion 
>> > > with the Rob
>> > to deal with issues from the Technical Committee. We have changed the 
>> > approach to require the Technical Committee to get approval from the 
>> > Board prior to making a change in the OpenStack Integrated Release 
>> > which would delete any of the OpenStack Core Project. I also took 
>> > another look the Standards provision in Section 7.4 and decided to 
>> > make clear that it would not affect the new approach to determining 
>> > the OpenStack Integrated Release and OpenStack Core Project. I am enclosing a markup to the existing version.
>> > >
>> > > This draft has been approved by the Legal Affairs Committee. Please 
>> > > review it
>> > and provide any comments so we can put it on the website for community 
>> > review prior to the September 22 Board meeting Thanks.
>> > >
>> > >
>> > > Please consider the environment before printing this email.
>> > >
>> > > 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 at dlapiper.com. Thank you.
>> > 
>> > Please consider the environment before printing this email.
>> > 
>> > 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 at dlapiper.com. Thank you.
>> 
>> Please consider the environment before printing this email. 
>> 
>> 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 at dlapiper.com. Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140911/7558bf8b/attachment-0001.html>