使用 OpenShift Origin 降低开源贡献的门槛

图片来源：

Opensource.com

上周，GitHub 上的 OpenShift Origin 存储库看到了一些来自外部贡献者的重大代码合并，这些合并为 OpenShift Origin 平台添加了 MSFT .Net 功能。数千行新代码经过测试并成功合并到 OpenShift Origin 代码库中，然后立即提供给任何人下载和部署。

.Net 代码库的合并展示了 OpenShift Origin 社区如何成功利用 GitHub 的社交编码服务来帮助建立敏捷和开放的开发流程。在 Origin 的文档部分中，提供了一个优秀的贡献者入门技术指南。

除了使 OpenShift 在技术上易于构建、开发和测试之外，Origin 的开放社区文化也使高效协作变得容易。这种文化是从 Red Hat 的一些历史协作实践演变而来的，这些实践使社区具有非常高效的生产力，并使其更具敏捷性。

保持冷静并合并在 Red Hat，我们认为，为了开源项目的未来发展和采用，拥有厂商中立的任人唯贤的流程以及适当的知识产权管理至关重要。这就是为什么我们选择了 Apache V2.0 许可证 - 以及为什么我们选择不要求贡献者许可协议 (CLA) 或建立基金会。这些选择通常会引起一些疑问，因此我想在本周的博文中在 Red Hat 的法律顾问 Richard Fontana 的帮助下解决这些问题。

开放协作

当加入一个开放社区时，您的第一个入口点是通过技术基础设施。在 OpenShift Origin 的案例中，该入口点是 GitHub。

对于开源项目，基础设施的选择对项目本身的文化具有巨大影响。像 GitHub 这样的工具不仅通过为我们提供版本控制、源代码管理、问题跟踪和社交协作机制来帮助我们构建项目 - 而且 GitHub 还使社区能够以开放和透明的方式贡献和协作。

贡献形式多样

OpenShift Origin 项目的递归和开放性质在项目基础设施的许多层面上都可见，因为贡献形式多样。通过对 origin-server 核心项目的贡献，添加了对基于 dotNet 环境的支持。但是，许多贡献以社区快速入门和 cartridge 的形式出现。通过 Bugzilla 提交错误报告、通过 Trello 协作进行功能跟踪以及加入 StackOverFlow 论坛的讨论也是贡献的好方法。这些贡献的公共性质正是项目本身的生命力所在。

Chris Kelly 在他的书《Two Bits: The Cultural Significance of Free Software》中谈到了“递归公众”，即围绕构建、修改和维护赋予其生命的基础设施的能力而组织的公众。

正如 Kelly 所说

“递归公众是一个公众，它非常关注作为公众而存在的物质和实践维护以及技术、法律、实践和概念手段的修改；它是一个独立于其他形式的构成权力的集体，并且有能力通过生产实际存在的替代方案来对现有权力形式说话。” - 《Two Bits: The Cultural Significance of Free Software》

OpenShift Origin 社区是一个基于功绩的权力模型。它非常像一个“递归公众”，驱动社区努力的方向，设定包容性的基调，并确保开放和透明的流程。权力掌握在那些做出贡献的公众成员手中。一些贡献者是受雇主支付报酬这样做的，但他们塑造项目的权力是基于功绩，而不是任何付费模式。

开放许可

每当有大量代码合并到项目中时，通常会询问关于贡献许可的问题。从历史上看，Red Hat 起源于 Linux 运动，并且在文化上与 GPL 开源许可模式紧密相连，尽管总是存在例外。在过去的几年中，许多重要的 Red Hat 项目（oVirt、OpenShift Origin 和 JBoss 的关键部分）都已在 Apache 许可证下发布 - 这比 GPL（总体而言）更宽松，从而减少了我们贡献者社区的抵制。

这有很多原因，但可能最重要的是信任问题。如果我们被视为放弃更多控制权，那么围绕一个从 Red Hat 代码开始的项目建立一个成功的社区的机会就更大。这与 CLA 问题有关，因为 CLA 是控制和施加不对称性的机制。当公司发布开源代码时，Apache License 2.0 非常擅长向社区发出“信任我们”的信号。fork 一个 Apache 许可证项目很容易，即使是竞争对手，对代码如何商业化也没有太多限制。参与是安全的。

降低参与门槛

Red Hat 发起的开源项目比任何其他公司都多，而且其中绝大多数从未使用过任何形式的 CLA 或版权转让。大多数例外是收购产生的项目（例如，Cygwin 或各种 JBoss 项目），尽管即使是收购产生的项目，我们最近的趋势也是消除任何现有的版权转让或 CLA 的使用 - GlusterFS 就是一个例子。CLA 在 Red Hat 通常不使用的原因与传统和文化有关 - Red Hat 是开源社区文化的真实产物，典型的开源项目不使用 CLA，而且实际上在开源社区中，由于上述所有原因，CLA 和版权转让多年来一直是备受争议的政治问题。

对于 Apache License 2.0 项目，不需要 CLA 还有一个特殊的附加原因：Apache License 2.0 实际上包含一个明确的许可证条件，该条件实际上规定，提交给上游项目的补丁默认情况下应根据贡献者接收项目代码时所依据的相同条款获得许可 - 即 Apache License 2.0。即使忽略上面提出的所有其他要点，如果曾经有哪种许可证不需要 CLA，那就是 Apache 许可证。

当我们启动 OpenShift Origin 时，我们决定不使用 CLA，原因与上面讨论的内容有关。CLA 不是必需的，只会限制我们围绕 OpenShift Origin 构建协作和信任社区的努力。

为什么基金会、行业协会和其他围墙花园仍然紧抓 CLA 不放

一些开源项目组织正在慢慢接受社交编码，但仍然紧抓不对称 CLA 等参与障碍不放。使用此类 CLA 的原因并不总是很清楚。一些公司使用条款故意不公平或繁重的 CLA，因为实际上渴望阻止基于功绩的“外部”参与。

此类公司希望他们的项目看起来像社区项目，而实际上是围墙花园。在其他情况下，似乎有人认为 CLA 对于某些从未真正得到很好解释的法律原因来说是必要的。我们甚至见过一个特殊的案例，一个项目显然认为其积累的 CLA（特别是如果由“大市值”公司签署）在某种程度上证明了其生态系统的健康状况。

然而，CLA 的大多数用途的共同点是不对称性和为贡献者施加繁文缛节。CLA 通常使一家公司或组织享有特权，并为那些寻求参与和贡献的人制造法律障碍。

关于贡献者保护的错误观念

我们有时会遇到错误的观念，即 CLA 在某种程度上是保护贡献者和用户免受 IP 问题侵害所必需的。现实情况是，典型的 CLA 根本无法保护贡献者。相反，它们要求贡献者承担超出开源许可证本身要求的法律义务，因此如果有什么的话，那就是增加了他们参与开源项目的风险。这是此类 CLA（以及类似的版权转让制度）成为社区贡献障碍的原因之一。CLA 也不能保护用户，至少不比项目的出站开源许可证更能保护用户。下游用户不能调用 CLA 来防止某种 IP 风险。用户需要代码是开源的，并具有所有隐含的法律权利，但这正是开源许可证提供的。

CLA 的唯一真正受益者是将其作为贡献要求的公司或基金会。即使在那里，好处也更多的是虚幻而非真实，相对于项目承担的成本而言，几乎肯定是很小的，因为采用 CLA 会使其他人更难做出贡献，或者使贡献更难根据其技术价值得到对待。

在像 OpenShift Origin 这样在 Apache License 2.0 下获得许可的项目的情况下，这可能最容易理解。Apache 许可证为贡献者提供了非常慷慨的版权许可，并且贡献者也明确授予了专利许可。这些权利授予所有人。许多 Apache License 2.0 项目也使用 CLA，但从贡献者的角度来看，这些 CLA 无一例外都是更具限制性的法律义务，这些义务是为了一个组织的利益而不是为了社区的利益。与 Apache 许可证不同，Apache 许可证与所有开源许可证一样，无需额外的法律手续或文书工作即可操作，而 CLA 通常像传统合同一样构建，需要某种形式的正式同意和官僚程序。

在 Red Hat，我们不觉得需要对我们赞助的项目进行如此严格的控制。套用 Chris Kelly 的话 - “项目的技术、法律、实践和概念手段的物质和实践维护和修改掌握在非常公开的提交过程手中”

例如，不需要 CLA 即可为用户提供他们期望从 Apache License 2.0 项目中获得的权利。这些权利来自 Apache 许可证本身，由项目的各个贡献者直接授予。对于 OpenShift Origin，这些权利在经过身份验证的 github 用户提交 github pull request 时授予。否则，就意味着绝大多数开源软件，包括一些最广泛使用的代码库，都包含致命的法律缺陷，因为大多数代码都源于不使用 CLA 或版权转让的项目。这种观点是不负责任的，但也被以下事实驳斥：这些相同的开源项目构成了充满活力的社区和商业生态系统的基础。

避免付费参与的行业协会开源基金会路线

一些开源项目选择走基金会路线。随着主要项目计划从公司中脱颖而出，我们已经看到许多案例，其中成立了行业协会基金会，以便将公司资源用于他们的项目并推广更付费参与的动力模式。这种基于基金会的方法将第一个入口点转移到“先加入基金会”模式，然后您才能真正开始参与项目。这通常需要“付费参与”模式才能在谈判桌上获得一席之地。大多数此类基金会也对项目贡献者施加 CLA 要求可能只是巧合，但付费参与模式代表了一个障碍，如果有什么的话，这个障碍远比要求开发人员签署不必要的或重复的许可协议更重要

现实情况是，公司补贴并不构成真正开源的那种集体独立驱动的项目。付费参与的行业协会开源基金会模式实际上是仿照老式的标准联盟，这些联盟实际上早于开源开发的兴起，而开源开发代表了一种更敏捷、透明和更平等的开发技术方式。在某些方面，开源可以被视为取代标准开发。

结论

在 OpenShift Origin 中，我们不计算 CLA 签署者的市值，而是通过对代码库的实际贡献来衡量参与度。这种方法使我们在 GitHub 上按合并的 pull request 数量排名时，跻身前五大社区项目之列。我们的开放、社交协作基础设施模式、我们采用 Apache V2.0 许可证以及我们明智地不要求 CLA（或向基金会捐赠大量资金）才能做出贡献的结合，使我们成为最成功的可用开源 PaaS。