Open Stack

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.

3)  The real question is:  what should those technical requirements be to call your product “OpenStack” (i.e. to get a license)?  In particular, how should the code inclusion requirements evolve?

If we can come to a consensus on an answer to that question, we (the foundation staff) can work with our trademark counsel to update the agreements. That won’t be a lengthy process, as the product requirements are all in one section of the agreements.

The trick is coming to a consensus on what those requirements should be.  Amending the Bylaws to clear up the admittedly confusing language is a nice thing to pursue for the sake of clarity, but I think it’s a red herring for the more pressing matter.

Defcore was formed to come up with that answer, in an open community involved way, in conjunction with the TC and PTLs and any other stakeholders.  I don’t want to try to summarize the current state of Defcore in this email, but in general the direction is to express the requirements in terms of capabilities as well as tests, rather than projects per se, with code requirements that are likely to be less than 100% within each particular project.  

The question that is raised when we consider going below 100% of a particular project, is do you eventually consider 0%, as long as the APIs are implemented?  Let’s say, hypothetically, your product or cloud service exposes the Swift API but uses an alternative back end, say Ceph for example.  Is that still “OpenStack”?  Let’s face it, that’s the question on a lot of people’s minds.  The Defcore committee has approached these questions holistically by starting with documenting criteria for making such weighty decisions.  The time draws near to make the big calls, so if you care about this stuff, get involved!

Mark




> On Jun 25, 2014, at 11:10 AM, Jonathan Bryce <jonathan at openstack.org> wrote:
> 
> Rather than going line-by-line through several of the previous messages in the thread, I wanted to clarify the existing framework that governs OpenStack trademark usage, which I think may address a few of the comments. It can be a complicated issue because there are several documents that are involved and they impact different areas of trademark usage. Fair warning: this email is really long. = )
> 
> 1) The Bylaws - The Bylaws of the OpenStack Foundation (http://www.openstack.org/legal/bylaws-of-the-openstack-foundation/) with Appendices are the overall governing documents for the Foundation. They define the Project, the Membership, delegate authority to the Technical Committee, the Board of Directors, and in Section 7.3 point to the Trademark Policy (http://www.openstack.org/brand/openstack-trademark-policy/) as the governing document of trademark usage.
> 
> The Bylaws also contain what has ended up being a much debated sentence of varied interpretation in Section 4.1(b). I’m going to deviate from just recounting solidly established fact for a minute to explain how I have historically viewed 4.1(b) in the context of overall trademark usage, the history of some of the terms used, and the drafting of the Bylaws.
> 
> The context of Section 4.1 is "General Powers." This section is meant to define at the very highest level, the overall breakdown of responsibility in the Foundation.
> 
> Section 4.1(a) contains a pretty standard corporate line stating that the affairs of the Foundation are overseen by its Board of Directors: "The business and affairs of the Foundation shall be managed by or under the direction of a Board of Directors, who may exercise all of the powers of the Foundation except as otherwise provided by these Bylaws."
> 
> Section 4.1(b) designates the Technical Committee as being responsible for "The management of the technical matters relating to the OpenStack Project.…” 
> It also defines the term "OpenStack Project" to include work produced by the technical community and governed by the Technical Committee, including "a 'Core OpenStack Project,' library projects, gating projects and supporting projects.”
> 
> In the very early days of OpenStack, July of 2010, there were only 2 projects: Compute and Object Storage. Within the first 6 months, other projects got off the ground and we created the initial rudimentary incubation process. The Project Policy Board was the governance body at the time, and we created a delineation between software that was an established part of OpenStack (called “core” projects) and software that was getting started and may become an established part later (called “incubated” projects). All of this software was intended to be used to build a public or private cloud. It was all “cloud software."
> 
> It’s hard to picture this now with our current level of development activity, but at the time, there were only a few dozen total contributors across all of OpenStack, and the systems for managing the development process were MUCH more basic. As the number of developers and contributions grew rapidly and we begin to commit more effort to automated testing and CI, the community started to develop software that made the continued growth and improved quality possible. This software enhanced the development process of building OpenStack, but was not “cloud software” in the sense that it was never meant to be distributed as OpenStack to build a public or private cloud. These were the library, gating and supporting projects. These were being formally recognized by the technical governance right around the time that we were forming the Foundation and drafting the Bylaws in 2012.
> 
> In writing the Bylaws, the defined term “OpenStack Project” refers to the whole body of governed OpenStack software. The defined term “Core OpenStack Project” refers to the specific pieces that were the original two components plus the later components that had gone through the incubation and core graduation process. The existing core projects at the time of drafting are listed at the end of 4.1(b) "Block Storage, Compute, Dashboard, Identity Service, Image Service, Networking, and Object Storage.” No changes to the set of core projects have been made since that time.
> 
> At the time of drafting the Bylaws, we included a process for modifying what comprised the “Core OpenStack Project,” which can be seen in section 4.13(b): "The Technical Committee shall have the authority to determine the modules for addition, combination, split or deletion from the OpenStack Project except for modules of the Core OpenStack Project (as defined in Section 4.1(b) above) which shall be managed as provided below. For modules of the Core OpenStack Project, the Technical Committee may recommend to the Board of Directors the modules for addition, combination, split or deletion from the Core OpenStack Project. Except as provided below, the Board of Directors shall consider only those additions, combinations, splits or deletions that are recommended by the Technical Committee, but shall have the sole authority to approve or reject such additions, combinations, splits and deletions from the Core OpenStack Project.”
> 
> Basically, the TC is responsible for the scope of the overall "OpenStack Project," but for any changes to the “Core OpenStack Project,” the Board of Directors must also approve the recommended change from the Technical Committee.
> 
> This brings us back to Section 4.1(b). This section gives explicit permission to refer to the components of the “Core OpenStack Project" with OpenStack trademarks: "The Core OpenStack Project means the software modules which are part of an integrated release and for which an OpenStack trademark may be used.” The next sentence is the hotly debated one: "The other modules which are part of the OpenStack Project, but not the Core OpenStack Project may not be identified using the OpenStack trademark except when distributed with the Core OpenStack Project."
> 
> The intent of Section 4.1 is not to define the totality of allowed trademark usage. The Bylaws are explicit in Section 7.3 that the referenced Trademark Policy is the governing document for overall trademark usage. The intent of this section was to provide a distinction between the OpenStack community-developed software that is developed and made available to build OpenStack clouds, and the OpenStack community-developed software that is developed for other purposes (e.g. testing, CI). If you take a project like Jenkins Job Builder (JJB), for instance, it is developed within the OpenStack Infra program. However, if you were to take only JJB, and create a service that took YAML files and configured Jenkins machines, that is very different from creating an “OpenStack Cloud.” It would be confusing to the market to launch that service and say “I’m running OpenStack,” so the intent of this portion of 4.1(b) was to draw a line between the community-developed, TC-governed projects that are used to build an instance of “OpenStack” and the projects that are not.
> 
> The controversial aspect comes in when you start talking about the modules that are intended to be used to be cloud services but that are not part of core (e.g. Heat). In my reading, these projects fall under the except clause from the sentence above: "except when distributed with the Core OpenStack Project.” While Heat may not be a part of the Core OpenStack Project because it has not gone through the process in 4.13(b), it is distributed as part of the integrated release with the entirety of the Core OpenStack Project. In my mind, it creates a very odd mismatch for the community to work for six months on the code, do an integrated release of OpenStack software, and for some pieces of that development effort to not actually be “OpenStack.” By my recollection, this is the exact scenario for which we added the “except” to the sentence in question during drafting the Bylaws. So we could talk about all of the components of the OpenStack integrated release as being part of OpenStack. I’ve yet to hear a sensible alternate explanation for the purpose or meaning of the exception in that sentence.
> 
> So then, you may ask, what is the difference between Core and Integrated when it comes to the trademark guidelines. We’ll get to that in just a moment. Let’s look at the other documents of the trademark framework.
> 
> 2) The Trademark Policy - The Trademark Policy is the primary governing document for OpenStack mark usage. The policy has not changed since the Foundation was created, and would require a high-bar amendment process as defined in Section 9.2(d). This high bar was put in place because we saw the OpenStack trademark as a community asset in non-commercial contexts.
> 
> The policy describes and sets out explicitly the right of the community to use the marks for community, non-commercial, community-building purposes. It also prohibits commercial, attention-getting, and branding usage of OpenStack marks without a license from the Foundation. The OpenStack Foundation has the power to grant and revoke the commercial-use licenses and to specify eligibility requirements for those licenses. It lays out several of the licensing programs that existed at the time of drafting but also states "Other licensing programs may be available for a specific use. Please contact us at logo at openstack.org for obtaining the applicable OpenStack Trademark License.” That leads us to the third piece of the framework...
> 
> 3) Commercial Use Trademark Licenses - There are several commercial use licensing programs that the Foundation administers. These can be seen in the side navigation on the Trademark Policy page. These licenses allow commercial entities to incorporate OpenStack marks into their product marketing—for instance Acme Cloud Solution Powered by OpenStack or Acme Training for OpenStack.
> 
> When licensing a trademark, it is important from a legal perspective to have some quality control around the usage so we can still claim and defend the trademark. It’s also important to ensure that there is clarity in the market. Each of the commercial-use licenses have a set of requirements to provide this quality control. For instance, for the OpenStack Powered agreement, your product needs to run OpenStack, including at least the Compute and Object Storage components, it must be running a relatively recent release, it must expose the OpenStack APIs, you must be clear about which OpenStack components and versions are included, and you must pass tests that validate its compatibility.
> 
> Back to the earlier question about the difference between Core and Integrated. Once the Foundation was established and these processes and governance bodies had gotten settled in, the intent was to replace the specific enumeration of two projects (Compute and Object Storage) in these licenses with a reference to the Core OpenStack Project. Then, the Core OpenStack Project would become the common set of required software and APIs that commercial products must incorporate to be able to license OpenStack marks. It would be the baseline for compatibility and interoperability. So while the OpenStack release may contain any number of projects, they may not all be required to be present in every commercial implementation and distribution of OpenStack and licensed the OpenStack trademark. A change like this is part of the Foundation-administered license, rather than an amendment to the Bylaws or Trademark Policy.
> 
> The testing was also a carryover from pre-Foundation days when it was being worked on by the Project Policy Board. The licenses still contain a reference to a test suite approved by the Technical Committee. This test suite has yet to be implemented, however, once in place, it can fit into the existing license agreements.
> 
> 
> 
> From my understanding, DefCore is hoping to clarify the debated areas in Bylaws through some amendments, provide the missing testing that’s already mentioned in the license agreements, and come up with an aggregation of which code across integrated projects is required to be included in a commercial product, replacing the current enumeration of two projects. Getting into the details of that process is beyond the scope of what I was hoping to touch on in this email (it’s arguably too long already). I know there’s going to be a dedicated TC/DefCore meeting next week that will hopefully clarify the purpose and path forward even more. Thanks,
> 
> Jonathan
> 
> 
> 
> On Jun 24, 2014, at 8:52 PM, Michael Still <mikal at stillhq.com> wrote:
> 
>> On Wed, Jun 25, 2014 at 9:53 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>>> On Tue, Jun 24, 2014 at 2:56 PM, Mark McLoughlin <markmc at redhat.com> wrote:
>>>> On Sun, 2014-06-22 at 22:19 -0700, Joe Gordon wrote:
>>>>> Hi all,
>>>>> 
>>>>> In trying to wrap my head around DefCore, I read the DefCore
>>>>> committe's mission as documented on the committee's wiki page[0]. The
>>>>> mission is to "define 'OpenStack Core' as chartered by the by-laws and
>>>>> guided by Governance/CoreDefinition.'  While the bylaws don't have any
>>>>> reference to "OpenStack Core" they do define a term called "Core
>>>>> OpenStack Project"[1]. Is this what the DefCore Comittee is refering
>>>>> to when talking about "OpenStack Core?"
>>>> 
>>>> Yes, it is. The crucial bit is:
>>>> 
>>>> "The Core OpenStack Project means the software modules which are part
>>>>  of an integrated release and for which an OpenStack trademark may be
>>>>  used. The other modules which are part of the OpenStack Project, but
>>>>  not the Core OpenStack Project may not be identified using the
>>>>  OpenStack trademark except when distributed with the Core OpenStack
>>>>  Project."
>>>> 
>>>> The aspect of this I think everyone is agreed on is that "The Core
>>>> OpenStack Project" is a subset of the integrated release. And that "The
>>>> Core OpenStack Project" has something to do with the OpenStack
>>>> trademark.
>>>> 
>>>> There are two interpretations of this AFAICT:
>>>> 
>>>> 1) Only the core modules can be called OpenStack Foo and OpenStack Bar
>>>> 
>>>> 2) Only the core modules can be required in some way for commercial
>>>>    products which license the OpenStack trademark in some way
>>> 
>>> 
>>> Isn't legalese fun.  I have a third interpretation that combined those two.
>>> 
>>> Only the core modules can be called OpenStack Foo and OpenStack Bar (as long
>>> as the usage is in line with the Trademark Policy), and how the trademarks
>>> are licensed is subject to the Trademark Policy. The Trademark Policy cannot
>>> define a trademark that only requires something outside of the Core
>>> OpenStack Project. For example the Trademark Policy clearly states what is
>>> required to use the "Powered by OpenStack™" trademark. So the issue of
>>> licensing the trademark for commercial products is purview of only the
>>> Trademark Policy. Any requirements of running or passing specific tests
>>> would fit under the Trademark Policy.
>> 
>> I gave Joe a call to have a chat about this, and it seems to be we can
>> best progress this by sharing a draft of the proposed trade mark
>> policy after the defcore changes go through. Who can share a link to
>> the proposed new policy?
>> 
>>>> The DefCore effort is about clarifying (2) "by defining 1) capabilities,
>>>> 2) code and 3) must-pass tests for all OpenStack products. This
>>>> definition [..] drives interoperability by creating the minimum
>>>> standards for products labeled "OpenStack."
>>> 
>>> 
>>> Based on my interpretation above, this goal would not apply to defining
>>> core, but about amending the Trademark Policy, as the bylaws describe when
>>> talking about how the Board of Directors may amend the the Trademark Policy
>>> without doing a general vote as long as the amendment is made prior to
>>> January 31, 2013.
>>> 
>>> "amend the Trademark Policy prior to January 31, 2013 to establish testing
>>> and certification requirements for the use of the trademarks owned by the
>>> Foundation in connection with the use of the Core OpenStack Project."
>>> 
>>>> 
>>>> 
>>>>> If so, the bylaws already clearly state the process to change what
>>>>> software modules make up the "Core OpenStack Project." The Technical
>>>>> Committee(TC) proposes a change to what is in the "Core OpenStack
>>>>> Project" and the Board of Directors has the sole authrity to approve
>>>>> or reject the TC's recommendation [2].
>>>> 
>>>> Under interpretation (1) above, that means the TC can ask the board for
>>>> e.g. Heat to be called OpenStack Orchestration:
>>>> 
>>>> 
>>>> http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20131106-ceilometer-and-heat-official-names.rst
>>> 
>>> 
>>> To the best of my knowledge the Board of Directors has not approved this
>>> resolution. I have not been able to find any evidence of a vote on this.
>>> 
>>>> 
>>>> 
>>>> 
>>>> Under interpretation (2) above, the TC would be recommending that Heat
>>>> should in some way be required for OpenStack products.
>>> 
>>> 
>>> 
>>> The current list of The current list of modules in "Core OpenStack Project"
>>> are "Block Storage, Compute, Dashboard, Identity Service, Image Service,
>>> Networking, and Object Storage modules." But the Trademark Policy says "The
>>> Powered by OpenStack' Logo, shown immediately below, may be used by
>>> individuals, organizations, and companies that use formally released
>>> OpenStack Compute (Nova) code in their application or product." And never
>>> says an OpenStack product must run all the modules in  "Core OpenStack
>>> Project." In fact it never uses the word 'Core.'
>>> 
>>> which makes me thing interpretation (2) is not entirely correct.
>>> 
>>>> 
>>>> 
>>>>> This mismatch between DefCore's mission and the bylaws has already
>>>>> been identified by the DefCore committee itself [3]. So if the current
>>>>> mission statement doesn't align with the bylaws then what is the
>>>>> DefCore committe's current mission statement?
>>>> 
>>>> It's part of the DefCore committee's mission to help get the bylaws
>>>> confusion clarified AIUI.
>>>> 
>>>> AFAICT the assumption is that the language should be clarified such that
>>>> interpretation (2) is clear.
>>>> 
>>>>> The 'Core Definition' document[5] mentions DefCore will help
>>>>> "determine how commercial implementations of OpenStack can be granted
>>>>> use of the trademark," and the committee "may suggest changes to the
>>>>> by-laws to clarify the definition of core." So presumably DefCore is
>>>>> not about defining "Core OpenStack Project," but rather about revising
>>>>> the trademark policy as defined in Appendix 8 of the bylaws [6].
>>>> 
>>>> It's about changing how "Core OpenStack Project" is defined such that it
>>>> is no longer "a set of modules which is a subset of the integrated
>>>> release" but instead "a set of API tests and required sections of code".
>>>> 
>>>> That involves both coming up with the process for managing that (in that
>>>> it wouldn't begin simply with the TC nominating some modules for Core)
>>>> and proposing the bylaws changes to reflect the process.
>>>> 
>>>> That raises the question of what happens if DefCore-recommended bylaws
>>>> changes can't be passed. What interpretation of the current bylaws
>>>> allows the commercial trademark requirements process to evolve in this
>>>> way?
>>> 
>>> 
>>> The bylaws seem pretty clear about this, the commercial trademark
>>> requirements cannot evolve without a large vote " In addition to the vote of
>>> the Board of Directors as provided in Section 9.1, the amendment of the
>>> following Sections requires an affirmative vote of (i) two-thirds of the
>>> Gold Members, (ii) two-thirds of the Platinum Members, and (iii) a majority
>>> of the Individual Members voting (but only if at least 25% of the Individual
>>> Members vote at an annual or special meeting): Article II (not including the
>>> Appendices referenced in Article II), Sections 4.1, 4.2(a), 4.9, 4.10, 4.11,
>>> 4.13, 4.17, 4.20, 7.1, 7.2, 7.3, 7.4 "   7.3 is the Trademark Policy
>>> 
>>>> 
>>>> 
>>>>> This interpretation alligns with the special clause on ammendments in
>>>>> the bylaws "the Board of Directors may by majority vote, amend the
>>>>> Trademark Policy prior to January 31, 2013 to establish testing and
>>>>> certification requirements for the use of the trademarks owned by the
>>>>> Foundation in connection with the use of the Core OpenStack
>>>>> Project."[7]  What is the progress on drafting a revision to the
>>>>> trademark policy? Is there a preliminary draft on the proposed change?
>>>>> Seeing this would help me wrap my better understand DefCore.
>>>> 
>>>> Good question, I don't know if the Foundation is working on drafting a
>>>> new trademark policy.
>>>> 
>>>> AIUI the Foundation staff is responsible for the details of the
>>>> trademark policy and it has changed somewhat since the bylaws were
>>>> drafted. I think it was only included in the bylaws for informational
>>>> purposes and doesn't require a vote of the Individual Members. Then
>>>> again, section 9.2(a) suggests voting is required to change any of the
>>>> appendices.
>>>> 
>>>> Thanks,
>>>> Mark.
>>>> 
>>>>> [0] https://wiki.openstack.org/wiki/Governance/DefCoreCommittee
>>>>> [1] http://www.openstack.org/legal/bylaws-of-the-openstack-foundation/
>>>>> Sections 4.1.b
>>>>> [2] http://www.openstack.org/legal/bylaws-of-the-openstack-foundation/
>>>>> Sections 4.13.b
>>>>> [3] https://etherpad.openstack.org/p/DefCoreBylawsIPE
>>>>> [5] https://wiki.openstack.org/wiki/Governance/CoreDefinition
>>>>> [6] http://www.openstack.org/brand/openstack-trademark-policy/
>>>>> [7] http://www.openstack.org/legal/bylaws-of-the-openstack-foundation/
>>>>> Sections 9.2.d
>>>> 
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Foundation mailing list
>>> Foundation at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
>>> 
>> 
>> Thanks,
>> Michael
>> 
>> -- 
>> Rackspace Australia
>> 
>> _______________________________________________
>> Defcore-committee mailing list
>> Defcore-committee at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
> 
> 
> _______________________________________________
> Foundation mailing list
> Foundation at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation