开源软件基金会的崛起与演化

基金会黄金时代的道理，不止于国内的有识之士看到了这点，欧美地区的很多人也在虎视眈眈这块肥肉，中国政府对于非营利性的组织把关非常严格，相反欧美要宽松了很多，那么他们的成功率又如何了呢？我们不妨了解一个想的挺美，结果很差的例子。

Mon Mar 2, 2020 | 10500 Words | 大约需要阅读 21 分钟 | 作者： Stephen Walli 和 Paula Hunter | 译者： 开源之道

开源之道引言

本文翻译之一篇基于CC-By协议的论文，该论文最初发表在《International Free and Open Source Software Law Review》Vol. 5, Issue 1 中，作者是 Paula Hunter 和Stephen Walli。

开源之道打算在2020年的3月份花一整个月的时间来整理关于开源软件基金会的资料，这篇算是开篇，外加前几年的累积，预计会在月底有一个较为宽广的视野，起码让人有路径可循，如果能够回答“开源基金会为什么会存在？能够帮助人们干什么？”这个问题，那就真是万幸了。

摘要

自由和开源软件（FOSS）项目共同体（Community）仍然保持着增长和爆发的上升姿态。当开源项目的增长达到某个临界点的时候，就会有一些企业意图想要参与，而企业有大量的软件知识产权相关的内容需要管理，然而，这些却不是项目本身所擅长的。那么中立的、非营利性质的 FOSS 基金会就是提供这些问题的解决方案的，通过提供知识产权的管理、以及业务和技术方面的服务，进一步帮助项目和共同体的成长。本文重点回顾了中立、非营利性的组织是如何发展的，以及它为何能够满足自由/开源软件共同体、以及企业不断变化的法律、商业和技术需求。

引子

伴随着开放源代码软件的增长，以及全球开发者的积极参与，当然，这些都得益于日益廉价和普及的互联网访问，渐渐形成了一个巨大的基于协作的共同体，软件开发者和IT 专业人员在整个软件的生命周期都可以相互协作。随着软件知识产权(IP)实践的成熟，自由和开源软件(FOSS)共同体也逐渐的完善了自我保护。

FOSS 许可证经过了30多年的发展和演化，已经从最初的完全的学术性即“随你所愿”，继而到从总体软件格局的自由软件的萌芽，以及现在更为复杂的确保软件自由的方法。举例来说，随着美国法律承认软件专利及其带来的风险，FOSS许可也引入了专利相关的条款。伴随着商业公司对开发和使用基于FOSS许可下的自由/开源软件的重度依赖，FOSS的许可证则重新启用了一些传统的许可证结构和语言。这其中这个逐渐成熟的演变过程中，起着关键角色的就是开源非营利基金会的对于软件知识产权管理机制、以及在其中的沟通、斡旋、协作的作用。

许多由志愿者所带领的、基于共同体而开发的自由/开源软件许可项目，在其技术发展和演变过程中达到了企业也希望参与其中的程度。而商业公司在知识产权管理、种源跟踪和治理方面有非常不同的需求，因为它们关心的是管理其专利组合的风险，并希望尽可能减少潜在的诉讼。自由/开源软件基金会则恰好满足了这样的需求，其实一些关键的自由/开源软件项目已经做到了。

Apache 软件基金会（下称 ASF），围绕 Apache httpd 软件项目，于1999年建立，隶属于美国的慈善组织，而后发展壮大，尤其是 Apache 许可证 2.0 是相当的成功。这也是当年 IBM 倾其全力而参与到 Apache Httpd 的直接原因，而且还将该项目纳入其旗舰产品：WebSphere。同样，开源发展实验室（OSDL）是为了支持Linux而在2000成立，作为一个非营利性的行业协会，该协会致力于更好地管理知识产权风险，从而让Linux 心无旁骛的发展，Linux操作系统成为了许多传统上竞争UNIX系统领域的供应商的产品线的基石，OSDL 作为非盈利组织后来与自由标准组织进行了合并，自由标准组织是一个负责制定 Linux 编程接口的非盈利贸易组织，合并之后就是现在如日中天的——Linux 基金会。Eclipse基金会是在2004年围绕Eclipse IDE项目成立的，它一直是严格的Eclipse软件知识产权管理过程和自由/开源软件许可演进的守护者。

尽管每个基金会都有不同的价值观和主张，也有着完全不同的发展路线，而且都有自己忠实的拥泵。但是他们之间还是有共同点的，那就是：提供知识产权管理、委托补偿的治理结构、以及共同体和协作的支持机制。

Outercurve Foundation 是最近（在本文翻译的过程中，2020年3月，该基金会已经死亡。——译者注）建立的，它采用了这个定义良好的模型，并将其应用到自由/开源软件项目中，以这样一种方式，让开源项目从这种非盈利的自由/开源软件基金会中受益，而不用承担建立自己基金会的费用和风险。Outercurve Foundation提供与自由/开源软件基金会相关的知识产权管理和商业运作，亦是一个非盈利的行业协会。它与技术、项目孵化和自由/开源软件许可证无关的 (只要许可证得到了开源项目的批准)。

公益还是会员制？

多个重要的开源软件基金会最初都是在美国本土创建的(如 ASF 和Linux基金会），自由/开源软件基金会的一个早期决定是将自己建立为一个非盈利的贸易协会(美国税法第501©第6条)还是一个公益的非盈利慈善组织(美国税法第501©第3条)。自由/开源软件社区上述两类非营利组织之间的微妙区别还是颇为在意的。

在评价这些备选方案时，经常讨论两个主要因素:所涉经费问题和组织控制方面，谁是最终的受益者？许多自由/开源软件项目，如ASF或自由软件基金会，都在寻找一种方法，在鼓励向实体捐款的同时，将个人开发人员与组织的财务是相分离的。慈善性质的基金会，是可以接受资金捐助的，而且所接受的资金是可获减免税的，关于资金的用户，可以用来支付基金会在运营方面的基础设施费用，而且在某些情况下，还可以用于特定的项目开发。在很多情况下，一个健壮的治理结构是随着项目的成长而演化的，（例如 ASF), 因此采用一个很正式的慈善组织来管理项目的整个生命周期是合情合理的，至于”公益“的概念，它也是与自由/开源软件共同体的哲学思想相辅相成的，因此，其实选择慈善组织不是那么的简单，如仅仅只是找一个记账的单位罢了。

通常是由众多的供应商（如，软件公司）合力来指定组织，如果他们要参与到项目中来、或者资助项目、或者参与组织的架构，不过都是为了控制权的平衡。虽然这里的主要区别是，基金会的成员是基金会运作之下的受益者，但在大多数情况下，更为广泛的共同体参与贡献并享受劳动成果。Linux项目是自由/开源软件项目的一个很好的例子，它通过一个基金会从大量的供应商投资中获益。Linux基金会(美国税法下的一个贸易组织)通过其成员计划和成员章程来平衡其成员在一个非常大的共同体中的需要和利益。在大多数情况下，对税收的影响不是主要因素;治理结构和知识产权管理更为重要。

基金会的价值

其实无关乎自由/开源软件基金会的具体性质，贸易组织也好，慈善组织也罢，他们的价值主要是体现在以下三个方面：

  1. 为参与者提供了一个软件知识产权管理的法律框架，在这个框架中，商业公司可以和自由/开源软件项目的贡献者和谐的在一起工作。
  2. 还提供一些技术服务，如软件仓库、问题跟踪、代码签署证书、以及技术指导等。
  3. 提供日常的运营和治理支持，如财务和现金服务、会员管理以及项目的沟通和公关相关。

法律框架和知识产权管理

所有权中立

对于非营利性的自由/开源软件基金会来说，企业参与到基金会来主要的益处，就是由于基金会对于软件知识产权的管理和拥有所有权，让项目成为了一个中立的地方，是企业之间的协作成为了可能。没有哪家公司愿意参与到其他公司（可能是友商或合作伙伴）持有的 FOSS 项目。企业也会担心自己的钱打了水漂，或者是为友商做嫁衣裳，这些都是难以让商业公司接受的。那么作为中立的基金会在此所起的作用就非常的大了，因为中立的机构拥有所有权，并允许所有公司平等参与，没有哪家公司称拥有项目，因此，无论公司彼此之间是竞争还是合作伙伴，都可以从项目中获得最大的回报，还毋须担心将优势拱手想让给对手。

基金会拥有开源项目的知识产权，而且对该软件没有任何商业利益，即基金会不出售基于该软件的产品或服务。软件的版权则由贡献者通过会员协议、转让或许可协议（有时是项目开源许可本身）等各种方式分配或授权给基金会。专利也通常会给到基金会，这样的话，让基金会的中立性成为了现实，为个人、公司提供合作的场地，进而让贡献者共同体进一步获得扩展。同时，拥有良好的知识产权管理还能够提高项目的接受度和许可证的采用率，参与项目的任何一方，均希望自身的项目获得清晰的管理，事实上也是这样，目前而言，这个世界上所有最大、最活跃的 FOSS 项目，均是在基金会下托管的，对比而言，那些由单个公司所把控的相对还算活跃的开源项目，项目的规模上要小很多。

由单个公司运营的 FOSS 项目往往较小，可能是由于担心知识产权管理或所有权变更引发的后果所导致，让我们来看看，当某个 FOSS项目是由一家公司所控制时，如果公司改变方向或被收购，它的知识产权会发生什么？以 MySQL 为例，这是 FOSS 历史上最为成功的项目之一，但是被 Sun公司和Oracle 收购之后的一系列变更，让其共同体成员备受折磨和困惑。MySQL 的知识产权是完全属于 MySQL AB 这家商业公司的，那也就意味着，现在 Oracle公司拥有MySQL 所有的知识产权，而且该公司也确实在从中受益。当然，在过去的几年中，人们对 MySQL 的兴趣日渐减少，有多个颇具实例的 FOSS 数据库项目出现在了市场之上。假如，这里只能假如，如果当年的 MySQL 将之捐赠给基金会，保持所有权上的中立，那么当初参与的贡献者也就不会像今天这样，觉得自己受到了伤害，甚至是被剥夺了的感觉。MySQL 共同体也不至于衰弱至此，完全和早些年的蒸蒸日上的活力不可同日而语。

责任与风险管理

基金会有的时候扮演的角色，可以说是企业的防火墙或防护盾牌，如果某个开源的所有权是某家公司，那么绝大多数公司是不愿意去进行协作、分享和发布的。让中立的第三方拥有版权、所有权可以降低责任风险。基金会作为法人实体，充当着保护盾，通常保护其成员免于承担合同，承诺和基金会本身可能的过失的责任。基金会（法律实体）还可以保护未参加特定活动的成员免受在特定情况下其他成员的行为（例如，将侵权软件引入基金会拥有的软件）。

所有自由/开源软件许可都不承担责任。有蛮多厂商使用自由/开源软件许可的项目来开发商业产品(例如，Red Hat Advanced Server 就是使用自由/开源软件许可下的 Linux 项目中的软件所开发的商业产品)。供应商愿意与已经为产品付款并在其产品许可中嵌入责任条款的客户进行产品性能责任讨论。然而，许多供应商仍然认为自由/开源软件许可的项目有义务承担风险。将自由/开源软件授权项目的版权所有转让给非营利的基金会，就是一个明确的“非版权所有”信息。供应商仍然可以通过参与项目治理和支持项目的主要开发人员和提交者来把控项目的走向，但是有一点非常的明确，他们已经减少了责任风险，因为他们不拥有项目的软件版权。基金会在这里的作用就是从原来的所有者转移可能的诉讼。

此外，将项目托管到合法注册的基金会，或者进行赞助，还可以为公司带来某些潜在的利益，因为中立，所以让人们知道，这些软件项目的法律问题和运作，是和成员、贡献者和提交者们经过了非常仔细的审查和讨论了的。

除了充当成员和贡献者的法律盾牌之外，基金会还可以通过补偿自由/开源软件项目的参与者这样一个实际的行动，进而达到来保护独立参与者。当然了，补偿的形式是多种多样的。

自由/开源软件项目提交者是项目的主要开发人员，他们拥有对软件仓库的拥有完全的写权限，也就是说，他们处于“提交”软件变更的位置。这些提交者的身份，有可能是一名独立的软件开发者，也有可能是某些厂商的雇员。基金会可以对这些提交者起到非常好的保护作用，当然了，具体情况还要基金会本身的治理和组织架构，基于这样一种情况，不管自由/开源软件许可中嵌入了什么责任条款，个人提交者都不需要对软件承担个人责任。Outercurve Foundation 和 ASF 都是这么做的。

基金会通常会在其治理政策中明确保障其董事和成员的利益。 ASF 、Eclipse 基金会、Outercurve 基金会都是这么做的。

代码来源

基金会一般还提供治理流程用来跟踪代码出处。有各式各样的法律意见和实践都讨论过关于软件的版权归属权问题，有的认为是应该交给基金会，有的认为应该属于软件项目的协作共同体，有的认为两者都不能拥有。当然，还有的认为应该将所有的权限赋予 copyleft (比如，自由软件基金会)，有的认为 copyright 就足够好了（比如 ASF），还有一些认为所有必要的权利都应体现在开源许可证以及和成员签订的协议当中(例如Eclipse Foundation)。

上述所有的立场和实践都是有足够的理由的，也是可以站得住脚的，拥有所有的 CopyRight 可以让独自所有者直接处理涉及软件的任何诉讼。而且独自所有者还能够随时更改软件的许可条款。这也是正式许多开发者所担心的：”为她人做嫁衣裳“的状态，如果他们为一个是属于某单个实体所拥有的 FOSS 项目做贡献，而版权是不是也要同样属于该家实体单位？如果是的话，那么这家实体单位确实是赢得贡献者们的信任了，当然，如果版权是属于中立的基金会的话，那么开发者们完全就没有这样的顾虑。

与上述情况相反的情况则是这样的，所有的内容均是由许可证决定的，而且由许可的共同体拥有软件，—— 这样的话，诸如变更条款之类的事情就变的非常的复杂，但这样的情况，仍然拥有大量的拥泵，他们认为这是对共同体和共同体价值观的重新落实。

当我们去有意识的去比较上述所有权归属情况的时候，如归属中立的、非营利性的基金会还是营利性的商业公司，可以非常容易的开发人员共同体内的贡献分配和许可协议实践的可接受性。开发人员所担心的是，如果企业选择在背后操纵随时关闭项目（毕竟拥有所有权），或者是为了企业利益而重新更改条款，那么 FOSS 软件的贡献分配就面临很大的风险，MySQL 依然最为鲜明的例子，MySQL AB 这家公司将所有权转让给了另一家营利性质的公司，通过向GPL许可软件出售封闭许可获得了相当大比例的利润。在Sun Microsystems和甲骨文(Oracle Corp.)随后进行的两笔收购中，这种纯营利性的所有权问题引起了广泛关注。最终的结局就是另外有新的 fork 出现，当然是以全新的自由软件许可来进行的，目的就是完全取代MySQL。如果当时是交给基金会的话，法律中立的组织就不可能出现这样的情况。

另外需要特别注意的是，不管法律上的结构是怎样的，在软件开发实践当中，跟踪贡献的流程亦是非常重要和必要的，这也是代码跟踪的重要部分。在技术手段上：版本控制系统、问题跟踪系统、邮件归档、贡献者的分配、许可协议等等都是要跟踪的对象。所有的基金会在这方面做的都非常的到位。

在任何分配和贡献许可实践的方法中，能够拥有良好的知识产权管理，清晰的来源跟踪，都是其它组织的 FOSS 项目愿意采用的，而且对于用户社区和贡献者增长都是积极有益的。

自由/开源软件项目的许可和许可管理

FOSS 项目所采用的许可证通常被视为不仅仅是软件许可的法律协议。通常许可证还定义了项目共同体关于他们希望如何合作和共享工作成果的价值观。一个项目的共同体是否相信所有的参与者和贡献者都必须在相同的许可下对贡献和派生进行许可，这与早期共同体对软件本身的选择有密切的关系。共同体如何看待专利问题，是和软件已有的嵌入的许可有关联的，例如，BSD 之类的许可是没有这方面讨论的，而诸如 Apache 2.0、Eclipse 公共许可、GPLv3 ，无论是对于专利，以及相关的专利都有相当的涉及。

当然，我们也要动态的看待许可证，其本身也是在不断进化着的，基金会必须意识到这点。如 Apache 许可证，正如其当初从一个 Apache 的软件项目开始进化为一个非营利性的慈善基金会一样，当初的Apache 许可证 1.0 是类似于 BSD 宽松许证，后来经过修订，增加的尊重结构、引入专利等，逐步演变为现在Apache许可证2.0。同样，Eclipse 也有着相似的经历，随着 Eclipse 基金会治理的成熟，Eclipse 许可证也经历了一些演变，最初是由IBM 制定的 公共许可，然后是Eclipse 基金会拟的通用公共许可证（Common Public License），到现在的Eclipse 公共许可证。还有，GPL 的演化过程，也是和自由软件基金会密切相关的，多年以来，自由软件基金会对于自由软件的诠释都在不断的嬗变和演化，以 GPLv3 达到了其至高境界，它试图将软件自由的概念置于现代互联网、万维网的发展以及有关专利的明确条款的背景之下。

尽管 FOSS 许可证可以是围绕基金会本身为中心的，但这也并非是必须的。例如，Outercurve Foundation 就仅仅要求其管理下的项目使用开源促进中心(OSI)承认的 FOSS 许可证，Outercurve Foundation 不受特定项目的约束，因此可以自由地决定项目许可的选择。这么做是多方受益，皆大欢喜的，OSI 的使命是倡导、布道 FOSS 的诸多益处，Outercurve Foundation 的意愿是让更多的 FOSS 项目和共同体能够健康的成长，二者之间简直是完美搭配。

技术服务

工作坊和沟通通道

每一个成功的软件项目，可能许可证采用的五花八门，但是对于软件开发本身的一些支撑如：版本控制、配置管理、构建脚本、自动化测试、问题跟踪等这些都是必须项。有了这些工具，方能保证软件的交付，而且当下的这些工具均有相关的基于互联网的服务（SourceForge、Codeplex、Github）。由于这些是支持复杂协作开发的基本工具，一些自由/开源软件基金会也提供了这些工具，如 ASF 和Eclipse基金会就提供相应的基础设施。又比如 Linux 内核团队发展了如此多年，对于自身的开发流程构建已经拥有完善的基础架构，但是即便如此，仍然交给 Linux 基金会来保证。但是 Outercurve Foundation 就不提供这样的工具集，因为它无法确保加入的开源项目所采用的何种构建工具，当然还是要确保项目在项目提案审查期间是使用了常用的一些工具的。

（开放式）协作开发需要强有力的沟通通道，开发者邮件列表、IRC 频道、论坛、以及 Wiki 等等平台或工具都可以提供非常好的沟通通道，基金会当然也可以提供这些工具和平台。

指导和孵化

软件构建规程是项目文化的一部分。同样项目的决策、沟通方式也是必不可少的部分，能够拥有一个良好的软件开发实践文化对于项目的扩展非常重要，一个新的项目想要进入基金会，通常是处于需要增长的阶段，他们本身没有太多这方面的经验，所以基金会这时候起到的作用是帮助这些新的项目来进行运作和实践。

ASF 和 Eclipse 基金会都为新的项目设置了孵化的流程，新进来的项目会被安排有特定的导师，项目想要毕业成为基金会旗下的一份子，需要按照导师的安排来操办，一般需要严格的按照基金会的文化规范进行。相比而言，Outercurve 基金会并不是围绕着某个特定的自由/开源软件项目发展起来的，而是按照某种规定而逐步发展起来的，当然也会提供相应的导师，从而让开发者们一开始就熟悉其纪律来。

通用管理和日常运营

跨项目生命周期的支持

基金会除了能够支持知识产权管理的机制，还提供了一套业务运营服务，以满足在项目生命周期不同阶段对于管理项目的需求。就过去的开源项目实践来看，基于一个现成的项目所发展起来的基金会，对于软件管理有一套自己的实践，这对于开发者、用户以及软件的发行，都是非常重要的，当然共同体的扩张也非常关键。这些个软件管理实践在 ASF 中被称为Apache 之道，在Eclipse Foundation中也被称为 Eclipse 之道。每个基金会都有对原始项目的托管工具，如版本控制、代码仓库、以及问题跟踪。

尽管 ASF 和 Eclipse 基金会均是从一个独立的项目逐步发展起来的，其最佳实践扩展到了基金会下所有的项目，而Outercurve Foundation 作为新创立的机构，就直接挪用了他们现在的模式，可以支持所有符合 FOSS 许可协议的项目，希望通过基金会帮助项目进一步的扩展的更加受欢迎。当然，这些基金会中均制定了指导流程以支持新项目。不过 Outercurve Foundation 的做法和 前两者有些不同，在ASF或 Eclipse 基金会中，均有非常成熟的孵化流程，帮助新项目在开发、知识产权、共同体建设方面提供指导，并在一到两年的时间，将之与基金会所倡导的方式相匹配，而 Outercurve Foundation 则为项目直接安排导师，以确保项目领导者在满足其需求的开源社区协作和开发技术方面获得最佳知识。

不同的项目有不同的需求，具体取决于它们在生命周期中的位置以及项目参与者中已经获得的经验。一些项目，例如Outercurve Foundation 的 CoApp项目，在概念阶段就被纳入，还没有编写一行代码；还有一些较为成熟的项目，已经拥有一定的下载量和忠实用户了，如 Outercurve Foundation 所孵化的 Word 的化学支持插件。CoApp 和 Chemistry 插件有着完全不同的需求，可以说是整个软件生命周期：从知识产权管理、治理、运营、到市场支持、技术指导、再到协作开发等等，统统不一样，或者说不同的阶段。

上述两个项目采用了由 Outercurve Foundation 提供的完全两种不同的服务，根据项目实际的需要而灵活处理。

资金来源:会员、会费和捐款

自由/开源软件基金会作为一个组织，得以运转依赖于捐赠，或者是成员的会费，以及志愿者的劳动力，来完成大部分的工作，尽管其本身是一个非营利的组织。

ASF 是一个完全由志愿者驱动的最佳实践，ASF 从性质上讲是一家非营利的慈善组织，其可以接受捐赠，但是大部分的工作是由志愿者来完成的，所以其运营的成本是低到不能再低了。其所收到的捐赠主要是用于基础设施的日常开销中了。

当一家公司要参与到非营利的贸易组织当中时，他们其实相比于参与慈善组织，期望的内容是颇为不一样的。除了较为正式的业务和运营支持之外，非营利贸易组织的成员还希望基金会可以帮助推动项目和市场营销等，这些 staff 是颇为灵活的，有可能是基金会的全职员工、也有的是成员公司所调派过来的、又或者本来就是协会管理服务（AMS）的成员，Outercurve Foundation采用混合模型，有几个全职员工，同时利用AMC来提供财务、运营、管理和项目的管理工作。该模型允许基金会在其项目组合增长时保持敏捷和增长的空间，抛开人员配置模式不谈，由商业成员驱动的自由/开源软件贸易组织比志愿者领导的公益慈善组织运营成本更高，这是一个事实。

总结

开发者们分享代码自从有软件开始就已形成默认的习惯，有了互联网之后，更是如虎得翼，加速了这个分享的过程。也就是说，信息的高速公路最大化了软件开发的协作。那么开源项目想要获得更大的发展和增长，那么就需要较为正式的治理和法律框架，从而让商业公司能够放心的进行参与，为开源项目及其共同体的发展做出进一步的努力。

基于自由开放源码之下的协作软件开发，持续地让开发者们提升自己的生产能力、为公司的产品加速了上市时间、最重要的还为用户提供不可估量的价值。开源软件基金会是自由/开源软件生态系统中重要的部分。基金会提供了一种简单、优雅的机制，通过这种机制，企业等组织可以为自由/开源软件共同体做出贡献，基金会通过提供一个完全中立的协作空间，让所有人参与开发自己的项目，同时降低法律风险;为每个开发人员和各种规模的项目提供了一个安全的避风港。

也许最为重要的是，基金会可以确保共同体的健康成长，并持续的为共同体提供支持，一个开源软件项目的成败取决于它的提交者（commiter）。提交者是他们自身项目的真实领导者，也把控者项目的方向，提交者发起一款软件，也要对软件的规程和质量负责。而基金会则提供了组织架构、治理方式、以及知识产权管理，让提交者们能够专心的去专注于项目本身、以及共同体的状态，因为项目总是需要更多的开发者和用户的，而且更为重要的是，能够让其它公司的参与免去了后顾之忧。基金会通过提供一个持有软件财产的实体来鼓励共同体的发展，进而确保没有一个人或实体可以持有知识产权来限制项目的发展。 另外，加入一个已经成了很久的基金会，相比于自己去从零开始建立一个基金会，可以让公司和项目节省很多的成本，因为基金会也不是那么说建就建的，需要大量的专业知识和必要的努力，才能保证一个基金会的成功。

关于作者

Paula Hunter

Outercurve Foundation 执行董事，Hunter 具有令人信服的行业洞察力、高管级别的商业头脑和与非盈利组织合作的经验。在加入 Outercurve Foundation 之前，亨特曾担任搜索引擎营销专业组织SEMPO的运营总监，该组织是一个非盈利的专业协会，致力于提高全球搜索引擎营销的知名度和价值。在加入SEMPO之前，Hunter是开源开发实验室（OSDL）的全球营销和业务开发总监，她在推动行业倡导组织的成员增长方面发挥了重要作用，并领导了提高行业意识的活动，并通过OSDL项目吸引大型企业IT组织。此前，亨特是 United Linux的总经理，这是一家合资企业，旨在创建一个统一的Linux产品。她的职业生涯始于DEC，在那里她管理 DEC 的UNIX工作站和PC产品线的营销程序。亨特在宾利大学获得计算机信息系统学士学位。

Stephen Walli

Outercurve Foundation 的技术总监，Walli 自1980年以来一直在IT行业工作，既是客户又是供应商。他最近是软件业务开发和开源策略方面的顾问。其客户包括微软、Eclipse 基金会、Linux基金会等，他同时也是 Ohloh (被BlackDuck收购)、Bitrock、Continuent和eBox的顾问。Walli 算是中国的老朋友了，他在2007年在北京举办的软件创新峰会上组织、演讲、赞助了首个开源软件分论坛。Stephen 是 Optaros 的开源开发战略副总裁，微软开源业务经理，他曾是 softway Systems 的副总裁兼创始人，softway Systems是一家由风投支持的公司，在被微软收购之前，该公司开发了一个 UNIX 可移植性环境，用于NT，该环境使用免费和开源软件，并与微软授权的Windows软件相结合。

参考文献

  1. Apache 发展时间轴（超级短）http://www.apache.org/history/timeline.html
  2. Apache 许可证 http://www.apache.org/licenses/
  3. Weinberg, Bill. 2005年在硅谷用户组上的分享： http://www.svlug.org/prev/2005jun/OSDL_Overview_SVLUG.pdf
  4. 关于自由标准小组的介绍：http://www.linfo.org/free_standards_group.html
  5. Walli, Stephen R. 撰写的博客，关于OSDL 和 FSG 合并 http://stephesblog.blogs.com/my_weblog/2007/01/jim_zemlin_repe.html
  6. http://www.eclipse.org/org/
  7. http://www.irs.gov/charities/charitable/article/0,,id=96099,00.html , http://www.irs.gov/charities/nonprofits/article/0,,id=96107,00.html
  8. Apache是如何工作的
  9. http://www.linuxfoundation.org/programs
  10. http://www.linuxfoundation.org/about/bylaws
  11. Henrik Ingo 研究了开源的规模，并总结了一些内容，然后发布到了网站上：http://openlife.cc/blogs/2010/november/how-grow-your-open-source-project-10x-and-revenues-5x (2020.3.3 访问有效）
  12. 先是 Sun公司 http://blogs.the451group.com/opensource/2008/05/07/mysql-licensing-redux/
  13. 然后是 Oracle http://www.infoworld.com/t/dbms/oracle-eliminate-budget-plans-in-mysql-license-hike-323
  14. http://arstechnica.com/business/2011/09/oracle-may-fork-itself-with-recent-mysql-moves/
  15. http://www.eclipse.org/legal/cpl-v10.html
  16. 通用公共许可证（GPL)简史：http://en.wikipedia.org/wiki/GNU_General_Public_License
  17. Outercurve Project Proposal requirements: http://www.outercurve.org/About/ProjectProposal （死链. 2020.3.1）