The last TC update discussed the DefCore effort being led by the OpenStack Foundation Board. The DefCore subcommittee had made some requests for input from the TC. This week we held a special meeting entirely focused on clarifying some points around DefCore and providing some responses to the questions given to us.

It’s also worth noting that prior to the meeting, Jonathan Bryce posted a very comprehensive review of the existing framework that governs OpenStack trademark usage. This thread is absolutely worth reading for a good understanding of this topic.

Scope of DefCore

The first point on the agenda was to clarify the scope of DefCore. Specifically, we wanted to clarify which uses of the trademark this effort was applicable to. There were some important points of clarification reached during the meeting on this topic. DefCore is only about the commercial uses of the trademark. Currently, this only includes the “Powered by OpenStack” trademark license program. We also understand that the board has left open the option of an “OpenStack Compatible” trademark program in the future that may have a different set of requirements than what we are discussing right now.

Jonathan clarified this very well during the meeting (at 20:25:56):

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”. All of those different 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).

DefCore Capabilities

The DefCore subcommittee has been working to define a set of capabilities with associated tests that would be used as a part of the process to determine if a given OpenStack product or service was allowed to use the OpenStack mark under the “Powered by OpenStack” trademark program. They have been using a scoring system to determine which capabilities should be required. Part of the input into this scoring is “technical direction”. They do not want to include a required capability that the technical community does not view as something we want to keep around long term. The TC was asked to provide input on some capabilities where the future was unclear. We have been working on clarifying all of these points in two reviews to the OpenStack technical governance repository. We are close to reaching a final conclusion on these points.

DefCore capabilities are currently defined in a JSON file as a mapping to a set of tests. One recommendation that the TC provided was that a 1 or 2 sentence description for each capability would help provide easier understanding of the intended coverage of a capability. Otherwise, interested parties must go read each test to understand exactly what it’s attempting to verify. While this would be helpful, we all agreed that this does not actually block progress. It would just make things easier.

The final point discussed in this section of the meeting was the intersection of capabilities and designated sections of code. Generally you have to implement designated section code and deliver core capabilities, but it was clarified that designated sections of code would only be required if there is a corresponding capability that is deemed required. If a project has no required capabilities, then the use or distribution of that project is not required.

Designated Sections

This was the most controversial part of the meeting. The DefCore committee had requested that the TC provide a proposed set of designated sections of code. This input would then be used as the basis for what code is required under the “Powered by OpenStack” trademark license program. After much discussion, the TC was able to reach consensus on this topic and a response was provided in this meeting.

One of the primary responsibilities of the TC is to define the OpenStack integrated release which is released every 6 months. This is the set of things that we vouch for. We have a defined process with a set of requirements projects must satisfy to apply for incubation and potentially eventually graduate to be a part of this integrated release. Defining a subset of the integrated release would make the TC appear to endorse or encourage replacing part of their work with proprietary alternatives. The TC is an elected representation of the contributors to the project and as such it does not feel it should declare a subset of the integrated release less important than the rest.

We do value that the Apache license provides the option of replacing part of the code with alternative solutions, and we respect that it’s the board prerogatives to determine trademark use policy. So we would like to clearly recognize that it’s the board’s right to define the subset of the integrated release required by commercial trademark license agreements (such as the “OpenStack Powered” trademark program), and therefore they should have final say on “designated sections”. A process to achieve that was suggested by Mark McLoughlin on the Defcore list, where the Board would propose designated sections and ask the wider community for comments on it, then make the final calls based on that feedback.