Open Stack

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)