为什么你应该为你的开源项目使用 BSD 风格的许可证

本文档论证了为软件和数据使用 BSD 风格许可证的理由；具体来说，它建议使用 BSD 风格许可证代替 GPL。它也可以被视为 BSD 与 GPL 开源许可证的介绍和总结。

早在“开源”一词被使用之前，软件就已经由松散的程序员协会开发并自由交换。从 20 世纪 50 年代初开始，SHARE 和 DECUS 等组织开发了许多计算机硬件公司与其硬件产品捆绑在一起的软件。当时，计算机公司从事的是硬件业务；任何降低软件成本并提供更多程序的事情都会使硬件公司更具竞争力。

这种模式在 20 世纪 60 年代发生了变化。1965 年，ADR 开发了第一个独立于硬件公司的许可软件产品。ADR 当时正在与一个最初由 IBM 客户开发的免费 IBM 软件包竞争。ADR 于 1968 年为其软件申请了专利。为了阻止其程序的共享，他们以设备租赁的形式提供它，其中付款分摊在产品的整个生命周期内。因此，ADR 保留了所有权，可以控制转售和再利用。

1969 年，美国司法部指控 IBM 通过将免费软件与 IBM 硬件捆绑在一起来破坏企业。由于此诉讼，IBM 取消了其软件的捆绑；也就是说，软件成为独立于硬件的独立产品。

1968 年，Informatics 推出了第一个商业杀手级应用程序，并迅速确立了软件产品、软件公司和非常高的回报率的概念。Informatics 开发了现在整个计算机行业通用的永久许可证，其中所有权永远不会转移给客户。

AT&T 拥有最初的 Unix 实现，是一家受公共监管的垄断企业，陷入反垄断诉讼；它在法律上无法将产品销售到软件市场。但是，它能够以媒体成本的价格将其提供给学术机构。

在一个操作系统会议宣传了 Unix 的可用性后，大学迅速采用了 Unix。Unix 能够运行在 PDP-11 上，这是一台非常经济的 16 位计算机，并且是用一种对系统编程明显有效的高级语言编写的，这一点非常有帮助。DEC PDP-11 实际上具有一个开放的硬件接口，旨在方便客户编写自己的操作系统，这很常见。正如 DEC 创始人 Ken Olsen 所著名宣称的那样，“当你拥有良好的硬件时，软件来自天堂”。

Unix 作者 Ken Thompson 于 1975 年回到他的母校加州大学伯克利分校 (UCB)，并逐行教授内核。这最终导致了一个被称为 BSD（伯克利标准发行版）的不断发展的系统。UCB 将 Unix 转换为 32 位，添加了虚拟内存，并实现了互联网基本上构建在其上的 TCP/IP 协议栈版本。UCB 以媒体成本的价格提供了 BSD，并在当时被称为“BSD 许可证”的许可下提供。客户从 AT&T 购买 Unix，然后从 UCB 订购 BSD 磁带。

在 20 世纪 80 年代中期，针对 AT&T 的政府反垄断案件以 AT&T 的分拆告终。AT&T 仍然拥有 Unix，现在能够销售它。AT&T 开始积极开展许可工作，当时大多数商业 Unix 成为 AT&T 派生的。

在 20 世纪 90 年代初，AT&T 起诉 UCB 违反与 BSD 相关的许可证。UCB 发现 AT&T 未经认可或支付，将其产品中许多由于 BSD 而产生的改进纳入了 AT&T 的产品，并随之产生了一场漫长的诉讼，主要发生在 AT&T 和 UCB 之间。在此期间，一些 UCB 程序员开始了一个项目，以重写与 BSD 相关的任何 AT&T 代码。该项目产生了一个名为 BSD 4.4-lite 的系统（lite 因为它不是一个完整的系统；它缺少 6 个关键的 AT&T 文件）。

稍后在 Dr. Dobbs 杂志上发表的一系列长篇报道描述了一个基于 BSD 的 386 PC 版 Unix，其中包含用于 6 个缺少的 4.4 lite 文件的 BSD 许可的替换文件。这个名为 386BSD 的系统是由前 UCB 程序员 William Jolitz 开发的。它成为今天所有 PC BSD 的最初基础。

在 20 世纪 90 年代中期，Novell 收购了 AT&T 的 Unix 权利，并达成了一项（当时保密）协议以终止诉讼。UCB 很快终止了对 BSD 的支持。

所谓的新 BSD 许可证在过去几年中应用于 FreeBSD，实际上是一个声明，您可以对程序或其源代码做任何事情，但您没有任何保证，并且任何作者都不承担任何责任（基本上，您不能起诉任何人）。这种新的 BSD 许可证旨在鼓励产品商业化。任何 BSD 代码都可以出售或包含在专有产品中，而不对您代码的可用性或您未来的行为施加任何限制。

不要将新的 BSD 许可证与“公共领域”混淆。虽然公共领域中的项目也可以免费供所有人使用，但它没有所有者。

当 Unix 的未来在 20 世纪 80 年代末和 90 年代初变得如此混乱时，GPL 这一具有重要许可证考虑因素的另一项发展也取得了成果。

Emacs 的开发者 Richard Stallman 是麻省理工学院 (MIT) 的工作人员，当时他的实验室从自制系统切换到专有系统。当 Stallman 发现自己无法合法地为该系统添加小的改进时，他感到不安。（Stallman 的许多同事已离开成立了两家公司，这两家公司基于在 MIT 开发并由 MIT 许可的软件；在访问此软件的源代码方面似乎存在分歧）。Stallman 设计了一种商业软件许可证的替代方案，并将其称为 GPL 或“GNU 通用公共许可证”。他还成立了一个非营利基金会，即自由软件基金会 (FSF)，该基金会旨在开发一个完整的操作系统，包括所有相关软件，这些软件不会受到专有许可证的约束。该系统称为 GNU，代表“GNU is Not Unix”。

GPL 被设计为标准专有许可证的对立面。为此，对 GPL 程序所做的任何修改都必须返还给 GPL 社区（通过要求程序的源代码对用户可用），并且任何使用或链接到 GPL 代码的程序都必须在 GPL 下。GPL 的目的是防止软件变成专有软件。正如 GPL 的最后一段所述

“本通用公共许可证不允许将您的程序合并到专有程序中。”[1]

由于GPL是一个复杂的许可证，因此在使用 GPL 时，以下是一些经验法则

部分由于其复杂性，如今在世界许多地方，人们在涉及 Linux 和相关软件时都忽略了 GPL 的法律规定。这带来的长期后果尚不清楚。

在商业 Unix 战争肆虐的同时，Linux 内核作为 PC Unix 克隆而开发。Linus Torvalds 将 Linux 内核的存在归功于 GNU C 编译器和相关 GNU 工具的存在。他将 Linux 内核置于 GPL 下。

请记住，GPL 要求任何静态链接到任何 GPL 代码下的代码也必须放在 GPL 下。因此，此代码的源代码必须对程序用户可用。但是，动态链接不被视为违反 GPL。将专有应用程序放在 Linux 上的压力变得势不可挡。此类应用程序通常必须链接到系统库。这导致了 GPL 的修改版本，称为LGPL（“库”，后来更名为“较小”，GPL）。LGPL 允许专有代码链接到 GNU C 库，glibc。您不必发布已动态链接到 LGPLed 库的源代码。

如果您将应用程序与 glibc 静态链接，例如嵌入式系统中通常需要的那样，则您不能使您的应用程序成为专有的，也就是说，必须发布源代码。GPL 和 LGPL 都要求发布对直接在许可证下的代码所做的任何修改。

专有软件带来的一个严重问题被称为“孤立”（orphaning）。当一家企业的失败或产品策略的改变导致大量依赖其系统的企业和公司也随之失败时，就会发生这种情况，而这些失败的原因却超出了它们的控制范围。数十年的经验表明，软件供应商的规模或当时的成功并不能保证其软件的持续可用性，因为当前的市场状况和策略可能迅速发生变化。

GPL 试图通过切断与专有知识产权的联系来防止软件孤立。

BSD 许可证为小型公司提供了相当于软件托管的权益，而无需任何法律纠纷或成本。如果一个获得 BSD 许可证的程序被孤立了，那么一家公司可以简单地以专有的方式接管他们所依赖的程序。当一个 BSD 代码库由一个小型非正式联盟维护时，情况会更好，因为开发过程不依赖于单个公司或产品线的生存。开发团队处于最佳状态时的生存能力比源代码的简单物理可用性更为重要。

任何许可证都不能保证软件的未来可用性。尽管版权持有者传统上可以随时更改版权条款，但 BSD 社区的假设是，此类尝试只会导致源代码分叉。

GPL 明确禁止撤销许可证。然而，曾经发生过一家公司（美泰）购买了 GPL 版权（cphack），撤销了所有版权，并诉诸法院并胜诉[2]。也就是说，他们合法地撤销了所有基于该版权的发布和衍生作品。这种做法是否适用于更大规模、更分散的发布尚是一个悬而未决的问题；关于该软件是否真正属于 GPL 也存在一些混淆。

在另一个例子中，红帽收购了 Cygnus，这是一家工程公司，它接管了 FSF 编译器工具的开发。Cygnus 能够做到这一点，因为他们开发了一种商业模式，即销售 GNU 软件的支持服务。这使他们能够雇用大约 50 名工程师，并通过贡献大部分修改来推动程序的发展方向。正如唐纳德·罗森伯格所说，“使用 GPL 等许可证的项目……一直面临着有人通过更快地制作更好的代码版本来接管项目的威胁。” [3]

使用 GPL 的一个常见原因是在修改或扩展 gcc 编译器时。当在所有软件成本都可能被视为间接费用、并且很少期望其他人使用生成的编译器的环境中使用一次性专用 CPU 时，这一点尤其适用。

GPL 对销售 CD 的小型公司也很有吸引力，在这些公司中，“低买高卖”仍然可以为最终用户提供非常廉价的产品。对于那些期望通过提供各种形式的技术支持（包括文档）来维持生存的公司来说，它也很有吸引力，这些技术支持针对的是 GPL 许可的知识产权世界。

GPL 的一个鲜为人知且意外的用途是，它对希望削弱软件公司的那些大型公司非常有利。换句话说，GPL 非常适合用作营销武器，可能会降低整体经济效益并助长垄断行为。

对于那些希望将软件商业化并从中获利的人来说，GPL 可能会带来真正的问题。例如，GPL 增加了研究生直接成立公司将其研究成果商业化，或学生在加入一家公司时假设一个有前景的研究项目将被商业化的难度。

对于必须使用多个软件标准的静态链接实现的人来说，GPL 通常是一个糟糕的许可证，因为它排除了使用标准的专有实现。因此，GPL 减少了可以使用 GPL 许可的标准构建的程序数量。GPL 的本意不是提供一种机制来开发一个可以构建专有产品的标准。（这并不适用于 Linux 应用程序，因为它们不使用静态链接，而是使用基于陷阱的 API。）

GPL 试图让程序员为不断发展的程序套件做出贡献，然后在这个套件的发布和支持方面展开竞争。对于许多必需的核心系统标准来说，这种情况是不现实的，这些标准可能应用于各种不同的环境，这些环境需要商业定制或与现有（非 GPL）许可证下的遗留标准集成。实时系统通常是静态链接的，因此 GPL 和 LGPL 绝对被许多嵌入式系统公司视为潜在问题。

GPL 试图将工作（无论需求如何）都保持在研究和开发阶段。这最大限度地提高了研究人员和开发人员的利益，但对那些将从更广泛的发布中受益的人来说，其成本尚不清楚。

GPL 的设计目的是防止研究成果转变为专有产品。这一步通常被认为是传统技术转移管道中的最后一步，而且在最佳情况下通常也足够困难；GPL 的本意是让它变得不可能。

对于需要一个开发环境的长期研究或其他项目，BSD 风格的许可证是一个不错的选择，该开发环境

最后一点考虑因素通常是最主要的考虑因素，就像 Apache 项目决定其许可证时一样。

“这种类型的许可证非常适合促进使用实现通用服务协议的代码参考库。这是我们选择它作为 Apache 项目的另一个原因——我们中的许多人希望看到 HTTP 能够生存并成为一个真正的多方标准，并且如果微软或 Netscape 选择将我们的 HTTP 引擎或我们代码的任何其他组件整合到他们的产品中，我们一点也不介意，如果这有助于实现保持 HTTP 通用性的目标……所有这一切都意味着，从战略上讲，该项目需要保持足够的势头，并且参与者通过将他们的代码贡献给该项目来实现更大的价值，即使是如果保留为专有代码也会有价值的代码。”

开发人员倾向于发现 BSD 许可证很有吸引力，因为它消除了法律问题，并让他们可以随意处理代码。相比之下，那些主要期望使用系统而不是对其进行编程、期望其他人改进代码或不期望从与系统相关的工作中谋生（例如政府雇员）的人，会发现 GPL 很有吸引力，因为它迫使其他人开发的代码被赋予他们，并防止他们的雇主保留版权，从而可能“掩埋”或孤立软件。如果你想迫使你的竞争对手帮助你，GPL 很有吸引力。

BSD 许可证不仅仅是一份礼物。在与 BSD 许可证相关的讨论中，经常会提出“我们为什么要帮助我们的竞争对手或让他们窃取我们的成果？”的问题。根据 BSD 许可证，如果一家公司在其他公司认为具有战略意义的产品领域占据主导地位，那么其他公司可以毫不费力地组建一个小型联盟，旨在通过为竞争对手的 BSD 变体做出贡献来重新建立平等竞争，从而增加市场竞争和公平性。这使得每家公司都相信，他们将能够从他们所能提供的某些优势中获利，同时也有助于提高经济灵活性和效率。合作成员能够越快、越容易地做到这一点，他们就会越成功。BSD 许可证本质上是一个尽可能简单的许可证，它能够实现这种行为。

GPL 的一个关键影响是，使一个完整且具有竞争力的开源系统以媒体成本广泛可用，这是一个合理的目标。BSD 风格的许可证，结合个人的临时联盟，可以实现这一目标，而不会破坏围绕技术转移管道部署端构建的经济假设。

与旨在防止开源代码专有商业化的 GPL 相比，BSD 许可证对未来行为施加的限制最少。这允许 BSD 代码保持开源或集成到商业解决方案中，因为项目的或公司的需求会发生变化。换句话说，BSD 许可证在开发过程中的任何阶段都不会成为法律上的定时炸弹。

此外，由于 BSD 许可证没有 GPL 或 LGPL 许可证的法律复杂性，因此它允许开发人员和公司将时间花在创建和推广好的代码上，而不是担心该代码是否违反了许可。

本白皮书是对原始作品的浓缩，原始作品可在 http://alumni.cse.ucsc.edu/~brucem/open_source_license.htm 获取