上次 TC 更新 讨论了由 OpenStack 基金会董事会领导的 DefCore 工作。DefCore 子委员会向 TC 提出了一些输入请求。本周，我们举行了一次 特别会议，完全专注于澄清围绕 DefCore 的一些要点，并对我们收到的问题做出了一些回应。

值得注意的是，在会议之前，Jonathan Bryce 发布了一篇关于管理 OpenStack 商标使用的现有框架的 非常全面的评论。这个主题的良好理解值得阅读这个帖子。

DefCore 范围

议程的第一点是澄清 DefCore 的范围。具体来说，我们想明确这项工作适用于商标的哪些用途。在关于这个主题的会议期间，达成了一些重要的澄清。DefCore 仅涉及商标的商业用途。目前，这仅包括“Powered by OpenStack”商标许可计划。我们还了解到，董事会已保留在未来推出“OpenStack Compatible”商标计划的选项，该计划可能与我们现在讨论的内容具有不同的要求集。

Jonathan 在会议期间对此进行了非常清晰的解释（在 20:25:56）：

所讨论的许可协议称为 OpenStack Powered，旨在用于使用 OpenStack 软件构建的产品和服务。例如，公共云“FooTron Compute Powered By OpenStack”，设备“FooTron Appliance Powered by OpenStack”，发行版“FooTron OpenStack”。所有这些不同的产品都将遵守相同的标准。换句话说，它们都需要暴露相同的功能（通过 API 可测试）并包含相同的实际社区开发的软件组件（指定的部分）。

DefCore 功能

DefCore 子委员会一直在努力定义一组功能以及相关的测试，这些功能和测试将用作确定给定 OpenStack 产品或服务是否允许在“Powered by OpenStack”商标计划下使用 OpenStack 商标的过程的一部分。他们一直在使用评分系统来确定应要求哪些功能。这个评分的输入部分是“技术方向”。他们不想包含技术社区不认为我们希望长期保留的功能。TC 被要求对一些未来不明确的功能提供输入。我们一直在 两个 评论 中澄清所有这些要点，提交到 OpenStack 技术治理仓库。我们即将就这些要点达成最终结论。

DefCore 功能当前定义在一个 JSON 文件中，映射到一组测试。TC 提供的一个建议是，为每个功能提供 1 或 2 句话的描述将有助于更轻松地理解功能的预期覆盖范围。否则，感兴趣的各方必须阅读每个测试才能了解它试图验证的内容。虽然这将很有帮助，但我们都同意这不会实际阻止进展。它只会让事情变得更容易。

会议的这一部分讨论的最后一点是功能和代码指定部分之间的关系。通常，您必须实现代码指定部分并且交付核心功能，但已明确代码指定部分仅在存在被认为必需的相应功能时才需要。如果一个项目没有必需的功能，那么该项目的使用或分发是不需要的。

代码指定部分

这是会议中最具争议的部分。DefCore 委员会要求 TC 提供一组建议的代码指定部分。然后将此输入作为“Powered by OpenStack”商标许可计划下需要哪些代码的基础。经过长时间的讨论，TC 能够就此达成共识，并在本次会议中提供了回复。

TC 的主要职责之一是定义每 6 个月发布的 OpenStack 集成版本。这是我们所担保的一组内容。我们有一个明确的流程，项目必须满足 一组要求 才能申请孵化，并最终可能毕业成为此集成版本的一部分。定义集成版本的一个子集会使 TC 看起来像是认可或鼓励用专有替代品替换其工作的一部分。TC 是项目贡献者的选举代表，因此它不认为应该宣布集成版本的一个子集比其余部分不重要。

我们重视 Apache 许可提供的替换部分代码的选项，并且我们尊重董事会确定商标使用策略的特权。因此，我们希望明确认识到，董事会有权定义商业商标许可协议（例如“OpenStack Powered”商标计划）所需的集成版本的子集，因此他们应该最终决定“代码指定部分”。Mark McLoughlin 在 Defcore 列表中提出了一种 实现这一目标的过程，即董事会提出代码指定部分，并要求更广泛的社区对其进行评论，然后根据该反馈做出最终决定。