Open Stack

> On Jun 29, 2014, at 8:34 AM, Mark McLoughlin <markmc at redhat.com> wrote:
> 
> 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”.


Great point, no product can be called simply “OpenStack”.  OpenStack (that which we produce every 6 months as a community) is, in fact, “OpenStack”. :)  What is possible, with a signed license, is to use the word “OpenStack” as _part of_ your product name, when meeting all of the requirements, in a particular manner.

To directly address the word mark usage examples in product names, Jonathan did give one example (ACME Cloud Powered by OpenStack).  However, in the case of Distributions, we have been granting the right to use it in combination with the company’s brand such as “Piston OpenStack” or “Red Hat OpenStack” or “Mirantis OpenStack”.  Each of those examples are of products from companies who’ve signed a TM license with the foundation.  




> 
>> 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.
>