本文为软件和数据使用 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 开发了永久许可证的概念，这种许可证现在已经成为计算机行业的标准，即所有权永远不会转移到客户手上。
拥有最初的 Unix 实现，AT&T 是一家在反垄断法庭上被束缚的公共监管垄断公司；从法律上讲，它无法将产品销售到软件市场。然而，它可以将其提供给学术机构，售价为媒体费用。
大学在一个操作系统会议宣传其可用性后迅速采用了 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 因与 UCB 相关的 BSD 许可违规问题起诉了 UCB。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，其中包括用于替换缺失的 4.4 lite 文件的 BSD 许可文件。这个系统叫做 386BSD，由前 UCB 程序员 William Jolitz 开发。它成为了今天所有 PC BSD 的原始基础。
1990 年代中期，Novell 购买了 AT&T 的 Unix 权利，并达成了一项（当时保密的）协议来终止诉讼。 UCB 很快终止了对 BSD 的支持。
在过去几年里，适用于 FreeBSD 的所谓的新 BSD 许可证实际上是一个声明，你可以对程序或其源代码进行任何操作，但是你没有任何保修，作者也没有任何责任（基本上，你不能起诉任何人）。这个新的 BSD 许可证旨在促进产品商业化。任何 BSD 代码都可以自由出售或包含在专有产品中，对你的代码或你将来的行为不受任何限制。
不要将新的 BSD 许可证与“公有领域”混淆。虽然公有领域中的项目也可供所有人免费使用，但它没有所有者。
尽管 20 世纪 80 年代末和 90 年代初的 Unix 的未来曾一片混乱，但 GPL，另一个具有重要许可考虑因素的发展成果浮出水面。
Emacs 的开发者 Richard Stallman，当他的实验室从自制系统转向专有系统时，曾是麻省理工学院的一员。当 Stallman 发现自己无法合法地对系统进行微小改进时，他感到不满（Stallman 的许多同事已经离开，成立了两家基于麻省理工学院开发的软件并由麻省理工学院授权的公司；对于这些软件的源代码访问存在分歧）。Stallman 设计了一种替代商业软件许可证，称之为 GPL，即“GNU 公共许可证”。他还成立了一个非营利基金会，自由软件基金会（FSF），旨在开发一个完整的操作系统，包括所有相关软件，不受专有许可证的约束。这个系统被称为 GNU，代表“GNU 不是 Unix”。
GPL 旨在成为标准专有许可证的对立面。为此，对 GPL 程序所做的任何修改都要求归还给 GPL 社区（要求程序的源代码对用户可用），任何使用或链接到 GPL 代码的程序都必须遵守 GPL。GPL 旨在防止软件变为专有。正如 GPL 的最后一段所述：
“本通用公共许可证不允许将你的程序合并到专有程序中。” [1]
GPL 是一个复杂的许可证，因此在使用 GPL 时有一些经验法则：
你可以为分发、支持或文档化软件收取任意费用，但不能出售软件本身。
经验法则规定，如果编译程序需要 GPL 源代码，则该程序必须遵循 GPL。静态链接到 GPL 库需要程序遵循 GPL。
GPL 要求与 GPL 软件相关联的任何专利必须为所有人的免费使用许可。
简单地聚合软件，就像将多个程序放在一个磁盘上一样，不算将 GPL 软件包含在非 GPL 软件中。
程序的输出不算是衍生作品。这使得 gcc 编译器可以在商业环境中使用而不会出现法律问题。
由于 Linux 内核受 GPL 许可，任何与 Linux 内核静态链接的代码必须遵循 GPL。这一要求可以通过动态链接可加载内核模块来规避。这使得公司可以分发二进制驱动程序，但往往缺点是它们只能用于特定版本的 Linux 内核。
由于其复杂性的部分原因，如今世界许多地方对于 Linux 及相关软件的 GPL 法律要求被忽视。这样做的长期影响尚不清楚。
在商业 Unix 战争激烈的时候，Linux 内核作为 PC Unix 的克隆版本开发出来。Linus Torvalds 归功于 GNU C 编译器及相关的 GNU 工具的存在才有了 Linux。他将 Linux 内核置于 GPL 下。
请记住，GPL 要求任何静态链接到 GPL 下任何代码的东西也必须放置在 GPL 下。因此，此代码的源代码必须提供给程序的用户。然而，动态链接不被视为 GPL 的违规行为。将专有应用程序放在 Linux 上的压力变得无法抗拒。这些应用程序通常必须与系统库链接。这导致了 GPL 的修改版本，称为 LGPL（"Library"，后来更名为 "Lesser"，GPL）。LGPL 允许专有代码链接到 GNU C 库，glibc。你不必发布已经动态链接到 LGPL 库的源代码。
如果你将应用程序与 glibc 静态链接，如在嵌入式系统中经常需要的那样，你不能保留你的应用程序的专有性，也就是说，源代码必须发布。GPL 和 LGPL 都要求对直接受许可证约束的代码进行的任何修改都必须发布。
私有软件面临的一个严重问题是所谓的“孤儿问题”。 当单个商业失败或产品策略变化导致依赖系统和公司的巨大金字塔迎来不可控制的失败时，便会出现这种情况。 几十年的经验表明，软件供应商瞬间的规模或成功并不保证其软件将继续可用，因为当前的市场条件和策略可能会迅速变化。
GPL 试图通过切断与专有知识产权的联系来防止孤儿问题。
BSD 许可证为一家小公司提供了等同于不带任何法律复杂性或成本的软件押金。如果一个采用 BSD 许可的程序变得成了孤立的，一家公司可以简单地以专有方式接管其所依赖的程序。当 BSD 代码库由一个小的非正式财团维护时，情况会更好，因为开发过程并不依赖于单个公司或产品线的生存。在开发团队在心理上处于状态良好时，其生存能力比简单的源代码的物理可用性更重要。
没有任何许可证能够保证未来的软件可用性。尽管传统上版权所有者可以随时更改版权条款，但在 BSD 社区中的假设是这样的尝试会导致源代码复刻。
GPL 明确禁止吊销许可证。然而，发生过这样的情况，一家公司（Mattel）购买了 GPL 版权（cphack），吊销了整个版权，起诉并获胜[2]。也就是说，他们在法律上吊销了整个发布以及所有基于该版权的衍生作品。对于更大规模和更广泛分布的发布是否会出现这种情况是一个尚未解决的问题；关于该软件是否真正受 GPL 协议保护也存在一些混淆。
在另一个例子中，红帽公司收购了 Cygnus，一个接管自由软件基金会编译器工具开发的工程公司。Cygnus 之所以能够这样做，是因为他们制定了一个商业模式，为 GNU 软件提供支持。这使得他们能够雇佣约 50 名工程师，并通过贡献大部分修改内容来引导程序的发展方向。正如唐纳德·罗森伯格所说“使用 GPL 等许可证的项目……一直面临着有人通过生产比原所有者更好、更快的代码版本来接管项目的持续威胁。”[3]
使用 GPL 的一个常见原因是修改或扩展 gcc 编译器。当在环境中使用一次性特殊 CPU 且所有软件成本可能被视为开销时，这是特别合适的，且很少期望他人使用生成的编译器。
GPL 对于在销售 CD 的小公司也具有吸引力，在这种环境中，“低买高卖”仍然可能为最终用户提供非常廉价的产品。对于那些期望通过为 GPL 知识产权世界提供各种形式的技术支持（包括文档）来生存的公司，GPL 也很有吸引力。
GPL 的一个较不被宣传且未预期的用途是，它非常有利于想要削弱软件公司实力的大公司。换句话说，GPL 非常适合用作营销武器，有可能减少总体经济效益，并促成垄断行为。
GPL 对于那些希望商业化和从软件中获利的人可能会带来真正的问题。例如，GPL 增加了研究生直接成立公司以商业化他的研究成果或学生加入公司并假设一个有前途的研究项目将被商业化的困难。
对于那些必须使用多个软件标准的静态链接实现的人来说，GPL 通常不是一个好的许可证，因为它排斥了使用标准的专有实现。因此，GPL 最小化了可以使用 GPL 标准构建的程序数量。GPL 的初衷并不是为了提供一种开发用于工程专有产品的标准的机制。（这不适用于 Linux 应用程序，因为它们不是静态链接，而是使用基于陷阱的 API。）
GPL 试图让程序员为一套不断发展的程序做出贡献，然后在这套程序的分发和支持上竞争。这种情况对于许多需要的核心系统标准来说是不现实的，这些标准可能被应用在需要商业定制或与现有（非 GPL）许可证下的遗留标准集成的各种环境中。实时系统通常是静态链接的，因此对许多嵌入式系统公司来说，GPL 和 LGPL 肯定被视为潜在问题。
GPL 是一种试图在研究和开发阶段保持努力的许可协议。这最大程度地使研究人员和开发人员受益，但对那些希望获得更广泛分发的人来说成本是未知的。
GPL 旨在阻止研究结果过渡到专有产品。这一步通常被认为是传统技术转移管道中的最后一步，在最理想的情况下已经足够困难；GPL 旨在使这一步变得不可能。
BSD 风格许可证是长期研究或需要开发环境的其他项目的一个很好的选择：
成本接近 0
将在很长一段时间内发展
允许所有人在最小化法律问题的情况下保留商业化最终结果的选择。
这最终考虑可能经常是主导因素，就像 Apache 项目在决定其许可证时那样：
这种许可证非常适合推广实现常见服务协议的代码参考体系的使用。这也是我们选择 Apache 组的另一个原因 - 我们中的许多人希望看到 HTTP 得以生存并成为真正的多方标准，并且如果微软或网景选择将我们的 HTTP 引擎或我们代码的任何其他组件纳入其产品以帮助实现保持 HTTP 通用的目标，我们一点也不介意……所有这些都意味着，从战略角度来看，项目需要保持足够的动力，并且参与者通过向项目贡献其代码实现更大价值，即使这些代码如果保持专有也会有价值。
开发人员倾向于认为 BSD 许可证很有吸引力，因为它可以将法律问题排除在外，让他们可以随心所欲地处理代码。相比之下，那些主要期望使用系统而不是编程它的人，或者期望他人演进代码的人，或者不指望通过与系统相关的工作谋生（比如政府雇员），会觉得 GPL 很有吸引力，因为它强制要求他人开发的代码必须提供给他们，并阻止雇主保留版权，从而潜在地“埋藏”或使软件变成孤儿。如果你想强迫你的竞争对手帮助你，GPL 就很有吸引力。
BSD 许可证并不仅仅是一份礼物。关于 BSD 许可证，经常会出现这样的问题：“为什么我们要帮助我们的竞争对手或让他们窃取我们的工作？”在 BSD 许可证下，如果一家公司主导了其他公司认为战略性的产品领域，其他公司可以通过最小的努力组成一个小型联盟，旨在通过为竞争性的 BSD 衍生做出贡献来恢复平衡，从而增加市场竞争和公平性。这使得每家公司都相信自己将能够从自己提供的某种优势中获利，同时也有助于经济的灵活性和效率。合作成员能够更快速、更轻松地做到这一点，他们就会更加成功。BSD 许可证本质上是一种最简单的许可证，可以实现这种行为。
GPL 的一个关键效果是，在媒体成本的代价下，使得一个完整且具有竞争力的开源系统广泛可用，这是一个合理的目标。BSD 风格的许可证，与个人的临时联盟结合起来，可以在不破坏围绕技术转移管道部署端的经济假设的情况下实现这一目标。
BSD 许可证在传输研究结果方面是首选，能够广泛部署并最大程度地造福经济。因此，诸如 NSF、ONR 和 DARPA 等研究资助机构应该在资助研究项目的最早阶段鼓励采用 BSD 风格许可证，用于软件、数据、结果和开放硬件。他们还应该鼓励基于已实施的开源系统和正在进行的开源项目的标准形成。
政府政策应该将从研究到部署的成本和困难最小化。在可能的情况下，资助应该要求结果在商业化友好的 BSD 风格许可证下可用。
在许多情况下，BSD 风格许可证的长期结果更准确地反映了大学研究章程中宣称的目标，而不是当结果被版权和专利保护并受专有大学许可管理时所发生的情况。有传闻证据表明，大学通过发布研究结果，然后向商业成功的校友捐赠而从长远来看获得了更好的经济回报。
公司长期以来已经意识到，创造事实上的标准是一种关键的营销技巧。如果一家公司在演变系统方面真正具有独特优势，则 BSD 许可证非常适合扮演这一角色。许可证对最广泛的受众具有法律吸引力，而公司的专业知识确保了他们的控制。在试图创建这样的标准时，GPL 有时可能是适当的工具，特别是在试图破坏或利用其他公司时。然而，GPL 惩罚了该标准的演变，因为它促使了一套而不是一个商业适用的标准。使用这样的一套标准不断引起商业化和法律问题。当一些标准受 GPL 管辖而另一些标准则不受时，可能无法混合标准。真正的技术标准不应该因非技术原因而排斥其他标准。
有意推广不断演进的标准，并成为其他公司商业产品核心的公司应该警惕 GPL。无论使用何种许可证，最终的软件通常会轮回给实际进行大部分工程变更并最了解系统状态的人。GPL 只是给结果增加了更多的法律摩擦。
大公司，在其中开发开源代码的情况下，应意识到程序员欣赏开源，因为当他们更换雇主时，软件仍然可供员工使用。一些公司鼓励这种行为作为一种就业福利，特别是当涉及的软件并非直接战略性时。实际上，这是一种前期提供的退休福利，可能会带来机会成本的损失，但没有直接成本。鼓励员工在公司外为同行赞誉而工作是公司有时可以提供的一种廉价便携福利，几乎没有负面影响。
对于软件项目容易被遗弃的小公司，应尽可能使用 BSD 许可证。各种规模的公司在维护与真正的 BSD 风格开源项目相关的最低法律和组织开支时，应考虑组建这样的开源项目，这对它们互惠互利是有利的。
非营利组织应尽可能参与开源项目。为了最小化软件工程问题，如混合不同许可证下的代码，应鼓励采用 BSD 风格的许可证。对于与发展中国家互动的非营利组织，对 GPL 持谨慎态度尤为重要。在一些法律适用变得成本高昂的地方，与 GPL 相比，新 BSD 许可证的简单性可能具有相当大的优势。
与 GPL 相反，其旨在防止对开源代码进行专有商业化，BSD 许可协议对未来行为施加了最小的限制。这使得 BSD 代码可以保持开源状态或成为商业解决方案的一部分，随着项目或公司需求的变化。换句话说，BSD 许可证在开发过程的任何阶段都不会成为法律定时炸弹。
另外，由于 BSD 许可证没有 GPL 或 LGPL 许可证的法律复杂性，它允许开发人员和公司花费时间创建和推广优秀的代码，而不是担心代码是否违反许可证。
[3] 开源：未经授权的白皮书，唐纳德·K·罗森伯格，IDG 图书，2000 年。引文来自第 114 页，“GNU GPL 的影响”。
[4] 在 http://www.oreilly.com/catalog/opensources/book/brian.html 的“使用哪个许可证？”部分
这份白皮书是原始作品的一份精简版本，原作品可在 http://alumni.cse.ucsc.edu/~brucem/open_source_license.htm 获取。