[OpenStack-DefCore] Updated Bylaws

Radcliffe, Mark Mark.Radcliffe at dlapiper.com
Mon Sep 8 19:08:45 UTC 2014


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 <Mark.Radcliffe at dlapiper.com> 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.




More information about the Defcore-committee mailing list