<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.5pt;
font-family:Consolas;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Consolas;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:54161454;
mso-list-type:hybrid;
mso-list-template-ids:-539482776 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1
{mso-list-id:2147038575;
mso-list-type:hybrid;
mso-list-template-ids:-1518689400 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoPlainText">(Top posting because this veers significantly and because Outlook has really sucky reply options)<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">It just struck me that the "OpenStack Powered" discussion is really just another version of the "Made in America" discussion. And the solution to that eventually evolved into:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Designed and Manufactured in America<o:p></o:p></p>
<p class="MsoPlainText">% Manufactured (sourced) in America<o:p></o:p></p>
<p class="MsoPlainText">Assembled in America<o:p></o:p></p>
<p class="MsoPlainText">(probably others)<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Extrapolating from this and various Defcore discussions:<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo1">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>We have already defined the core parts of projects vs. non-core as:<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:1.0in;text-indent:-.25in;mso-list:l1 level2 lfo1">
<![if !supportLists]><span style="font-family:"Courier New""><span style="mso-list:Ignore">o<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Plugins are not core<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:1.0in;text-indent:-.25in;mso-list:l1 level2 lfo1">
<![if !supportLists]><span style="font-family:"Courier New""><span style="mso-list:Ignore">o<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Extensions are not core<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:1.0in;text-indent:-.25in;mso-list:l1 level2 lfo1">
<![if !supportLists]><span style="font-family:"Courier New""><span style="mso-list:Ignore">o<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Immature features are not yet core<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo1">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Trademark definition is *<b>not</b>* an engineering issue, it is a business issue<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo1">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>One Trademark will not satisfy how the community wants to use the OpenStack bits<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">So, how about we turn this whole thing on end.<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>We keep Capabilities as defined by maturity, integration and deployment<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>We keep Interop Tests as a certification of Capabilities inclusion in products<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>We come up with a %OpenStack based on something like APIs, functionality, LOC (I don’t recommend this one) and come decide on a minimum percentage to be met to call a product “powered by OpenStack” or “Built on OpenStack” or “100%
OpenStack” or etc.<o:p></o:p></p>
<p class="MsoPlainText">This approach allows large inclusion of the mature parts of the OpenStack integrated codebase (developers are happy) but doesn’t require any specific part of the codebase be included (keeps vendors happy). The IBM Cloud Storage product
might include 100% of Swift, but maybe replaces Horizon and might be 70% OpenStack (Or even 100%) with no Nova code or APIs. Their compute cloud might end up 65% OpenStack based on 100% Nova and some extra code for a proprietary Hypervisor.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Right now I see that the Foundation would have to rely on Vendors to self-report how much extra code that replaces existing OpenStack DefCore capabilities is in their product, but that’s not something that hasn’t been considered before
as a short term option.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">This approach also gets DefCore out of the politics of Trademark and Business and back to the technical evaluation of maturity (and future direction) of specific OpenStack Integrated features.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Comments? Discussion? Flames?<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">--Rocky<o:p></o:p></p>
<p class="MsoPlainText">Trying to think around the box<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">-----Original Message-----<br>
From: Mark McLoughlin [mailto:markmc@redhat.com] <br>
Sent: Wednesday, September 17, 2014 7:34 AM<br>
To: Doug Hellmann<br>
Cc: Defcore-committee@lists.openstack.org<br>
Subject: Re: [OpenStack-DefCore] Results from Community Meetings > discussion/+1 about reconsidering Havana Swift as a core capability</p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">On Wed, 2014-09-17 at 10:17 -0400, Doug Hellmann wrote:<o:p></o:p></p>
<p class="MsoPlainText">> On Sep 17, 2014, at 4:29 AM, Mark McLoughlin <markmc@redhat.com> wrote:<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> > On Fri, 2014-09-12 at 09:38 -0400, Doug Hellmann wrote:<o:p></o:p></p>
<p class="MsoPlainText">> >> The point I have been trying to make is that because our community<o:p></o:p></p>
<p class="MsoPlainText">> >> creates code and not standards, we should not simply trademark an API<o:p></o:p></p>
<p class="MsoPlainText">> >> without including the implementation.<o:p></o:p></p>
<p class="MsoPlainText">> > <o:p></o:p></p>
<p class="MsoPlainText">> > To make sure the basic point isn't getting lost - we're talking about<o:p></o:p></p>
<p class="MsoPlainText">> > the requirements for products and clouds that wish to use the "OpenStack<o:p></o:p></p>
<p class="MsoPlainText">> > Powered" trademark. We're not "trademarking an API”.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> If the cloud or product does not include the OpenStack implementation,<o:p></o:p></p>
<p class="MsoPlainText">> how is it “Powered” by OpenStack? I could see saying “Compatible with”<o:p></o:p></p>
<p class="MsoPlainText">> or something like that. Maybe I’m reading too much into the word<o:p></o:p></p>
<p class="MsoPlainText">> “Powered”.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Yes, a trademark license that just required API compatibility would be a<o:p></o:p></p>
<p class="MsoPlainText">different thing.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">That doesn't mean that some part of *every* capability needs to be<o:p></o:p></p>
<p class="MsoPlainText">"OpenStack Powered".<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">> > We want there to be a vibrant commercial ecosystem of "OpenStack<o:p></o:p></p>
<p class="MsoPlainText">> > Powered" products and clouds. But we also want to ensure that such<o:p></o:p></p>
<p class="MsoPlainText">> > products offer an experience which reflects well on our brand and<o:p></o:p></p>
<p class="MsoPlainText">> > encourages healthy engagement with our community.<o:p></o:p></p>
<p class="MsoPlainText">> > <o:p></o:p></p>
<p class="MsoPlainText">> > i.e. at least three things to balance - growing this commercial<o:p></o:p></p>
<p class="MsoPlainText">> > ecosystem, making sure the brand isn't damaged and growing our<o:p></o:p></p>
<p class="MsoPlainText">> > community.<o:p></o:p></p>
<p class="MsoPlainText">> > <o:p></o:p></p>
<p class="MsoPlainText">> > If the implementation of a capability offers users a good experience and<o:p></o:p></p>
<p class="MsoPlainText">> > the vendor is engaged with our community in good faith, then I'd err on<o:p></o:p></p>
<p class="MsoPlainText">> > the side of allowing the use of the trademark since they will grow the<o:p></o:p></p>
<p class="MsoPlainText">> > commercial ecosystem.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> So if they are engaged in one area (Nova) but not in another (Swift)<o:p></o:p></p>
<p class="MsoPlainText">> they are allowed to replace the component entirely with their own?<o:p></o:p></p>
<p class="MsoPlainText">> That feels very strange. We don’t apply that logic to *any* other<o:p></o:p></p>
<p class="MsoPlainText">> component.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Swift *is* different because it doesn't have "pluggable backends".<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Part of my "good faith" criteria here is that (some, at least) of the<o:p></o:p></p>
<p class="MsoPlainText">vendors who implement a Swift compatible API without using Swift code<o:p></o:p></p>
<p class="MsoPlainText">need to be engaged with evolving Swift so they can use it.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">(The only real data I have on that is that some Red Hat affiliated<o:p></o:p></p>
<p class="MsoPlainText">developers have been contributing in this area, but this isn't a Red Hat<o:p></o:p></p>
<p class="MsoPlainText">concern - I don't think the decision affects Red Hat's ability to<o:p></o:p></p>
<p class="MsoPlainText">license the trademark.)<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Point is that this is the kind of stuff that I'd like to hear more about<o:p></o:p></p>
<p class="MsoPlainText">during the debate, rather than talking in the abstract about<o:p></o:p></p>
<p class="MsoPlainText">"capabilities must also have designated code".<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">> > I don't like to see us making rigid rules like "required capabilities<o:p></o:p></p>
<p class="MsoPlainText">> > must have some designated sections", because such rules are so far<o:p></o:p></p>
<p class="MsoPlainText">> > removed from the nuanced non-technical considerations we should be<o:p></o:p></p>
<p class="MsoPlainText">> > making about trademark usage.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> This is a nuanced issue, no doubt. Maybe we should be reconsidering<o:p></o:p></p>
<p class="MsoPlainText">> the idea that we only want to have one trademark. A single mark<o:p></o:p></p>
<p class="MsoPlainText">> doesn’t seem to support the varied ways the ecosystem wants to use<o:p></o:p></p>
<p class="MsoPlainText">> OpenStack in their products while also making clear how those products<o:p></o:p></p>
<p class="MsoPlainText">> differ from each other.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Agree :)<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">http://lists.openstack.org/pipermail/foundation/2014-July/001709.html<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">At the same time, there's a balance to be struck - too many trademark<o:p></o:p></p>
<p class="MsoPlainText">programs and they all begin to lose meaning because no-one can keep<o:p></o:p></p>
<p class="MsoPlainText">track of the differences between them.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Mark.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">_______________________________________________<o:p></o:p></p>
<p class="MsoPlainText">Defcore-committee mailing list<o:p></o:p></p>
<p class="MsoPlainText">Defcore-committee@lists.openstack.org<o:p></o:p></p>
<p class="MsoPlainText">http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee<o:p></o:p></p>
</div>
</body>
</html>