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 we need the PTLs to decide what code sections are designated sections nova might make the "conductor" a designated section capabilities don't have to be implemented with the same code unless that code is a designated section 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.