Open Stack

Thanks for your comments.  As I noted, I will be including a number of the changes relating to Integrated Release/OpenStack Project.  Please see my other responses below.

-----Original Message-----
From: Mark McLoughlin [mailto:markmc at redhat.com]
Sent: Wednesday, September 17, 2014 5:22 AM
To: Radcliffe, Mark
Cc: Joshua McKenty; eileen.evans at hp.com; Roay, Leslie; aclark at suse.com; defcore-committee at lists.openstack.org
Subject: Re: [OpenStack-DefCore] Updated Bylaws

This feels like deja-vu, but I just spent some time reviewing the wrong version of these changes before finding the right one.

For the avoidance of doubt, I think this document:

Change-Pro Redline - 233015232-v15-OpenStackFoundation Bylaws FINAL (as amended September 7, 2012) and 233015232-v24-OpenStackFoundation Bylaws FINAL

is the one we should all be looking at. It shows the changes between the current bylaws (v15) and the latest proposed changes (v24). I would really like that document to be published somewhere that we can all easily refer to rather than it being forwarded around over email.


The main thing that occurs to me is that I wonder why we're perpetuating this "Core OpenStack Project" term at all. I found this email from Jonathan extremely instructive:

http://lists.openstack.org/pipermail/foundation/2014-June/001701.html

The intent is of the "Core OpenStack Project" is to help define the requirements for commercial trademark usage, but we now have "capabilities" and "designated sections" to define that. The perception that the "Core" term creates is there is a subset of the Integrated Release that the board approves of, and by extension a subset that they disapprove of.

RESPONSE:  First, I realize that no-one likes the word "Core" and I would be happy to replace it with another term, but we have not been able to agree on a new term.  However, the definition of capabilities and designated sections are not sufficient to delete the "Core" definition because we need a term to refer to the code/capabilities required for trademark use. I don't understand (and don’t agree) with the statement that the Board is disapproving parts of the Integrated Release, the bylaws reflect the reality that the code/functionality required for trademark use is less than the entire Integrated Release. And we are also drafting the bylaws to take into account the possibility that we will change the process in the future. We started with defined modules and we are now moving to the DefCore process, but in the future the Board may decide that to adopt a different procedure to define what is needed for trademark use.

If we now have a clear way of defining the requirements for trademark usage, I really don't understand why we're seeking to perpetuate the confusion and controversy created by the "Core OpenStack Project" term.

RESPONSE:  I don't think that we have a clear method of defining trademark use.  Even if we did have a clear method of defining trademark use, we still need to have the concept that only certain parts of the Integrated Release are needed to use the trademark.  This definition also limits the scope of the Board's authority and clarifies the broader authority of the TC.

As for removing the trademark policy from the bylaws, I see the policy as a high-level set of principles about how the trademarks should be managed and I'm fine with those principles requiring bylaws changes.
However, specific implementation details of those principles (like the exact set of trademark programs) should determined by the board.

In other words, if there are parts of the trademark policy which are "implementation details" which we feel should be determined by the board, why not just remove those details from the policy?


RESPONSE:  Trademark policies by their nature are very detailed because they are meant to explain to third parties how to use the marks (see the current policy).  I am not sure what you mean by “high level principles”.  I have included a limitation on the scope of the trademark policy in the bylaws. Since I am not sure about the nature of the distinctions that you are suggesting please provide specific proposals.  This draft reflects the statement that TC were not concerned about the exact nature of the trademark policy so we have left it to the Board to determine it (and the current bylaws do not have a role for the Technical Committee in determination of the trademark policy).


More specific comments below.

Mark.

---

4.1

  - The Technical Committee is responsible for managing the OpenStack
    Project, not simply the Integrated Release.

RESPONSE:  As noted in my email to Josh, we will make this change. This change was a misunderstanding on my part.

  - I don't know that the sentence "the OpenStack Project shall include
    the" is all that useful, and the new wording really doesn't clear up
    any of the confusion it has caused.

RESPONSE:  This provision is based on the definition in the original bylaws. We are trying to include the components of the OpenStack Project which are not distributed (the Integrated Release is what is distributed), including tools. My understanding is that these components do not go through the type of management and approval process used on the Integrated Release and since they are not part of the Integrated Release they do not need to be under the Apache License.  If you have specific suggestions for how to clarify this definition, please provide me with those suggestions.

The whole "New Definition Date" thing is extremely awkward.

RESPONSE:  I am not sure I understand the nature of the concern.  This provision simply states that after we get all of the necessary corporate approvals the Board will then decide the exact date to implement the changes. Otherwise, the bylaws changes would be effective immediately and the Foundation might not be ready for them. Even after the Foundation gets the corporate approvals, the Foundation will need to put in place the new procedures on the website and educate the community on issues such as the trademark policy so we want to do it in an orderly manner.

  - This section has been a constant source of confusion and
    controversy. I think the proposed changes are simply going to cause
    more of the same. We should step back and think about what this
    paragraph is attempting to get across. The proposed changes will not
    eliminate the confusion and controversy.

RESPONSE:  I don't understand this comment.  The paragraph is based on the existing paragraph and is meant to clarify the difference in roles between the Board and the TC.     Please clarify.

  - "The use of the OpenStack trademarks on the Core OpenStack Project
    shall be defined in the Trademark Policy in Section 7.3." - I think
    that overstates the purpose of the policy. The policy does little
    more than define some high level principles and leaves the way open
    for defining additional programs.

RESPONSE:  The policy has been and will be very detailed because it is designed to provide detailed guidance to potential users of the trademark.


4.13

  - In 4.13(c)(i) we're now requiring the TC to seek board approval
    before removing certain capabilities/code from the Integrated
    Release. I understand that the intent is to avoid poorly handling
    the removal of parts of OpenStack which we see as critically
    important, but I really think we need to trust the TC to manage
    this correctly rather than requiring board sign-off. Imagine the
    Nova v2 is communicated as deprecated for multiple cycles before it
    is removed, and then the TC seeks approval for this in advance of
    the release but the board refuses. Then what?

RESPONSE: This provision does not change the current procedure in which  changes in the "Core" need prior approval by the Board (see below). It is not about trusting the Technical Committee.
If certain code or functionality is required for trademark use, the group which is responsible for setting trademark policy (the Board) needs to be able to control any changes to such code/functions.  In the original bylaws, the Technical Committee did have the exclusive right to make proposals to change the scope of Core.  I included that approach in the draft this summer, but I was told that the Technical Committee was not interested in continuing that approach since it dealt with trademark use.  If that view has changed, we should discuss it.


                (b)       The Technical Committee shall have the authority to determine the modules for addition, combination, split or deletion from the OpenStack Project except for modules of the Core OpenStack Project (as defined in Section 4.1(b) above) which shall be managed as provided below.  For modules of the Core OpenStack Project, the Technical Committee may recommend to the Board of Directors the modules for addition, combination, split or deletion from the Core OpenStack Project.  Except as provided below, the Board of Directors shall consider only those additions, combinations, splits or deletions that are recommended by the Technical Committee, but shall have the sole authority to approve or reject such additions, combinations, splits and deletions from the Core OpenStack Project. If any software in the Core OpenStack Project is (i) subject to an injunction or other court order which would subject the distributors or users of such software to liability for intellectual property infringement or misappropriation or (ii) the majority of the Board of Directors believes that such an order is reasonably likely, the Board of Directors shall give notice to the chair of the Technical Committee of the issue. If the Technical Committee does not take reasonable steps to mitigate the risk  (such as ceasing distribution of such software or modifying such software to make it non-infringing) as determined by the Board of Directors within thirty (30) days of the receipt of such notice, the Board of Directors may waive the requirement in the Trademark Policy or otherwise to include such software in a distribution in order to use the OpenStack trademarks.

  - Again, the whole "OSP New Definition Date" thing seems overly
    involved.

RESPONSE:  See above.

4.15

  - IMO, we should just remove the definition of the Legal Affairs
    Committee from the bylaws. I don't see why it shouldn't be like any
    other board subcommittee so that it can be evolved without bylaws
    changes.

RESPONSE:  It was included at the request of some of the members. It is not really a Board committee since its members are not Board members. We are trying to make it governed by the Board and minimize requirements for future bylaw changes.


  - The emphasis on the Integrated Release is weird/wrong here. What
    was wrong with including the entire OpenStack Project in the remit
    of the committee?

RESPONSE:  Normally, the committee would be focused on the product distributed by the Foundation (the Integrated Release, not the tools which are included in the OpenStack Project), but I am fine with changing it to the OpenStack Project.

4.17

  - Again, emphasizing the Integrated Release seems wrong.

RESPONSE:  The change in Section 4.1 will also mean that we make this change.

7.1

  - The "Project" to "Integrated Release" change here implies that the
    Foundation may distribute software under a license other than the
    Apache License 2.0. I doubt that's intentional.

RESPONSE:  This change was included to reflect that some of the tools which are part of the OpenStack Project, but not part of the Integrated Release are not distributed by the Foundation and are under different licenses (the Foundation may not even control them).


7.3

  - I'm not sure I see why the trademark policy needs to be determined
    by the board. Again, we need the board to be able to determine the
    "implementation details, but not the high level principles.

RESPONSE:  The trademark policy has always been the responsibility of the Board with input from the members. The determination was that “locking” down the policy was too inflexible. Once again, if you want to provide me with the high level principles to which you refer we can discuss whether and how to include them.

Appendix 7

  - "The OpenStack Integrated Release must have a CLA on file" makes no
    sense.

RESPONSE:  As I noted above, this change was also included to reflect that some of the tools are not distributed by the Foundation and are under different licenses (the Foundation may not even control them).

Please consider the environment before printing this email.

The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster at dlapiper.com. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140919/0e6b3d63/attachment-0001.html>