Open Stack

On Wed, 2014-06-25 at 13:57 -0500, Mark Collier wrote:
> Great summary Jonathan.  
> 
> TL;DR if you read to the end I mention Ceph!
> 
> Here are the key points which relate to the debate at hand.  
> 
> 1)  The TM policy itself simply requires companies to get a license
> for commercial use, but does not dictate what the contents of those
> licenses should be. The requirements inside of those license
> agreements can be updated as needed by the Foundation.  
> 
> 2)  The current product requirements in those agreements are
> essentially “include entirety of Nova & Swift from a recent release
> and pass some FITs tests approved by the TC when available."  This is
> outdated and insufficient given how fast the project has expanded, but
> it is the status quo. Any improvement on this status quo is progress
> in my book, fwiw.

Yep, agree.

> 3)  The real question is:  what should those technical requirements be
> to call your product “OpenStack” (i.e. to get a license)?

We should be careful of our language around this - nobody gets to call
their product "OpenStack". This is about the technical requirements for
products to use the "OpenStack Powered" logo, call their product "Acme
Cloud Software Powered by OpenStack" or similar, or (I assume this bit -
see my question to Jonathan) call their product "Acme OpenStack".

> In particular, how should the code inclusion requirements evolve?

Yes, this is certainly the big question.

The way we've structured OpenStack governance, we have made the Board of
Directors ultimately responsible for this important policy question. The
DefCore committee, the Foundation staff, the TC, PTLs, etc. cannot make
this decision unless the board chooses to delegate the decision, which
it hasn't done AFAICT.

This wasn't my preferred structure, but the most easily understood
rationale for it is that the Foundation Board is the body best suited to
making the difficult tradeoffs required to grow the commercial ecosystem
around OpenStack.
 
> If we can come to a consensus on an answer to that question,

To be clear - consensus is not required. The Board can choose to proceed
to instruct the Foundation staff how the trademark licenses should be
updated without any wider community consensus.

(I should say AIUI - I'm happy for someone to explain how that isn't the
case if my understanding is wrong)

>  we (the foundation staff) can work with our trademark counsel to
> update the agreements. That won’t be a lengthy process, as the product
> requirements are all in one section of the agreements.
> 
> The trick is coming to a consensus on what those requirements should
> be.  Amending the Bylaws to clear up the admittedly confusing language
> is a nice thing to pursue for the sake of clarity, but I think it’s a
> red herring for the more pressing matter.

Yep, agree. Jonathan's clarification about the Trademark Policy and
individual trademark license agreements makes that clear.

> Defcore was formed to come up with that answer, in an open community
> involved way, in conjunction with the TC and PTLs and any other
> stakeholders.  I don’t want to try to summarize the current state of
> Defcore in this email, but in general the direction is to express the
> requirements in terms of capabilities as well as tests, rather than
> projects per se, with code requirements that are likely to be less
> than 100% within each particular project.  

A simple example of this shows how the meat of these questions are
policy decisions around growing the commercial ecosystem rather than
technical ones. Cinder has a volume driver layer and quite a number of
drivers are part of the OpenStack Project and included in the Integrated
Release.

The intent of "designated sections" seems to be to avoid placing any
restrictions on vendors of "OpenStack Powered" products around what
volume driver code they use or ship. The code could be pristine drivers
from upstream, heavily patched versions of upstream drivers, open-source
but not upstream drivers, or completely proprietary drivers.

Cinder's scheduler, and various parts of cinder's scheduler, is also
extremely pluggable. If we said that the scheduler is a "designated
section" but the scheduler filters are not designated, we're saying that
proprietary filters should be allowed under the "OpenStack powered"
trademark license. Under what basis would the TCs or PTLs make that
judgment call, given that it's a question of what is best for growing
the commercial ecosystem?

> The question that is raised when we consider going below 100% of a
> particular project, is do you eventually consider 0%, as long as the
> APIs are implemented?  Let’s say, hypothetically, your product or
> cloud service exposes the Swift API but uses an alternative back end,
> say Ceph for example.  Is that still “OpenStack”?  Let’s face it,
> that’s the question on a lot of people’s minds.  The Defcore committee
> has approached these questions holistically by starting with
> documenting criteria for making such weighty decisions.

I think the criteria for deciding which API capabilities are required
has been well documented and looks to be giving a very reasonable
outcome. However, the process for deciding "designated sections" looks
increasingly backwards to me.

In the case of Swift, the conclusion so far seems to be that certain
Swift APIs could be considered required capabilities, but *only if* the
TC decides that 0% of Swift's code is designated.

  https://etherpad.openstack.org/p/DefCoreLighthouse.F2F

  Picking designated sections for Swift > we are in a position to choose
  0 or 100 without any intermdiate.

  DefCore agrees that the TC is the deciding body for designated
  sections.

  Official position, DefCore asks TC to resolve Swift D.S. question.

  ACTION > Rob to take to TC that if Swift has any designated sections
  then the DefCore committee will likely recommending omitting the
  "object-*" capabilities from core.

i.e. that DefCore sees that it is impossible for the "OpenStack Powered"
trademark license to require the use of any Swift code, and that if the
TC thinks any code should be required then DefCore will recommend that
no APIs are required, effectively resulting in no code being required
anyway.

The starting assumption that "the TC is the deciding body for designated
sections" just seems (and has always seemed) wrong to me, particularly
if it results in the Board removing capabilities from the "required
capabilities" list because the Board disagrees with the TC's opinion
that the code for those APIs should be required.

Thanks,
Mark.