Open Stack

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