355 lines
24 KiB
Markdown
355 lines
24 KiB
Markdown
# CNCF章程
|
||
|
||
CNCF（云原生计算基金会）是Linux基金会旗下的一个基金会，加入CNCF等于同时加入Linux基金会（也意味着你还要交Linux基金会的份子钱），对于想加入CNCF基金会的企业或者组织首先要做的事情就是要了解CNCF的章程（charter），就像是作为一个国家的公民，必须遵守该国家的宪法一样。CNCF之所以能在短短三年的时间内发展壮大到如此规模，很大程度上是与它出色的社区治理和运作模式有关。了解该章程可以帮助我们理解CNCF是如何运作的，也可以当我们自己进行开源项目治理时派上用场。
|
||
|
||
该章程最后更新于2018年5月15日，详见<https://www.cncf.io/about/charter/>。下文中关于CNCF章程的介绍部分引用自[CNCF 是如何工作的](http://www.ocselected.org/posts/foundation_introduce/how_cncf_works/)，有改动。
|
||
|
||
下图是我根据CNCF章程绘制的组织架构图。
|
||
|
||
|
||
|
||
## 1. CNCF的使命
|
||
|
||
CNCF 没有偏离自己的主题，核心是解决技术问题：基金会的使命是创建并推动采用新的计算模式，该模式针对现代分布式系统环境进行了优化，能够扩展至数万个自愈式多租户节点。
|
||
|
||
所谓的云原生系统须具备下面这些属性：
|
||
|
||
- **应用容器化**：将软件容器中的应用程序和进程作为独立的应用程序部署单元运行，并作为实现高级别资源隔离的机制。从总体上改进开发者的体验、促进代码和组件重用，而且要为云元是国内应用简化运维工作。
|
||
- **动态管理**：由中心化的编排来进行活跃的调度和频繁的管理，从根本上提高机器效率和资源利用率，同时降低与运维相关的成本。
|
||
- **面向微服务**：与显式描述的依赖性松散耦合（例如通过服务端点），可以提高应用程序的整体敏捷性和可维护性。CNCF 将塑造技术的发展，推动应用管理的先进技术发展，并通过可靠的接口使技术无处不在，并且易于使用。
|
||
|
||
## 2. CNCF扮演的角色
|
||
|
||
CNCF 其实是在开源社区的基础上发挥着作用，应负责：
|
||
|
||
a) 项目管理
|
||
|
||
- 确保技术可用于社区并且没有杂七杂八的影响
|
||
- 确保技术的品牌（商标和标识）得到社区成员的关注和使用，特别强调统一的用户体验和高水平的应用程序兼容性
|
||
|
||
b) 促进生态系统的发展和演进
|
||
|
||
- 评估哪些技术可以纳入云原生计算应用的愿景，鼓励社区交付这样的技术，以及集成它们，且要积极的推进总结进度。
|
||
- 提供一种方法来培养各个部分的通用技术标准
|
||
|
||
c) 推广底层技术和应用定义和管理方法，途径包括：活动和会议、营销（SEM、直接营销）、培训课程和开发人员认证。
|
||
|
||
d) 通过使技术可访问和可靠来为社区服务
|
||
|
||
- 旨在通过对参考架构进行明确定义的节奏，为每个组成部分提供完全集成和合格的构建。
|
||
|
||
## 3. CNCF的价值观
|
||
|
||
CNCF 会极力遵循以下一些原则：
|
||
|
||
1. **快速胜过磨叽**，基金会的初衷之一就是让项目快速的发展，从而支持用户能够积极的使用。
|
||
2. **开放！** CNCF 是以开放和高度透明为最高准则的，而且是独立于任何的其它团体进行运作的。CNCF根据贡献的内容和优点接受所有的贡献者，且遵循开源的价值观，CNCF输出的技术是可以让所有人使用和受益的，技术社区及其决策应保持高度透明。
|
||
3. **公平**：CNCF 会极力避免那些不好的影响、不良行为、以及“按需付费”的决策。
|
||
4. **强大的技术身份**：CNCF 会实现并保持高度的自身技术认同，并将之同步到所有的共享项目中。
|
||
5. **清晰的边界**：CNCF 制定明确的目标，并在某些情况下，要确定什么不是基金会的目标，并会帮助整个生态系统的运转，让人们理解新创新的重点所在。
|
||
6. **可扩展**：能够支持从小型开发人员中心环境到企业和服务提供商规模的所有部署规模。这意味着在某些部署中可能不会部署某些可选组件，但总体设计和体系结构仍应适用。
|
||
7. **平台中立**：CNCF 所开发的项目并不针对某个特定平台，而是旨在支持各种体系结构和操作系统。
|
||
|
||
## 4. 会员制
|
||
|
||
CNCF中的会员包括白金、金牌、银牌、最终用户、学术和非赢利成员等级别，不同级别的会员在理事会中的投票权不同。
|
||
|
||
a) **白金会员**：在CNCF理事会中任命1名代表，在理事会的每个次级委员会和活动中任命1名有投票权的代表，在网站可以突出显示；如果也是终端用户成员将继承终端用户成员的所有权利
|
||
|
||
b) **金牌会员**：基金会中每有5个金牌会员，该级别的会员就可以任命1名代表，最多任命3个；如果也是终端用户成员将继承终端用户成员的所有权利
|
||
|
||
c) **银牌会员**：基金会中每有10个银牌会员，该级别的会员就可以任命1名代表，最多任命3个；如果也是终端用户成员将继承终端用户成员的所有权利
|
||
|
||
d) **终端用户**：参加终端用户咨询社区；向终端用户技术咨询委员会中提名1名代表
|
||
|
||
e) **学术和非赢利会员**：学术和非营利会员分别限于学术和非营利机构，需要理事会批准。学术成员和非营利成员有权将其组织认定为支持CNCF使命的成员以及理事会确定的任何其他权利或利益。
|
||
|
||
## 5. 理事会
|
||
|
||
a) CNCF理事会负责市场营销、业务监督和预算审批，不负责技术方面，除了与TOC配合确定CNCF工作范围、完成时间表a)、更新CNCF网站
|
||
|
||
b) 负责日常事务
|
||
|
||
1. 与TOC协商CNCF的整体范围
|
||
2. 商标和版权保护
|
||
3. 市场营销、布道和生态系统建设
|
||
4. 创建和执行品牌承诺项目，如果需要的话
|
||
5. 监督运营，业务发展；
|
||
6. 募资和财务管理
|
||
|
||
c) 理事会投票成员由会员代表和社区代表组成：
|
||
|
||
1. 成员代表包括：
|
||
- 每名白金会员任命1名代表
|
||
- 黄金和银牌成员当选代表
|
||
2. 技术社区代表包括：
|
||
- 技术监督委员会主席
|
||
- 根据当时在任的理事会批准的程序从CNCF项目中选出两名提交者。
|
||
3. 理事会可能会以白金会员比例的价格扩展白金会员资格，对年收入低于5000万美元的创业公司进行长达5年的逐年审计，这些公司被视为理事会的战略技术贡献者。
|
||
4. 只有来自一组**关联公司**的人员可以担任会员代表。只有来自一组**关联公司**的人员可以担任技术社区代表。
|
||
|
||
d) 职责
|
||
|
||
1. 批准预算，指导将所有收入来源筹集的资金用于技术、市场或社区投资，以推动 CNCF 基金的使命；
|
||
2. 选举理事会主席主持会议，批准预算批准的支出并管理日常运作；
|
||
3. 对理事会的决定或事项进行投票；
|
||
4. 界定和执行基金会的知识产权（版权，专利或商标）政策；
|
||
5. 通过活动、新闻和分析师宣传、网络、社交媒体以及其他营销活动进行直接营销和布道；
|
||
6. 监督运营，业务发展；
|
||
7. 建立并监督为推动CNCF的使命而创建的任何委员会；
|
||
8. 根据CNCF要求（可能包括认证测试）建立并执行品牌合规计划（如有），以使用TOC建立的品牌标志；
|
||
9. 采用商标使用准则或政策；
|
||
10. 提供整体财务管理。
|
||
|
||
e) 基金会的收入用途
|
||
|
||
1. 市场营销，用户扩展CNCF中的项目的采用
|
||
2. 关键设施建设、运行和管理项目的基础设施
|
||
3. 促进基于容器的计算使用CNCF中的项目实现
|
||
|
||
## 6. 技术监督委员会（TOC）
|
||
|
||
### a) 要求
|
||
|
||
CNCF 技术监督委员会，为了保持中立，则达成了以下共识：
|
||
|
||
1. 定义和维护CNCF的技术愿景。
|
||
2. 批准由理事会制定的CNCF范围内的新项目，并为项目创建一个概念架构。
|
||
3. 纠正项目的发展方向，决策删除或存档项目。
|
||
4. 接受最终用户委员会的反馈并反映在项目中。
|
||
5. 在科学管理的情况下调整组件的接口（在代码标准化之前实现参考）
|
||
6. 定义在CNCF项目中实施的常用做法（如果有的话）。
|
||
|
||
### b) 技术监督委员会的构成
|
||
|
||
1. TOC最多由9名成员组成。
|
||
2. 选出的TOC成员将涵盖关键的技术领域：容器技术、操作系统、技术运维、分布式系统、用户级应用程序设计等。
|
||
3. 理事会将选举6名TOC成员，最终用户TAB将选出1名TOC成员，最初的7名TOC成员应另选两名TOC成员。
|
||
4. 如果超过两名TOC成员来自同一组关联公司，无论是在选举时还是来自后来的工作变更，他们将共同决定谁应该下台，或如果没有协商的依据，则应抽签决定。
|
||
|
||
### c) 运营模式
|
||
|
||
1. TOC 会选举出TOC的主席来，此角色主要负责 TOC 的议程和召集会议。
|
||
2. TOC 每个季度会面对面讨论重要的热点问题。
|
||
3. TOC 可能会根据需要开会讨论新出现的问题。 TOC审核可能会提出以下问题：
|
||
- 任何的 TOC 成员
|
||
- 任何的理事会成员
|
||
- 建立的CNCF项目的维护者或顶级项目负责人
|
||
- CNCF 执行董事
|
||
- 最终用户技术咨询委员会获得多数票
|
||
4. 保持透明：TOC会议、邮件列表、以及会议记录等均是公开可访问的。
|
||
5. 简单的TOC问题可以通过简短的讨论和简单的多数表决来解决。TOC讨论可通过电子邮件或TOC会议进行。
|
||
6. 在对意见和可选虚拟讨论/辩论选项进行审查后，寻求共识并在必要时进行投票。
|
||
7. 目的是让TOC在TOC和社区内寻找达成共识的途径。满足法定人数要求的会议的TOC决定应以超过TOC成员出席率的50％的方式通过。
|
||
8. TOC会议需要TOC总人数的三分之二法定人数进行表决或作出任何决定。如果TOC会议未能达到法定人数要求，可以进行讨论，但不应有任何投票或决定。
|
||
9. TOC决定可以在没有会议的情况下以电子方式提出，但要通过表决则需要多少票数才能达到会议法定人数。在电子投票中，如果任何两名TOC成员要求召开会议讨论决定，则电子投票结束时无效，并且在会议结束后可以启动新的投票，以讨论决定已经完成。
|
||
|
||
### d) 提名标准
|
||
|
||
获得 TOC 提名的开源贡献者应该具备下面条件：
|
||
|
||
1. 承诺有足够的可用可用时间参与CNCF TOC的活动，包括在CNCF成立时相当早期的投入，然后需持续投入时间，而且在季度的 TOC 会议之前要进行充分的准备和审查事宜。
|
||
2. 在CNCF范围内展示了高水准的专业经验。
|
||
3. 证明其有资格能够获得额外的工作人员或社区成员协助其在 TOC 的工作。
|
||
4. 在讨论中保持中立，并提出CNCF的目标和成功与公司目标或CNCF中的任何特定项目保持平衡。
|
||
|
||
### e) TOC成员提名和选举程序
|
||
|
||
1. TOC由9位TOC成员组成：由理事会选出的6位，由最终用户TAB选出的1位和由最初的7位TOC成员选出的2位。
|
||
2. 提名：每个有资格提名TOC成员的个人（实体或成员）可以提名至多2名技术代表（来自供应商、最终用户或任何其他领域），其中至多一个可能来自其各自公司。被提名者必须提前同意加入到候选人名单中。
|
||
- 最初的7名TOC成员（理事会选出的6名成员加上由最终用户TAB选出的1名成员）应使用提名程序提名并选举2名TOC成员。
|
||
- 提名者需要提供最多一页纸的介绍，其中包括被提名者的姓名，联系信息和支持性陈述，确定了在CNCF领域提名的经验。
|
||
- 理事会、最终用户TAB和TOC应确定提名、投票和关于TOC选举提名和选举过程的任何其他细节的时间表和日期。
|
||
- 评估期间最少保留14个日历日，TOC 提名者可以联系和/或评估候选人。
|
||
3. 选举：评估期结束后，理事会、最终用户标签和最初的7位TOC成员应分别对每位被候选人进行表决。有效投票需要满足会议法定人数所需的选票数量。每名被候选人均需要支持超过50％的投票人数，以确认被提名者符合资格标准。以多数票通过的候选人应为合格的 TOC 成员。
|
||
4. 如果合格的被提名者的人数等于或少于可选 TOC 席位的数量，则此被提名者应在提名期结束后获得批准。如果有更多的合格被候选人比理事会，最终用户TAB或TOC可选的开放TOC席位多，那么该组应通过Condorcet投票选出TOC成员。Condorcet投票应通过康奈尔在线服务（http://civs.cs.cornell.edu/）使用Condorcet-IRV方法运行。
|
||
5. 如果理事会，最终用户TAB或TOC可供选举的公开TOC席位的合格被候选人数较少，该小组将启动另一轮提名，每名成员或个人有资格提名至多提名1名候选人。
|
||
|
||
### f) 约束条件
|
||
|
||
1. TOC 的成员任期为两年，来自理事会选举的最初六名当选TOC成员的任期为3年。由最终用户TAB和TOC选出的TOC成员的初始任期为2年。
|
||
2. TOC成员可能会被其他TOC成员的三分之二投票撤除，受影响的个人不能参加投票。
|
||
3. 任何TOC成员连续3次连续会议都将被自动暂停投票资格，直至连续参加两次会议。为避免疑义，暂停的TOC成员有资格在连续第二次会议中投票。
|
||
4. TOC章程、模式、方法、组成等可以由整个理事会的三分之二票通过修改。
|
||
5. TOC议程将由TOC制定。但是，预计最初的TOC讨论和决定将包括：
|
||
- 评估包含在CNCF中的技术
|
||
- 确定新技术纳入CNCF的接受标准
|
||
- 定义批准作为标准API的贡献技术的流程
|
||
- 找出需要进一步调查的直接差距
|
||
|
||
## 7. 最终用户社区
|
||
|
||
a) CNCF的最终用户成员有权协调和推动CNCF用户作为CNCF设计的消费者的重要活动。任何作为最终用户的成员或非成员，每个“最终用户参与者”均可被邀请参加。最终用户参与者将帮助向技术咨询委员会和CNCF社区就与用户有关的主题提供意见。
|
||
|
||
b) 最终用户技术咨询委员会是由最终用户社区成员选举所产生。
|
||
|
||
c) 最终用户社区成员将获得CNCF执行董事的批准，或者 CNCF 执行董事缺席的话，则由 Linux 基金会执行董事来批准。
|
||
|
||
## 8. 最终用户技术咨询委员会（“最终用户 TAB”）
|
||
|
||
a) 构成：最终用户TAB应由来自最终用户参与者的7名代表加上TOC的1名成员组成，以便于从最终用户TAB到TOC的晋级。
|
||
|
||
b) 选举：为了鼓励最终用户参与CNCF，前7名最终用户会员可以委任1名代表参加初始最终用户TAB，并将CNCF董事分配给任何最终用户参与者的任何剩余席位。在第一年之后，所有最终用户参与者可以提名1名代表并且最终用户社区应该投票选择使用当前最终用户 TAB 批准流程的最终用户TAB成员。
|
||
|
||
c) 经过三分之二投票通过后最终用户 TAB 可以更改最终用户社区的大小，前提是至少有7名可能的代表。
|
||
|
||
d) 最终用户代表应当基于业务和技术敏锐度提名。候选人应该具备建设和运营体现CNCF原则的基础设施和应用方面的重要实践经验。
|
||
|
||
e) 最终用户 TAB 将讨论和推进主题，重点是找出TOC和CNCF开发者社区的差距并提出优先事项。
|
||
|
||
f) 也会侧重于主动推进最终用户关心的话题，促进CNCF的市场采用，为最终用户举办会议或向理事会提供咨询。
|
||
|
||
g) 如果最终用户 TAB 有意愿的话，它可以批准小组委员会特别兴趣小组 （“SIG”）来解决行业或专业话题。
|
||
|
||
h) 最终用户 TAB 是技术监督委员会的主要输入方，应与技术监督委员会的其他输入方和反馈一起作出决策和计划。这些建议只是建议性的，在任何时候，最终用户TAB的建议都不能用于命令或指导任何TOC或项目参与者采取任何行动或结果。
|
||
|
||
i) 为促进与TOC的双边互动，最终用户技术咨询委员会应选出1名TOC代表。最终用户 TAB 可邀请任何人参加最终用户会议、SIG或其他讨论。
|
||
|
||
## 9. CNCF项目
|
||
|
||
通常情况下，是由CNCF的成员公司、开源社区的成员将项目先是带到CNCF 的技术监督委员会来进行讨论，然后决定是否被CNCF接纳。要贡献给CNCF的项目必须是经过技术监督委员会制定的标准的，之后当然还要经过理事会的批准。CNCF 的目标是希望捐赠给CNCF的项目和CNCF已有的项目在一定程度上是有关联的，而且是可集成的。
|
||
|
||
和CNCF 关联起来有以下三种方法：
|
||
|
||
1. 已经在CNCF的纳管之下，毕竟CNCF是中立的，致力于成为大家的协作的归属地。
|
||
|
||
a) 项目的方方面面都交由CNCF来打理
|
||
|
||
b) 项目是由CNCF 来进行市场推广的
|
||
|
||
c) 项目是解决云原生计算问题的核心组件，如Kubernetes、Mesos、etcd等等
|
||
|
||
2. 通过API或规范与CNCF相关联XM
|
||
|
||
a) 包括CNCF可能提供或启用多个选项的组件
|
||
|
||
b) 该项目被称为CNCF集成的一个组成部分，而不是由CNCF主办的项目
|
||
|
||
c) 集成和合规性由API或规范定义
|
||
|
||
d) 项目或组件的开发是由上游社区所开发，而且保持一定的活跃度
|
||
|
||
3. CNCF 使用到的
|
||
|
||
a) 项目或组件完全根据OSI批准的开源许可证进行授权，并且管理良好，并在CNCF中被用作组件。
|
||
|
||
b) 项目并没有由CNCF 来进行市场推广
|
||
|
||
c) 项目或组件的开发是由上游社区所开发，而且保持一定的活跃度
|
||
|
||
现有的开源项目应该继续保持其现有的技术治理结构，以保持凝聚力和速度。但是由技术监督委员会批准之后，则会适当的进行一些适应。
|
||
|
||
应根据个人的水平和贡献期限在项目间建立一个达到提交者地位的标准协议。因为提交者是维护者的选拔人才池，有了一定程度的贡献，且经过同行们的认可，提交者就可晋升为维护者。
|
||
|
||
CNCF启动的新开源项目应完成TOC采纳的项目建议模板，并由TOC批准纳入CNCF。TOC成员应有充足的时间讨论和审查新的项目建议书。新的项目建议书应包括项目中的角色细节，为项目提出的治理，并确定与CNCF的角色和价值观保持一致。
|
||
|
||
## 10. 市场委员会
|
||
|
||
a) 构成，市场委员会将向所有成员开放参与，应选举市场委员会主席制定会议议程，进行一般的讨论，并帮助委员会实现其目标。市场委员会应尽可能寻求共识。在市场委员会中无法达成共识的任何问题应提交给理事会。
|
||
|
||
b) 职责，市场委员会代表理事会负责设计，开发和执行相关的市场工作。
|
||
|
||
c) 如果市场委员会变得太大而无法有效运作，市场委员会可以选择选举市场董事，并将决策权委托给市场董事。
|
||
|
||
## 11. 知识产权政策
|
||
|
||
a) 任何加入到CNCF的项目都必须将其拥有的商标和徽标资产转让给Linux基金会的所有权。
|
||
|
||
b) 每个项目应确定是否需要使用经批准的CNCF CLA。对于选择使用CLA的项目，所有代码贡献者将承担Apache贡献者许可协议中规定的义务，只有在必要时才作出修改，以确定CNCF是捐赠的接受者，并且应由理事会批准。请参阅 <https://github.com/cncf/cla> 上提供的CNCF参与者许可协议。
|
||
|
||
c) 所有向CNCF提交的新入站代码应当（i）附有开发者原始证书签名（<http://developercertificate.org>和（ii）根据Apache许可证2.0版（可从<http://developercertificate.org>和<http://www.apache.org/licenses/LICENSE-2.0> 获得）该许可证除了并且不得取代根据上文（b）规定的供款许可协议所承担的义务。
|
||
|
||
d) 所有出站代码将在Apache许可证2.0版下提供。
|
||
|
||
e) 所有评估纳入CNCF的项目都必须获得OSI批准的开源许可证的完全许可，如果CNCF中包含的项目的许可证不是Apache许可证2.0版，则需要获得理事会的批准。
|
||
|
||
f) 所有文档将由CNCF根据知识共享署名4.0国际许可证来提供。
|
||
|
||
g) 如果需要替代入站或出站许可证以符合杠杆式开放源代码项目的许可证或为实现CNCF的使命而需要其他许可证，理事会可以批准使用替代许可证 对于例外情况下的接受或提供的项目捐赠。
|
||
|
||
## 12. 反托拉斯指南
|
||
|
||
a) 所有成员均应遵守<http://www.linuxfoundation.org/antitrust-policy>上提供的Linux基金会反托拉斯政策中规定的Linux基金会的要求。
|
||
|
||
b) 所有成员都应鼓励任何能够满足成员要求的组织的公开参与，而不论其竞争利益如何。换言之，理事会不应根据除用于所有成员的标准，要求或原因之外的任何标准，要求或理由寻求排除成员。
|
||
|
||
## 13. 行为准则
|
||
|
||
所有参与者都须同意遵守 [Linux基金会行为准则](http://events.linuxfoundation.org/code-of-conduct)。 TSC可以投票通过自己的CNCF行为准则。
|
||
|
||
## 14. 关联公司
|
||
|
||
a) 定义：
|
||
|
||
1. “子公司”是指会员直接或间接拥有所涉实体超过百分之五十有投票权的证券或会员权益的任何实体；
|
||
2. “关联公司”是指任何控制或由成员控制的实体，或者与成员一起受第三方共同控制的实体，在所有情况下，直接或间接拥有多于所有权的控制权；
|
||
3. “关联公司”是指各成员的关联公司。
|
||
|
||
b) 只有执行了参与协议的法人实体及其子公司才有权享有该会员的权利和特权；但条件是该成员及其子公司应作为单一成员共同对待。
|
||
|
||
c) 只有一名属于一组关联公司的成员有权一次性任命或提名理事会代表参加类别选举。
|
||
|
||
d) 如果会员本身是会员或赞助商的基金会，联盟，开源项目，会员组织，用户组或其他实体，那么授予该成员的权利和特权只能扩展到该成员的员工代表，而不能扩展到其成员或发起人，除非理事会不时在特定情况下另行批准。
|
||
|
||
e) 会员资格不得转让，不可转让、也不能转让，除非现有会员将其现有的会员利益和义务转让给其大部分业务和/或资产的继任者，无论是通过合并，出售还是其他方式；只要受让人同意遵守 CNCF 的章程以及Linux Foundation成员所需的章程和政策。
|
||
|
||
## 15. 预算
|
||
|
||
a) 理事会应批准年度预算，绝不会承诺超出筹集的资金。预算应与Linux基金会的非营利性使命相一致。
|
||
|
||
b) Linux基金会应定期报告预算支出。
|
||
|
||
## 16. 常规和管理费用
|
||
|
||
a) Linux基金会应保管任何费用，资金和其他现金收据。
|
||
|
||
b) 一般和行政（G＆A）费用将用于筹集资金以支付财务、会计和运营费用。 G＆A费用应等于CNCF首期总收入1,000,000美元的9％以及CNCF总收入超过1,000,000美元的6％。
|
||
|
||
## 17. 一般规则和操作
|
||
|
||
参与CNCF 应做到：
|
||
|
||
a) 展示与开源项目开发人员社区进行协调的计划和方法，包括关于代表社区的品牌、徽标和其它标志性的主题；
|
||
|
||
b) 以专业的方式体现维持社区的凝聚力为目标，同时还要保持Linux基金会在开放源代码软件社区的善意和尊重；
|
||
|
||
c) 尊重所有商标所有人的权利，包括任何品牌和使用准则；
|
||
|
||
d) 参与Linux基金会的所有新闻和分析师关系活动；
|
||
|
||
e) 根据要求，向Linux基金会提供关于项目参与的信息，包括参加项目赞助活动的信息；
|
||
|
||
f) 直接参与到基金会旗下的任何站点。
|
||
|
||
g) 根据理事会批准的规则和程序进行运营，前提是这些规则和程序不得与Linux基金会的宗旨和政策不一致，并且不得损害Linux基金会。
|
||
|
||
## 18. 修正案
|
||
|
||
本章程可以通过所有理事会成员的三分之二票数（不包括弃权）进行修改，前提是任何此类修改不得与Linux基金会的目的或政策不一致，并且不得对Linux基金会产生不利影响。
|
||
|
||
## 时间表A：提出CNCF范围愿景
|
||
|
||
CNCF背后的首要目标是支持和加速“云原生计算”的采用。以下内容是初步范围，旨在阐明CNCF将努力实施的“云原生计算”的核心概念。该初始范围应成为发布在CNCF网站上的文档。
|
||
|
||
CNCF社区坚信云原生计算包含三个核心属性：
|
||
|
||
- 容器化包装和分发
|
||
- 动态调度
|
||
- 面向微服务
|
||
|
||
**注**：关于云原生的定义正在重新设定中，已经与上述不同了。
|
||
|
||
云原生计算系统支持基于这些核心属性的计算，并包含以下理想：
|
||
|
||
- 开放性和可扩展性
|
||
- 在标准化子系统的边界处定义良好的API
|
||
- 应用程序生命周期管理的最小障碍
|
||
|
||
|
||
|
||
因为上述时间表已经有些过时了，CNCF成立已经有三年时间了，正在规划新的方案。
|
||
|
||
## 参考
|
||
|
||
- [CNCF 是如何工作的](http://www.ocselected.org/posts/foundation_introduce/how_cncf_works/)
|
||
- https://www.cncf.io/about/charter/ |