settingsLogin | Registersettings

[OpenStack-DefCore] Updated Bylaws

0 votes

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.

4.1(b)(ii) conflates the Integrated Release with the broader OpenStack project again.

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.)

4.1.(b)(iii) - Could we move the last sentence (posting to the website) into Section 7.3 for clarity?

Is it ?Core OpenStack Project? or ?OpenStack Core Project?? 4.13(c)(i) and 4.1 don?t match. (Ditto 7.4)

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.

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.

4.15 - The legal affairs committee should strive to protect the entire OpenStack project ecosystem, not just the integrated release, no?

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)

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.

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.

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).

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.

--

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.

asked Sep 8, 2014 in defcore-committee by Joshua_McKenty (540 points)   1
retagged Apr 14, 2015 by admin

22 Responses

0 votes

Great set of comments, Josh. This might be a bit of an aside?.

Regarding the comment below, have we had any opportunity to discuss this with the TC in more depth? I guess what I?m thinking of here is that when we did the last joint meeting it was clear that the TC owned all ?tactical matters related to the software development life cycle (SDLC)? and the board owned all ?strategic business matters related to copyright, trademarks, marketing, and overall direction.? At that time we all agreed that there was a gap around what I will call ?strategic product management?. There were a variety of ideas of how to address that, but for me, that function is ?technical? so I?m unclear if it falls under the TC ultimately, when we resolve the issue or under the Foundation/Board.

I?m mostly just curious if anyone has tried to dig into this offline or if it?s still a niggling issue?

To be clear, I?m not expecting any bylaw changes regarding this since it?s still a nascent discussion. I just wanted to air it since I think saying ?the TC owns everything technical? actually doesn?t quite cover the reality of the situation since there are technical aspects that the TC currently doesn?t own. In fact, it?s fair to say that no one owns them, which is the crux of the problem.

Best,

--Randy

Founder & CEO, Cloudscaling
Board of Directors, OpenStack Foundation
+1 (415) 787-2253 [SMS or voice]
TWITTER: twitter.com/randybias
LINKEDIN: linkedin.com/in/randybias

On Sep 8, 2014, at 10:55 AM, Joshua McKenty wrote:

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded Sep 8, 2014 by Randy_Bias (260 points)   1
0 votes

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.

responded Sep 8, 2014 by Radcliffe,_Mark (820 points)   1
0 votes

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded Sep 10, 2014 by Rob_Hirschfeld_at_de (1,900 points)   1 4
0 votes

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: RobHirschfeld at Dell.com [mailto:RobHirschfeld 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<mailto: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<mailto: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<mailto: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:

responded Sep 10, 2014 by Radcliffe,_Mark (820 points)   1
0 votes

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: RobHirschfeld at Dell.com [mailto:RobHirschfeld 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:

responded Sep 10, 2014 by Joshua_McKenty (540 points)   1
0 votes

And the DefCore committee has been very clear about our belief that we are not yet ready to pursue Bylaws amendments.
+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded Sep 10, 2014 by Rob_Hirschfeld_at_de (1,900 points)   1 4
0 votes

Josh:

I am very puzzled by this email. This work was authorized by the Board. We have been working on it since November of last year. I provided the Board with an initial draft of the revisions on December 2, 2013 and a more recent draft on July 20, 2014. I also provided two interim drafts to the Bylaws and Trademark Policies Subcommittee of the DefCore Committee (and copied the entire Defcore Committee) in March and April. You were a recipient of all of these emails. I have discussed the issue at several Board meetings, specifically the need to have the revisions approved by Individual Members with a minimum of 25% of the Individual Members voting. Given past turnout, it appears likely that this number of Individual Members will only be available for a vote during the annual director elections.

Consequently, if the Foundation does not proceed with an amendment to the bylaws during the 2015 election cycle, we will probably not be able to amend the bylaws to implement the new DefCore standards or the revised approach to trademark usage until the 2016 Board elections in January 2016.

I don?t think that email is an effective vehicle for this discussion on this issue and suggest that we schedule a call for the DefCore Committee to discuss the appropriate approach on the bylaws. Please tell me if you want me to have my assistant set it up.

From: Joshua McKenty [mailto:joshua at pistoncloud.com]
Sent: Wednesday, September 10, 2014 2:24 PM
To: Radcliffe, Mark
Cc: Rob_Hirschfeld at Dell.com; 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

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<mailto: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: RobHirschfeld at Dell.com [mailto:RobHirschfeld 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<mailto: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<mailto: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<mailto: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<mailto: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.
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:
-------------- next part --------------
An embedded message was scrubbed...
From: "Radcliffe, Mark" <Mark.Radcliffe at dlapiper.com>
Subject: Revised Draft of Bylaws
Date: Mon, 7 Apr 2014 16:35:36 +0000
Size: 577053
URL:
-------------- next part --------------
An embedded message was scrubbed...
From: "Radcliffe, Mark" <Mark.Radcliffe at dlapiper.com>
Subject: Revised Draft of Bylaws
Date: Sat, 8 Mar 2014 23:02:28 +0000
Size: 629284
URL:
-------------- next part --------------
An embedded message was scrubbed...
From: "Radcliffe, Mark" <Mark.Radcliffe at dlapiper.com>
Subject: Revised Bylaws
Date: Sun, 20 Jul 2014 20:54:46 +0000
Size: 221599
URL:
-------------- next part --------------
An embedded message was scrubbed...
From: "Radcliffe, Mark" <Mark.Radcliffe at dlapiper.com>
Subject: RE: [Foundation Board] Update from DefCore pre-kickoff meeting (first meeting planned for 12/3 @ 8:30am PDT)
Date: Tue, 3 Dec 2013 06:46:56 +0000
Size: 361641
URL:

responded Sep 11, 2014 by Radcliffe,_Mark (820 points)   1
0 votes

We have detailed minutes of all DefCore meetings, specifically with no request to engage in Bylaws amendment. Can you point me to the board motion that authorized you to begin this work?

Sent from my iPhone

On Sep 10, 2014, at 5:58 PM, "Radcliffe, Mark" <Mark.Radcliffe at dlapiper.com> wrote:

Josh:

I am very puzzled by this email. This work was authorized by the Board. We have been working on it since November of last year. I provided the Board with an initial draft of the revisions on December 2, 2013 and a more recent draft on July 20, 2014. I also provided two interim drafts to the Bylaws and Trademark Policies Subcommittee of the DefCore Committee (and copied the entire Defcore Committee) in March and April. You were a recipient of all of these emails. I have discussed the issue at several Board meetings, specifically the need to have the revisions approved by Individual Members with a minimum of 25% of the Individual Members voting. Given past turnout, it appears likely that this number of Individual Members will only be available for a vote during the annual director elections.

Consequently, if the Foundation does not proceed with an amendment to the bylaws during the 2015 election cycle, we will probably not be able to amend the bylaws to implement the new DefCore standards or the revised approach to trademark usage until the 2016 Board elections in January 2016.

I don?t think that email is an effective vehicle for this discussion on this issue and suggest that we schedule a call for the DefCore Committee to discuss the appropriate approach on the bylaws. Please tell me if you want me to have my assistant set it up.




From: Joshua McKenty [mailto:joshua at pistoncloud.com]
Sent: Wednesday, September 10, 2014 2:24 PM
To: Radcliffe, Mark
Cc: Rob_Hirschfeld at Dell.com; 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

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: RobHirschfeld at Dell.com [mailto:RobHirschfeld 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.
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:

responded Sep 11, 2014 by Joshua_McKenty (540 points)   1
0 votes

Josh:

Since I have not attended many of the DefCore meetings and do not have the minutes, so I can?t respond to your statement about the minutes. I realize that a great deal of time has passed but I think that it would be useful to return to the beginning of the DefCore process. These revisions have been part of the process since its inception, Rob?s email on November 22 stated:

2) We?ve agreed it?s important to present a bylaws change to the committee for consideration by the board.
a. This change is to address confusion around how core is defined and possibly move towards the bylaws defining a core process not a list of core projects.
b. This is on an accelerated track because we?d like to include it with the Community Board Member elections.

Rob also listed the requirements for getting the revised bylaws approved in a November 27 email to the group and described it as being ?fast tracked? (and expressed concerns about getting the necessary approvals which I continue to share). The first draft went out to the Board in early December of that year. In fact, the DefCore Committee formed a SubCommittee (including you) in December to review drafts of the revisions to the bylaws circulated in December. I am enclosing your email about the formation of the SubCommittee. As I noted below, the SubCommittee received two proposed drafts as well as having several meetings to discuss them. And the Board has received drafts of the proposed revisions twice: in December and in July.

During this period, no-one has suggested that we should cease preparing revisions to the bylaws. Your email today was the first time I have had heard these concerns expressed.

From: Joshua McKenty [mailto:joshua at pistoncloud.com]
Sent: Wednesday, September 10, 2014 7:03 PM
To: Radcliffe, Mark
Cc: Rob_Hirschfeld at Dell.com; 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

We have detailed minutes of all DefCore meetings, specifically with no request to engage in Bylaws amendment. Can you point me to the board motion that authorized you to begin this work?

Sent from my iPhone

On Sep 10, 2014, at 5:58 PM, "Radcliffe, Mark" <Mark.Radcliffe at dlapiper.com<mailto:Mark.Radcliffe at dlapiper.com>> wrote:
Josh:

I am very puzzled by this email. This work was authorized by the Board. We have been working on it since November of last year. I provided the Board with an initial draft of the revisions on December 2, 2013 and a more recent draft on July 20, 2014. I also provided two interim drafts to the Bylaws and Trademark Policies Subcommittee of the DefCore Committee (and copied the entire Defcore Committee) in March and April. You were a recipient of all of these emails. I have discussed the issue at several Board meetings, specifically the need to have the revisions approved by Individual Members with a minimum of 25% of the Individual Members voting. Given past turnout, it appears likely that this number of Individual Members will only be available for a vote during the annual director elections.

Consequently, if the Foundation does not proceed with an amendment to the bylaws during the 2015 election cycle, we will probably not be able to amend the bylaws to implement the new DefCore standards or the revised approach to trademark usage until the 2016 Board elections in January 2016.

I don?t think that email is an effective vehicle for this discussion on this issue and suggest that we schedule a call for the DefCore Committee to discuss the appropriate approach on the bylaws. Please tell me if you want me to have my assistant set it up.

From: Joshua McKenty [mailto:joshua at pistoncloud.com]
Sent: Wednesday, September 10, 2014 2:24 PM
To: Radcliffe, Mark
Cc: Rob_Hirschfeld at Dell.com; defcore-committee at lists.openstack.org; Roay, Leslie; eileen.evans at hp.com<mailto:eileen.evans at hp.com>; aclark at suse.com; jonathan at openstack.org
Subject: Re: Updated Bylaws

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<mailto: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: RobHirschfeld at Dell.com [mailto:RobHirschfeld 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<mailto: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<mailto: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<mailto: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<mailto: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.
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:
-------------- next part --------------
An embedded message was scrubbed...
From: "Radcliffe, Mark" <Mark.Radcliffe at dlapiper.com>
Subject: RE: [Foundation Board] Update from DefCore pre-kickoff meeting (first meeting planned for 12/3 @ 8:30am PDT)
Date: Thu, 28 Nov 2013 06:03:06 +0000
Size: 15726
URL:
-------------- next part --------------
An embedded message was scrubbed...
From: "Rob_Hirschfeld at Dell.com"
Subject: [Foundation Board] Update from DefCore pre-kickoff meeting (first meeting planned for 12/3 @ 8:30am PDT)
Date: Fri, 22 Nov 2013 16:53:59 +0000
Size: 41296
URL:
-------------- next part --------------
An embedded message was scrubbed...
From: Joshua McKenty
Subject: Re: [OpenStack-DefCore] Subcommittee -- Bylaws & OpenStack Trademark Policies
Date: Sun, 8 Dec 2013 23:50:14 +0000
Size: 11313
URL:

responded Sep 11, 2014 by Radcliffe,_Mark (820 points)   1
0 votes

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 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: RobHirschfeld at Dell.com [mailto:RobHirschfeld 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:

responded Sep 11, 2014 by jonathan_at_openstac (1,540 points)   1 3
...