Open Stack

+1000

On Sep 22, 2014 4:47 AM, Mark Collier <mark at openstack.org> wrote:
>
> Well said 
>
>
>
> On September 22, 2014 2:54:52 AM Thierry Carrez <thierry at openstack.org> wrote: 
>
> > Radcliffe, Mark wrote: 
> > >> 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. 
> > 
> > I think the view of the TC is that we produce a number of projects and 
> > that at every release, the Board picks subsets of those projects to use 
> > for various trademark policies. For example, for havana, the board picks 
> > "designated sections" among the "integrated release" to use with the 
> > "Powered by OpenStack" trademark. For icehouse, it may pick other 
> > projects among those we produce. At every release, the TC creates the 
> > superset and the Board picks the subset(s). The TC is not interested in 
> > proposing subset(s). And the board should not prevent removals from the 
> > superset. 
> > 
> > If a given project is abandoned by all developers and no longer part of 
> > the integrated release, having the board mandate that it's still part of 
> > the integrated release would be awkward. Now, I understand the intent -- 
> > we don't want to bluntly deprecate / remove items that have become part 
> > of trademark rules. But the TC has structure in place for deprecation / 
> > removal of features already (takes at least two cycles), so I think that 
> > concern can be solved without having the Board step into TC territory in 
> > the definition of the superset. 
> > 
> > > [...] 
> > > 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. 
> > 
> > I'll expand on my comment. I think that ideally, we would not have to 
> > change bylaws every time we adapt our processes or trademark license 
> > programs. Ideally, the language in the bylaws would let us some 
> > maneuvering room so that we don't constantly have to consider costly 
> > changes to them (especially around the protected sections). Therefore I 
> > think the language in the bylaws should avoid unnecessary details as 
> > much as possible. 
> > 
> > The "Core OpenStack Project" is a detail. It's a subset of projects that 
> > the future "powered by OpenStack" trademark policy will use. Actually, 
> > the policy doesn't even mention "core" anymore, but uses "designated 
> > sections" and "required capabilities", which are much more descriptive. 
> > What if tomorrow we want to have two trademark policies (add "OpenStack 
> > compatible") which affect different subsets of projects, and the bylaws 
> > only define one ? Saying that "the board may pick any subset of the 
> > OpenStack Project as they deem necessary to use as part of trademark 
> > license programs definition" gives the board much more room to evolve 
> > trademark policies in the future without requiring a new bylaws change. 
> > 
> > The name "integrated release" is also a detail. If the projects in the 
> > release stop being "integrated" or the release becomes staggered, it 
> > should not prevent the board from picking a subset of it for trademark 
> > policies. That said, I think we can live with this one being in the 
> > bylaws, since there will probably always be a concept that we can map to 
> > it in the future, so it should not really prevent anything from 
> > happening (or require a bylaws change one year down the road). 
> > 
> > That said, I'm not a lawyer... you certainly know better than I do about 
> > required language. My concern is about agility. IMHO our bylaws set too 
> > much in stone, so we can't undertake any change in policy without 
> > changing them, and it takes a couple of years to do so. 
> > 
> > -- 
> > Thierry Carrez (ttx) 
> > 
> > _______________________________________________ 
> > Defcore-committee mailing list 
> > Defcore-committee at lists.openstack.org 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee 
>
>
>
> _______________________________________________ 
> Defcore-committee mailing list 
> Defcore-committee at lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee 
>