Open Stack

-----Original Message-----
From: Thierry Carrez [mailto:thierry at openstack.org]
Sent: Friday, September 19, 2014 7:29 AM
To: Mark McLoughlin; Radcliffe, Mark
Cc: aclark at suse.com; defcore-committee at lists.openstack.org; eileen.evans at hp.com; Roay, Leslie
Subject: Re: [OpenStack-DefCore] Updated Bylaws

Mark McLoughlin wrote:
> This feels like deja-vu, but I just spent some time reviewing the
> wrong version of these changes before finding the right one.
> [...]

I fully agree with your analysis. Two items are of particular concern:

* the general search/replace of "the OpenStack Project" by "the OpenStack Integrated Release" reduces the reach of the TC to integrated projects only, which would place critical release-building functions (like release management or infrastructure) out of the TC authority under the bylaws. That's pretty wrong; both from a technical standpoint and a governance standpoint.

RESPONSE:  These comments are the reason that we are getting the DefCore review.  As I noted to Josh and Mark, we will change Integrated Release to OpenStack Project.

* the "ask for permission before removing" is, as you clearly mention, impractical. That creates an area where disagreement between the board and the TC would end up being paid by our users (we could be forced to keep around things we technically deprecated and nobody maintains), which I think is unacceptable.

My other concern is that those changes seem to fail to address the issues in the current bylaws. Our bylaws are currently hopelessly out of date because they are not flexible enough and they are hard to change.
Rather than taking this opportunity to clean the mess up, we seem to perpetuate old concepts like "the Core OpenStack Project" or the "Definition Date", while we should have learned by now that in bylaws, less usually means more.

The situation is actually really, really simple: the TC is responsible for a set of code repositories collectively known as "the OpenStack project", which aim to fulfill the OpenStack Mission. Even speaking of the "Integrated Release" is treading on an implementation detail, which may prevent further evolution ! The "Core OpenStack Project" is an historical artifact, and trademark policy now uses much more quantifiable concepts (like capabilities and designated sections), so I don't see the value of continuing to mention it in the bylaws themselves.

Personally I would just get rid of any mention of "Core OpenStack Project" and "Integrated release" in the bylaws, and only keep "the OpenStack Project". That would give us flexibility we need to evolve in the future, both on the TC side and on the Trademark policy side.

RESPONSE:  Let's make sure that we remember the background: the Board (and I) agree that the current bylaws are too detailed and too difficult to change. The DefCore process was started by the Board in November to determine how to redefine the process. However, the requirement that changes in the Core require Board approval has been part of the bylaws from the Foundation's beginning (see below). In fact, DefCore is a committee appointed by the Board to determine how to define Core in the future. The Board certainly wants to define those capabilities with the Technical Committee input and has been doing so, so I think that you concern about a disagreement between the Board and the TC are misplaced. However, the Board does have responsibility for trademark policy , if certain code or functionality is required for trademark use,  the Board needs to be able to control any proposed deletion to such code/functions.  For example, if the trademark policy specifies "designated code" and the Technical Committee deprecates that designated code, what does it mean to have a trademark policy?  As I noted to Mark,  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.  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.

We need the three definitions for the following reasons:

1.      Core OpenStack Project: The parts of the distributed code/capabilities required for trademark use. Since the Board is responsible for the trademark policy, they need input on removing these functions/designated code.

2.      Integrated Release: The parts of the OpenStack Project (of which the Core OpenStack Project is a subset) which are distributed and need to be under the Apache License version 2.0. The definition of what goes into the Integrated Release is completely in the discretion of the Technical Committee except that it needs to be available under the Apache Software License version 2.0.

3.      OpenStack Project:  All of the code managed or used by the OpenStack community (of which the Integrated Release and the Core OpenStack Project are subsets) whether distributed or not. The code that is not distributed does not need to be under the Apache Software License version 2.0 which gives the Technical Committee more flexibility.

I don't understand how defining Integrated Release impinges on implementation details (see above). However, if you can explain the concern, I will work to resolve it.




--
Thierry Carrez (ttx)

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/6bcc0287/attachment.html>