[OpenStack Foundation] [OpenStack-DefCore] Understanding DefCore

Mark McLoughlin markmc at redhat.com
Wed Jul 2 09:23:07 UTC 2014

On Tue, 2014-07-01 at 11:30 -0500, Mark Collier wrote:
> > 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.  

I liked Jonathan's further clarifications at yesterday's TC meetings:


  20:25:56 <jbryce> the license agreement in question is called
    OpenStack Powered and is intended for use with products and services
    that are built using OpenStack software. for instance a public cloud
    “FooTron Compute Powered By OpenStack”, an appliance “FooTron
    Appliance Powered by OpenStack, a distribution “FooTron OpenStack”
  20:26:38 <jbryce> all of those difference products would be held to
    the same standard. in other words, they would all be required to
    expose the same capabilities (testable over the APIs) and include
    the same actual community-developed software bits (designated

That's super clear. Currently, both the use of "FooTron Cloud Powered by
OpenStack" and "FooTron OpenStack" would have the same technical
requirements around API compatibility and community-developed software

What might be good for the board to consider is having different
requirements for these two types of trademark usages.

How about if the trademark programs were structured like this:

  FooTron OpenStack - passes API tests, includes all code from the 
    integrated release

  FooTron Cloud Powered by OpenStack - passes API tests, includes a 
    subset of the integrated release called 'designated sections'

  FooTron Cloud, OpenStack API Compatible - passes API tests, may not 
    include any code from the integrated release

i.e. why shouldn't we have a trademark program that applies only to
those commercial products which includes the entire integrated release?


More information about the Foundation mailing list