原文：A Brief History of Open Source Software, Part 2: OSS Licenses and Legalities   
作者：Andy Updegrove，编译：御坂弟弟

可以毫不夸张地说，开源软件的魔力既基于法律创新，也基于合作。事实上，启动自由软件和开源软件的重要创新并不是 Richard Stallman 的 GNU 项目，而是他宣布了一种革命性的新的许可理念，以及将这种理念付诸实施所需的实际许可协议。直到后来，全球开发者之间的合作才在 Stallman 的许可证、Linus Torvald 在创建分布式开发过程中的开创性工作以及迅速增加的电信带宽的推动下爆发。

本文接下来将将探讨 Stallman 的理念是如何传播和分叉的，以及今天它将我们带向何处。

与 FOSS 相关的法律理论、协议和文档都太复杂了，在这类文章中无法进行更多的浅显探讨。就目前而言，掌握 FOSS 法律术语的深刻知识不如深入了解为什么 FOSS 的法律问题如此重要。

门槛事实和原则

除非首先了解一些重要的事实，否则开源软件和法律的相互作用就会显得非常混乱：

• 通常没有一个实体拥有 FOSS 产品。 出于部分历史和部分意识形态的原因，在大多数项目中，每个贡献了一行代码的开发者都会保留这一行的所有权。因此，任何一个 FOSS 都可能有许多作者 —— 有时，就像 Linux 内核一样，甚至有成千上万的作者。由于成功的 FOSS 在不断地改进和修正，作者和他们的贡献也在不断地变化。当你获得一个 FOSS 授权时，你不是从一个授权者那里获得授权，而是从许多人那里获得授权。
• 建立一个发行版需要一个村庄。FOSS 有很多大大小小的部件：文本编辑器、库、编程语言、界面等等。因为可用的 FOSS 的存储量越来越大，而且没有理由不断地重新发明轮子，所以一个 FOSS 应用程序或操作系统很可能包括许多从其他项目借来的模块和组件，以及由项目开发的软件，而这个项目的名字主要与 FOSS 有关。顺便说一句，许多专有软件包也是如此，这种做法将在下面讨论。
• 岩石、纸、剪刀。 由于这种 "村庄" 软件的异质性，一个 FOSS 项目纯粹从技术上进行的选择很可能导致最终的软件包中包含了根据不同的许可证协议开发的模块。因此，必须注意确保与最终软件包的组成部分有关的所有许可证都是兼容的，这可能会在开发项目结束时造成两难的局面，除非在开发过程中遵循良好的法律习惯。对于专有软件供应商来说，问题更为严重，他们不仅要确保能够向客户提供所有必要的法律权利，而且要避免包含可能要求他们以类似的许可条款许可整个产品的版权许可代码。
• 这不仅仅是钱的问题。下文讨论的版权许可包括一些条款，旨在保护喜欢这种许可的开发者的强烈个人信仰。因此，这些许可证包含的规则在起源和效果上既是哲学上的，也是经济上的。
• 新瓶装旧酒。虽然自由软件许可证的某些部分与它们的专有类似物非常相似，并为类似的目的而被包括在内（例如，担保免责声明的语言），但其他部分则试实现新的结果，往往使用律师以前不熟悉的语言。这类许可向法官提出了新的解释问题，到目前为止，并不是所有的问题都得到了解答。在这些问题得到解决的地方，都是在各个司法管辖区的孤立的法院里。因此，对于一些 FOSS，特别是版权许可，可能在一段时间内还无法达成 "既定法律"。
• 不仅仅是一个许可证。因为任何一个开源软件都可能有许多作者，每个人都保留着自己代码的所有权，所以在每个开发者和他们所参与的项目之间签订贡献协议或 "原产地证书"（或类似的标题）文件是很重要的，以确保项目提供的软件的被许可人真正拥有使用该软件的权利。由于许多产品的贡献者可能与他们的雇主签订了与项目所需的权利不一致的协议，因此收集这些权利的过程就变得很复杂。
• 这通常都是关于版权的问题。虽然有些许可证（如 GPL 2.0 和 GPL 3.0）包括一些与专利有关的条款，或试图影响与专利有关的行为，但与开源软件有关的贡献协议和发行许可证往往主要涉及版权和商标权。相比之下，两个商业实体之间的专有软件许可总是会给予被许可人与所有者拥有或控制的任何专利有关的明确权利。这种二分法的部分原因是，那些为 FOSS 项目贡献代码的人可能并不了解或控制所有可能因使用他们贡献的代码而被侵犯的专利权（他们的雇主也可能不了解）。如果被许可人后来被起诉侵权，他们也没有经济能力或愿意支付赔偿。由于这些原因，从代码库下载的 FOSS 应被视为 "按原样" 提供。然而，从实际情况来看，由于市场上对此类程序主张专利的禁忌已经形成，流行的 FOSS 产品的用户可能不必担心。当用户获得一个 FOSS 程序的商业发行版（如 Linux）的许可时，他们很可能会比使用非商业发行版得到更大的保护，因为软件供应商通常会向其客户提供与专有软件供应商相同的保证和赔偿保护。

可以看出，启动和维护一个成功的开源软件项目，以及发布和使用其成果，都是在一个相当复杂的法律环境中进行的。在已经启动的数千个 FOSS 项目中（特别是在早期），有些项目对法律上的小细节关注相对较少，而这些小细节可以减少以后使用其工作产品的问题。然而，现在，开源软件开发的最佳做法和支持性法律文件已经广泛存在，包括下面讨论的每一个伞状组织，因此，代码维护不慎的情况越来越少。

允许性许可证和版权许可证

第一批可识别为 "开源" 许可证的许可证确实非常简单，重点在于被许可人可以做什么，而不是他不能做什么。普遍认为所有开源许可证的共同祖先是 BSD 许可证的原始版本，其条款只说了一句话："你可以随意使用，但要让人们知道这段代码的来源 —— 不要起诉我们"。因此，BSD 许可证以及随后的多种类似变体被称为 "允许" 许可证。

在允许性许可下提供越来越有价值的代码，有两个可预见的结果：一是人们会使用这些代码，二是其中一些人会利用这些代码来赚钱。这让一些开发者很恼火，尤其是麻省理工学院人工智能中心的一位名叫 Richard Stallman 的程序员，他发誓要为此做点什么。Stallman 所做的是将他的信念编入他所谓的自由软件定义中，然后制作一个许可证，对此类软件的再利用施加条件，以符合该定义及其所代表的软件社区价值。其结果是一种新的许可证 —— GNU 通用公共许可证，或称 GPL。GPL 的目的是对用户施加义务，以保证被许可人创建的任何修改都能在符合自由软件定义的条件下使用，主要是要求被许可人发布源代码和二进制代码，并禁止被许可人添加任何会颠覆开发者自由的限制性条件。

Stallman 给实现这些目标中比较创新的条款取名为 "copyleft"。由于包含 copyleft 条款的许可证限制被许可人只能在符合原始许可证条款的许可证条件下发布其修改后的作品，这类协议有时被称为 "限制性 "许可证。

GPL 的演变

GPL 的第一个版本是以 GNU 项目组件程序所使用的前期许可证为基础的，它允许多个开源软件程序更容易地结合起来。它在 1989 年被首次使用，并在 1991 年进行了修订，当时增加了一个用于软件库的更宽松的许可证。该许可证最初被称为 "图书馆通用公共许可证"（Library General Public License），或 LGPL（开始时是第 2 版，而不是第 1 版，以便与新版本的 GPL 相匹配，与之协调），后来改名为 "有限通用公共许可证"（Limited General Public License）。

从第一版到第二版 GPL 的主要变化是增加了一个更广泛、更自由的法律义务，Stallman 称其为 "自由或死亡"（Liberty or Death） 条款，目的是阻止任何可能限制其被许可人的自由的行为。

GPL 的第三个（也是当前的）版本直到 2007 年 3 月才发布，经过了漫长而费力的讨论、公众评论和多个讨论稿。旷日持久的过程有几个原因，反映了在 GPL 下发布的自由软件的商业价值在不断增加（最值得注意的是，Linus Torvalds 已经将 Linux 内核从早期的允许性许可转为 GPL 2.0）。它的目的也是为了阻止某些被 Stallman 和其他人认为是反社区的新兴商业行为，而 GPL 2.0 的条款并没有禁止这些行为。导致 GPL 第三版最终获得批准的原因主要是就大量有争议的修改和目标达成共识。包括律师和非律师，总共超过 130 人，分成四个委员会，来进行这些讨论。

其结果是一个受到许多人称赞的许可证，但并不是所有的人都认为它适合所有的情况。因此，GPL 3.0 并没有在所有项目中取代以前的版本，许多新项目继续采用 GPL 2.0 许可证。许多先前存在的项目仍然采用 GPL 2.0，在某些情况下是由于后勤方面的困难（例如，无法追踪到不再活跃的程序员，他们对所包含的贡献拥有版权）。

GPL 许可证系列在很多方面都是独一无二的，其中最重要的是它作为法律文件的标志性地位，同时也是采用它的人之间的社会契约。其结果是，任何对 GPL 的法律挑战都将被视为对整个全球自由软件开发者社区的攻击。由于许多商业利益集团和他们的客户都非常依赖受 GPL 约束的自由软件，所以 GPL 在法律上享有某种特权地位。也许主要是由于这个原因，当这样一个创新和广泛使用的许可证被引入市场时，GPL 许可证吸引了比通常预期的更少的法律挑战。

允许性许可证的演变

随着时间的推移，一些 FOSS 的贡献者和用户开始担心，最初非常简短的允许性许可证（如 BSD 和 MIT 许可证）可能会被理解为只传达版权许可，而不是关于使用贡献的代码会侵犯专利要求的承诺。因此，2004 年，Apache 基金会用一份更长、更详细的协议取代了当时的类似 BSD 的许可证，该协议解决了几个明显的改进点，其中之一是明确许可使用贡献者拥有的专利权所涵盖的发明。Apache 基金会还采用了补充的个人和企业贡献者许可协议。这些协议由使用 Apache 2.0 许可的项目的代码贡献者签署，以向项目确认下游开发者和用户将拥有 Apache 2.0 许可协议中列举的版权和专利权。截至本文撰写之时，Apache 2.0 许可证协议是第三大使用的 FOSS 许可证。

其他许可证

目前有 60 多种 FOSS 许可证得到 OSI（Open Source Initiative）的承认。当开源软件刚出现时，新的项目创始人有时会对前者的许可证进行修改，从而形成了从最初的 BSD 使用条款发展而来的进化型许可证树。Sun Microsystem、微软和其他公司提出了他们自己的 FOSS 许可证，各种非盈利基金会也是如此，包括 Apache、Eclipse 和 Mozilla 基金会。甚至政府，如欧盟委员会，也创造了独特的变体。在 Richard Stallman 的自由软件基金会和其他地方，GPL 也经历了同样的过程，专有厂商特别喜欢在 FOSS 主题上制作自己的变体。通常情况下，产生新许可证的厂商或项目会将其提交给 OSI 批准，并将其列入 OSI 批准许可证的主列表。

随着时间的推移，这棵进化的许可证树上的许多分支都枯萎了，导致一些早期的许可证变得很少使用（它们很少被新的项目选择，而且最初使用它们的项目可能已经转移到其他许可证上）。今天，人们普遍承认，OSI 认可的许可证数量较多，差异太小，超过了必要的数量。因此，今天绝大多数项目只用少数几种许可证来许可其代码。

但是，这些早期许可证的代码仍然在使用中。遗憾的是，一些软件开发者对他们从软件库中提取并添加到自己的程序中的软件条款没有给予足够的关注（或根本没有关注）。其结果可能是软件产品中包含了许多甚至几十种不同的、经常不兼容的许可证。令人欣慰的是，为了应对大量的许可证，人们创建了有用的分类法，以便让项目更容易决定哪些许可证代码可以适当地纳入他们的代码库，哪些不应该。

开源实践

 虽然 FOSS 的目标是直接的，但法律问题并非如此。将多种来源的代码合并到开源软件和专有产品中，在商业（如代码污染）和法律（误解特定许可证条款的目的）两方面都给不小心的人制造了许多陷阱。

GPL（第二版和第三版）特别注重实现各种重要的，有时是微妙的法律和商业目标，这些条款背后的社会契约要素与严格的法律条款同样重要。断定一种特定类型的行为是 "合法的"，而忽略了这种行为在 FOSS 世界中可能被认为是合法的方式，可能会导致不受欢迎的社区后果，而不一定是法律后果。

最后，如前所述，法院在制定与这些新许可证有关的决定时，可供参考的案例法还很少。由于这些原因，任何在 FOSS 领域开展业务的人，以及他们的法律顾问，都应该在过深地卷入其中之前，花时间了解新出现的理论和法律。

相关阅读

• 开源软件简史（一）
• 开源软件简史（三）：如今的 FOSS 环境