Open Stack

On Wed, 2014-09-17 at 10:17 -0400, Doug Hellmann wrote:
> On Sep 17, 2014, at 4:29 AM, Mark McLoughlin <markmc at redhat.com> wrote:
> 
> > On Fri, 2014-09-12 at 09:38 -0400, Doug Hellmann wrote:
> >> The point I have been trying to make is that because our community
> >> creates code and not standards, we should not simply trademark an API
> >> without including the implementation.
> > 
> > To make sure the basic point isn't getting lost - we're talking about
> > the requirements for products and clouds that wish to use the "OpenStack
> > Powered" trademark. We're not "trademarking an API”.
> 
> If the cloud or product does not include the OpenStack implementation,
> how is it “Powered” by OpenStack? I could see saying “Compatible with”
> or something like that. Maybe I’m reading too much into the word
> “Powered”.

Yes, a trademark license that just required API compatibility would be a
different thing.

That doesn't mean that some part of *every* capability needs to be
"OpenStack Powered".

> > We want there to be a vibrant commercial ecosystem of "OpenStack
> > Powered" products and clouds. But we also want to ensure that such
> > products offer an experience which reflects well on our brand and
> > encourages healthy engagement with our community.
> > 
> > i.e. at least three things to balance - growing this commercial
> > ecosystem, making sure the brand isn't damaged and growing our
> > community.
> > 
> > If the implementation of a capability offers users a good experience and
> > the vendor is engaged with our community in good faith, then I'd err on
> > the side of allowing the use of the trademark since they will grow the
> > commercial ecosystem.
> 
> So if they are engaged in one area (Nova) but not in another (Swift)
> they are allowed to replace the component entirely with their own?
> That feels very strange. We don’t apply that logic to *any* other
> component.

Swift *is* different because it doesn't have "pluggable backends".

Part of my "good faith" criteria here is that (some, at least) of the
vendors who implement a Swift compatible API without using Swift code
need to be engaged with evolving Swift so they can use it.

(The only real data I have on that is that some Red Hat affiliated
developers have been contributing in this area, but this isn't a Red Hat
concern - I don't think the decision affects Red Hat's ability to
license the trademark.)

Point is that this is the kind of stuff that I'd like to hear more about
during the debate, rather than talking in the abstract about
"capabilities must also have designated code".

> > I don't like to see us making rigid rules like "required capabilities
> > must have some designated sections", because such rules are so far
> > removed from the nuanced non-technical considerations we should be
> > making about trademark usage.
> 
> This is a nuanced issue, no doubt. Maybe we should be reconsidering
> the idea that we only want to have one trademark. A single mark
> doesn’t seem to support the varied ways the ecosystem wants to use
> OpenStack in their products while also making clear how those products
> differ from each other.

Agree :)

http://lists.openstack.org/pipermail/foundation/2014-July/001709.html

At the same time, there's a balance to be struck - too many trademark
programs and they all begin to lose meaning because no-one can keep
track of the differences between them.

Mark.