Open Stack

Hi Jonathan,

On Wed, 2014-06-25 at 11:10 -0500, Jonathan Bryce 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. = )

Thanks for doing this. I think it's fair to say that many of us are
growing weary of debating the nuances of this stuff, but it's clear that
confusion (including my own confusion) persists. Your email really helps
IMHO.

> 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.

And I guess one way of looking at how that has evolved since is that we
(the TC, at least) now see the "Integrated OpenStack Project" as being
the "cloud software" which has passed through our integration process.
It is the subset of the OpenStack Project which is intended to be used
to provide public and private cloud services.

This is a pretty straightforward clarification of TC powers - the TC
determines the scope of the OpenStack Project and is responsible for the
incubation process. Whether a project is "cloud software" is pretty much
a question of fact, not a policy decision. So, we needed a term to
describe "cloud software" projects which we've included in the OpenStack
Project and graduated from the incubation process, but which have not
yet been through a process by which the Board of Directors included it
in the "Core OpenStack Project". We now call that "Integrated".

It does beg the question, what exactly then is the purpose of this "Core
OpenStack Project" idea. I've always felt it was strictly related to
some trademark concepts, and strictly a Board of Directors matter since
trademark policy decisions are also a Board matter.

(You raise an interesting point on that, though - the Trademark Policy
isn't something the Board can change of its own accord, so their powers
are in relation to the trademark license agreements which the Foundation
staff take much of the responsibility for)

> 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, your summary of the "except" clause is basically that it allows what
we now call the "Integrated OpenStack Project" to be described as
OpenStack. That all modules in the integrated release can be described
as OpenStack because they are distributed together.

> 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...

This is a hugely important distinction and one that I'd forgotten about.
The DefCore process is not about changing the Trademark Policy as
defined it in the bylaws, it is about evolving and clarifying the
requirements for some of our Trademark Licenses.

> 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.

In terms of publicly visible trademark license programs that are
relevant to the DefCore process, I guess the requirements for use of the
"OpenStack Powered" logo is the relevant license? And I see that license
isn't just about the logo, but also permission to including the
OpenStack Word Mark and "Powered" in their product name, e.g. Acme Cloud
Solution Powered by OpenStack, as you describe.

However, see plenty of OpenStack products in the market place who use
the Word Mark in different ways:

  http://www.openstack.org/marketplace/distros/

    HP Helion OpenStack®
    Red Hat Enterprise Linux OpenStack Platform
    Ubuntu OpenStack 
    Metacloud OpenStack
    Mirantis OpenStack
    etc.

Have each of these companies obtained a different Word Mark license
agreement (i.e. something other than the "OpenStack Powered" license)
from the Foundation? Do those licenses essentially have the same
requirements as the "OpenStack Powered" license, except they allow
slightly different usage of the Word Mark?

Clarifying exactly which trademark licenses DefCore is relevant to turns
out to be pretty important. If you look at e.g.

  https://wiki.openstack.org/wiki/Governance/DefCoreCommittee
    creating the minimum standards for products labeled "OpenStack."

  https://wiki.openstack.org/wiki/Governance/CoreDefinition
    Implementations that are Core can use OpenStack trademark 
    (OpenStack™) 

you'd be forgiven in thinking that this is a much broader thing than
simply the "OpenStack Powered" licenses, and the only place I've seen
this made more clear is here:

  http://www.slideshare.net/rhirschfeld/what-is-openstack-defcore-altanta-conference/13
    "OpenStack Powered"

> 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 way DefCore has evolved, the Bylaws concept of the "Core OpenStack
Project" becomes pretty much irrelevant - if its only purpose was to be
referenced in the trademark licenses and we no longer plan to reference
it in the trademark licenses, then it no longer has a purpose?

Instead, we now have the concept of "designated sections", and the TC
and PTLs are being asked to help DefCore figure out what code should be
"designated". So far, we've come up with this attempt at guidelines:

  http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20140402-defcore-designated-sections-guidelines.rst

which, in retrospect, are still fairly ambiguous and confusing. The
question of which code should be designated is not simply a technical
question, it is a policy question. And it is not yet clear what values
are driving the desired policy outcome.

The main question around policy and values is the "project design
explicitly intended this section to be replaceable" part. Projects may
have a "driver" or "plugin" layer and you could argue that this layer is
intended to make the code underneath it "replaceable", but we may have
several upstream drivers or plugins. Is the intended outcome of DefCore
that the "OpenStack Powered" trademark license allows proprietary
drivers or plugins, only open-source drivers or plugins, or only
upstream drivers or plugins?

If the intent is for "non-designated sections" of code to be replaceable
by proprietary implementations under the "OpenStack Powered" trademark
license, then the TC and PTLs are being asked "which sections of code
should the trademark license allow proprietary alternatives?". That
seems like a bizarrely loaded and charged trademark policy question,
rather than a purely technical question.

> 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,

Personally I'm not paying too much attention to the Bylaws aspect of
this right now since it seems the least pressing - DefCore plans to make
progress on the other aspects without any Bylaws changes.

>  provide the missing testing that’s already mentioned in the license
> agreements,

This is the part which seems the furthest along. It is also the part
which is most important to driving improved interoperability.

> 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.

This part still seems the most controversial and is now somewhat stalled
because the hugely charged policy question has been punted to the TC and
PTLs.

>  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.

Yes, I think the meeting is necessary and is going to be useful. Your
mail provides really useful framing for that discussion.

Thanks,
Mark.