20:02:18 <ttx> #startmeeting tc
20:02:19 <openstack> Meeting started Tue Jul  1 20:02:18 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:22 <openstack> The meeting name has been set to 'tc'
20:02:32 <ttx> So today is the Defcore-specific TC meeting that was requested last week
20:02:43 <ttx> I had several discussions with TC members to try to clearly identify key concerns and questions
20:02:54 <ttx> They fell into 3 main categories, which will form our agenda for today
20:03:02 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:03:17 <ttx> #topic Scope of Defcore
20:03:22 <markmc> ttx, do we want to give josh a minute?
20:03:27 <markmc> he did say he was going to be here
20:03:46 * markmcclain is stuck in traffic
20:03:48 <ttx> zehicle_at_dell: is someone else from defcore supposed to attend?
20:03:53 <ttx> shall we wait?
20:04:14 <markmc> http://lists.openstack.org/pipermail/defcore-committee/2014-June/000221.html
20:04:35 <zehicle_at_dell> I did not get specific RSVPs
20:04:43 <zehicle_at_dell> but thought we had some people say they would join
20:04:49 <troytoman1> I am here if needed
20:05:05 <ttx> I just don't want to lose too much of our precious single-topic meeting time
20:05:21 <markmc> ttx, cool
20:05:26 <dhellmann> we're ~10% into the meeting, maybe we should go ahead and circle back if josh joins late?
20:05:27 <ttx> I guess we can wait a bit more
20:05:30 <russellb> we're 5 minutes in *shrug*
20:05:38 <markmc> let's go
20:05:40 <markmc> :)
20:05:44 <russellb> yup
20:05:51 <ttx> so this topic is about...
20:05:56 <ttx> what exactly are the trademark use cases being targeted ?
20:06:07 <ttx> It might be clear from Defcore standpoint, but we found conflicting documentation on that topic
20:06:17 <ttx> And the answer affects a lot how strongly the TC feels about some issues
20:06:30 <ttx> Our guess was that the capabilities/designated sections approach would be used for the "OpenStack-powered" trademark license program
20:06:39 <ttx> zehicle_at_dell: Is that a correct guess ?
20:06:53 <zehicle_at_dell> yes
20:07:03 <zehicle_at_dell> that was the expectation
20:07:06 <mikal> So to be clear...
20:07:11 <markmc> ttx, and similar licenses like $VENDOR OpenStack as explained by sparkyc
20:07:15 <zehicle_at_dell> trademark would require using designated sections and passing required tests
20:07:17 <mikal> We're talking about "FooTron powered by OpenStack"
20:07:24 <mikal> Not "FooTron OpenStack"
20:07:25 <mikal> Yes?
20:07:35 <markmc> mikal, both
20:07:43 <sparkyc> both
20:07:52 <markmc> commerical trademark license agreements administered by the foundation
20:07:55 <zehicle_at_dell> there is a community use for the trademark that is not commercial
20:08:00 <ttx> zehicle_at_dell: "powered by openstack" trademark program would require using designated sections and passing required tests ?
20:08:02 <sparkyc> yep
20:08:06 <zehicle_at_dell> there are really three uses: commercial, community & code
20:08:11 <mikal> So, I thought the "powered by" mark was a runner up prize
20:08:13 <mikal> Am I confused?
20:08:13 <zehicle_at_dell> ttx, yes
20:08:17 <dhellmann> so this is for all 3 uses, not just the powered-by use?
20:08:25 <zehicle_at_dell> mikal, no.  that's the primary mark
20:08:34 <mikal> i.e. powered by was for people who didn't comply with the full defcore requirements?
20:08:35 <markmc> mikal, yeah, there's *potential* for an "OpenStack API Compatible" type trademark program in future; not agreed on yet
20:08:42 <zehicle_at_dell> dhellmann, NO.  it;s only for commerical
20:08:43 <zaneb> it seems backwards to be designating the sections that are OpenStack. Shouldn't everything be designated by default and then we identify the legitimate plugin points?
20:08:45 <markmc> mikal, that would be the "runner up"
20:08:53 <mikal> markmc: ahhh, ok
20:09:04 <zehicle_at_dell> To my knowledge, Compatible is for drivers / plug-ins
20:09:05 <ttx> zehicle_at_dell: is Defcore about defining more than the Powered by openStack trademark license program ?
20:09:09 <russellb> zaneb: we're not to that part yet :)
20:09:17 <dhellmann> zehicle_at_dell: ok
20:09:21 <zehicle_at_dell> what do you mean "runner up"
20:09:24 <zehicle_at_dell> that's not clear
20:09:34 <mikal> zehicle_at_dell: someone who doesn't ship all the required bits
20:09:37 <jbryce> mikal: openstack powered = things built with openstack software; openstack compatible = things build on top of openstack or plugging into, emulating, etc
20:09:56 <mikal> So, for example...
20:09:56 <zehicle_at_dell> you could not call it openstack if you did not have the required bits AND pass the tests
20:10:02 <mikal> If I rewrote nova in quickbasic
20:10:04 <jbryce> openstack powered includes things like appliances, converged hardware/software products, distrubitions
20:10:06 <zehicle_at_dell> there is no "runner up"  - it's a binary thing
20:10:12 <devananda> is the intent for the outcome of DefCore to apply equally to all commercial trademark applications, or to create a test between different trademarks ("OpenStack" vs "Powered by OpenStack" vs "OpenStack Compatible", for example)
20:10:15 <mikal> I could not get "FooTron OpenStack", or "FooTron powered by OpenStack"
20:10:22 <zehicle_at_dell> of course, it's Apache2 so, you could use the code without using the trademark
20:10:22 <jbryce> mikal: nove in quickbasic would not be powered by openstack and you would not get either
20:10:26 <mikal> But I might one day be able to get "FooTron OpenStack Compatible"
20:10:35 <jbryce> mikal: correct
20:10:44 <mikal> jbryce: cool. Just wanting to be super clear on this point
20:10:44 <vishy> DefCore is only dealing with one trademark currently
20:10:46 <zehicle_at_dell> mikal, no
20:10:51 <markmc> zehicle_at_dell, there is potential for "OpenStack API Compatible" mark for products that just meet the API requirements, but not the designated sections requirements
20:10:55 <zehicle_at_dell> that's not the way Compatible is currently defined
20:11:08 <ttx> zehicle_at_dell: when you say "you could not call it openstack" you mean you cannot use the "Powered by OpenStack" trademark license program, right ?
20:11:10 <zehicle_at_dell> markmc, yes.  that's a potential but not under discussion at this time
20:11:11 <markmc> zehicle_at_dell, as I said, not agreed on - but important TC understands the potential is there; helps clarify "OpenStack Powered"
20:11:15 <ttx> sorry to insist but that's a key question
20:11:33 <zehicle_at_dell> ttx, yes.  control of the trademark is the only real power that we have
20:11:41 <sparkyc> focus is on the OpenStack powered in this phase afaik
20:12:13 <markmc> zehicle_at_dell, we really need precision here - you mean "control of the requirements for the commercial trademark licenses"
20:12:15 <sparkyc> for commercial contexts
20:12:34 <jbryce> openstack powered is for any product (cloud, appliance, distribution) that includes the community-developed software
20:12:40 <markmc> zehicle_at_dell, that confusion is all this item on the agenda is hoping to clear up
20:12:41 <russellb> and not defining "openstack" itself
20:12:49 <zehicle_at_dell> markmc, it's about controlling who can use the trademark.  that's the power the Foundation has
20:13:06 <markmc> zehicle_at_dell, *for commercial uses*
20:13:06 <mordred> zehicle_at_dell: the specific scope of the trademark is what we're trying to clarify
20:13:07 <jbryce> capabilities and designated sections are meant to set the bounds on what is required for those products to be able to sign an openstack powerd license agreement
20:13:07 <zehicle_at_dell> really, the foundation manages ALL THREE of the uses cases
20:13:15 <zehicle_at_dell> has to or we'd lose control of the mark
20:13:18 <mordred> because it changes how we're thinking about what it says to respond to it
20:13:25 <zehicle_at_dell> BUT DefCore is only concerned about the commerical use
20:13:28 <ttx> so it's about the "OpenStack" trademark, not just the Powered by OpenStack" trademark license program
20:13:44 <zehicle_at_dell> for DefCore, it's only about the commercial ones
20:13:49 <ttx> Ah.
20:13:57 <dhellmann> zehicle_at_dell: and that's
20:13:59 <dhellmann> oops
20:14:01 <sparkyc> exactly
20:14:10 <dhellmann> and that's "powered by" not "compatible", right?
20:14:23 <mordred> can someone please restate this very clearly - I am still not clear on scope
20:14:27 <zehicle_at_dell> dhellmann, I believe it's both.  those are both commericial
20:14:35 <zehicle_at_dell> but we're mainly focused on Powered By right now
20:14:38 <sparkyc> compatible to be considered in future phase
20:14:47 <zehicle_at_dell> there was some activity around the Compatiblie mark too
20:14:55 <ttx> mordred: I think what zehicle_at_dell means by "commercial uses of the trademark" is what we mean by "commercial trademark license programs"
20:14:57 <zehicle_at_dell> but that is not moving as fast
20:14:58 <sparkyc> if we get powered right we have a great starting point
20:15:00 <vishy> the current scope doesn’t include it
20:15:00 <dhellmann> ok, well, if my answer today is going to be used for both then I would like to understand the intent of both clearly
20:15:03 <ttx> and by we I mean the bylaws
20:15:15 <jbryce> dhellmann: powered by = built with community-developed openstack software (therefore capabilities and designated sections are relevant); compatible = built around the software, more api based. may tie into capabilities for instance, but still has to be fleshed out
20:15:23 <zehicle_at_dell> vishy, yes.  we intentioanlly keep DefCore narrow
20:15:37 <vishy> dhellman_: the designated sectrions and capabilities only apply to the powered by mark
20:16:02 <sparkyc> yes
20:16:02 <zehicle_at_dell> vishy, yes.
20:16:03 <dhellmann> jbryce: so would compatible be part of what we're asking to designate, with substitutions, or would it be a layer above (apps) or below (drivers)?
20:16:08 <dhellmann> vishy: ok, thanks
20:16:13 <ttx> Let me try to summarize:
20:16:17 <devananda> I gather the "Compatible" mark is not being discussed now, but I'm still not clear if we're talking about the commercial use of the "OpenStack" trademark or the "Powered by OpenStack" trademark or both.
20:16:17 <ttx> "DefCore is only about the commercial uses of the trademark -- currently, only the "Powered by OpenStack" trademark license program"
20:16:20 <markmc> summary - "the capabilities and designated sections defined through the DefCore process is only immediately intended to be used in the context of the 'OpenStack Powered' commercial trademark license agreement'
20:16:38 <ttx> zehicle_at_dell: does that work for you ?
20:16:41 <jbryce> dhellmann: compatible would most likely have no designated code requirements. it could include management software for instance, that only integrates with the api but never implements any openstack
20:16:41 <zehicle_at_dell> +1
20:16:55 <ttx> #agreed the capabilities and designated sections defined through the DefCore process is only immediately intended to be used in the context of the 'OpenStack Powered' commercial trademark license agreement
20:17:03 <ttx> #agreed DefCore is only about the commercial uses of the trademark -- currently, only the "Powered by OpenStack" trademark license program
20:17:05 <devananda> ttx: thanks
20:17:15 <ttx> OK, let's move on
20:17:18 <ttx> Lots to cover
20:17:20 <sparkyc> yup
20:17:21 <ttx> #topic Defcore Capabilities
20:17:24 <dhellmann> jbryce: ok, I'm trying to understand if compatible would allow for something that looks like an openstack service but isn't our code
20:17:34 <ttx> Our answer on scoring the "Aligns with Technical Direction" columns is almost finalized
20:17:40 <ttx> We have two governance reviews up (initial scoring, clarification of 0.5 scores) to address that:
20:17:45 <ttx> #link https://review.openstack.org/100721
20:17:47 <ttx> #link https://review.openstack.org/100722
20:17:58 <ttx> There is a bit of confusion about capabilities though, mostly because they seem to be only defined in a json file that maps to test names
20:18:13 <ttx> If those are to form the basis of a trademark license program, our suggestion would be to document 1-2 sentences about the intent of each capability, with the tests used as a backup definition
20:18:13 <markmc> dhellmann, my understanding on that - potentially yes, but not agreed on by the board yet
20:18:25 <zehicle_at_dell> ttx, we'd love for that to happen
20:18:36 <zehicle_at_dell> I think it would be a very power thing for the community
20:18:37 <dhellmann> markmc: ok, that feels very different from how it is being presented here in this meeting, though, almost like another type of license
20:18:40 <ttx> zehicle_at_dell: cool
20:18:41 <jbryce> dhellmann: that is not currently allowed by the existing license, but it has definitely been talked about as a potential additional use for that license
20:18:53 <zehicle_at_dell> troytoman make a great start with the capabilities list BUT it still has a long way to go
20:18:57 <ttx> The second question on capabilities would be to clarify the relationship between capabilities and designated sections
20:18:58 <zehicle_at_dell> we did not expect DefCore to own that
20:19:09 <ttx> zehicle_at_dell: My understanding was that the "OpenStack-powered" trademark license program would apply to those which run designated sections *and* appeared to implement capabilities
20:19:15 <troytoman1> ttx: that was the intention but the work needs to be done. i have been planning to work on that but was waiting for some of the processes to settle to make editing the json feasible
20:19:47 <ttx> troytoman: I don't think that prevents us from answering, just makes it a bit more time-consuming
20:19:57 <zehicle_at_dell> ttx, yes.  Appeared = passed tests for those cabilities
20:20:06 <ttx> zehicle_at_dell: But there is wording in some defcore etherpads that seem to suggest that designated sections could be nullified by excluding capabilities
20:20:06 <troytoman1> ttx: understood.
20:20:22 <zehicle_at_dell> troytoman and ttx, and that's what's in the JSON file
20:20:41 <zehicle_at_dell> we have to have a single source of truth for capabilities (which tests and the description)
20:20:56 <zehicle_at_dell> ttx, exteending??
20:20:57 <jbryce> dhellmann: the openstack compatible license does not allow for the same naming rights as the openstack powered license. for instance, you can never called something “FooTron OpenStack” under the compatible license. you can only say things like “FooTron Widget compatible with OpenStack”
20:21:10 <dhellmann> jbryce: ok
20:21:22 <zehicle_at_dell> that's a surprise.  I do not remember any disucssion where we talked about capabilities beyond those covered by the reference implementation
20:21:26 <zehicle_at_dell> IMHO that would be a failure
20:21:36 <ttx> zehicle_at_dell: https://etherpad.openstack.org/p/DefCoreLighthouse.F2F (lines 96-102)
20:21:47 <zehicle_at_dell> (and I can point to past cases where a licensed implementation did that and it was bad)
20:21:50 <ttx> maybe we misread that
20:22:19 <zehicle_at_dell> Swift creates interesting discussion
20:22:29 <zehicle_at_dell> but it's a bit of a single item compared the the broader questions
20:22:39 <ttx> zehicle_at_dell: ok, you confirm that it should be an AND
20:22:39 <zehicle_at_dell> happy to spend time on it, but it's not necessarily the common case
20:22:46 <ttx> capabilities AND designated sections
20:22:50 <zehicle_at_dell> ttx, YES
20:22:58 <jeblair> jbryce: the "Powered by OpenStack" program also supports calling something "FooTron OpenStack"?
20:23:05 <ttx> so they do not intersect
20:23:25 <zehicle_at_dell> ttx, that was the specific work hammered out in the spider cycle where we did the 10 principles
20:23:35 <ttx> #agreed Powered by OpenStack should pass capabilities tests AND implement designated sections
20:23:55 <ttx> OK, I think that clarifies well
20:23:57 <zehicle_at_dell> there is required (designated) code and required tests.  vendors may have alternate implementation of non-designated areas
20:24:01 <jbryce> can i take one second to clarify something
20:24:08 <ttx> jbryce: sure
20:24:48 <markmc_> I think it's worth spelling out the swift example
20:24:58 <markmc_> but that contradicts the AND thing we've just agreed here
20:25:10 <markmc_> code can be required to be shipped even if the APIs it implements aren't required?
20:25:23 <zehicle_at_dell> if there is no designated code then part of the AND is a noop
20:25:50 <zehicle_at_dell> marmc_, good question
20:25:51 <markmc_> if there is designated code and no corresponding capabilities, is the question
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:14 <markmc_> the etherpad says something like "if the TC designates swift, we'll remove the swift capabilities"
20:26:19 <zehicle_at_dell> if the required code is part of sections without required capabilities then we _assumed_ that that project would not be required
20:26:23 <ttx> <if Swift has any designated sections then the DefCore committee will likely recommending omitting the "object-*" capabilities from core>
20:26:27 <jeblair> jbryce: thank you, that is very clear :)
20:26:29 <zehicle_at_dell> so, we should clarify that
20:26:32 <mordred> jbryce: thank you
20:26:34 <russellb> jbryce: thanks
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 sections)
20:26:38 <mordred> jbryce: that clarifies the scope of this
20:27:01 <devananda> jbryce: thanks. that answers my question from earlier
20:27:03 <ttx> #info 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:27:03 <mordred> we've been thinking of FooTron Openstack and FooTron powered by OpenStack as different things
20:27:04 <dhellman_> jbryce: thanks, that is helpful
20:27:06 <markmc_> jbryce, very nice summary
20:27:11 <ttx> #info 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 sections)
20:27:19 <ttx> (sorry, capturing for the meetgin minutes)
20:27:26 * mordred hands ttx a beer
20:27:43 <mikal> jbryce: thanks for clarifying
20:27:49 <markmc_> <zehicle_at_dell> if the required code is part of sections without required capabilities then we _assumed_ that that project would not be required
20:27:54 <markmc_> think that's where we were at
20:28:16 <jbryce> the only other product-type license agreement that currently exists, is OpenStack Compatible which is intended for products and services which are built on top of or plug into the community-developed software. For instance, a back-end storage system, or a cloud automation management layer that consumes the OpenStack APIs
20:28:25 <troytoman1> markmc_: I think that makes sense but I don't know that we've been explicit
20:28:27 <ttx> #info if the required code is part of sections without required capabilities then Defcore _assumed_ that that project would not be required
20:28:37 <zehicle_at_dell> for example, if Saraha has designated code but no capabilities then it would still not be required for the mark
20:28:55 <ttx> OK, I think that answers our question
20:28:59 <troytoman1> yes
20:29:05 <markmc_> yeah, contradicting the AND thing earlier
20:29:19 <russellb> but if you include something that implements the Swift APIs, the swift code is not required, right?  (if no swift capabilities included)
20:29:25 <zehicle_at_dell> markmc_, I don't see why.  you need both
20:29:33 * ttx looks into boolean theory to find the right operator
20:29:41 <zehicle_at_dell> xor?
20:29:46 <russellb> AND AND IFF
20:29:47 <markmc_> zehicle_at_dell, you don't need swift designated code if there are no swift capabilities - that's the AND we meant
20:29:50 <russellb> or something bizarre
20:30:23 <zehicle_at_dell> markmc_, yes.  no required caps means the code is not required
20:30:29 <markmc_> anyway, cool - clarified now ...
20:30:33 <zehicle_at_dell> so, perhaps there's an ordering item that's important
20:30:35 <ttx> #info no required caps means the code is not required
20:30:42 <zehicle_at_dell> first, you need to have required capabilities
20:30:50 <russellb> passes test == (!capabilities_included OR (capabilities_pass && designated_sections_included))
20:30:59 <zaneb> zehicle_at_dell: so if the capability is not required, but you deploy it anyway, but you don't use the designated section... ?
20:31:08 <zehicle_at_dell> then you must include the designated code under those capabilities
20:31:19 <zehicle_at_dell> zaneb, we call that earning karma
20:31:31 <dhellman_> and if there is no capability then it doesn't matter if the code is there or not?
20:31:45 <zehicle_at_dell> dhellman_, +1
20:31:51 <ttx> OK, I propose we move on
20:32:00 <zehicle_at_dell> we did a graphic of this at the ATL summit
20:32:04 <ttx> It clarified what we needed clarified
20:32:11 <russellb> fair enough
20:32:18 <ttx> #topic Defcore Designated sections
20:32:18 <dhellman_> yeah, I think I get it now -- this is what I thought the position as in the beginning
20:32:19 <zehicle_at_dell> Will is pointing out to me that we're looking for a MINIMUM (least common deminotor)
20:32:30 <ttx> So, our view on this (as the TC) is the following:
20:32:40 <ttx> The TC defines the contents of the integrated release, and that's the set of things we vouch for
20:32:44 <zehicle_at_dell> I'll go ahead and be the first person to say "INTEROP"
20:32:55 <ttx> Defining a subset of the integrated release would make the TC, the representation of the contributors to the project, appear to endorse or encourage replacing part of their work with proprietary alternatives
20:33:05 <ttx> (although we value that the Apache license gives you that freedom)
20:33:14 <ttx> (and we respect that it's the board prerogatives to determine trademark license programs)
20:33:26 <ttx> Basically, the TC doesn't want to be the deciders of where proprietary replacements are allowed in "OpenStack Powered" products
20:33:30 <zehicle_at_dell> ttx, my understandoing is that the project is _designed_ to have replacable parts
20:33:51 <ttx> zehicle_at_dell: i wouldn't say it's designed to use proprietary replacements, no
20:33:57 <zehicle_at_dell> ttx, that does not make sense to me.  it's part of the design of the project
20:33:59 <ttx> it's designed to be modular
20:34:04 <ttx> Anyway
20:34:10 <ttx> we'd like to recognize that it's the board's right to define a subset of the integrated release to use for the purpose of commercial trademark license agreements
20:34:15 <zehicle_at_dell> modular, but only for open alternatives?
20:34:20 <ttx> (such as the "OpenStack Powered" trademark program)
20:34:21 <zaneb> zehicle: OpenStack is not an open core project imo
20:34:29 <ttx> and therefore the board should have final say on "designated sections"
20:34:36 <russellb> zehicle: modular because that's the implementation that makes sense.  the projects have multiple choices within the project itself
20:34:40 <ttx> It is very consistent with what the bylaws currently say, fwiw. TC builds the set, and Board picks a subset to apply trademark rules on.
20:34:43 <markmc_> zehicle_at_dell, the technical architecture allows for replacements, we make no guarantees about the API for those replacements
20:34:58 <zehicle_at_dell> markmc_, agreed.  that's why we want tests
20:34:59 <markmc_> zehicle_at_dell, we value that our copyright license allows proprietary replacements
20:35:09 <vishy> basically the upshot is the tc shouldn’t be making this decision because it isn’t a technical decision
20:35:16 <markmc_> zehicle_at_dell, but think it's the board's call on what the trademark license allows
20:35:34 <zehicle_at_dell> if you ask the board to make a technical decision about which code to include, they will likely have to say none (since we are not in a position to make that decision)
20:35:42 <zehicle_at_dell> we are asking for help from the TC about this
20:35:46 <mordred> it puts us in a weird position to have already decided what's in an out, the integrated release, and then come back and be asked for a different set of software that's in
20:35:58 <mordred> for us, we've already made a very clear call on what's in
20:36:10 <markmc_> whether "OpenStack Powered" products are required to ship swift or not is certainly *not* a technical question
20:36:12 <russellb> right, we have a process for stuff making it into the integrated release over time
20:36:17 <markmc_> not one iota of that is technical
20:36:24 <dhellman_> markmc_: +1
20:36:29 <mordred> from our point of view, swift is part of opensatck
20:36:42 <ttx> we respect that it's the board right to say otherwise
20:36:52 <zehicle_at_dell> mordred, based on evidence from a commerical perspective, it's not
20:36:53 <ttx> for use oin trademark programs
20:37:05 <markmc_> totally, the board controls the requirements of the commercial trademark licenses
20:37:12 <mordred> zehicle_at_dell: that's why it is the board's perrogative to contradict us
20:37:14 <zehicle_at_dell> there are people using openstack without including swift
20:37:19 <zehicle_at_dell> and other integrated parts too
20:37:21 <mordred> zehicle_at_dell: that is their right to do
20:37:27 <mordred> but we, as the people who make openstack
20:37:30 <mordred> have included swift in it
20:37:35 <dhellman_> zehicle_at_dell: there are people using *parts of* openstack that way
20:37:39 <mordred> which means swift is a part of openstack
20:37:40 <vishy> zehicle_at_dell: correct but it isn’t a technical decision to say whether that is allowed
20:37:45 <zehicle_at_dell> so, should they be allowed to use the name OpenStack if they don't include swift?
20:37:53 <vishy> zehicle_at_dell: if the board says so
20:37:57 <zehicle_at_dell> even if they use every other line of the prodyct
20:37:59 <ttx> zehicle_at_dell: that's the board's call
20:38:03 <mordred> that's teh board's call. but from our side, swift is a part of openstack
20:38:17 <markmc_> zehicle_at_dell, it's completely the board's decision whether some products should be allowed to be called "OpenStack Powered"
20:38:24 <ttx> We have two ways to get there, I think
20:38:24 <mordred> and if the board makes a different decision from us based on things, then that's within its legal rights
20:38:26 <zehicle_at_dell> if you want to push the technical decision about designatated sections to the board, I'm happy to run that up the flag pole
20:38:38 <ttx> zehicle_at_dell: We have two ways to get there, I think
20:38:39 <mordred> we do not want to push the technical decision to the board
20:38:40 <zehicle_at_dell> but I don't advise it
20:38:46 <mordred> we already made the technical decision
20:38:48 <dhellman_> zehicle_at_dell: as markmc_ said, swift isn't a technical decision
20:38:50 <ttx> (1) would be to designate all the havana integrated release as a havana designated section, *and* recognize that it's the Board's right to designate a final subset of that set for trademark license program usage
20:38:50 <troytoman1> Does the TC have a preference? (i.e. it should be the same as the integrated release?)
20:38:54 <vishy> zehicle_at_dell: the assertion is there is no technical part to this
20:39:05 <markmc_> right, it's not a technical decision and it's patently clear that it's the board decision anyway
20:39:08 <ttx> (2) would be to adopt markmc's suggested process on the Defcore list: let the Board come up with a strawman designated sections list, RFC that with TC and PTLs and the wider community, then let the board build the final synthesis
20:39:18 <mordred> zehicle_at_dell: we've already declared to the world the software we think is in openstack
20:39:29 <ttx> I think both approaches would address the concern that the TC should not decide where proprietary replacements are allowed in "OpenStack Powered" products
20:39:35 <mordred> if the board wants to grant someone the ability to use the trademark when they use a different set of software
20:39:36 <markmc_> troytoman1, we would prefer the board to come up with a strawman based on their full understand of the commercial considerations
20:39:37 <mordred> tehy can
20:39:39 <zehicle_at_dell> based on community feedback in the process, we felt that it was important to have upstream code included
20:39:44 <zehicle_at_dell> as a requirement
20:39:44 <markmc_> troytoman1, we're happy to provide input on that
20:39:49 <zaneb> zehicle_at_dell: it seems like the default here (that sections have to be designated explicitly to be required) is backwards
20:39:52 <mordred> zehicle_at_dell: I think upstream code is exsential
20:40:03 <zehicle_at_dell> IMHO, the design of the code allows for us to have designated sections
20:40:04 <dhellman_> zaneb: +1
20:40:05 <markmc_> troytoman1, but the board - with its understanding of the commercial ecosystem - is best placed to come up with that strawman
20:40:09 <jbryce> it’s not just about proprietary replacements
20:40:10 <mordred> zaneb: +!
20:40:21 <zaneb> zehicle_at_dell: I don't think there would be as much objection to designating optional sections
20:40:24 <dhellman_> zehicle_at_dell: you are not differentiating between whole projects and plugin APIs
20:40:25 <zehicle_at_dell> jbryce, +1.  there are lots of ways to replace the code
20:40:25 <mikal> zehicle_at_dell: this is an important point
20:40:26 <jbryce> in my experience in the real world, there are open alternatives being switched into places
20:40:31 <troytoman1> markmc_: that's fine. i'm just trying to understand if the TC has any guidance or preference - I'll take it that it doesn't
20:40:35 <jbryce> probably most frequently
20:40:39 <mordred> troytoman1: I do not agree
20:40:46 <mikal> zehicle_at_dell: we are saying that the plug in interfaces inside our code were intended for alternate implementations also present in our code
20:40:49 <zaneb> e.g. I would designate the heat-cfn-api and all the AWS compatibility resources as optional quite happily
20:40:50 <mordred> troytoman1: I think we're saying quite the opposite of that
20:40:57 <zehicle_at_dell> dhellman_, I am asking for the TC help help make that distinction.  I'm intentionally trying to stay away from that
20:41:06 <troytoman1> mordred: quite the opposite of what?
20:41:08 <mordred> troytoman1: I believe _I_ a t least am saying that I have already made the call on which bits are in and out
20:41:15 <mordred> troytoman1: that we don't want to give guidance
20:41:23 <zehicle_at_dell> mikal, like KVM?  it's that inside our code?
20:41:23 <dhellman_> zehicle_at_dell: you certainly can tell the difference between swift and a hypervisor driver in nova, though, so we should not conflate those 2 cases
20:41:23 <russellb> mordred: +1
20:41:24 <mordred> troytoman1: I want to give guidance - I voted on the integrated release
20:41:32 <mordred> I believe that's opensatck
20:41:41 <mikal> zehicle_at_dell: like the kvm and xen drivers, yes
20:41:41 <mordred> if someone else, who is not me, wants to call someone else openstack
20:41:41 <jeblair> mordred: agreed
20:41:43 <troytoman1> mordred: I read that as "I think it should be the integrated release but you can decided differently"
20:41:46 <mordred> they're going to have to do that without my agreement
20:41:49 <dhellman_> zehicle_at_dell: the nova driver to talk to kvm is in our code
20:41:49 <mordred> troytoman1: you can
20:41:56 <zehicle_at_dell> mikal, those are not inside OpenStack or part of the integrated release
20:42:01 <mordred> troytoman1: you are legally allowed to disagree with the TC
20:42:07 <ttx> zehicle_at_dell: the trick is, that distinction is more about policy than it is about a technical question
20:42:07 <mikal> zehicle_at_dell: the drivers are
20:42:08 <troytoman1> mordred: I am trying to figure out if that is a TC view or a mordred view
20:42:20 <russellb> TC view
20:42:21 <mordred> everyone in the TC who agrees with me ++
20:42:24 <dhellman_> ++
20:42:25 <russellb> ++
20:42:27 <jeblair> mordred: ++
20:42:30 <ttx> ++
20:42:31 <markmcclain> ++
20:42:32 <mikal> ++
20:42:32 <sdague> troytoman: it's pretty heavily believed by the TC
20:42:36 <devananda> ++
20:42:38 <troytoman1> mordred: I'm fine with either but I would like to know what the thoughts are as we deliberate or come up with a strawman
20:42:41 <devananda> zehicle_at_dell: what we're saying is, that code is modular is a result of good coding practices, not the result of an intent to enable proprietary plugins or alternate implementations.
20:42:55 <vishy> --
20:42:56 <troytoman1> thanks for that input everyone - it is very helpful to me, at least
20:43:00 <vishy> that is not my view
20:43:16 <vishy> but that is the tc consensus
20:43:20 <ttx> vishy: that's because you're unique
20:43:24 <vishy> and the correct position for the tc imo
20:43:24 * mordred loves vishy
20:43:43 <markmc_> -- (I can see good reason for the board to allow OpenStack Powered products not ship all of OpenStack)
20:43:45 <ttx> zehicle_at_dell: which of the two approaches I ourtlined earlier would have your preference ?
20:43:56 <markmc_> but I think the TC is not the ones best placed to make that call
20:44:04 <markmc_> I think it's a terrible idea to ask the TC to make that call
20:44:06 <vishy> markmc_: ++
20:44:09 <troytoman1> i think we can work on a straw man - but it is helpful to know what the current opinion is
20:44:10 <ttx> We can provide technical feedback on a strawman, for sure
20:44:15 <ttx> as anybody in our community can
20:44:19 <devananda> markmc_: I can see good reasons for the board to do that, too
20:44:32 <ttx> troytoman1: so... approach (2) ?
20:44:39 <vishy> highly suggest that the strawman differentiates between replacing components and projects
20:44:42 <ttx> "adopt markmc's suggested process on the Defcore list: let the Board come up with a strawman designated sections list, RFC that with TC and PTLs and the wider community, then let the board build the final synthesis" ?
20:44:54 <zehicle_at_dell> ttx, we already did that
20:44:59 <vishy> and addresses the swift case head-on
20:45:08 <jbryce> so…can i ask a crazy question?
20:45:16 <jbryce> vishy: that’s where my question was going = )
20:45:16 <russellb> jbryce: please :)
20:45:19 <zehicle_at_dell> our strawman has swift = 0%
20:45:25 <dhellman_> troytoman1: defcore needs to differentiate between vertical division between projects like swift and nova and horizontal divisions of those projects into layers with drivers that can be added outside the tree
20:45:26 <ttx> zehicle_at_dell: so be it
20:45:27 <devananda> markmc_: but the point is that that is not a technical decision
20:45:27 <dhellman_> vishy: ++
20:45:38 <ttx> zehicle_at_dell: some people will cmplain at that in RFC phase
20:45:46 <zehicle_at_dell> #link https://etherpad.openstack.org/p/openstack-designated-sections
20:45:48 <troytoman1> dhellman_: Defintely
20:45:50 <devananda> dhellman_: ++
20:46:00 <sdague> yeh, instead of trying to come up with a policy that dances around the hard problems, just call them out
20:46:04 <ttx> zehicle_at_dell: tbh, since you can nullify the designated section by removing capabilities, the end result is the same
20:46:06 <mordred> ++
20:46:26 <zehicle_at_dell> ttx, removing the capabilities LIMITS interopability
20:46:32 <zehicle_at_dell> the end goal is interoperability
20:46:42 <sdague> swift, keystone, anything else we know folks are replacing, and just have the board decide if that's the commercial ecosystem they want
20:46:50 <mordred> I think the goal of trademarks is to designate the "is"-ness of something
20:46:52 <zehicle_at_dell> so, when we remove a capability it means that vendors will not have to include those APIs
20:47:00 <zehicle_at_dell> which reduces the scope of OpenStack clouds
20:47:02 <mordred> if you put a name on something, you want to know that you are getting that thing
20:47:13 <notmyname> for the record, swift does support "drivers" that ecosystems members have replaced with both proprietary and open alternate implementations
20:47:16 <ttx> zehicle_at_dell: feair enough, that's why designated sections should be designed in parallel with capabilities, not provided by a third-party
20:47:17 <zaneb> mordred: ++
20:47:18 <mordred> notmyname: ++
20:47:20 <jbryce> the most common scenario i’ve seen so far that doesn’t comply with the existing OpenStack Powered license agreement (“must include the entirety of the nova and swift code from a recent release”) has to do with people using an alternate object storage system that exposes the swift APIs. it seems like everyone keeps dancing away from making a call one way or the other on what object storage in an openstack cloud shoul
20:47:33 <mordred> jbryce: +1000
20:47:44 <ttx> and i don't think that's a technical question
20:47:47 <mordred> nope
20:47:49 <ttx> I have an opinion on it
20:47:51 <dhellman_> notmyname: ++
20:47:51 <jbryce> are there other examples besides the swift one that are so hot-button?
20:47:52 <mordred> I do too
20:47:53 <ttx> but it's NOT technical
20:48:02 <jbryce> or is this really all about what does object storage in openstack mean?
20:48:03 <troytoman1> ttx: i agree
20:48:10 <mordred> ttx: ++
20:48:17 <ttx> troytoman1: and the TC is not elected to decide that. You guys are
20:48:17 <sdague> ttx: +++ :)
20:48:17 <zehicle_at_dell> jbryce, keystone (but no one gets up set that it's also 0% designated)
20:48:22 <vishy> jbryce: i think the closest second place is out-of-tree cinder drivers
20:48:24 <dhellman_> jbryce: there are some things going on in block storage that may raise questions
20:48:34 <devananda> jbryce: almost. I think it's "what does openstack mean"
20:48:37 <russellb> i think replacing a virt driver in nova is controversial, as well, IMO
20:48:38 <troytoman1> ttx: nod
20:48:40 <mikal> jbryce: I think nova hypervisor drivers are close, but not as hot button
20:48:41 <jbryce> mordred: “if you put a name on something, you want to know that you are getting that thing” +1
20:48:43 <vishy> jbryce: and 3rd place would be storage systems implementing the cinder or glance api
20:48:54 <mikal> jbryce: for example, Oracle shipping an "OpenStack" with a hypervisor driver we've never seen
20:48:55 <jeblair> ttx, mordred: i disagree with the idea that we're only permitted to hold opinions on technical subjects -- we're quite clearly often concerned with the nature of this software and how it grows
20:49:02 <russellb> nova virt drivers are very much NON-trivial bits of code, that's a huge part of nova
20:49:05 <mordred> jeblair: I agree with that
20:49:11 <dhellman_> mikal: how much of any of the rest of their fork have you seen?
20:49:18 <mordred> I have a very strong opinion on the fact that people not running swift are not running opensatck
20:49:19 <mikal> dhellman_: none
20:49:20 <mordred> btw
20:49:25 <notmyname> monitoring not with ceilometer? management not with horizon?
20:49:28 <markmc_> jeblair, of course we have opinions, the TC as a body doesn't have mandate tho
20:49:30 <vishy> mikal: good point out of tree hypervisors is up there with other cinder drivers
20:49:30 <ttx> jeblair: objection noted :)
20:49:30 <mordred> and neither are people running keystone replacements or cinder replacements
20:49:33 <theannegentle> I am often concerned with the growth for programs that provide resources for all projets
20:49:41 <mordred> I think none of them should be allowed to use the trademark
20:49:42 <vishy> horizon is another good example
20:49:49 <mikal> I see a lot of announcements from people like Cray and Oracle
20:49:51 <mikal> But never any code
20:49:54 <mikal> And that worries me a lot
20:49:56 <troytoman1> jeblair: I think you should absolutely have opinions - the questions is who makes the decision
20:49:58 <mordred> I believe that people shipping non-horizon dashboards should not be allowed to call themselves opensatck
20:49:59 <ttx> at least no mandate for the "Powered by openStack" trademark license program
20:50:11 <dhellman_> mikal: +1
20:50:15 <dhellman_> annegentle: +1
20:50:16 <mordred> I believe that people running public clouds that do not run horizon should not be allowed to cal themselves openstack
20:50:30 <vishy> mordred: can you replace the css themes?
20:50:31 <mordred> and I believe they should all be ashamed of being bad community members
20:50:33 <lifeless> mordred: what if they don't offer a web UI at all?
20:50:41 <vishy> or move around panels
20:50:43 <vishy> ?
20:50:44 <ttx> mordred: that's only you though.
20:50:47 <mordred> vishy: of course - I also don't think we should get all legalistic about it all
20:50:49 * troytoman1 hangs his head in shame
20:50:50 <mordred> ttx: yes. I'm extremem
20:50:51 <theannegentle> on the TC we represent the people making the code patches, and that's the members of swift and horizon and all of integrated now
20:50:58 <markmcclain> mikal: true I know there are forks of Neutron without code that's been seen
20:50:58 <vishy> mordred: that is far to extreme imo :)
20:50:59 <mordred> I'm just being very direct about teh opinions I have that are not technical
20:51:02 <vishy> * too
20:51:03 <ttx> anyway, let's go back on topic
20:51:03 <zaneb> lifeless: that's ok if it's not a required capability, AIUI
20:51:07 <jbryce> markmc_: i disagree about the mandate. the bylaws set it up so that the decisions about core were board decisions, but based off tc recommendation
20:51:08 <ttx> i'd like a resolution on that one
20:51:11 <mordred> theannegentle: ++
20:51:24 <mordred> jbryce: ++
20:51:31 <ttx> jbryce: based on a set the TC provides, which is the (upstream) integrated release
20:51:37 <sdague> jbryce: right, so I think that's the crux of it. The TC made that recommendation with the integration votes for these projects
20:51:43 <mordred> sdague: ++
20:51:45 <russellb> ++
20:51:48 <dhellman_> ++
20:51:48 <markmcclain> sdague: ++
20:51:51 <theannegentle> sdague: correct
20:52:07 <mordred> we'd be happy to makea  formal recommendation if that's helpful
20:52:08 <vishy> sdague: ++
20:52:09 <devananda> sdague: ++
20:52:21 <ttx> TC defines set, Board picks subset for trademark usage. that's always how it was meant to be
20:52:22 <russellb> but it would be "the entire integrated release"
20:52:26 <mordred> russellb: ++
20:52:33 <ttx> It's all over the bylaws
20:52:48 <troytoman1> feels like we are saying the TC recommends the integrated release and the board now needs to decide what modifications (if any) should be made.
20:52:52 <ttx> looks like we either lost or flooded zehicle
20:52:56 <mordred> troytoman1: yup
20:53:01 <zehicle_at_dell> ttx, I'm here
20:53:04 <russellb> troytoman1: ++
20:53:07 <vishy> its unfortunate that the number of projects is confusing
20:53:17 <jbryce> time check: 7 minutes
20:53:19 <ttx> zehicle_at_dell: ah good
20:53:24 <zehicle_at_dell> thing that the TC forcing a decision that will have negative implications
20:53:29 <vishy> because it would be way simpler if you could just use which projects you wanted and call each one openstack
20:53:31 <ttx> OK, so I would like a way forward on that
20:53:42 <vishy> so if you don’t use swift you can’t say openstack-storage
20:53:51 <mordred> vishy: you know - I'd be more ok with that than the other thing
20:53:53 <vishy> but then we’d have way too many trademarks and it would be confusing
20:53:53 <zehicle_at_dell> I've voiced my position and tried to represent the broader ones that I've heard over the last 18 months
20:54:06 <ttx> zehicle_at_dell: which negative implication?
20:54:10 <theannegentle> zehicle_at_dell: negative for whom?
20:54:14 <theannegentle> look at me all grammarly
20:54:17 <jbryce> vishy: you can have different naming standards under a single license. we already do for OpenStack Powered
20:54:24 <zehicle_at_dell> I think that this position will lead to vendors forking OpenStack and not contributing
20:54:27 <dhellman_> theannegentle: show off
20:54:31 <mordred> zehicle_at_dell: they already do that
20:54:32 <vishy> jbryce: yeah but do we really want to have 12 of them?
20:54:38 <theannegentle> zehicle_at_dell: already evidenced
20:54:40 <zehicle_at_dell> yes, they do
20:54:47 <vishy> jbryce: they kinda lose meaning. But that is a board discussion anyway
20:54:50 <mordred> zehicle_at_dell: most of the cases of vendors we're referencing who are doing these thigns are not contributing and have forked
20:54:55 <troytoman1> zehicle_at_dell: that's only true if the board decides on the full integrated release - which is far from a given
20:55:03 <zehicle_at_dell> the DefCore position is set to bring them back into contributing upstream as much as possible AND adding tests
20:55:04 <ttx> zehicle_at_dell: how would designated sections from the TC help ?
20:55:12 <mordred> zehicle_at_dell: they're not going to, no matter what we do
20:55:18 <ttx> compared to designated section strawman from the board ?
20:55:20 <zehicle_at_dell> troytoman1, yes.  but I'd rather not have the Board do it w/o the TC
20:55:31 <mordred> zehicle_at_dell: stop saying w/o
20:55:33 <ttx> zehicle: we can still comment on a strawnman
20:55:36 <mordred> it's "in conflict with"
20:55:37 <zehicle_at_dell> I think we worked out a compromise position and the TC is not working toward the compromise
20:55:38 <ttx> but since you have final call...
20:55:40 <russellb> not clear to me how this has anything to do with encouraging contribution
20:55:43 <ttx> you should propose the original set
20:55:49 <troytoman1> zehicle_at_dell: i think that's why we have an RFC on any changes we recommend
20:55:56 <ttx> troytoman: +1
20:56:02 <zehicle_at_dell> ttx, yes.  Josh and I will work to create a strawman because we think it's the right thing to do
20:56:11 <zehicle_at_dell> IMHO, the TC could have been leading that
20:56:20 <mordred> zehicle_at_dell: we did. we made a choice. you just disagree with it
20:56:22 <dhellman_> zehicle_at_dell: we've *given* you an answer
20:56:30 <zehicle_at_dell> yes.  that's right
20:56:34 <zehicle_at_dell> you asked why I was being quite
20:56:38 <ttx> zehicle_at_dell: our answer would be "the integrated release"
20:56:46 <ttx> which is the only answer the TC can give
20:56:47 <zehicle_at_dell> ttx, I understand
20:56:51 <ttx> since that's what we work on
20:56:54 <zehicle_at_dell> and will convey that back to the board
20:57:01 <ttx> we can't decide that a subset of what we do is less important
20:57:08 <mordred> ttx: ++
20:57:09 <ttx> or replaceable
20:57:11 <jbryce> vishy: we’ve always had the reciprocal where if you don’t have compute, you can be Storage Powered OpenStack…hasn’t seemed to create too much of a problem
20:57:14 <russellb> ttx: ++
20:57:15 <ttx> we represent the contributors
20:57:18 <zehicle_at_dell> ttx, I think that's not a real limit.  it's self imposed
20:57:20 <ttx> they are all equal
20:57:26 <mordred> the ATC's are who voted me in
20:57:27 <ttx> as soon as we accept them in the integrated release
20:57:28 <troytoman1> zehicle_at_dell: i think we have an opportunity to make modifications with a business or community rationale and have a discussion around that.
20:57:29 <mordred> they are my constituency
20:57:42 <zehicle_at_dell> mordred, you have multiple constituencies
20:57:44 <ttx> we are just their representants
20:57:50 <mordred> zehicle_at_dell: in my role as a TC member, I have one
20:57:57 <mordred> and I am representing them
20:58:04 <mordred> in my role as a board member, I have a different one
20:58:08 <mordred> I also believe I'm representing them
20:58:14 <sdague> zehicle_at_dell: this is also fundamentally a business decision on the commercial ecosystem. Companies are going to take hits or wins based on the definition. Defining the parameters of the commercial ecosystem seems to be the reason for the board.
20:58:15 <mordred> because I believe a broad definition of opensatck is better for everyone
20:58:22 <mordred> but people may disagree with me on that
20:58:31 <mordred> and I respect their ability to do so
20:58:59 <mordred> I do not think it's good for the opensatck business ecosystem to have a minimum definition of openstack
20:59:17 <mordred> because I thnk it makes the word meaningless
20:59:23 <zehicle_at_dell> I have heard from many people that a minimum one is better than ALL or NONE
20:59:25 <mordred> and this is as a person who is a massive end-user of openstack clouds
20:59:37 <mordred> zehicle_at_dell: I doubt most of those people are as heavy users ofopenstack as I am
20:59:54 <ttx> zehicle_at_dell: it's a trademark policy call, always was.
21:00:05 <mordred> so as a board member, I will represent that position
21:00:07 <zehicle_at_dell> I'm happy to take the TC position back the board
21:00:17 <russellb> sounds good, we're about at time
21:00:17 <troytoman1> mordred: i'm not sure it is useful to have one so narrow that few can use the trademark
21:00:21 <zehicle_at_dell> my role, as always, was to find a compromise
21:00:26 <mordred> troytoman1: they TOTALLY can use the trademark
21:00:32 <mordred> troytoman1: all they have to do is run the code
21:00:40 <mordred> we gave it to them for free even
21:00:49 <ttx> ok, time is up
21:01:02 <ttx> Thanks everyone
21:01:12 <jeblair> ttx: thank you
21:01:16 <zehicle_at_dell> thanks everyone
21:01:17 <mordred> troytoman1: but different opinions are what make the world go aroudn!
21:01:21 <mordred> thanks zehicle_at_dell !
21:01:22 <ttx> I think we reached some conclusions, even if they are not universally appreciated
21:01:24 <mordred> thanks ttx !
21:01:26 <sparkyc> the current definiton is nova and swift only fyi
21:01:27 <markmcclain> ttx: thanks!
21:01:30 <dhellman_> zehicle_at_dell, troytoman1, jbryce : thanks for clarifying things today
21:01:35 <mordred> jbryce: ++
21:01:36 <sparkyc> so expand it :)
21:01:50 <sparkyc> thanks all
21:01:53 <ttx> #endmeeting