This resolution is the draft of an email from the TC to the Board DefCore
committee on the issue of identifying "required sections" of code.
The Technical Committee thanks the Board for requesting our assistance in
defining the requirements for usage of the OpenStack trademark. This is
an important and complicated issue, so the Technical Committee feels that it
needs to be solved in two parts.
In order to improve the engagement of the Technical Committee on this issue,
we have selected Michael Still as our representative to the "DefCore"
subcommittee, with Anne Gentle as his backup.
The first part is interoperability. Our end users care about interoperability
of deployed OpenStack clouds. This interoperability is best measured by API
testing, with tempest being a one potential vehicle to drive such testing.
The second part is upstream collaboration. We feel that encouraging
distributors and other employers of developers to engage with the upstream
community is of value, and that the preference is for all code to end up
going through our development process instead of being held in private. The
tension here is between deployers and distributors desire to be interoperable
while still retaining some ability to differentiate.
Conveniently, our existing trademark requirements already see this distinction:
2) To ensure compatibility, your product must:
i. include the entirety of the OpenStack [..] code from either of the latest
two releases and associated milestones, but no older, and
ii. expose the associated OpenStack APIs [..] without modification.
Since these requirements will evolve over time, we feel that it is important
to focus our short term efforts on improving our requirements around API
interoperability since the project is already having good success in
encouraging upstream collaboration.
The DefCore committee specifically requested our advice in designating sections
of code as required. Our initial discussions have identified some policy
questions we feel the board would need to address, for example:
- how granular and specific does the board want these requirements to be?
- how limiting should they be? For example, are backports from master of
fixes or features to the designated areas allowed?
- many parts of OpenStack are pluggable in ways that do not replace
designated sections and are not alternate implementations of a plugin
interface - for example you can add new WSGI middlewares or scheduler
filters - how much of this extensibility does the board wish to allow?
- altering libraries (3rd party, or part of OpenStack itself) can have as
much impact on behaviour as altering OpenStack services itself. Is there a
desire to address this?
- at some point, these sorts of requirements, and the desire to force people
to engage upstream, seem confusingly at conflict with our "business
friendly" choice of a permissive license (i.e. the Apache License vs, say,
the AGPL). How does the board reconcile the use of an extremely permissive
software license with an extremely restrictive trademark license?
Furthermore, we have identified some initial implementation issues which make
this non-trivial to get right:
- how exactly to "designate sections" - e.g. sha1 sums of the sections, a
list of python modules, a white-list of "non-designated sections" ?
- any of the above will require significant maintenance
- how do we coordinate updating designated sections with e.g. security
updates? How long would vendors have to before they must run the updated
designated sections?
- many parts of our codebase would never be used under certain configurations
- are we requiring "designated sections" to be executed or "included"? If
the latter, is it ok for all designated sections to be routed around?
Given the complexity of these issues and they do not directly address the most
immediate interoperability concerns, we have a preference for a focus on
ensuring that end users have a good experience with Icehouse being the priority
at this time. The Technical Committee encourages the DefCore committee to
therefore focus on defining the set of API tests that a compliant OpenStack
should pass for this release.
---
For reference, here is the context around the request we are responding to:
http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-02-04-20.02.log.html#l-332
<joshuamckenty> we need the PTLs to decide what code sections are designated
sections
<joshuamckenty> nova might make the "conductor" a designated section
<joshuamckenty> capabilities don't have to be implemented with the same code
unless that code is a designated section
<joshuamckenty> e.g., neutron plugins
https://wiki.openstack.org/wiki/Governance/CoreDefinition
4. Claiming OpenStack requiring use of designated upstream code
1. Implementation’s claiming the OpenStack™ mark must use the
OpenStack upstream code (or be using code submitted to upstream)
2. You are not OpenStack, if you pass all the tests but do not use
the API framework
3. This prevents people from using the API without joining the
community
4. This also surfaces bit-rot in alternate implementations to the
larger community
5. This behavior improves interoperability because there is more
shared code between implementation
http://lists.openstack.org/pipermail/openstack-dev/2014-February/026413.html
The DefCore subcommittee from the OpenStack board of directors asked the
Technical Committee yesterday about which code sections in each
integrated project should be "designated sections"
http://lists.openstack.org/pipermail/openstack-dev/2014-February/026559.html
"2) To ensure compatibility, your product must:
i.include the entirety of the OpenStack [...] code from either of
the latest two releases and associated milestones, but no older"
The request from the DefCore committee around designated sections
would replace Section 2(i) in the above example. [...] You’ll
notice that Section 2(i) is not granular at all, but does include a
version requirement.