Open Stack

Mark,

Thanks for the doc. From my understanding walking it through with some cloud use cases I know of:


1.      A cloud provider who was delivering Nova based compute services and ceph based storage (both block and object to the API) would be able to claim “OpenStack powered compute”. At some time in the future, they may be able to qualify for an “OpenStack compatible storage” mark when/if this is defined.

2.      A cloud provider who was delivering an API conversion layer and uses no OpenStack designated sections (such as Softlayer Jumpgate) would not be allowed to use any of the trade or word marks on the current proposal (but the current proposal does not exclude an alternative mark in the future)

The term “storage” is somewhat confusing for the case 1. If I am offering cinder compatible block storage, I still would not be able to use the powered-by storage mark although the missing code is actually ‘object based’ storage rather than the entire storage functional areas.

Clearly, the initial goal is to map to existing marks rather than create new ones and thus my need to clarify these scenarios as to what is in/out under the proposal.

Tim

From: Mark Collier [mailto:mark at openstack.org]
Sent: 01 October 2014 19:59
To: Rob_Hirschfeld at Dell.com
Cc: Defcore-committee at lists.openstack.org
Subject: Re: [OpenStack-DefCore] progress - met w/ Foundation

Background:

On a day to day basis, Foundation employees manage the various trademark license Programs (working with our trademark attorneys as needed). A “Program” provides a license for use of the trademarks in commercial contexts, executed between a company in the ecosystem and the Foundation, specific to a product or service. Note: There are multiple Programs (e.g. “OpenStack Powered”, “OpenStack Powered Storage”, “OpenStack Training”).

A Program typically includes access to a particular commercial-use logo (e.g. “OpenStack Powered”) and some ability to use the word “OpenStack” in the product name and marketing collateral (this is known as the “wordmark” in legalese). A signed contract is required, and there are technical requirements to qualify which include API Capabilities inclusion of specific upstream code (a la Designated Sections).

Now that we’re nearing the end of the initial DefCore  committee work for Havana, the Board felt it was a good time for the Foundation staff to look at how we might map the DefCore Capabilities and Designated Code to existing or new licensing Programs. Jonathan and I are working on a proposal for the October 20th Board Meeting and want as much input as possible prior.

This mapping will give everyone another level of understanding regarding how the DefCore components will play out in the market under such Programs, and ultimately give the Board something that they’re confident voting for to move this to implementation phase soon.

Note that while the Board DID approve the Havana Capabilities in the July Board meeting, they did not approve the proposed update in the September Board meeting, citing various concerns, including the status of Swift and a lack of clarity about how the requirements would play out with our trademark licensees. I believe that by illustrating the different Programs that we would expect to implement with respect to the DefCore work, along with some tweaks to the Designated Sections themselves, we can all get on the same page. We are very close.

What you’ll see is in practice it’s not an either/or thing with Swift because we have more than one Program to address different markets and choices. Multiple Programs is not a new concept.

For the purposes of this email I’m going to focus on the “OpenStack Powered” Programs, summarize the requirements and benefits today, then suggest a way that we could map the DefCore output to the two existing programs in a practical way, while adding a third program to address a specific use case. All without creating any more logos.

I believe this proposal can address the many different stakeholders' input to date, the incredible work of DefCore, TC and community input, while keeping true to our goal of improving interoperability.

Note: I strongly advise you check the Google Doc version because a table is a lot easier to follow:
https://docs.google.com/document/d/1WHVGwIxLSB0Dh9xVntxO5faM4pJjTe0yM0JwpsLUebA/edit?usp=sharing

“OpenStack Powered” Programs today:
1) Program Name: OpenStack Powered
         Requirements: Nova and Swift code included, Nova and Swift APIs exposed
         Benefits:  Can use “OpenStack Powered” logo, can use “OpenStack” in product name within guidelines
2) Program Name: OpenStack Powered Storage
         Requirements: Swift code included and Swift APIs exposed
         Benefits:  Can use “OpenStack Powered” logo, can use “OpenStack Storage” in product name within guidelines
          •     Note: Has more restrictive rights, such a requirement to include “Storage” qualifier in product marketing

Future Programs mapped to DefCore
1) Program Name: OpenStack Powered Platform
          •    Requirements: All Capabilities required by Defcore, All Designated Sections from Defcore, Pass Tests
        Benefits:  Can use “OpenStack Powered” logo, can use “OpenStack” in product name within guidelines — has broadest rights to use the name, such a “ACME OpenStack” for a distro and “ACME OpenStack Cloud” for a public cloud service
2) Program Name: OpenStack Powered Storage
        Requirements: All object storage specific Capabilities from Defcore, all Swift specific Designated Sections from Defcore, Pass Tests
        Benefits:  Can use “OpenStack Powered” logo, can use “OpenStack” in product name within guidelines.
        Note: Has more restrictive rights, such as requirement to include “Storage” qualifier in product marketing

3) Program Name: OpenStack Powered Compute
      Requirements: All compute specific Capabilities from Defcore, all Nova, Glance, Cinder specific Designated Sections from Defcore, Pass Tests
         Benefits:  Can use “OpenStack Powered” logo, can use “OpenStack” in product name within guidelines
         Note: Has more restrictive rights, such as requirement to include “Compute” qualifier in product marketing.

*For implementation, Defcore would need to group subsets of the overall output. For example:
          • Platform - no need to group as this is the superset. Suggest adding Swift Designated Sections for Havana based on input from September, and Keystone in Icehouse/Juno based on user input from Das Kamhout & Tim Bell)
          • Storage - subset focused on Object Storage Capabilities and Designated Sections
          • Compute - subset including the Nova, Glance, Cinder for Havana. Suggest adding others as they are included in future releases (e.g. Keystone)

All of this is also captured in a Google doc that is frankly more readable due to the table and formatting:
https://docs.google.com/document/d/1WHVGwIxLSB0Dh9xVntxO5faM4pJjTe0yM0JwpsLUebA/edit?usp=sharing




On Sep 27, 2014, at 6:09 AM, Rob_Hirschfeld at Dell.com<mailto:Rob_Hirschfeld at Dell.com> wrote:

To clarify, Mark Collier.  We have a lot of Marks working on marks.

From: Hirschfeld, Rob
Sent: Saturday, September 27, 2014 12:20 AM
To: Defcore-committee at lists.openstack.org<mailto:Defcore-committee at lists.openstack.org>
Subject: [OpenStack-DefCore] progress - met w/ Foundation

DefCore,

Since we’re time sensitive, I wanted to let you know that I had a working session with the Foundation staff Friday.  Alan and Troy also participated.

We laid out a some options that Mark will review on the list next week.  I think it was a very positive and productive discussion.  I’m optimistic that we have some good suggestions that will address the concerns raised by the Board.

Also, I’d like to thank those of you who reached out 1x1 after the last Board meeting.

Rob
______________________________
Rob Hirschfeld
Sr. Distinguished Cloud Solution Architect
Dell | Cloud Edge, Data Center Solutions
cell +1 512 909-7219 blog robhirschfeld.com<http://robhirschfeld.com>, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

_______________________________________________
Defcore-committee mailing list
Defcore-committee at lists.openstack.org<mailto:Defcore-committee at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20141001/6fb5b30e/attachment-0001.html>