> For the complete documentation index, see [llms.txt](https://book.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://book.bsdcn.org/articles/wei-shen-me-yao-wei-kai-yuan-xiang-mu-xuan-yong-lei-bsd-xu-ke-zheng.md). # 为什么要为开源项目选用类 BSD 许可证？ * 原文：[Why you should use a BSD style license for your Open Source Project](https://docs.freebsd.org/en/articles/bsdl-gpl/) ## 1. 引言 本文主张使用 BSD 风格的许可证用于软件和数据，特别推荐用 BSD 风格许可证来取代 GPL。你也可以将其看作是 BSD 与 GPL 开源许可证的介绍和总结。 ## 2. 开源简史 早在“开源”一词被提出之前，软件就由松散的程序员团队开发并自由交换。自 1950 年代初期，像 [SHARE](http://www.share.org/) 和 [DECUS](http://www.decus.org/) 这样的组织开发了许多计算机硬件公司与硬件捆绑的程序。在那个时代，计算机公司主要从事硬件业务；所有能降低软件成本并提供更多程序的方式，都能让硬件公司更具竞争力。 这种模式在 1960 年代发生了变化。1965 年，ADR 开发了第一款独立于硬件公司之外的授权软件产品。ADR 与原由 IBM 客户开发的免费 IBM 软件包竞争。1968 年，ADR 对其软件进行了专利保护。为了阻止软件共享，他们通过设备租赁的方式提供软件，租赁付款按产品生命周期分期支付。ADR 保留了所有权并控制转售和再利用。 1969 年，美国司法部指控 IBM 通过将免费软件与 IBM 硬件捆绑，摧毁了其他企业。作为诉讼的结果，IBM 解除了其软件捆绑，即软件变成了与硬件分离的独立产品。 1968 年，Informatics 推出了第一款商业“杀手级应用”，并迅速确立了软件产品、软件公司以及非常高的回报率的概念。Informatics 开发了现在在计算机行业中标准化的永久许可证，客户永远无法获得所有权。 ## 3. 从 BSD 许可证的角度看 Unix 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 磁带。 1980 年代中期，美国政府对 AT\&T 提起了反垄断诉讼，最终导致了 AT\&T 的拆分。AT\&T 仍然持有 Unix，并且现在可以将其出售。AT\&T 开始进行积极的许可工作，许多当时的商业 Unix 都源自 AT\&T。 1990 年代初，AT\&T 因与 BSD 相关的许可侵权问题起诉了加州大学伯克利分校。伯克利分校发现 AT\&T 在未进行承认或支付的情况下，将 BSD 的许多改进全面引入到了 AT\&T 的产品中，随之而来的是一场长期的诉讼，主要在 AT\&T 和伯克利分校之间进行。在此期间，一些伯克利分校的程序员开始重新编写与 BSD 相关的 AT\&T 代码。这一项目最终形成了一款名为 BSD 4.4-lite 的系统（因为它不是一个完整的系统，缺少了 6 个关键的 AT\&T 文件）。 稍后，《Dr. Dobbs》杂志上发布了一系列文章，介绍了一款基于 BSD 的 386 PC 版本的 Unix，它使用了 BSD 许可证下的替代文件来替代 4.4 lite 中缺失的 6 个文件。这个名为 386BSD 的系统由前伯克利分校程序员 William Jolitz 开发，成为了今天所有 PC BSD 系统的原始基石。 1990 年代中期，Novell 收购了 AT\&T 的 Unix 权利，并达成了一个（当时保密的）协议来终止诉讼。加州大学伯克利分校随后终止了对 BSD 的支持。 ## 4. FreeBSD 及 BSD 许可证的当前状态 近年来，FreeBSD 所采用的所谓 [新 BSD 许可证](http://www.opensource.org/licenses/bsd-license.php) 实际上声明，你可以对程序或其源代码做任何事情，但你不享有任何担保，且任何作者都不承担任何责任（基本上，你无法起诉任何人）。这种新 BSD 许可证旨在鼓励产品商业化。所有 BSD 代码都可以在不受任何代码可用性或未来行为限制的情况下，出售或包含在专有产品中。 不要将新 BSD 许可证与“公共领域”混淆。尽管公共领域的内容也是供所有人自由使用，但它没有所有者。 ## 5. GPL 的起源 在 1980 年代末至 1990 年代初，Unix 的未来变得非常模糊时，GPL（另一项重要的许可证发展）最终得以实现。 Richard Stallman（Emacs 的开发者）是麻省理工学院（MIT）的一名员工，当时他的实验室从自家开发的系统转向了专有系统。Stallman 在发现自己无法合法地对该系统进行一些小的改进时感到不满。（Stallman 的许多同事离开后，成立了两家公司，这些公司基于 MIT 开发的软件并获得 MIT 的许可；这似乎是因为对这些软件源代码的访问存在分歧）。Stallman 设计了一种替代商业软件许可证的方式，并称之为 GPL（“GNU 公共许可证”）。他还成立了一家非营利组织——[自由软件基金会](http://www.fsf.org/)（FSF），该基金会旨在开发一款完整的操作系统及其所有相关软件，且不受专有许可证的约束。这个系统被称为 GNU，意为“GNU 不是 Unix”。 GPL 被设计为标准专有许可证的对立面。为此，对 GPL 程序所做的任何修改都必须回馈给 GPL 社区（要求该程序的源代码对用户可用），任何使用或链接到 GPL 代码的程序也必须使用 GPL 许可证。GPL 旨在防止软件变成专有软件。正如 GPL 的最后一段所说： “这款通用公共许可证不允许将你的程序合并到专有程序中。”[\[1\]](https://docs.freebsd.org/en/articles/bsdl-gpl/#one) [GPL](http://www.opensource.org/licenses/gpl-license.php) 是一款复杂的许可证，以下是使用 GPL 时的一些经验法则： * 你可以对软件的分发、支持或文档编写收取任意费用，但不能出售软件本身。 * 经验法则指出，如果编译程序需要 GPL 源代码，则该程序必须遵循 GPL。静态链接到 GPL 库的程序必须遵循 GPL。 * GPL 要求与 GPL 软件相关的任何专利必须为所有人免费使用。 * 简单地将软件聚合在一起，例如将多个程序放在同一磁盘上，并不算是将 GPL 程序包含在非 GPL 程序中。 * 程序的输出不算作衍生作品。这使得 gcc 编译器可以在商业环境中使用，而不会遇到法律问题。 * 由于 Linux 内核是 GPL 许可的，任何与 Linux 内核静态链接的代码必须也遵循 GPL。这个要求可以通过动态链接可加载的内核模块来规避。这允许公司分发二进制驱动程序，但通常有一个缺点，即这些驱动程序只能在特定版本的 Linux 内核上运行。 部分由于其复杂性，今天在许多国家/地区，有关 Linux 和相关软件的 GPL 法律问题已被忽视。其长期后果尚不明确。 ## 6. Linux 的起源与 LGPL 在商业 Unix 战争激烈进行时，Linux 内核作为一款 PC Unix 克隆系统被开发出来。Linus Torvalds 将 Linux 的存在归功于 GNU C 编译器及相关的 GNU 工具。他将 Linux 内核发布为 GPL。 请记住，GPL 要求任何与 GPL 代码静态链接的内容也必须遵守 GPL。因此，该程序的源代码必须提供给用户。然而，动态链接并不被认为是 GPL 的违反行为。将专有应用程序放到 Linux 上的压力变得越来越大。这些应用程序通常需要与系统库进行链接。这导致了 GPL 的修改版本，即 [LGPL](http://www.opensource.org/licenses/lgpl-license.php)（“Library”，现已更名为“Lesser”GPL）。LGPL 允许专有代码与 GNU C 库（glibc）进行链接。你不必发布与 LGPL 库动态链接的源代码。 如果你将应用程序与 glibc 静态链接，例如嵌入式系统中常常需要的那样，你不能将你的应用程序保持专有，也就是说，源代码必须发布。GPL 和 LGPL 都要求对直接在许可证下的代码进行的任何修改都必须发布。 ## 7. 开源许可证与孤儿问题 专有软件相关的严重问题之一是“孤儿”（orphaning）。这发生在单一的商业失败或产品策略变化导致一大批依赖的系统和公司因超出其控制的原因而失败。数十年的经验表明，软件供应商的瞬时规模或成功并不能保证其软件始终可用，因为当前市场条件和策略可以迅速变化。 GPL 尝试通过切断与专有知识产权的联系来防止孤儿问题。 BSD 许可证为小公司提供了类似软件托管的效果，而没有任何法律复杂性或成本。如果一款 BSD 许可证的软件变成孤儿，企业可以简单地以专有方式接管他们所依赖的程序。更理想的情况是，当 BSD 代码库由一家小型非正式的联盟维护时，因为开发过程不依赖于单一公司或产品线的生存。当开发团队精神状态处于最佳时，其生存能力远比源代码的物理可用性更为重要。 ## 8. 许可证无法做到的事情 没有任何许可证能够保证软件的未来可用性。尽管版权持有者通常可以随时更改版权的条款，但在 BSD 社区中，假设这种尝试会导致源代码复刻。 GPL 明确禁止撤销许可证。然而，确实发生过公司（Mattel）购买了 GPL 版权（cphack），撤销了整个版权，诉诸法院并获胜 [\[2\]](https://docs.freebsd.org/en/articles/bsdl-gpl/#two)。也就是说，他们合法地撤销了整个分发和所有基于该版权的衍生作品。这种情况是否会在更大规模和更分散的分发中发生仍然是个开放的问题；关于软件是否真的是 GPL 许可下的问题也存在一些混淆。 在另一个例子中，Red Hat 收购了 Cygnus，这是一家接管了 FSF 编译器工具开发的工程公司。Cygnus 能够做到这一点，因为他们发展了一个商业模式，在这个模式下，他们为 GNU 软件提供支持。这样他们能够雇佣大约 50 名工程师，并通过贡献大量修改来推动程序的发展方向。正如 Donald Rosenberg 所说：“使用像 GPL 这样的许可证的项目……长期处于被他人通过更快发布改进版代码来接管项目的威胁之下。” [\[3\]](https://docs.freebsd.org/en/articles/bsdl-gpl/#three) ## 9. GPL 的优缺点 使用 GPL 的常见原因之一是在修改或扩展 gcc 编译器时。这尤其适用于在定制专用 CPU 环境中工作，在这些环境中，所有软件成本可能都被视为开销，并且对其他人使用所产生的编译器的期望很低。 GPL 对于小公司销售 CD 的环境也非常有吸引力，尤其是在“低买高卖”的情况下，最终用户可能会获得非常廉价的产品。它对于那些预期通过为 GPL 知识产权世界提供各种形式的技术支持（包括文档）来生存的公司也很有吸引力。 GPL 的一种鲜为人知且非故意的用途是，它对那些想要打击软件公司的大公司非常有利。换句话说，GPL 非常适合用作营销武器，有可能减少整体经济效益并助长垄断行为。 对于那些希望将软件商业化并从中获利的人来说，GPL 可能会带来真正的问题。例如，GPL 增加了研究生直接成立公司以商业化其研究成果的难度，或者增加了学生在假设某个有前景的研究项目将被商业化的情况下加入公司的难度。 对于那些必须使用多个软件标准的静态链接实现的人来说，GPL 通常不是个好的许可证，因为它排除了使用专有实现标准的可能性。GPL 从而最小化了可以使用 GPL 标准构建的程序数量。GPL 旨在不提供机制来开发可以让工程师开发专有产品的标准。（这不适用于 Linux 应用程序，因为它们不进行静态链接，而是使用基于陷阱的 API。） GPL 尝试让程序员对一套不断发展的程序套件做出贡献，然后在该套件的分发和支持中进行竞争。对于许多必需的核心系统标准，这种情况并不现实，因为它们可能会在广泛变化的环境中应用，这些环境需要商业定制或与现有（非 GPL）许可证下的遗留标准集成。实时系统通常是静态链接的，因此 GPL 和 LGPL 对许多嵌入式系统公司来说，肯定是潜在问题。 GPL 是一种不管需求如何都试图将努力保持在研究和开发阶段的机制。这最大化了研究人员和开发人员的好处，而对那些希望更广泛分发的利益方则可能造成未知的成本。 GPL 旨在防止研究成果转变为专有产品。这个步骤通常被认为是传统技术转移流程中的最后一步，在最好的情况下通常也足够困难；GPL 的目的是使这个过程变得不可能。 ## 10. BSD 的优点 BSD 风格的许可证是长期研究或其他项目的好选择，尤其是当这些项目需要一个开发环境时： * 几乎零成本 * 可以长期发展 * 允许任何人保留将最终结果商业化的选择，且没有法律问题。 这一最终考量可能经常是主导因素，就像 Apache 项目决定使用该许可证时一样： “这种许可证非常适合推广实现通用服务协议的参考代码的使用。这也是我们为 Apache 团队选择它的原因之一——我们中的许多人希望看到 HTTP 存活并成为一个真正的多方标准，甚至不介意微软或 Netscape 将我们的 HTTP 引擎或代码的任何其他部分纳入他们的产品中，如果这有助于保持 HTTP 的普及……所有这些意味着，从战略上讲，项目需要保持足够的动力，参与者通过为项目贡献他们的代码来实现更大的价值，甚至是那些如果保密仍然有价值的代码。” 开发人员通常会发现 BSD 许可证有吸引力，因为它远离了法律问题，能让他们随意使用代码。相比之下，那些主要期望使用系统而不是编程的人，或者期望其他人发展代码的人，或不期望从与系统相关的工作中谋生的人（例如政府雇员），则会发现 GPL 更具吸引力，因为它强迫其他人开发的代码必须提供给他们，并且防止他们的雇主保留版权，从而可能“埋葬”或孤儿软件。如果你想迫使竞争对手帮助你，GPL 会更具吸引力。 BSD 许可证并非简单的赠与。关于 BSD 许可证，常常会有人提出“我们为什么要帮助竞争对手或让他们偷走我们的工作？”这个问题。在 BSD 许可证下，如果一家公司开始主导某个被认为是战略性产品细分的市场，其他公司可以通过最小的努力，组成一家小型联盟，旨在通过贡献竞争性的 BSD 变体重新恢复平衡，从而增加市场竞争力和公平性。这能让每家公司相信它将能够从其提供的某种优势中获利，同时也促进经济灵活性和效率。合作成员可以越快速、越容易地完成这一点，它们就会越成功。BSD 许可证本质上是一种简化的许可证，使这种行为成为可能。 GPL 的一个关键作用是，以媒体成本广泛提供一个完整且竞争力强的开源系统，是一个合理的目标。BSD 风格的许可证，结合个体自发的联盟，可以实现这一目标，而不会破坏围绕技术转移管道部署端建立的经济假设。 ## 11. 使用 BSD 许可证的具体建议 * BSD 许可证在将研究成果转化为广泛部署并对经济产生最大效益的方式方面更为优越。因此，研究资助机构（如 NSF、ONR 和 DARPA）应在资助的研究项目的初期阶段，建议采纳 BSD 风格的许可证用于软件、数据、成果和开放硬件。同时，他们还应鼓励基于已实现的开源系统和持续进行的开源项目来形成标准。 * 政府政策应尽量减少从研究到部署的成本和难度。在可能的情况下，资助应要求成果能够以有利于商业化的 BSD 风格许可证提供。 * 在许多情况下，BSD 风格许可证的长期结果更能准确反映大学研究章程中所宣称的目标，而不是那些受专有大学许可的成果（如版权或专利）。有轶事证据表明，大学通过发布研究成果并通过商业成功的校友寻求捐赠，往往能够获得更好的长期财务回报。 * 公司早已认识到，创建事实标准是一个重要的营销手段。BSD 许可证很好地胜任了这一角色，特别是当公司确实拥有独特的优势来发展系统时。该许可证对最广泛的受众具有法律吸引力，而公司的专业知识则确保了他们的控制。在某些时候，GPL 可能是创建此类标准的合适工具，尤其是在试图削弱或收购他人时。然而，GPL 会惩罚该标准的演化，因为它促进的是某款套件，而不是商业适用的标准。使用这种套件会不断引发商业化和法律问题。如果一些标准受 GPL 约束而其他标准不受其约束，可能无法混合标准。真正的技术标准不应因为非技术原因强制排除其他标准。 * 有兴趣推动一项不断发展的标准（该标准可以成为其他公司商业产品核心）的公司，应谨慎使用 GPL。无论使用何种许可证，最终的结果通常会归属于那些实际做出大部分工程更改并且最了解系统状态的人。GPL 只是给结果增加了更多的法律摩擦。 * 在开放源代码开发的公司中，大公司应意识到程序员欣赏开源，因为它使员工在换工作时仍能访问软件。一些公司将这种行为作为一种就业福利，特别是当涉及的软件不直接具有战略意义时。实际上，这是一种前期退休福利，尽管存在潜在的机会成本，但没有直接成本。鼓励员工在公司外为同行认同而工作，是公司可以提供的一个低成本、可转移的福利，几乎没有任何负面影响。 * 有软件项目易受孤儿问题困扰的小公司应尽可能使用 BSD 许可证。所有规模的公司都应考虑在对维护最小法律和组织开销的真实 BSD 风格开源项目有共同利益时，发起此类开源项目。 * 非营利组织应尽可能参与开源项目。为避免混合不同许可证代码所带来的软件工程问题，应鼓励使用 BSD 风格的许可证。尤其是与发展中国家互动的非营利组织应特别谨慎对待 GPL。在某些地区，法律的适用可能成为一项昂贵的工作，与 GPL 相比，新 BSD 许可证的简洁性可能带来相当大的优势。 ## 12. 结论 与旨在防止开源代码专有化的 GPL 不同，BSD 许可证对未来行为的限制非常少。这使得 BSD 代码可以在项目或公司需求变化时，既保持开源，也可以整合到商业解决方案中。换句话说，BSD 许可证在开发过程中不会变成法律定时炸弹。 此外，由于 BSD 许可证不具备 GPL 或 LGPL 许可证的法律复杂性，它使得开发者和公司可以将时间用于创建和推广优质代码，而不是担心该代码是否违反了许可条款。 ## 参考文献 * \[1] * \[2] * \[3] 《开源：未授权的白皮书》，Donald K. Rosenberg，IDG Books，2000。引用自第 114 页，“GNU GPL 的影响”。 * \[4] 在 的“选择使用什么许可证？”部分 本文是原文的浓缩版本，原文可在 获取。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://book.bsdcn.org/articles/wei-shen-me-yao-wei-kai-yuan-xiang-mu-xuan-yong-lei-bsd-xu-ke-zheng.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.